Requirements Use Cases

Transcription

1 Requirements Engineering Requirements Use Cases Software Lifecycle Activities Requirements Analysis Software Design Implementation System Engineering Computer Science Department Baylor University Evolution Deployment Testing Use Cases-1 Use Cases-2 Requirements Use Cases What is use case modeling? A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system UML Specification use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions ( use cases ) that are meaningful to users ( actors ). Use Cases-3 Use Cases-4 Use Cases in UML 2.0 Use cases are associated with subjects A subject can be a system, a subsystem in a system, or a class A use case describes interactions between users (clients) and a subject At the requirements level the subject is the system under development Use Case Modeling: Core Elements Construct Description use case actor System/sub ject boundary A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A role played by an entity that interacts with the subject (e.g., system, subsystem, class). Represents the boundary between the subject and the actors who interact with the subject. Syntax UseCaseName ActorName Use Cases-5 Use Cases-6 CSI3372 1

2 Depicting actors Use Case Diagram system boundary NextGen POS communication Customer Process Sale Handle Returns Payment Authorization Service alternate notation for a computer system actor actor Cashier «actor» Tax Calculator Manager Cash In «actor» Accounting System «actor» Sales Activity System Analyze Activity «actor» HR System Payment Authorization Service System Administrator Manage Security Manage Users... use case Use Cases-7 Use Cases-8 Use Cases as requirements Simple Use Case example Use cases can be used to capture functional requirements System attributes associated with a system operation can be documented in a use case Not all requirements can be captured by use cases System attributes that span use cases are documented as supplementary requirements Actor Inputs 1. Customer submits identification information 3. Customer submits items to be rented 5. Customer pays. System Response 2. If customer is authenticated, then request rental items 4. Display calculated price. 6. Inform customer that payments is authorized Use Cases-9 Use Cases-10 Actor types Use Case instance (scenario) Primary: actor whose goal is accomplished by the use case Supporting: actor that provides services to the system E.g., authorization service Offstage: an actor that has an interest in the use case but is not primary or supporting E.g., regulating agency A scenario is a particular sequence of actions in a use case. A use case is a related set of scenarios that yields an observable result of value to a particular actor A use case instance is an execution of a scenario. Often use case instance and scenario are used synonymously in informal discussions. Use Cases-11 Use Cases-12 CSI3372 2

3 Levels of rigor Essential vs. Concrete Use Cases Brief: One paragraph summaries of functionality Casual: Multiple paragraphs that cover multiple scenarios Fully-dressed (Detailed): Structured, detailed description of scenarios Essential Use Cases describe functionality in implementation independent terms Requirements level use cases must be essential Concrete Use Cases describe external functionality in system dependent terms Use cases can be used during design to document externally observable behavior of subsystems Use Cases-13 Use Cases-14 Requirements Use Case template Analysis Use Case template cont d Use Case Number: Use Case Name: Overview: Type: Actors: Properties: EU-xxxx : Indicates an essential use case, i.e., a use case that describes activity in system independent terms Enter name of Use Case. Describe the purpose of the Use Case and give a brief description. Enter Use Case priority (primary, secondary, optional) List all actors that participate in this Use Case. Indicate the actor that initiates the use case by placing initiator in brackets after the actor name. Also, indicate primary actors by yplacing primary in brackets after actor name. Performance: Security: Other: Pre condition: Flow: Post Condition: Cross References: Enter the condition that must be true when the main flow is initiated. This should reference the conceptual model. Main Flow: Steps should be numbered. Subflows: Break down of main flow steps Alternate Flows: Include the post condition for each alternate flow if different from the main flow. Enter the condition that must be true when the main flow is completed. This should reference the conceptual model. Include the following information in this section: References to other Use Cases or textual requirements that relate to this Use Case. Use Cases-15 Use Cases-16 Goals and Use Cases Determining Use Case scope Interactions usually take place to satisfy system goals. Identifying goals is important because it can lead to consideration of more effective alternatives. For each interaction ask why? - the answer should lead to a system goal. A use case should describe end-to-end functionality Should describe a task carried in response to an event generated by an actor that produces a result of value to a subset of its actors and leaves the system in a stable state (one in which it is not waiting for a restricted set of inputs) Use Cases-17 Use Cases-18 CSI3372 3

4 Identifying Use Cases and Actors Approaches to identifying use cases Actor-first: Identify actors first and consider the ways they interact with the system Operation-first: Identify system-level operations and then identify actors that interact with operations Event-first: Identify external events and develop use cases that handle the events Developing Use Cases Scope system and identify primary actors that interact with the system Determine goals of primary actors (can be documented in an Actor-Goal list) For each actor, consider the ways that the actor typically interacts with the system to accomplish goals Consider exceptional behaviors Use Cases-19 Use Cases-20 Use Case Exercise 1 University library system requirements Books and journals the library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current year s journals are sent away to be bound into volumes at the end of each year. Borrowing it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved. Browsing this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not,to reserve the book. Anybody can browse in the library. P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, Use Cases-21 Use Case Exercise 1 Use Case Diagram of University Library System Book Borrower Reserve book Borrow copy of book Return copy of book Extend loan Borrow journal Return journal Browse Update catalog Journal Borrower Browser Librarian Use Cases-22 Use Case Exercise 2 Use Cases Construct an essential use case that represents borrowing a copy of book from the university library in a brief level rigor. Borrow copy of book A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and that s/he does not already have a maximum permitted number of books on loan. This maximum is six unless the member is a staff member in which case it is twelve. If both checks succeed, this system records that this library member has this copy of the book on loan. Use Case Exercise 3 - Use Cases Construct essential use cases that represent returning a copy of book to the university library in each of the following three levels rigor: Brief Casual Fully-dressed Use Cases-23 Use Cases-24 CSI3372 4

