Requirements Management
with Use Cases
Module 7: Refine the System Definition
Where Are We in The Requirements Workflow?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
2
Refine the System Definition: Module Objectives





Decide on the detailed software requirements
Define the Software Requirements Specification
Detail the use cases
Detail the declarative requirements
Learn qualities of good requirements
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
3
Refine the System Definition: Activities and Artifacts
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
4
Refine the System: Software Requirements Focus
Problem
Problem
Space
Needs
Features
Solution
Space
Software
Requirements
The
Product
To Be
Built
Test
Procedures
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
Design
5
User
Docs
What Do Software Requirements Specify?
Inputs
Outputs
System
Environments
Functions
Performance
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
6
Features Drive Software Requirements
Trending periods can be
entered in units of days,
weeks or months.
Trending information will be
charted with a line graph
showing time on the x axis,
and number of defects
found on the y axis.
Feat 63 - the defect tracking
system will provide trending
information to help the project
manager assess project status
Operator
An example trend report
is shown in Figure 1:
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
7
Print Status
Report
Project
Manager
Specifying the Software Requirements
Needs
Vision
Document
Features
SRS
Software
Requirements
SRS Package
Use-Case Model
Supplementary
Specifications
The Software Requirements Specification (SRS) package defines
complete external behavior and characteristics of the system to be built
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
8
Roles of the SRS Package
 Basis of communication between all parties
 Contractual agreement between parties
 Basis for development: design, implement, test
SRS
Use-Case Model
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
9
SRS Package
Supplementary
Specifications
Who Uses the SRS Package?
 Client team
 Customer: approve what system should do
 Users: understand what system should do
 Developer team
 Use-case and requirements specifiers:
refine software requirements
 Designers: find design classes
 Testers: use as basis for test cases
 Project Manager: manage the project
 Technical Writers: write user’s guide
Remember the SRS is for people to read, not for computers
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
10
What Is In An SRS Package?
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Overall Description
2.1 Use-Case Model Survey
2.2 Assumptions and Dependencies
3. Specific Requirements
3.1 Use Case Reports
3.1.1 <Use Case 1>
3.1.2 ...
3.2 Supplementary Specifications
3.2.1 Usability Requirements
3.2.2 …
4. Supporting Information
Appendices
Index
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
11
TP7:SRS Package
Template
Where to Store The Items in The SRS Package?
Project
Repository
Documents
The mechanics of where to store depend on
 Available tools
 Developer environment and preferences
 Client environment and preferences
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
12
How to Specify Functional Requirements ?
The system shall …
The system shall …
The system shall ...
Use Cases
Declarative
Statements
Use Cases
?
Which one to choose?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
13
How to Specify Functional Requirements ?
 Recommendation
 Use Both Use Cases and Declarative Statements
• Both are necessary to understand any system of
significant complexity
 Preference for uses cases, where appropriate
Use Cases
+
Declarative
Statements
Use Cases
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
The system shall …
The system shall …
The system shall ...
14
SRS Variations For Functional Requirements
The system …
The system …
The system …
The system …
The system …
The system …
The system …
The system …
The system …
The system …
The system …
Use Cases
Declarative
Statements
Use Cases
Situation 1
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
Declarative
Statements
Situation 2
15
Specifying Software Requirements in Use Cases
 Each use case
 Describes actions the system takes to deliver
something of value to the actor
 Shows the system functionality that an actor uses
 Models a dialogue between the system and actors
 Is a complete and meaningful flow of events, from the
