Transcript Overview of Requirements Engineering Activities

Use-Case Modeling:
Overview and Context
SE 555 Software Requirements &
Specification
1
Essential SE Process
The Software Engineering Process transforms conceptual
application models into detailed solution models
Application
Domain
Conceptual Models
Transform
Formal Models
• Problem space
• Customer-speak
From Bruce I. Blum, Software
Engineering - a Holistic View
• Solution space
• Developer-speak
• Computer-speak
• programming languages
• systems languages
SE 555 Software Requirements &
Specification
Implementation
Domain
• Run-time space
• Computer-speak
• binary
2
Each Discipline Contributes a
Particular Set of Models
(and other Artifacts)
SE 555 Software Requirements &
Specification
3
Model Characteristics
Transform Models
Requirements
• Feature lists
• Domain
models
• Use cases
• Customer
language
• External view
Analysis
Design
Implementation
• Unambiguous • Physical
• Implement
models
• Technologies details (source,
• Consistent use and “-ilities”
scripts,
cases
• Many
binaries,
• Developer
abstractions, executables,
language
subsystems,
etc.)
• Internal view
interfaces
• Distribute
• Sets solution • Detailed
executable
architecture
• Formal
components
• Conceptual
across
• Informal models
computing
• Few
nodes
abstractions,
• Unit test
subsystems,
interfaces
SE 555 Software Requirements &
Specification
Test
• Test cases,
procedures,
components
• Integration and
system tests
• Feed results
back into
process
4


Model (specify) requirements as use
cases
In requirements analysis, model usecase realizations
Model an interaction of objects that
realize the requirements
 Class diagrams and object interaction
diagrams

SE 555 Software Requirements &
Specification
5
What is a Use Case?
[from the UML 2.0 Superstructure Specification]



A use case is the specification of a set of actions performed by a
system, which yields an observable result that is, typically, of value
for one or more actors or other stakeholders of the system.
Use cases are a means for specifying required usages of a system

Typically, use cases are used to capture the requirements of a
system, that is, what a system is supposed to do
The key concepts associated with use cases are actors, use cases,
and the subject

The subject is the system under consideration to which the use
cases apply

The users and any other systems that may interact with the
subject are represented as actors
 Actors always model entities that are outside the system

The required behavior of the subject is specified by one or more
use cases, which are defined according to the needs of actors
SE 555 Software Requirements &
Specification
6
Use Cases Capture Requirements

Use cases capture system functional
requirements

They tell a story of how someone may use the
system


Each way the actors use the system is
represented by a use case


When an actor (user or external subsystem) uses the
system, the system performs a use case
Chunks of functionality the system offers to add an
observable result of value to its actors
All use cases = all the things the system must do
SE 555 Software Requirements &
Specification
7
Use Cases Capture Requirements

Use cases capture the intended behavior of the
system


System behavior is how a system acts and reacts



Ways an external user (human or machine) interact with a
system
The outwardly visible and testable activity of a system
Use cases describe the system, its environment, and
the relationship between the system and its
environment
For many non-interactive systems (batch processes,
data warehousing, infrastructure management, etc.),
there may be few use cases with complex use-case
descriptions
SE 555 Software Requirements &
Specification
8
NASA
Integrated Technical
Standards System
Create/Modify Document
<<extend>>
Example UseCase Diagram
Document Author
or Adopter
<<extend>>
Publish Document
Notify of New/Changed Document
Find Document
Standards User
External Document System
<<extend>>
Retrieve Document
Administer System
Administrator
(Standards Program Office)
View Metrics and Reports
External System
Data Exchange/Web Site Launch
SE 555 Software Requirements &
Specification
9
Use-Case Realization
Use Case
Use-Case Realization
Class
diagram
Use
Cases
Sequence
diagram
DocumentList
FileMgr
Document
add( )
delete( )
fetchDoc( )
sortByName( )
<<trace>>
name : int
docid : int
numField : int
get( )
open( )
close( )
read( )
sortFileList( )
create( )
fillDocument( )
FileList
fList
read() fill the
code..
add( )
delete( )
1
rep
Repository
(from Persistence)
File
read( )
GrpFile
name : char * = 0
readDoc( )
readFile( )

read( )
open( )
create( )
fillFile( )
A use-case realization is a description
of how a particular use case is
realized within the design model, in
terms of collaborating objects
SE 555 Software Requirements &
Specification
Collaboration
diagram
10
Major Concepts in Use-Case Modeling

An actor represents anything that interacts with
the system
<<Actor>>
Actor
Actor

A use case is a sequence of actions a system
performs that yields an observable result of value
to a particular actor
UseCase
UseCase
SE 555 Software Requirements &
Specification
11
Use-Case Diagram

A use-case diagram
shows relationships
between actors and
use cases
Note: the system
boundary is usually
not shown
View Grades
System

Relationships:
“communicates with” Student
(exchanges data,
signals, events)
<<Actor>>
CourseCatalog
Register for Courses
Login
SE 555 Software Requirements &
Specification
12
Use-Case Model


A use-case model is more than a uc diagram
Each use-case has a specification
 Use-case name
 Relationships to actors and other use cases
 Brief description
 Start states (preconditions)
 The first action to perform
 Flow of events (often captured as a UML Activity Diagram)
 Basic/normal flow
 Alternates
 Constraints
 How the use case ends
 Possible end states (postconditions)
 Special (non-functional) requirements
SE 555 Software Requirements &
Specification
13
Advanced Use Case Concepts



Generalize: child inherits the
behavior and meaning of its
points
parent; can substitute for its Extension
- set priority
<<extend>>
parent
(set priority)
Include: the base use case
Place rush order
Place order
explicitly incorporates the
<<include>>
behavior of another use case at
a location specified in the base
<<include>>
use case; factor out common
Check password
Track order
Validate user
behavior – never stands alone
Extend: the base use case
implicitly incorporates the
Retinal scan
behavior of another use case at
a location specified indirectly by
the extending use case; optional
behavior
SE 555 Software Requirements &
Specification
14
Requirements Discipline Activities
From the Rational Unified Process
SE 555 Software Requirements &
Specification
15
Requirements Discipline in the
RUP Context
SE 555 Software Requirements &
Specification
16
Requirements
Workflow

Shown in sequence, but
performed continuously and in
varied order
 Inception phase: emphasize
understanding the problem
 Elaboration phase:
emphasize defining and
refining the system
 Construction and transition
phases: add remaining
details and manage changes
Focus on these
SE 555 Software Requirements &
Specification
17
Requirements Artifacts Overview
Focus on
these
SE 555 Software Requirements &
Specification
18
Purpose of the Requirements Discipline

To establish and maintain agreement with the customers and other
stakeholders on what the system should do

To provide system developers with a better understanding of the
system requirements

To define the boundaries of (delimit) the system

To provide a basis for planning the technical contents of iterations

To provide a basis for estimating cost and time to develop the system

To define a user-interface for the system, focusing on the needs and
goals of the users
SE 555 Software Requirements &
Specification
19
Sources:
Material © IBM Rational Software Corp.
SE 555 Software Requirements &
Specification
20