1. 1 Objectives  Describe design constraints.  Identify methods of specifying functional requirements.  Describe techniques for writing and structuring use cases.  Detail the use case flows.  Flows of Events  Pre- and postconditions  Use case structure  Specify nonfunctional requirements.  Usability, Reliability, Performance, Supportability

2. 2 Where Are We in the Requirements Discipline?

3. 3 Refine the System Definition: Activities and Artifacts

4. 4 Features Drive Software Requirements Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status Trending information will be charted with a line graph showing time on the x axis, and number of defects found on the y axis. Trending periods can be entered in units of days, weeks, or months. Print Status Report Operator Project Manager

5. 5 Detail Each Use Case 1.Identify actors and use cases.  Brief Description. 2.Outline each use case.  Basic Flow of Events.  Alternative Flows of Events. 3.Detail each use case.  Detail the flow of events.  Structure each use case flows of events.  Add detail. Pre- and postconditions, special requirements, relationships, use-case diagrams, and so on.

6. 6 Why Detail Use Cases?  Specify the software requirements.  Create a specification that can be implemented.  Clarify important details in flow of events.  What the actor does.  What the system does in response.  What information is exchanged.  Describe additional information.  Preconditions  Postconditions

7. 7 Detail a Use Case 1. Find the actors and use cases. 2. Detail the use cases. 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Preconditions 5. Postconditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/Enclosures 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Preconditions 5. Postconditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/Enclosures Brief Outline Add Detail RUCS6: Get Quote Use-Case Description

8. 8 Detail the Basic Flow of Events Structure the flow into steps Number and title each step Describe steps (completely and concisely) Make each step a roundtrip of events Get Quote 1.1 Basic Flow 1. Customer Logs On The use case starts when the Trading Customer logs on. The system validates the customer id and password. The system presents a list of available functions. 2. Customer Selects “Get Quote” Function The Trading Customer chooses to get a quote. The system displays the list of trading symbols and names of securities. 3. Customer Selects Security The Trading Customer selects from the list of securities or enters the trading symbol for a security. 4. System Gets Quote from Quote System The system sends the trading symbol to the Quote System, and receives the Quote System Response. The system presents the corresponding Quote Display (see fields to display in Supplementary Specifications) to the Trading Customer.

9. 9 Review: Flows of Events (Basic and Alternative)  One Basic Flow  Happy day scenario  Successful scenario from start to finish  Many Alternative Flows  Regular variants  Odd cases  Exceptional (error) flows Flow: A sequential set of steps.

10. 10 Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Detail Alternative Flows Describe what happens Condition Actions Resume location Location

11. 11 Avoid Inline Conditional Behavior  Make identifying scenarios difficult.  Harder to test and implement. Preference should be for alternative flows.

12. 12 Avoid Inline Repetitive Behavior  Make identifying scenarios difficult.  Harder to test and implement. Preference should be for alternative flows.

13. 13 Alternative Flows Versus Inline Conditional Behavior  Alternative Flows  Pros Can be used anywhere there is conditional behavior.  REPEAT-UNTIL, IF-THEN-ELSE-ENDIF Make identifying scenarios simpler.  Helps testing and implementation  Cons Increased complexity in maintaining cross-references.  Inline Conditional Behavior  Pros Easier to handle small variations in flows.  Cons Harder to identify scenarios, test and implement.

14. 14 Visualize Alternative Behavior Trading System Quote System Customer

15. 15 Subflows  Increase clarity.  Allow internal reuse of requirements.  Unlike an alternative flow, are explicitly called.  Always return to the line after they were called. Alternative Flows Subflow

16. 16 Example Subflow RUCS6.2: Execute Trade UC Spec

17. 17 Leave the User Interface Out of the Use Case  Text is not good at describing visual things.  Use cases are user-interface agnostic.  Describe user Interfaces during Analysis and Design with:  User-experience model or prototypes RUCS11: Use-Case Modeling Guidelines Click Drag Form Open Close Drop Button Field Drop-down Pop-up Scroll Browse Record Window Prompts Chooses Initiates Specifies Submits Selects Starts Displays Informs Words to AVOIDWords to Use

18. 18 Use the Glossary Effectively Glossary Customer Details: Information that uniquely identifies and provides contact information for a customer located in the U.S.A. The information consists of: Name, two address lines, city, state, zip code, and daytime phone number. Use Case 5. Enter Customer Info The system prompts the Customer to enter their Customer Details. The Customer enters the Customer Details. The Customer creates the account. Implementation