1 objectives describe design constraints. identify methods of specifying functional requirements. ...

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

Where Are We in the Requirements Discipline?

3

Refine the System Definition: Activities and Artifacts

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 StatusReport

Operator ProjectManager

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

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

Detail a Use Case

1. Find the actors and use cases.

2. Detail the use cases.

<Use-Case Name>1. Brief Description2. Flow of Events Basic Flow of Events Alternative Flows of Events3. Special Requirements4. Preconditions5. Postconditions6. Extension Points7. Relationships8. Use-Case Diagrams9. Other Diagrams/Enclosures

<Use-Case Name>1. Brief Description2. Flow of Events Basic Flow of Events Alternative Flows of Events3. Special Requirements4. Preconditions5. Postconditions6. Extension Points7. Relationships8. Use-Case Diagrams9. Other Diagrams/Enclosures

Brief Outline

Add Detail

RUCS6: Get Quote Use-Case Description

8

Detail the Basic Flow of Events

Structure the flow into steps

Number andtitle each step

Describe steps (completely and concisely)

Make each step a roundtrip of events

Get Quote1.1     Basic Flow1. 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” FunctionThe Trading Customer chooses to get a quote.The system displays the list of trading symbols and names of securities.

3. Customer Selects SecurityThe Trading Customer selects from the list of securities or enters the trading symbol for a security.

4. System Gets Quote from Quote SystemThe 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

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

Alternative FlowsA3 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 QuitIf at any time the Trading Customer decides to quit.The use case ends.

A5 Unknown Trading SymbolIn 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 FlowsA3 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 QuitIf at any time the Trading Customer decides to quit.The use case ends.

A5 Unknown Trading SymbolIn 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 FlowsDescribe what

happens

Condition

Actions

Resume location

Location

11

Avoid Inline Conditional Behavior

Make identifying scenarios difficult. Harder to test and implement.

Preference should be for

alternative flows.

12

Avoid Inline Repetitive Behavior

Make identifying scenarios difficult. Harder to test and implement.

Preference should be for

alternative flows.

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

Visualize Alternative BehaviorTrading System Quote SystemCustomer

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

Example Subflow

RUCS6.2: Execute Trade UC Spec

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 FormOpen Close DropButton Field Drop-down Pop-up Scroll Browse Record Window

Prompts Chooses Initiates SpecifiesSubmits SelectsStarts Displays Informs

Words to AVOID Words to Use

18

Use the Glossary Effectively

GlossaryCustomer 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 InfoThe system prompts the Customer to enter their Customer Details.

The Customer enters the Customer Details.

The Customer creates the account.

Implementation