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 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