Application Requirements Analysis

Transcription

1 Application Requirements Analysis Use Case Modeling 1 \ ch. 3 Requirements Analysis Goals The main goals are: To analyze and document what the system should do in a form that clearly communicates to the client and to the development team. To develop an initial development plan. To address the highest risk elements of the project. 2 \ ch. 3

2 Requirements Analysis Activities Define Problem Domain Concepts Develop Use Case Model Develop Conceptual Object Model Develop Initial Product Development Plan Review 3 \ ch. 3 Use Cases is the BASIC tool for SE 4 \ ch. 3

3 What are Use Cases? A use case is a single, complete unit of the system s functionality to a user. Useful to an actor (e.g., stakeholder) Actor can also be an external system or module End-to-end Described as a scenario of usage. Examples Drawing money from an ATM Sending an ICQ message 5 \ ch. 3 Use Cases A use case is a document that describes the sequence of events of an actor (an external agent) using a system to complete a process [Jacobson]. A process describes, from start to finish, a sequence of events, actions, and transactions required to produce or complete something of value to an organization or actor. Use cases are end-to-end scenarios that describe the use of a system Use Cases Model a dialogue between an actor and the system. Use cases are not exactly requirements or functional specifications, but they illustrate and imply requirements in their dialogues. The set of all use cases specifies all the defined ways the system may be used. A use case diagram illustrates a set of use cases for a system, the actors, and the relation between the actors and use cases. Actor Use Case 6 \ ch. 3

4 Classical Example - ATM Machine Main flow of events: A customer approaches an ATM Inserts ATM card Enters PIN number Selects a transaction The ATM contacts its local bank and processes the request The customer takes the results of the transaction and leaves Alternative flow of events: The Customer enters an invalid PIN Invalid message is displayed The use case restarts 7 \ ch. 3 An actor is someone or some thing that must interact with the system under development Type of Actors Main Users Secondary Users External Systems Actors Borrower Librarian Technical Support Billing System 8 \ ch. 3

5 9 \ ch \ ch. 3

6 !"# $ %" & ' 11 \ ch. 3 A use case is a pattern of behavior the system exhibits Each use case is a sequence of related transactions performed by an actor and the system in a dialogue Actors are examined to determine their needs, i.e.: User -- access the system, reads and updates the info SourceManager -- manages the sources and controls access to them TechnicalSupport -- maintains the system Type of Use Cases: Use Cases Primary - represent major common processes Secondary - represent minor or rare processes Optional - represent processes that may not be tackled Abstract - represent processes that are not activated directly by an actor Lend Item Add Title PrintReport 12 \ ch. 3

7 Goals of Use Case Modeling? Understand the system s functionality Discuss with the customer our understanding Identify system concepts, classes, attributes and operations alidate the analysis and design models Provide data for system and acceptance testing 13 \ ch. 3 Modeling Use Cases Complete piece of functionality Main flow Alternate flows Exception flows Piece of externally visible functionality Orthogonal piece of functionality Piece of functionality initiated by an actor Piece of functionality that delivers an identifiable value to an actor 14 \ ch. 3

8 Process of Use Case Modeling Use Case Modeling is an iterative process A flow of events document is created for each use case Written from an actor point of view Details what the system must provide to the actor when the use cases are executed In each phase and iteration, additional information is added and the degree of detail is increased 15 \ ch. 3 ()"* """ ) $"" "" ++ "" " 16 \ ch. 3

9 Use Case Description Each use case may include all or part of the following: Title or Reference Name Author/Date Modification/Date Purpose Overview Cross References Actors Pre Conditions Post Conditions execution normally Normal flow of events - meaningful name of the UC - the author of the UC and its creation date - last modification to the UC and its date - specifies the goal to be achieved by the UC - short description of the use cases processes - requirements references - agents which initiate or participate in the UC - must be true to allow the execution of the UC - will be set when the use use completes its - regular flow of activities of the UC Alternative flow of events - other flow of activities of the UC Exceptional flow of events - unusual situations Implementation issues implementation of the UC - possible foreseen problems in the 17 \ ch. 3 Example Withdraw Money (1) Use Case: Withdraw Money Author: Money Spender Date: 1-Aug-2001 Purpose: To withdraw some cash from user s bank account Overview: The use case starts when the customer inserts his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 amount exceeded is executed. Cross References: R1.1, R1.2, R7 18 \ ch. 3