perspective of a particular actor
Use-Case Model
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
16
Use-Case Report: Template
The Use-Case Report
contains detailed
information about an
individual use case
<Use-Case Name>*
1. Brief Description*
2. Flow of Events*
Basic Flow of Events
Alternative Flows of Events
3. Special Requirements
4. Pre-Conditions
5. Post-Conditions
6. Extension Points
7. Relationships*
8. Use-Case Diagrams
9. Other Diagrams/enclosures
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
TP5: Use Case
Report Template
17
Use-Case Properties in the Use-Case Report
 Name (same as in Use-Case-Model Survey)
 Brief description (same as in Use-Case-Model Survey)
 Flow of events
 The use case’s behavior
 What the actors do, what the system does in response
 Special requirements
 Requirements about this use case not covered in flow of events
 Usually non-functional requirements
 Pre-conditions
 Constraints on when the use case may start
 Post-conditions
 Constraints on the system after the use case has ended
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
18
Use-Case Properties in the Use-Case Report (cont.)
 Extension points
 Places in the flow of events to attach extensions
 Relationships (same as in Use-Case-Model Survey)
 Associations with actors and with other use cases
 Use-Case diagrams
 Visual model of all relationships involving this use case
 Other Diagrams or enclosures
 Interaction, activity, or other diagrams
 Pictures of the user interface
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
19
Sample Basic Flow of Events
Withdraw Cash Use Case
1. Insert Bank Card
This use case begins when the Bank Customer inserts a bank card in
the card reader on the ATM machine. The ATM validates the card.
2. Enter PIN
The ATM asks for the customer PIN code. The Bank Customer enters
the PIN code.
3 Select ‘Withdraw Cash’
The ATM displays the different alternatives that are available on this
unit. The Bank Customer selects “Withdraw Cash”.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
20
Sample Basic Flow of Events (cont.)
4. Enter Account and Amount
The ATM asks for account to withdraw from and amount to withdraw.
The Bank Customer enters account and amount.
5. Debit Bank Account
The ATM sends the card id, PIN, amount and account to the Bank
Consortium. The Bank Consortium replies that the transaction is
accepted. The ATM system reports to the Bank Customer that it is
ready to dispense cash.
6. Print Receipt
The ATM asks the Bank Customer if a receipt is desired. The Bank
Customer requests a receipt. The ATM system prints the receipt.
7. Receive Cash and Card
The ATM system dispenses money to the Bank Customer, and returns
the Bank Card. The use case ends.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
21
Sample Alternative Flows of Events
A1. Bank Card Not Valid
If in Step 1, Insert Bank Card, the card is not valid, it is ejected to the Bank
Customer with a "sorry not a valid card" message. The use case ends.
A2. Wrong PIN
If in Step 5, Debit Bank Account , the Bank Consortium reply indicates a
wrong PIN. The message "wrong PIN" is shown to the Bank Customer.
The Bank Customer has three tries to get it right. If the Bank Customer
correctly enters the PIN, the basic flow resumes at Step 4, Enter Account
and Amount. Otherwise the card is kept by the ATM machine and the use
case ends.
What other alternatives can you think of?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
22
Exercise: Choosing a Style for the Flow of Events
 Read the different flow of events descriptions on
the following three (3) slides and answer the
following questions:
 Who is the intended audience?

Which is the easiest to understand (read)?

Which do you think is the easiest to write?

Is any one “better” than the others?

Which one do you prefer? Why?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
23
Flow of Events - Style Type I
Orderers can create Orders to collect measurement data from Network
Elements.
The system will assign the Order a unique name and default values for
when and how long the measurement should be and also how often it is
to be repeated. These values can of course be edited by the Orderer.
The Orderer must further specify which measurement function, network
element and measurement objects to apply. The Orderer can also add a
personal comment to the order.
When necessary information is defined, a new Order is created and
initialized with the defined attributes, the name of the creator, date of
creation, and status of the order will be set to 'scheduled'. (Possible
values for the status are: Scheduled, Executing, Completed, Canceled,
and Erroneous).
The Operator is then notified that a new Order has been created and
receives a reference to the new Order so that it can be displayed.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
24
Flow of Events - Style Type II
1. Request a Measurement Order
This use case starts when the Operator requests a Measurement Order.
The system displays all available Network Elements that the operator
has the authority to access.
2. Configure Network Elements
• The operator selects which network elements to measure, and chooses
measurement objects and functions for each selected network element.
• The operator indicates he is finished configuring network elements.
3. Specify Measurements
• The system give the measurement order a unique name and displays
default values for when, how often, and for how long the measurements
should be made. The operator edits the default values as needed.
• The operator optionally enters a comment on the order.
4. Create Measurement Order
The operator requests the system to create the measurement order. The
system confirms creation of the measurement order with the operator
and provides a reference to it. The use case ends.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
25
Flow of Events - Style Type III
=> 'Administrator order' (User identity)
REPEAT
<='Show administrator order menu'
IF (=> 'Creating an Order' (Measurement function,
network element, measurement object)) THEN
The system finds a unique name, default values for when, how often
and for how long the measurement should be executed.
<= 'Show order' (Default attributes)
REPEAT
=> 'Edit order' (Attribute to change, New value of attribute)
<= 'Update screen' (New attributes)
UNTIL (All attributes are defined)
REPEAT
IF (=> 'Edit order' (Attribute to change, New value of attribute))
THEN <= 'Update screen' (New attributes)
ELSIF (=> 'Save order' (Order identity, Attributes)) THEN
The order is created and initialized in the system with the
defined attributes, the name of the creator, date of creation and
the status 'scheduled'.)
ENDIF
UNTIL (=> 'Quit')
ENDIF
UNTIL 'Quit administrator order'
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
26
Exercise: Perspectives in Flow of Events
 Now, read the different flow of events descriptions
