1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.

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