5 Use Case Modeling tips Writing essential use cases: Focus on intent Keep user interface terms out Ask what is the goal? Write black-box use cases Do not describe internal operations (e.g., storing to a data base) Focus only on interactions between system and actors Ignore interactions between actors Focus on text description Use diagrams for presentation purposes only A use case diagram should contain only use cases at the same level of abstraction include only required actors How do I know I have a good use case? Use case should describe an activity that yields an observable result of value to an actor. A use case can describe an elementary business process (EBP): a sequence of tasks performed to handle a business event Use cases are typically not single steps or single low-level actions. Use Cases-25 Use Cases-26 Good use cases... are Good use cases... aren t Text No GUI No data formats 3-9 steps in main scenario Easy to read At user s goal level A record of decisions made UML use case diagrams describing the GUI describing data formats multiple-page l main scenario complicated to read at program-feature level a tutorial on the domain Use Cases-27 Use Cases-28 Use Case role in development Functional requirements are primarily recorded in essential use cases The scope of an iteration is usually expressed in terms of use case scenarios covered Use case realizations drive the design Use cases realized as collaborating objects in designs The benefits of basing software development on use cases They can help to define the scope of the system They are often used to plan the development process They can be used to both develop and validate the requirements They can form the basis for the definition of test cases They can be used to structure user manuals They can be used during requirements to prototype user interfaces and during design to design user interfaces Use Cases-29 Use Cases-30 CSI3372 5

6 Some Useful Tips User interface our task is to build the underlying system providing functionality which will be invoked through the user interface. separation between user interface and underlying system. Beware of making diagrams very complex A diagram too complex to draw by hand is probably also it too complex to think out clearly. Split into multiple diagrams; use cases at high level of abstraction. Update catalog use case: Includes all the librarian s adding and removal of books, sending away of journals etc. When this functionality is considered in detail we may want to separate these out into multiple use cases. Short descriptions of use cases Do not invent requirements! Can be useful to make a list of questions and possibilities with each use case, for discussion with the customer. Use cases must not be seen as a panacea The use cases must be validated There are some aspects of development that are not covered by use case analysis. Non-functional requirements are often not covered Functionality that is not triggered by actors is not covered E.g., auditing transactions in a banking system Do not write use cases in terms of how a system works currently! Use Cases-32 Essence of Software Development Again! correspo ondence ess correctn Requirements Statement Design Implementation ver rification validatio on Evolution of Use Cases Inception Most interesting and complex or risky use cases written in brief format 10-20% of core complex functions rewritten in fullydressed format Elaboration In each iteration, use cases are prioritized and high priority use cases are developed in fully-dressed format 80-90% completed by end of elaboration Construction Remaining (minor) use cases are developed Software Processes - 33 Use Cases-34 Relating Use Cases Use Case Modeling: Core Relationships Construct Description Syntax Specializing/generalizing use cases Including use cases Extending use cases association generalization extend include The participation of an actor in a use case. i.e., instance of an actor and instances of a use case com municate with each other. A taxonom ic relationship between a more general use case and a more specific use case. A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case augments (subject to conditions in the extension) the behavior defined for the base use case. The base use case does not depend on the extension use case. Com pare: include. a relationship from a base use case to an in c lu s io n use case, specifying how the behavior for the base use case contains the behavior defined for the inclusion use case. The base use case depends on the inclusion use case. Compare: extend. <<extend>> <<include>> Use Cases-35 Use Cases-36 CSI3372 6

7 Use Case Relationships Including Use Cases Supply Customer Data «include» «include» Order Product Place Order Arrange Payment «include» Extension points «extend» 1 * additional requests : the salesperson asks for after creation of the order the catalog A use case can include another use case at a specified location. Used to avoid writing the same flow of events across a number of use cases. The included use case must not be a stand-alone use case. Request Catalog Fig. 3-54, UML Notation Guide Use Cases-37 Use Cases-38 Extending Use Cases A use case can extend a base use case by incorporating additional behavior at specified locations of the base use case. The base use case can act as a stand-alone use case. The base use case can only be extended at specified points called extension points. Often used to separate optional behavior from mandatory behavior. Also used to model a separate flow that is executed under certain conditions. Example: Online HR System Online HR System Locate Employees Update Employee Manager Profile {if currentmonth = Oct.} Update Benefits Employee Healthcare Plan System Access Travel {readonly} System Access Pay Records Insurance Plan System Use Cases-39 Use Cases-40 Online HR System: Use Case relationships Online HR System: Update Benefits Use Case Update Medical Update Dental Update Plan Plan Insurance Plan <<include>> <<include>> <<include>> Update Benefits Extension points extension point benefit options: name and after required enrollments location Employee <<extend>> <<extend>> employee requests employee requests reimbursement option stock purchase option Elect Elect Stock Reimbursement extension Purchase for Healthcare condition Actors: employee, healthcare plan system, insurance plan system Precondition: Employee has logged on to the system and selected update benefits option Basic course 1. System displays employee account. 2. System asks employee to select medical plan type; include Update Medical Plan. 3. System asks employee to select dental plan type; include Update Dental Plan System asks user to select benefits options: benefit options 7a. Reimbursement option selected: Elect Reimbursement for Healthcare 7b. Stock option selected: Elect Stock Purchase Use Cases-41 Use Cases-42 CSI3372 7

8 Specializing Use Cases Generalizing/specializing use cases A specialized use case inherits the behavior (sequences of actions) of its parent(s). A specialized use case can override some of the behavior of its parent(s). It can also add to the behavior. A specialized use case can be used anywhere the general use case is expected. Use Cases-43 CSI3372 8