on the following two (2) slides and answer the
following questions:

Who is the intended audience?

Which is the easiest to understand (read)?

Which do you think is the easiest to write?

Is one “better” than the other?

Which one do you prefer? Why?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
27
Outside Perspective
1.
2.
3.
Local Call
4.
Subscriber
5.
6.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
Flow of Events
The use case starts when the subscriber
lifts the phone, and gets a dial tone.
The dial tone disappears when the
subscriber dials the first digit.
The subscriber dials the rest of the
number and will then hear a ring tone if
the called party is not busy.
The ring tone will disappear if the called
party answers the phone call.
The call continues until both parties hang
up their phones.
If the called party is busy the subscriber
will hear a busy tone and will then hang
up the phone.
28
Inside Perspective
1.
2.
Local Call
Subscriber
3.
4.
5.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
Flow of Events
The use case is initiated when the subscriber
lifts the phone and the system finds the
correct subscriber object, marks it busy and
gives a dial tone to the subscriber.
The system turns off the dial tone when the
subscriber dials the first digit. The system
loads the digit into a register and will then
wait to receive and store the rest of the
digits.
When the system has received enough digits
it will start to analyze the received digits.
When the whole number has been analyzed
the system will find the corresponding
subscriber object and check whether or not it
is marked busy.
If the called party is not busy the system will
busy mark the object and start ...
29
How to Refine a Use Case Flow of Events
 Gradually add detail to the step-by-step outline
 Work together with users to refine the outline
• Include all events in the outline
• Sketch outlines on large paper
• Expect to revise the outline many times
 First refine the Basic Flow of Events
• What normally happens
 Then refine the Alternative Flows
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
30
Questions To Help Detail The Flow of Events
 Sequence
 What event starts the use case?
 How does the use case end?
 How does the use case repeat some behavior?
 Are there optional situations in the use case?
 Action
 What does each actor do?
 What does the system do?
 Interaction
 How does the use case interact with actors?
 What data is exchanged with actors?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
31
What does NOT belong in the Flow of Events?
 Do NOT describe
 Events outside the use case
• In other use cases
• Between an actor and others outside the system
 System operations not visible externally
 Details of the user interface
• Unless it is an important requirement
 Avoid vague terminology
 Such as “for example”, “etc. ” and “information”
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
32
Guidelines For Refining the Basic Flow of Events
 Structure the basic flow into steps
 Give each step a number and/or a title
 Describe each step in 1-3 sentences
 Make each step a roundtrip of events
 What the Actor does:
• When the <Actor> requests <System> to ...
 What the System does in response:
• <System> sends message to <Actor> and ...
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
33
Exercise: Detail the Basic Flow of Events
 Describe each step in the basic flow of events for
one or more use cases in your project
 Start with the step-by-step outlines written for your use
case model (in Unit 5)
 Give each step a title
 Describe each step in more detail: add 1 to 3 sentences
 Focus only on the normal “happy day” path through the