10 Example Withdraw Money (2) Actors: Customer Pre Condition: The ATM must be in a state ready to accept transactions The ATM must have at least some cash on hand that it can dispense The ATM must have enough paper to print a receipt for at least one transaction Post Condition: The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount A receipt was printed on the withdraw amount The withdraw transaction was audit in the System log file 19 \ ch. 3 Example Withdraw Money (3) Typical Course of events: Actor Actions 1. This use case begins when a Customer arrives at ATM 2. The customer inserts its Credit card into ATM 5. The customer chooses an Withdraw operation 7. The customer enters the cash amount System Actions 3. The system verifies the customer ID and status of account 4. The system asks for an operation type 6. The system asks for the withdraw amount 8. The system checks if the withdraw amount is legal 9. The system dispense the cash 10. The system deduces the withdraw amount from the customer account 11. The system prints a receipt 13. The customer takes the cash and the receipt 12. The system ejects the cash card 20 \ ch. 3

11 Example Withdraw Money (4) Alternative flow of events: Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. Exceptional flow of events: Power failure in the process of the transaction before step 9, cancel the transaction and eject the card 21 \ ch. 3 Discovering Use Cases One method to identify use cases is actor-based: Identify the actors related to a system or organization. For each actor, identify the processes they initiate or participate in. A second method to identify use cases is event-based: Identify the external events that a system must respond to. Relate the events to actors and use cases. The following questions may be used to help identify the use cases for a system: What are tasks of each actor? Will any actor create, store, change, remove, or read information in the system? What use cases will create, store, change, remove, or read this information? Will any actor need to inform the system about sudden, external changes? Does any actor need to be informed about certain occurrences in the system? Can all functional requirements be performed by the use cases? 22 \ ch. 3

12 Use Case Considerations When you model use cases in the UML, every use case should represent some distinct and identifiable behavior of the system or part of the system. A well structured use case: Names a single, identifiable, and reasonably atomic behavior of the system or part of the system. Factors common behavior by pulling such behavior from other use cases that it includes. Factors variants by pushing such behavior into other use cases that extend it. Describes the flow of events clearly enough for an outsider to easily understand it. Is described by a minimal set of scenarios that specify the normal and variant semantics of the use case. 23 \ ch. 3 Use Case Diagrams Use case diagrams are created to visualize the relationships between actors and use cases. A Use Case diagram is a graphical view of some or all of the actors, and their interactions identified for a system. Each system typically has a Main Use Case diagram, which is a picture of the system boundary (actors). Other use cases diagrams may be created as needed. Some examples are: A diagram showing all the use cases for a selected actor A diagram showing all the use cases being implemented in a development cycle A diagram showing a use case and all its relationships 24 \ ch. 3

13 Use Case Diagram Captures system functionality as seen by users Use Case 1 Actor 1 <<actor>> objects Use Case 2 <<includes>> Use Case 3 Actor 3 protocols Actor 2 Use Case 4 Use Case 5 <<extends>> Actor 4 Etc. system boundary 25 \ ch. 3 Use Case Relationships (1) Between Actor and Use Case Association - may be navigable in both directions, according to the initiator of the communication between the actor and the use case. 26 \ ch. 3

