1. 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. 2 Requirements Workflow

3. 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. 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. 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. 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. 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. 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. 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. 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. 11 Overview of Use Case Diagram

12. 12 Use Case Relationships

13. 13 Use Case Relationship

14. 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. 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. 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. 17 Workflow for Capturing Requirements

18. 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. 19 Identify Use Case and Actors

20. 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. 21 Detailing Use Cases

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

25. 25

26. 26 Activity: Prioritize Use Cases Determine which use cases to be developed in early iterations Captured in architectural view of the use case model Used for project planning

27. 27 Detailed Specification of Use Case Use case defines the states that its instances may enter and possible transitions (sequence of actions) between the states Structuring use case using basic and alternative paths Naturally viewed as state-transitions

28. 28 Example: Pay Invoice Use Case Precondition: The buyer has received the goods/services ordered and at least one invoice from the system. The buyer now plans to schedule the invoice(s) for payment. Flow of Events: Basic Path: 1. The buyer invokes the use case by beginning to browse the invoices received by the system. The system checks that the content of each invoice is consistent with order confirmation received earlier (as part of the Confirmation Order) and somehow indicate this to the buyer. The order confirmation describes which items will be delivered, when, where, and at what price. 2. The buyer decides to schedule an invoice for payment by the bank, and the system generate a payment request to transfer money to seller’s account. Notice that the buyer cannot schedule the same invoice for payment twice.

29. 29 Continued... 3. Later, if there is enough money in the buyer’s account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer’s account to the seller’s account, as described by (abstract) use case Perform Transaction (which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collects a fee for the transaction, which is withdrawn from the buyer’s account by the system. 4. The use case instance terminates. Alternative Paths: 1) In S2, the buyer may instead ask the system to send an invoice rejection back to the seller. 2) in S3, if there is no enough money in the account, the use case will cancel the payment and notify the buyer. Postcondition : The use case instance ends when the invoice has been paid or when the invoice payment was cancelled and no money was transferred.

30. 30 Necessary Elements of Use Case Description Define start state as precondition How and when the use case starts (S1) Order actions are performed How and when the use case ends (S4) Path of execution not allowed (S2) Alternative path descriptions that are inlined in the basic path description (S3 is performed only if … Other alternative path descriptions Interactions between actors and systems (S2 &3) Usage of objects, values and resources in the system (S3) Explicitly describe what actors and the system do (define system boundary)

31. 31 Non functional Requirement When a buyer issues an invoice for payment, the system should respond with a verification of the request within 1.0 second in 90% of the cases. The time for the verification must never exceed 10.0 seconds, unless the network connection is broken (in which case the user should be notified). Use case descriptions are finished when they are understandable, complete and consistent!

32. 32 Formalizing Use Case Descriptions More formal and structure mechanisms to handle complexity Startchart diagrams to describe state-transitions of the use cases Activity diagrams to describe the transitions between states in more detailed action sequences Interaction diagrams to describe how an instance of use case interact with an instance of an actor

33. 33 Example: Pay Invoice

34. 34 Review Identify actors Identify use cases Brief description of use cases Put them together Refine use cases Detailed description of use cases Check completeness and consistency

35. 35 Activity: Prototype User Interface Creating a logical UI design –Creating UI for each actor Which UI elements are needed to enable the use cases (that are relevant to the actor) How should they be related to each other How will they be used in different use cases What should they look like How should they be manipulated

36. 36 Prototype UI Identify UI elements –which of the domain classes, business entities, or work units are suitable as UI elements for the use case –What UI elements does the actor work with? (often these are terms from the glossary, e.g. account balance, due date, etc.) –What actions can the actor invoke; what decisions can actor make –What guidance and information does the actor need before invoking each action in the use case –What information does the actor need to supply to the system –What information does the system need to supply to the actor –What are average values for all I/O parameters, e.g. how many invoices will an actor normally deal with

37. 37 Example: Pay Invoice UI elements: Invoice (amount, due date,…) Additional information: Account

38. 38 Prototype UI Creating Physical UI Design and Prototype –creating UI sketch –validating UI design allow for proper navigation consistent look and feel complies with relevant standards –rapid prototyping executable UI

39. 39 Activity: Structure Use Case Model Goal: A more consistent and concise description Identify shared description of functionality and perform generalization if proper

40. 40 Structure Use Case Model Identify additional and operational descriptions of functionality Identify other relationships between use cases

41. 41