use case. No alternative flows, yet!
 Write neatly so that you can copy and distribute the text
to the rest of the group
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
34
Why Divide a Flow of Events into Alternative Flows?
 Keep basic flow short and easy to read
 Isolate optional sequences
• Variant events
• Optional events
• Exceptions and errors
 Isolate sequences executed
several times in same flow
 Clarify traceability
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
35
How to Refine The Alternative Flows
 Use one section for each alternative flow
 Give each alternative flow a number and title
 Divide into steps only if it helps clarify
 Describe what happens in the alternative flow
 Where in the basic flow or another subflow the
alternative flow starts
 The condition for doing the alternative flow
 Behavior within the alternative flow
 Where basic flow or another subflow is resumed
 Describe the order of the alternative flows
 Only describe order of flows as fixed, if it is
 In other cases, point out that the order is unfixed
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
36
Specific Alternative Flows
 Occur at a specific step in another flow
 Example
A3. Not Enough Money in Account
If the Bank Consortium finds that there is not enough
money in the Bank Customer’s bank account, the ATM
sends the Bank Customer an error message "Sorry not
enough money”. The Bank Customer has an
opportunity to enter a new account and amount.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
37
Specific Alternative Flows
 Should make clear references
 Where you pick up the sequence of actions
 Where you hand it over to another flow
 Previous example, with clearer references
A3. Not Enough Money in Account
In Step 5, Debit the Account, of the basic flow, if the
Bank Consortium replies to the ATM that there is not
enough money in the Bank Customer’s bank account,
the ATM sends the Bank Customer an error message
"Sorry not enough money”. The ATM continues at Step
4, Enter Account and Amount, of the basic flow.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
38
General Alternative Flows
 Occur anywhere in another flow
 Example
A4: Quit
The ATM will allow the Bank Customer to quit at any
time during the use case. The ATM will stop the
transaction, log the transaction, and eject the Bank
Card. The use case ends.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
39
Another Example: Alternative Flows of Events
Basic Flow of Events
1. Request a Measurement Order
This use case starts when the Operator requests a Measurement Order. …
2. Configure Network Elements
The operator selects which network elements to measure, and chooses ...
3. Specify Measurements
The system give the measurement order a unique name and displays …
3. Create Order
The operator requests the system to create the measurement order. ...
Alternative Flows of Events
A1. No Network Elements Available
If, in Step 1, no Network Elements are available to measure for this Operator,
the system will inform the operator. The use case then ends.
A2. No Measurement Functions Available
If, in Step 2, no measurement functions are available for the selected
network elements, the Operator may select other Network elements.
A3. Cancel Measurement Order
The system will allow the Operator to cancel all actions at any point during
the use case. The system will delete the Order and then end the use case.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
40
Exercise: Detail the Alternative Flows
 Further detail at least three (3) alternative flows
for each use case in the previous exercise
 Continue the description of the flow of events of the use
cases in your class project
 Use the alternatives identified in the step-by-step
outlines written for your use cases (in Module 5)
 Describe clearly what will happen in each alternative
 Write neatly so that you can copy and distribute the text
to the rest of the group
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
41
Pre- and Post-Conditions
 Using pre- and post-conditions
 Pre- and post-conditions are observable to the user
 Use only if needed for clarification
 A pre-condition
 Constraint on when use case can start
 NOT the event that starts the use case
 A post-condition
 Guaranteed true when
use case ends
 Should apply regardless of
alternative flows
 May contain different variants
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
42
Example of a Pre-Condition
Withdraw Cash
Pre-condition
 The customer has a personally-issued card that fits in the
card reader, has been issued a PIN number, and is
registered with the banking system.
Use only if needed for clarification!
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
43
Example of a Post-Condition
Withdraw Cash
Post-condition
 At the end of the use case, all account and transaction
logs are balanced, communication with the banking
system is reinitialized, and the customer has been
returned his card or informed of where it will be sent.
Use only if needed for clarification!
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
44
What About Requirements NOT in Use Cases?
 Use a declarative statement to describe the
