1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements...
-
Upload
silas-scott -
Category
Documents
-
view
215 -
download
2
Transcript of 1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements...
1
Capturing Requirements As Use Cases
• To be discussed– Artifacts created in the requirements workflow
– Workers participating in the requirements workflow
– Requirements capture workflow, including detailed activities
2
Requirements Workflow
3
Artifact: Use Case Model
• Allows developer and customer to agree on requirements, I.e. conditions and capabilities to which the system must conform
• A model of system containing actors and use cases and their relationships
4
Artifact: Actor
• Represents user type, external system• Each type of users may be represented by one or more actors• Often corresponds to worker in a business
– A role of a worker defines what the worker does in a particular business process
– The roles can be used to derive corresponding actors will play
• An actor plays one role in each use case
5
Use Case
• Each use case represents a way the actors use the system– A use case specifies a sequence of actions, including alternatives
of the sequence, that the system can perform
– Is a specification of the behavior of all possible instances of that use case
– E.g. withdraw money (granted, denied, different amounts, etc)
– Purpose: to define a piece of coherent behavior without revealing the internal structure of the system, hence it is not a manifest construct in the implementation of the system
– in UML term, a classifier that has operations and attributes, thus can include startchart, activity, collaboration and/or sequence diagrams
6
Use Case Instance
• Is the execution of a use case– It is one path through the use case
– An sequence of interactions between an actor instance and the use case
• Use case instance does not interact with other use case instances– only kind of interaction is between actor and use case instances
– don’t deal with interfaces between use cases, concurrency, and other conflicts (e.g. sharing of objects) between different use case instances (Note: this does not mean interference between different instances does not exist.)
• Use Case instance is atomic– either performed completely or not at all
7
Description of Use Case
• Statecharts specifies lifecycle of use case instances– each transition is a sequence of actions
• Activity diagrams describe the lifecycle in more detail by describing sequence of actions that occur within each transition
• Collaboration/sequence diagrams are used to describe between a typical actor instance and a typical use case instance
• Such “formal” description may or may not be necessary depending on the complexity of a use case
• Textual description can be used if appropriate
8
Example: Global Network Systems
• Largest system in the world, composed of systems of systems across different areas and countries
• Made of different technologies (local and international switches, land and satellite transmission systems
• Each system is a large scale one (e.g. 1000 man-years)• Main reason of success: precisely defined interfaces (both
structural and semantic)– via provide-require mechanism
– is in fact use case specification
9
Architecture Description - View of Use Case Model
• Architecture view (of use case model) describes architecturally significant use cases– use cases describing important and critical functionality
– involving important requirement that must be developed early in the software’s lifecycle
– used as input when use cases are prioritized to be developed within an iteration
• Usually corresponding use case realizations can be found in the architectural views of analysis, design models
10
Use Case Glossary
• Used to define important and common terms used in describing the system
• Useful for reaching consensus between different stakeholders regarding definition of various concepts and notions– especially important for large development effort
• Can be derived from domain or business models
11
Overview of Use Case Diagram
12
Use Case Relationships
13
Use Case Relationship
14
Worker
• Refer to a position (in a project) to which a person can be assigned, who are responsible for building the use cases
• Three types of workers:– system analyst
– use case specifier
– user interface designer
15
System Analyst
• System analyst responsible for the whole set of requirements (functional and nonfunctional) modeled as use cases – responsible for delimiting the system
– for finding actors and use cases and for defining glossary
– for ensuring that the use case model is complete and consistent
– Assisted by use case specifier and interface designer
16
Use Case Specifier and Interface Designer
• Assist system analyst• Use case specifier responsible for detailed description of one or
more use cases– need to work closely with real users
• User interface designer responsible for UI– usually one interface prototype for each use case
17
Workflow for Capturing Requirements
18
Find Use Cases and Actors
• We identify use cases and actors to:– define system boundary
– outline who and what (actors) will interact with the system and what functionality (use cases) is expected from the system
– capture and define in a glossary common terms that are essential for creating detailed descriptions of the system’s functionality
19
Identify Use Case and Actors
20
Basic Steps
• Finding the actors• Finding the use cases• Briefly describing each use case• Describing the use case model (including glossary) as a whole• Describe use cases in detail• Steps does not have to be performed in any particular order
21
Detailing Use Cases
22
Finding Actors
• If a business model known, use each worker in the business as an actor initially
• Criteria for enlisting actors– should be possible to identify at least one user who can play the
candidate actor
– minimal overlap between roles that instances of different actors play in relation to the system
• Example: – buyer, seller, accounting system (page 147)
• Brief description of actors, used as starting point for finding use cases
23
Finding Use Cases
• Interviewing or analyzing each actors to enlist candidate use cases
• Analyze, revise and combine use uses– some candidates won’t become use cases themselves, but rather
better be part of others
– choose name and define scope for the use cases
• a sequence of user-system interaction may be specified as one or more use cases
– consider if a use case is complete by itself or if it always follows as a kind of continuation of another use case.
– Guideline: a use case delivers an observable result that is of value to a particular customer
– Example: Pay Invoice use case (page 149)
24
Constructing Use Cases
• Initial brief description of use cases– Example: page 150
• Describe use case model as a whole– relationship between uses cases and actors
– model consistency: develop system glossary
– Output: survey description of the use case model (example, page 151), describing how actors and use cases interact and how use cases related to each other