14 Use Case Relationships (2) Between Use Cases Includes - specifies that the base UC needs an additional UC in order to fully describe its processes. It is mainly used to show common functionality that is shared by several use cases. Included UC is always necessary for the completion of the activating UC. It is described by a stereotype <<includes>>. Extends - specifies that the extended UC is an extension of the base UC, i.e. provides additional functionality. Another use case is activated occasionally at specific extension point. It is used to show: Optional behavior of a use case Behavior that is only run under certain conditions, such as triggering an alarm Several different flows which may be run based on actor selection The relation is described by a stereotype <<extends>> Generalization -The child use case inherits the behavior of its parent; the child may add to or override the behavior of its parent; and the child may be substituted any place the parent appears. 27 \ ch. 3 Generalization, Include, and Extend Place order <<extend>> (set priority) Place rush order <<include>> Check password Track order <<include>> alidate user (generalization) Retinal scan 28 \ ch. 3

15 Cellular Phone System Example Subscribe to Network M aintain System Un s ubs cr ibe from Net work < < ex tend> > U s er Place Phone Call < < inc lude> > Place Conferenc e C all A dmi nis tr ator Control Connections < < ex tend> > Receive Phone Call Receive Additional Call U s e S cheduler Cellular Phone System 29 \ ch. 3 Telemarketing Example Telemarketer Schedule and Make Next Call <<include>> Supporter Supporter Display Call Details <<extend>> <<extend>> <<extend>> Record Call Outcome Telemarketer <<extend>> <<extend>> Display Campaign Details Display Prize Details <<extend>> Update Supporter Display Supporter History Record Ticket Sale Schedule Callback 30 \ ch. 3

16 Use Case Diagram is not a Flow Chart! Place order <<extend>> (set priority) Place rush order Track order <<include>> <<include>> <<include>> alidate user (generalization) Check password Check manually Retinal scan A common mistake is to consider the use case diagram as a flow chart. In flow charts the intention is to show the functional decomposition of the process. If you must show it than use traditional methods as structure charts or pseudocode. 31 \ ch. 3 Use Case Driven Design as GUI Design The use case diagram may inspire the menu-system Close Doc Save Doc Open Doc User New Doc Edit Help File Edit Help Open New Save Save as Close 32 \ ch. 3

17 Use Cases and Scenarios A scenario is an instance of a use case - it is one path through the flow of events for the use case. Each use case is a web of scenarios - primary scenarios (which define essential sequences) and secondary scenarios (which define alternative sequences). Use cases and their scenarios can be documented either by text, state or interaction (collaboration, sequence) diagrams and oldfashioned pseudocode... They are usually represented as series of activities in top-down time sequence. 33 \ ch. 3 Scenarios Details Use case scenarios may have three degrees of detail: Exact scenario detailing a strict sequence of events. There are no alternatives, iterations or exceptions. Represents one possible execution of the use case. If there happens to be an interesting alternative, it may be listed in another scenario. Semi-algorithmic scenario Similar to the one above, but is more general, in the sense that it features alternatives, exceptions etc. The scenario adheres to one major execution path, taking into account alternatives and exceptions. Algorithmic use case minispec This is not a scenario, but a full fledged algorithm, using procedural control structures. It may be expressed by UML state or interaction (collaboration, sequence) diagrams and often with the addition of oldfashioned pseudocode. 34 \ ch. 3

18 Use Cases and Test Cases A test case is a set of test inputs, execution conditions, and expected results developed for a particular objective: to exercise a particular program path or verify compliance with a specific requirement. Use cases and their scenarios can serve as a major source to defining test cases. Three-step process for defining test cases from use cases: For each use case, generate a full set of use case scenarios For each scenario, identify at least one test case and the conditions that will make it execute For each test case, identify the data values with which to test 35 \ ch. 3 Example Register for Courses (1) Basic flow of events: Actor Actions 1. Logon - This use case begins when a Student accesses the University Web site 3. Personal Data Entry - The Student enters the ID and password 6. Select Operation - The Student chooses Create a Schedule 8. Select Courses The Student selects four primary course offerings and two alternate course offerings from the list of available course offerings 9. Submit Schedule The student indicates that the schedule is complete System Actions 2. Logon Initiation - The system asks for Student ID and password 4. Data erification - The system verifies the Student ID and password 5. Display Available Operations - The system asks for an operation type 7. Display Course Information - The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student 10. Selected Course erification - For each selected course offering the system verifies that the Student has the necessary prerequisites 11. Display Completed Schedule The system displays the schedule containing the selected course offerings for the Student and the confirmation number for the schedule 36 \ ch. 3