software requirement
 Number and title each requirement
 Group related requirements for understandability
 Use language users can easily understand
 Use simple sentence structure: subject + active verb
 Consider using a keyword, for example “shall”
 Keep it short: state a requirement in 1 to 3 sentences
 Use terms from the glossary
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
45
Where Are Declarative Requirements Specified?
 Does requirement apply to a particular use case?
 Specify in the use case report
 In “Special Requirements” property
 Does requirement apply to the whole system?
 Specify in the “Supplementary Specifications”
TP6: Supplementary
Specifications Template
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
46
Functional Requirements in Declarative Statements
 Some functionality is easier to state declaratively
 Example: ATM System
1. Internationalization
The ATM system shall display all messages and menus
in the user’s preferred language.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
47
What about Non-Functional Requirements?
 The “URPS” of FURPS
 Usability
 Reliability
 Performance
 Supportability
 Compliance with Legal
and Regulatory
requirements
 FCC
 FDA
 DOD
 ISO
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
 Design Constraints
 Operating systems
 Environments
 Compatibility
 Application standards
What are some others?
48
A Closer Look at the “URPS” of FURPS
Functionality
Feature Set
Capabilities
Generality
Security
Usability
Human Factors
Aesthetics
Consistency
Documentation
Reliability
Frequency/Severity Predictability
of Failure
Accuracy
Recoverability
MTBF
Performance
Speed
Efficiency
Resource Usage
Throughput
Response Time
Supportability
Testability
Extensibility
Adaptability
Maintainability
Compatibility
Configurability
Serviceability
Installability
Localizability
Robustness
Grady, 1992
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
49
Examples: Non-Functional Requirements
 The ATM System
 The system can only handle one customer at a time.
 The system has to be available 24 hours a day, 7 days
a week, with less than .01% downtime.
What are some others?
Where should each of these be specified?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
50
Specifying Usability Requirements
 Definition of “usability”
 The ease with which software can be learned and
operated by the intended users
 Usability requirements
 Training time requirements, measurable task times
 User abilities (unsophisticated/sophisticated)
 Comparison to other systems that users know and like
 On-line help systems, tool tips, documentation needs
 Conformity with standards
• Examples: Windows, style guides, GUI Standards
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
51
Specifying Reliability Requirements
 Definition of “reliability”
 The ability for the software to behave consistently in a
user-acceptable manner
 Reliability requirements
 Availability (xx.xx%)
 Accuracy
 Mean time between failures (xx hrs)
 Max. bugs per/KLOC (0-x)
 Bugs by class - critical, significant, minor
 Reliability predictors
 Lines of code
 Complexity metrics
Davis Workshop, 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
52
Specifying Performance Requirements
 Definition of “performance”
 A measure of speed or efficiency of the running system
 Performance requirements
 Capacity
 Throughput
 Response time
 Memory
 Degradation modes
 Efficient use of scarce resources
• Processor, memory, disk, network bandwidth
Davis Workshop, 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
53
Specifying Supportability Requirements
 Definition of “supportability”
 The ability of the software to be easily modified to
accommodate enhancements and repairs
 Supportability requirements
 Languages, DBMS, tools, etc.
 Programming standards
 Error handling and reporting standards
 If not observable, state as intent or goals
 If not measurable or observable, it is not a requirement
Davis Workshop, 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
54
How to Describe User Interfaces
 Enclose sketches of proposed screen appearance
with the use-case descriptions
 Be careful not to specify too much of the design in
the use-case documents
Replace
Find what
Replace with
Start
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
Cancel
55
How to Describe Communication Protocols
 Specify a communication protocol if the actor is
another system or external hardware
 The description of the use case should state if some
existing protocol is to be used
 If the protocol is new, it will be fully described during
object-model development
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
56
What About Design Constraints?
 A requirement allows more than 1 design option
 A design is a choice among options
 A requirement that leaves no options is a design
