Requirements Engineering with Use Cases

Transcription

1 Requirements Engineering with Use Cases Csaba Veres Outline What are use cases? What do they tell us? How can you write them (properly)? What is a use case? A use case specifies the behavior of a system or a part of a system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to the actor Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide Capture intended behavior without specifying how the behavior is implemented Functional requirements (and non functional) Use Cases Each use case describes a set of sequences a sequence represents an interaction of the system and actors A use case carries out a tangible amount of work something of value to the actor

2 Use cases and events A use case describes what, not how Detailed behavior given by a flow of events textual how and when the use case starts and ends what objects are exchanged alternate flows Flow of events: Validate User Main Flow of Events: The use case starts when the system prompts the Customer for a PIN number. The Customer can now enter a PIN number via a keypad. The Customer commits the entry by pressing the Enter button. The system then checks this PIN to see if it is valid. If the PIN is valid, the system acknowledges the entry, thus ending this use case. Exceptional Flow of Events: The Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the Customer's account. Exceptional Flow of Events: The Customer can clear a PIN anytime before committing it and reenter a new PIN. Organizing Use Cases Organizing Use Cases... Generalization If there are different ways of doing the same basic use case Include base UC incorporates behavior of another UC the included UC never stands alone

3 e.g. Track order includes Validate User Main Flow of Events: Obtain and verify the order number. include (Validate user). For each part in the order, query its status, then report back to the user. Organizing Use Cases... Extend base UC incorporates another UC at a specified location (extension point) base UC can stand alone optional behavior Use Cases: Requirements in context A methodology for constructing use cases The Facade Iteration The Filled Iteration The Facade Iteration This is the first iteration. Creates placeholders for each major interaction Model existing system, new functionality, new system Stakeholders, each with a different view of the above users project team industry experts IT management user management owners of the data

4 Early stages Many conflicting needs Accepted vs. new ways of doing things Avoid technology centered commitments technology trap often fails to deliver required functionality User centric needs, not solutions Steps in Facade Iteration 1. Create a problem statement 2. Identify and review existing documentation and intellectual capital 3. Get the executive sponsor's unique viewpoint 4. Identify the users, the user group management, the customers being served by the user group, and the owners of the data 5. Interview the stakeholders 6. Find the actors 7. Create the Facade Use Cases 8. Start the business rules catalog 9. Create a risk analysis 10.Create a statement of work 11.Get informal approval from the executive sponsor Create a Problem Statement Review existing documentation Lead by the executive sponsor Generates awareness and support Mission statement Review all available documents/communications about the document to answer: Any elements of the proposed system already ruled out? Why were they introduced? Who does/does-not want the system? Have COTS been considered? Does upper management concern themselves with this project? How long have the proposals been around?

5 Executive sponsor's unique viewpoint What is the problem being solved? business case customer service, comply with regulations, automate existing functions, save money, etc. Why is a system required? What would happen if the system did not work? Why is a computer system required? Why is existing practice not good enough? Who will be effected by the implementation? Identify the users, the user group management, the customers being served by the user group, and the owners of the data Up to date organization chart Previous years' organization chart to show recent developments Internal and external customers Interview the stakeholders and Find the actors Individual or group interviews unstructured semi structured questionnaires Identify the Actors a preliminary analysis of the system boundary Create the Facade Use Cases A rough sketch to show the scope of the proposed product Two to three sentence descriptions Primarily text based

6 Start the Business Rules Catalog Rules about how the organisation conducts its business Do the business rules constrain any of the use cases? Business rules catalog And finally... Create a risk analysis what are the perceived problems? are there goals which might not be reached? Create a statement of work a contract that makes an agreement over who will do what, when? Get informal approval from executive sponsor summarize key goals and problems

7 Tools to help with Facade Iteration System Context Use Case High level UC for the overall function of the entire system Most valuable for eliciting requirements rather than strictly documenting them helps identify the facade use cases Text document and maybe a simple UC diagram Use Case name filters Use case names should conform to verb-noun construction: determine eligibility, trace shipment, print letter can contain adjectives or adverbs: trace late shipment should not be instances of classes should not be tied to organizational structure, paper forms, or computer implementation: enter form 104- B, complete approval window should not use weak verbs : process, complete

8 Candidate use case list Actor Filter Roles, not individuals Don't tie to existing organisational structure Noun filter Facade Filter Only the most important interactions between users and the system are documented Security, audit, backup, and recovery merely support the business Don't bother with <<extends>>, <<includes>>

9 Review and Deliverables Peer review and User reviews Deliverables Problem statement Statement of work Risk analysis Prototype Use case diagrams Use cases Business rules Not started Complete Complete Partially complete Facade level Facade level Facade level The Filled Iteration Clarify and elaborate use cases Enhance business rules Six steps 1. Break out detailed use cases 2. Create Filled use cases 3. Collect and document the nonfunctional requirements 4. Add business rules 5. Test the Filled use cases 6. Put some things off Break out Detailed Use Cases Level of granularity always difficult to judge how to split the system into functional business units? How do you split Facade level use cases? Identify the macro pieces of functionality the subjective explanation of how something works A functionality that seems to be made up of a coherent set of steps is a candidate for a use case e.g. the main steps for designing clothing might be: consultation, design sewing, fitting, alterations but consultation might divide into fitting, and price estimate Add detail to use case diagrams add extra use cases and refine the actors involved Review use case granularity does each UC provide a sufficient big picture view of its functionality? If you broke down some UCs, would they be easier to understand? Can you make them easier to work on? Can one analyst/designer work on a single use case?

10 Create Filled Use Cases Fill each use case with appropriate detail Identify triggers When does the use case start? What event starts it? active, not passive: the manager asks the developer NOT the developer is asked document who is responsible for initiating the use case e.g. the system detects a work file in the inbound processing cue Use business, not software oriented language Identify preconditions a mandatory state of the system at the inception of the use case e.g. certain data must be available a trigger won't work unless preconditions are satisfied Refine Use Case names the name describes the primary actor's objective secondary actors contribute to the use case Refine the actors Specify the Basic Course of Events for all use cases refine existing ones, and specify new ones all interactions with the system, and between actors Document exceptions alternative course of events in the use case an exception should not be almost as big as the original use case

11 Document Nonfunctional Requirements Nonfunctional requirements can be associated to use cases through stereotypes at this stage, only text is needed sometimes subtle: prevent data loss vs. backup data daily Testing with scenarios The final review should use scenarios specific course of events several different scenarios for testing exceptions, etc.

12 Deliverables Candidate use case list Use cases Partially complete Filled level Use case diagrams Filled level Business rules catalogpartially complete Scenarios Several for each use case tested