19 Example Register for Courses (2) Alternative flow of events: Unidentified Student In Step 1 of the, Login, if the system determines that the Student ID and/or password is not valid, an error message is displayed. Quit The Course Registration System allows the Student to quit at any time during the use case. The Student may choose to save a partial schedule before quitting. All courses that are not marked as enrolled in are marked as selected in the schedule. The schedule is saved in the system. The use case ends. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts In Step 9 of the, Submit Schedule, if the system determines that one of the above conditions exists, the system will not enroll the student in the course. A message is displayed that the Student can select a different course. The use case continues at Step 8, Select Courses, in the basic flow. Course Catalog System Unavailable In Step 7 of the, Display Course Information, if the system is down, a message is displayed and the use case ends. Course Registration Closed If, when the use case starts, it is determined that registration has been closed, a message is displayed, and the use case ends. 37 \ ch. 3 Example Register for Courses (3) Use Case Scenarios Scenario 1 Scenario 2 Alternate Flow 1 Scenario 3 Alternate Flow 1 Alternate Flow 2 Scenario 4 Alternate Flow 3 Scenario 5 Alternate Flow 3 Alternate Flow 1 Scenario 6 Alternate Flow 3 Alternate Flow 1 Alternate Flow 2 Scenario 7 Alternate Flow 4 Scenario 8 Alternate Flow 3 Alternate Flow 4 38 \ ch. 3

20 Example Register for Courses (4) Defining Test Cases Step One: Define Scenarios Scenario Name Scenario 1 Successful registration Scenario 2 Unidentified student Scenario 3 User quits Scenario 4 Course catalog system unavailable Scenario 5 Registration closed Scenario 6 Cannot enroll Starting Flow Alternate A1 A2 A4 A5 A3 39 \ ch. 3 Example Register for Courses (5) Defining Test Cases Step Two: Identify Test Cases Test Case ID Scenario/Conditi on Student ID Passw. Courses Selected Prereq. fulfilled Course Open Schedule Open Expected Result 1 Scenario 1 Succesful registration Schedule and confirmation number displayed 2 Scenario 2 unidentified student I N/A N/A N/A N/A N/A Error message; back to login screen.. 6 Scenario 6 cannot enroll course full I Error message, back to step 8 7 Scenario 6 cannot enroll prerequisite not fulfilled I Error message, back to step 8 40 \ ch. 3

21 Example Register for Courses (5) Defining Test Cases Step Three: Identify Data alues to Test Test Case ID Scenario/Conditi on Student ID Password Courses Selected Prereq. fulfilled Course Open Schedule Open Expected Result 1 Scenario 1 Succesful registration Monika Levinsky Monika123 OOP01 OOAD01 Yes Yes Yes Schedule and confirmation number displayed 2 Scenario 2 unidentified student Bill Clinton N/A N/A N/A N/A N/A Error message; back to login screen.. 6 Scenario 6 cannot enroll course full Ehud Ehud07 OOAD01 Yes I Error message, back to step 8 7 Scenario 6 cannot enroll prerequisite not fulfilled Bibi BibiSara OOAD01 No Error message, back to step 8 41 \ ch. 3,(-, " 42 \ ch. 3

22 Summary Benefits of Use Cases Provide context around requirements by expressing sequences of events Most efficient communication mechanism with end users and domain experts Identify users and system boundaries Identify system interfaces Help us concentrate on the WHAT (rather than the HOW) Reusable in test planning and user documentation Good fit for all (OO or not) design methods. 43 \ ch. 3