constraint
 Distinguish it from other requirements
 Place in a special section of your software requirements
 Identify the source of each
 Document the rationale for each
 Examples
 An algorithm that is required to be used
 A database system that is required to be used
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
57
The What vs. How Dilemma
Question: How can you tell a requirement from design?
Answer: It depends on your point of view.
“One
man’s
ceiling
is
another
man’s
floor”
Stakeholder
Needs
What
How
Product or
System Features
What
How
Software Requirements
Specification (Use Cases)
What
How
Design Spec
Test Procedures
Documentation Plans
Davis, 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
58
Exercise: Non-Functional Requirements
 For your class project, list at least 5 non-functional
requirements
 Decide where each non-functional requirement
should be specified
1. In the properties of a particular use case
• Special Requirements
• Basic flow
• Alternative flows
2. In the Supplementary Specifications
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
59
Qualities of a Software Requirement Specification









Correct
Complete
Consistent
Unambiguous
Ranked for importance and stability
Verifiable
Modifiable
Traceable
Understandable
ref - IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
60
Qualities of an SRS: Correct
 A Requirements Specification is “correct” if:
 Every requirement within it is something required of the
system to be built
 For example, every requirement in the SRS contributes
to the satisfaction of some need
Hint: Involve the people who have the
problem or mission
ref - Davis ‘93
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
61
Qualities of an SRS: Complete
 A Requirement Specification is “complete” if it
contains:
 All significant requirements
 Responses of the software to all inputs
 Full labels and references to figures, tables, diagrams
 Definitions of all terms and units of measure
(Glossary / Data Dictionary)
IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
62
Qualities of an SRS: Consistent
 A Requirements Specification is “consistent” if:
 Individual requirements described in it do not conflict
 Hint: Trace all related requirements
SR101: The power LED shall be
illuminated whenever the machine is on.
(Consistent)
(Inconsistent)
SR245: When the on-button
is pressed, the system shall
illuminate the power LED.
SR841: When the on-button is
pressed, no observable
results shall occur.
IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
63
Qualities of an SRS: Unambiguous
 A Requirements Specification is “unambiguous” if:
 Every requirement within it has only one interpretation
“A shall do B to C”
Req. 1
“A shall do B to C”
“A shall do B to C”
ref - IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
64
Exercise: Exploring Ambiguity
Mary had a little lamb.
In the space below, write (or draw) two interpretations
of what this sentence means.
ref - Gause & Weinberg, 1989
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
65
Exploring Ambiguity: Dictionary Definitions
had - past of have
have - 1a: to hold in possession as property
4a: to acquire or get possession of: OBTAIN (best to be had)
c: ACCEPT; to have in marriage
5a: to be marked or characterized by (have red hair)
10a: to hold in a position of disadvantage or certain defeat
b: TRICK, FOOL (been had by a partner)
12: BEGET, BEAR (have a baby)
13: to partake of (have dinner)
14: BRIBE, SUBORN (can be had for a price)
lamb - 1a: a young sheep esp. less than one year old or without
permanent teeth
b: the young of various other animals (as smaller antelopes)
2a: a person as gentle or weak as a lamb
b: DEAR, PET
c: a person easily cheated or deceived especially in trading
securities
3a: the flesh of lamb used as food
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
66
Exploring Ambiguity: Analysis
have
1a
lamb
1a
4a
1a
5a
1a
10a
1a
10b
1a
12
12
1b
2a
13
14
3a
2c
Interpretation
Mary owned a little sheep under one year of age or
without permanent teeth.
Mary acquired a little sheep under one year of age or
without permanent teeth.
Mary is the person who owned a little sheep under
one year of age or without permanent teeth.
Mary held a little sheep under one year of age or
without permanent teeth in a position of disadvantage.
Mary tricked a little sheep under one year of age or
without permanent teeth.
Mary gave birth to a young antelope.
Mary is (or was) the mother of a particular small, gentle
person.
Mary ate a little of the flesh of lamb.
Mary bribed a small person trading in securities who
was easily cheated.
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
67
What to Do About Language Ambiguity
 The Ambiguity Poll - create a measure that requires a
solid understanding of the problem to estimate.
 Memorization Heuristic - get various individuals to try to
recall the problem statement from memory. Parts that are
not clear are likely the most ambiguous.
 Key Word Technique - determine the key operational
words in the statement and list their definitions. Mix and
match to determine different interpretations. (Use these
terms for glossary.)
 Emphasis Technique - emphasize different words until as
many interpretations as possible are discovered.
 Other Techniques - use other techniques, pictures,
graphics, formal methods -- that’s what use cases are for!
Gause & Weinberg, 1989
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
68
Exploring Ambiguity: An Observation
Techniques that reduce ambiguity in an SRS often decrease
understandability and alienate customers and users.
Our goal is to find the “sweet spot” where we attain the
greatest understandability with the least ambiguity
The sweet spot
Understandability
Ambiguity
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
69
Ambiguity vs. Understandability: What to Do?
 Use natural language for most of the specification
 Write as clearly and concisely as possible
 Use pictures, diagrams, and dialogs to further
illustrate the intent and features of the application
 Augment with use cases and other formal
techniques to fully define the functionality
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
70
Qualities of an SRS: Ability for Ranking
 A Requirements Specification is able to be
“ranked” for importance and stability if
 Each requirement in it has an identifier to indicate the
importance and stability of that particular requirement
Ranked by importance
Ranked by stability
SR172
SR103
SR63
SR71
SR192
SR103
SR172
SR192
SR71
SR63
ref - IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
71
Qualities of an SRS: Verifiable
 A Requirements Specification is “verifiable” if:
 Every requirement in it is verifiable. [… to a degree that
convinces everybody!]
 There exists some finite, cost-effective process with
which a person or machine can check that the product
meets the requirement
- The system supports up to 1,000 simultaneous users
- The system shall respond to an arbitrary query in 500 msec.
- The color shall be a pleasing shade of green
- The system shall be user friendly
- The system shall export view data in comma separated format
Are these requirements verifiable?
If not, what is a better way to state them?
(Involve QA folks to help decide)
IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
72
Qualities of an SRS: Modifiable
 A Requirements Specification is “modifiable” if:
 Its structure and style are such that any changes to
requirements can be made easily, completely, and
consistently, while retaining the structure and style.
 Features to facilitate modifiability
• Well organized
• Table of contents
• Index
• Cross references
• Minimum redundancy
IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
73
Qualities of an SRS: Traceable
 A Requirements Specification is “traceable” if:
 The origin of each requirement is clear and each
requirement can be referenced in future development
• Backward traceability (to previous stages of definition
or development)
• Forward traceability (to all documents spawned by
the SRS)
 Hints: Make sure every requirement is referenceable
• Use unique numbers
• Use labels
• Use “shall" or other unique identifiers
• Use a requirements repository to maintain traceability
ref - IEEE 1993
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
74
Qualities of an SRS: Understandable
 A Requirements Specification is “understandable”
if:
 Both the user and supplier communities are able to fully
comprehend the requirements stated in it
 Hints:
 Early document should focus on general description
and features of the system
 Requirements writers must understand both audiences
 Use cases can help with understanding the system’s
functional requirements and boundaries
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
75
What Is Not in an SRS?
 Design - How to accomplish the requirements
 Design Model specifies sub-components of a system
and/or their interfaces with other sub-components
 Verification - How you’ll know the requirements
have been met
 Test Model specifies test cases and test procedures
 Project Data - When the requirements will be met
 Software Development Plan specifies schedules,
verification and validation plans, and configuration
management plans
Adapted from Alan Davis
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
76
Review: Refine the System Definition
1. What is in a software requirement specification?
2. What are the properties of a use case?
3. What is the purpose of the flow of events in a use case?
 Who is it written for?
 What does the basic flow describe?
 What are some different types of alternative flows?
4. What are pre- and post-conditions?
 When should they be used?
5. What is the purpose of the “Special Requirements” of a
use case?
(Continued )
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
77
Review: Refining the System Definition
6. What are some types of non-functional requirements?
 Where should they each be specified?
7. Is your industry bound by legal or regulatory
requirements?
 If so, what types of specifications should be written to assure
compliance?
8. What is a design constraint? Where is it documented?
9. What are some measures of a high quality software
requirement specification?
10. What is not included in an SRS?
Requirements Management with Use Cases v2000
Copyright © 1998, 2000 Rational Software, all rights reserved
78