Eliciting

Requirements
in Use Cases

Terry Bahill
Systems and Industrial Engineering
University of Arizona
terry@sie.arizona.edu
©, 2004-09, Bahill
This file is located in
http://www.sie.arizona.edu/sysengr/slides/
 Reference
Daniels, J. and Bahill, A. T., Hybrid Process
Combines Traditional Requirements and Use
Cases, Systems Engineering, 7(4):303-319, 2004.
http://www.sie.arizona.edu/sysengr/publishedPap
ers/hybridProcess.pdf

12/08/21 2 © 2009 Bahill

 Motivation for this seminar
• Discovering system requirements is hard.
• Formally testing use case conformance is hard.
• We wanted to show that use cases and shall-
statement requirements can be applied
synergistically.

12/08/21 3 © 2009 Bahill

 Traditional requirement specs
• Requirements are documented as distinct,
textual statements of imperative
 Usually using “shall-statement” notation
• Typically organized by functional area
• Requirements are structured into parent-child
relationships to facilitate requirement
decomposition and derivation

12/08/21 4 © 2009 Bahill

 Traditional specs, strengths
• Allows for very precise wording
• Straightforward “sign off” of capabilities during
testing
 Important for defense contracts
• Requirements easily captured in a tool (e.g.,
database)
• Widely known and accepted, especially in the
defense industry

12/08/21 5 © 2009 Bahill

 Traditional specs, weaknesses
• Often become very long and tedious
 Increases chance of ambiguity*
 Hard to comprehend the entire set
 Difficult to review with customers
• Little context to each requirement
 Typically nothing that “ties” requirements together
into a comprehensive story

12/08/21 6 © 2009 Bahill

 Use cases1
• Originated in the software industry
• Focus: “What does my system have to do for
each user type”
• Describes system functionality through
structured narrative stories
• Provides light graphical modeling via UML use
case diagrams

12/08/21 7 © 2009 Bahill

 Use cases2
• A use case is an abstraction of a required behavior of a
system.
• A use case produces an observable result of value to the
user.
• A typical system will have many use cases each of
which satisfies a goal of a particular user.
• Each use case describes a sequence of interactions
between one or more actors and the system.
• A use case narrative is written in a natural language. It is
written as a sequence of numbered steps with a main
success scenario and alternate flows.
• This sequence of interactions is contained in a use case
report and the relationships between the system and its
actors are portrayed in use case diagrams.
12/08/21 8 © 2009 Bahill
 Use cases, strengths
• Simple concept
• Easy to comprehend and follow
 Contingent on writing skill, of course!
• User focused – ensures that you consider how
the system supports its environment
• Easy to review with non-technical stakeholders
• Easy to incorporate soft topics like goals,
capabilities and expectations.

12/08/21 9 © 2009 Bahill

 Use cases, weaknesses
• Lack precision
 Use cases feel vague
• Relatively hard to document and organize lots
of necessary details
• Use cases are not yet used by everyone
• Hard to definitively “sign off” a use case for
acceptance testing

12/08/21 10 © 2009 Bahill

 Two requirements specification methods
• Shall-Statement Requirements
 Precise and widely accepted but specs are typically
long and hard to comprehend as a set
• Use Cases
 Simple and ensure the system satisfies user needs but
are less precise and hard to formally test

12/08/21 11 © 2009 Bahill

 The starting point
• Capture non-functional requirements in shall-
statement form directly in use case report
• Use a “supplementary specification” to capture
global non-functional requirements

12/08/21 12 © 2009 Bahill

 Use Case
Requirements
Starting point Specification

1 1
Use Case Model Supplementary
Requirements
Specification
Other UML 0..*
1..*
Diagrams
Use Case Report

1..* 1..* 1
Other Sections Sequence of Specific
Events Requirements
Section
E.g. brief
description,
preconditions, 0..*
postconditions,
rules, etc. Nonfunctional
Requirements

1..*
1..*
System Wide
Requirements

12/08/21 13 © 2009 Bahill

 Use Case
The new part Requirements
Specification

1 1
Use Case Model Supplementary
Requirements
Specification
Other UML 0..*
1..*
Diagrams
Use Case Report

1..* 1..* 1
Other Sections Sequence of Specific
Events Requirements
Section
E.g. brief trace
description,
preconditions,
1..*
1..* 0..*
postconditions,
rules, etc. Functional Nonfunctional
Requirements Requirements

1..* 0..*

1..*

1..*
System Wide
Traditional Requirements Specification Requirements
12/08/21 14 © 2009 Bahill
 The Hybrid Process The new part

Extract
functional
requirements

Develop Define Write Capture

Vision,
ConOps &
Capabilities
business
model
actors &
architecture
use
case
nonfunctional
requirements
Σ Requirements
Specification
reports

Develop
supplementary
requirements

Revise

12/08/21 15 © 2009 Bahill

 The hybrid process that combines
traditional requirements and use cases
• Develop a business model
• Discover the actors and their goals
• Sketch out the use case reports
• Iterate on the architecturally significant use
cases
Extract the functional requirements from each
use case's Brief Description, Added Value and
Flow of Events and document them in the
Specific Requirements Sections

12/08/21 16 © 2009 Bahill

 The hybrid process (continued)
• Document the nonfunctional requirements in
the Specific Requirements Sections
• Iterate on the use case set to ensure consistency
and completeness
• Develop a Supplementary Requirements
Specification to capture system-wide
requirements that do not fit into individual use
case reports.

12/08/21 17 © 2009 Bahill

 Uses of process output
• With the shall-statement requirements a
traditional requirements spec can be easily
created
 Requirements are based on use cases – good
traceability to user goals
 Can be stored in a database
• Can build formal tests for each use case*
 Sign off shall-statements

12/08/21 18 © 2009 Bahill

 Uses of process output
• Specific requirements section used to document
details
 Data requirements
 User Interface preferences
 Constraints
• These details clutter scenario narrative

12/08/21 19 © 2009 Bahill

 Requirements and use cases
• Specific Requirements
 Functional requirements state, in formal shall statement
notation, the functions that the system must execute.
 Nonfunctional requirements are often performance
requirements that specify how well the system must execute
certain functions.
• Supplementary Requirements Specification contains the
requirements that are associated with more than one use
case. Often they are system wide. Examples include
cost, schedule, reliability, availability, technology,
design life, etc.

12/08/21 20 © 2009 Bahill

 Example use case
Name: Display System Status
Brief description: Indicate the health of the system
Added value: Home Owner knows if the system is working
properly.
Scope: An HVAC controller for a Tucson house
Primary actor: Home Owner
Frequency: Typically once a day
Main Success Scenario:
1. Home Owner asks the system for its status.
2. Each component in the system reports its status to the
Controller.
3. The system accepts this information and updates the
System Status display.
4. Home Owner observes the System Status [exit use case].
12/08/21 21 © 2009 Bahill
 Example use case (continued)
Alternate flows go here.
Specific Requirements
Functional Requirements:
1. Each component shall report its status to the
Controller.
2. The system shall display System Status.
Nonfunctional requirement: System Status shall be
displayed within 2 seconds of request.
Author: Terry Bahill
Date: July 20, 2004

12/08/21 22 © 2009 Bahill

 Use case diagram
HVAC System

Heat
House
Heater

Set
Temperature
Limits

Cool Evaporative
House Cooler

Home Select
Equipment
Owner

Display
System Air
Status Conditioner

12/08/21 23 © 2009 Bahill

 A missile system failure

12/08/21 24 © 2009 Bahill

 Customer requirements for a PCB*
PCB
trace Requirement
number
10 Trace-10 shall transmit signals
between element 1 and 2. Blah, blah,
blah, etc.
11 Trace-11 shall supply valves 1
through 6. Blah, blah, blah, etc. This
trace shall have a capacity of X5 mA.
Blah, blah, blah.
12 Trace-12 shall deliver power to
components 1 through 4. Blah, blah,
blah, etc.

12/08/21 25 © 2009 Bahill

 Derived requirements for the PCB
PCB
trace Origin Destination Type Length
number
10 Stuff Stuff Stuff
11 Pin-3 Pin 4 of 10
IC-2 Valves 1 to 6
12 Stuff Stuff P Stuff

As you can see,

someone forgot to mark trace 11
as a power trace (P)*.

As a result the missile blew up.

12/08/21 26 © 2009 Bahill

 Control Missile Attitude1*
Brief description: Valves 1 to 6 open and close allowing pneumatic fluid
to flow thereby controlling missile attitude.
Added value: Guidance, Navigation and Control (GNC) can control the
system state.
Scope: Control of attitude control valves
Primary actor: GNC
Supporting actors: Power Supply, Pneumatic Fluid, Control Valves
Precondition: The missile is flying and all valves are closed.
Trigger: GNC commands a course change.
Main Success Scenario:
1a. GNC commands Valve-1 to open for X1 msec.
2. Valve-1 opens, drawing X2 mA from the power supply through
printed circuit board (PCB) trace-11, allowing pneumatic fluid to flow
through its orifice.
3. After X1 msec Valve-1 closes, drawing X3 mA, thereby stopping the
flow of fluid [exit use case].
12/08/21 27 © 2009 Bahill
 Control Missile Attitude2
Alternate Flows:
1b. GNC commands Valve-2 to open for X4 msec.
1b1. Valve-2 opens, drawing X2 mA from the power supply through
PCB trace-11, allowing pneumatic fluid to flow through its orifice.*
1b2. After X4 msec Valve-2 closes, drawing X3 mA, thereby stopping
the flow of fluid [exit use case].
[Similar alternative flows exist for Valves 3 to 6.]
Postcondition: Missile has changed course and all valves are closed.
Rules:
1. Valves 1 to 6 will open and close at the same or at different times.

12/08/21 28 © 2009 Bahill

 Control Missile Attitude3
Specific Requirements*
Functional Requirements:
Req. FR1:* GNC shall command valves 1 to 6 to open. [From step 1.]
Req. FR2: Valves 1 to 6 shall open and close on command. [From steps 2
and 3.]
Req. FR3: Valves 1 to 6 shall regulate the flow of pneumatic fluid
through them. [From step 2.]
Nonfunctional requirements:
Req. NR1: PCB Trace-11 is a power trace. It shall have a capacity of X5
mA, because each of the six valves may open or close at the same
time. [From steps 2 and 3 and Rule 1.]
Req. NR2: Maximum pneumatic fluid flow rate shall be X6 kg/sec.
[Obtained from Stakeholder interviews.]
Req. NR3: Valve opening and closing times shall be less than one msec.
[Obtained from Stakeholder interviews.]
Author/owner: Terry Bahill
Date: April 1, 2004
12/08/21 29 © 2009 Bahill
 Orthogonally
• Use case requirements and traditional
requirements are orthogonal, not redundant.
• The traditional requirements concentrated on
the printed circuit board traces, whereas the use
case describes the functional behavior of the
missile.
• The existence of this use case would have
prompted engineers to see the mistake in the
derived requirements table.

12/08/21 30 © 2009 Bahill

 Example use case model:
microwave oven

Initiator Cook
Food

Cook Microwave Oven System Timer

Reference: Gomaa, H., Designing Software Product Lines with UML :

From Use Cases to Pattern-Based Software Architectures, Addison-
Wesley, Reading 2004.
12/08/21 31 © 2009 Bahill
 Use Case Name: Cook Food
Brief description: This use case describes the user
interaction and operation of a microwave oven. Cook
invokes this use case in order to cook food in the
microwave.
Added value: Food is cooked.
Scope: A microwave oven
Primary actor: Cook
Supporting actors: Timer
Preconditions:
The microwave oven
is waiting to be used.

12/08/21 32 © 2009 Bahill

 Main Success Scenario
1. Cook opens the microwave oven door, puts food into the
oven, and then closes the door.
2. Cook specifies a cooking time.
3. System displays entered cooking time to Cook.
4. Cook starts the system.
5. System cooks the food, and continuously displays the
remaining cooking time.
6. Timer indicates that the specified cooking time has been
reached, and notifies the system.
7. System stops cooking and displays a visual and audio
signal to indicate that cooking is completed.
8. Cook opens the door, removes food, then closes the
door.
9. System resets the display.
12/08/21 33 © 2009 Bahill
 Alternate Flows
1a. If Cook does not close the door before starting the system (step
4), the system will not start.
4a. If Cook starts the system without placing food inside the system,
the system will not start.
4b. If Cook enters a cooking time equal to zero, the system will not
start.
5a. If Cook opens the door during cooking, the system will stop
cooking. Cook can either close the door and restart the system
(continue at step 5), or Cook can cancel cooking.
5b. Cook cancels cooking. The system stops cooking. Cook may
start the system and resume at step 5. Alternatively, Cook may
reset the microwave to its initial state (cancel timer and clear
displays).
Author: Hassan Gama
Date: October 23, 2004
12/08/21 34 © 2009 Bahill
 Specific Requirements
Section of this use case

12/08/21 35 © 2009 Bahill

 Functional Requirements1
Req. F1: The system shall provide a mechanism for Cook to enter a
cooking time. [From step 2]
Req F2: The system shall be capable of displaying the cooking time
entered by Cook. [From step 3]
Req F3: The system shall cook food using microwave radiation. [From
step 5 and the Brief description]
Req F4: The system shall be capable of calculating and displaying the
remaining cooking time [From step 5]
Req F5: The system shall interface with a timer mechanism such that the
system is stopped when the timer elapses. [From step 6]
Req F7: The system shall emit an audible signal when the timer has
elapsed. [From step 7]
Req F8: The system shall visually indicate when the timer has elapsed.
[From step 7]

12/08/21 36 © 2009 Bahill

 Functional Requirements2
Req F9: The system shall be capable of determining whether the oven
door has been closed. [From step 1a]
Req F10: The system shall not start, if the system detects that the door is
open. [From step 1a]
Req F11: The system shall be capable of determining if food has been
placed in the oven. [From step 4a]
Req F12: The system shall not start, if the system detects that no food has
been placed in the oven. [From step 4a]
Req F13: The system shall stop running if the oven door is opened while
the system is running. [From step 5a]
Req F14: The system shall provide a mechanism to cancel a cook time
entered by Cook. [From steps 5a and 5b]
Req F15: The system shall stop running if the cook time is canceled while
the system is running. [From steps 5a and 5b]

12/08/21 37 © 2009 Bahill

 Nonfunctional Requirements1
Req N1: The system shall allow Cook to enter the cooking time in less
than five keystrokes. [Constraint on Req F1, from stakeholder
interviews]
Req N2: The cooking time displayed by the system shall be visible to a
Cook with 20/20 vision standing five feet from the oven in a room with
an luminance level between 0 and 100 foot-candles. [Constraint on
requirement F2, and from stakeholder interviews]
Req N3: The system shall raise the temperature of food in the oven such
that temperatures at two distinct locations in the food are different by
less than 10%. [Constraint on Req F3, and from stakeholder interviews
where stakeholders desire even cooking of food]
Req N4: The system shall update the remaining cook time display every
second. [Constraint on Req F4]
Req N5: The audible signal emitted by the oven shall have an intensity
level of 80 decibels, ±2 decibels. [Constraint on Req F7, from
stakeholder interviews]

12/08/21 38 © 2009 Bahill

 Nonfunctional Requirements2
Req N6: The system shall detect food items weighing at least 0.05
ounces and with a volume of at least 1 cubic inch. [Constraint on Req
F11, obtained from stakeholder interviews]
Req N7: The system shall comply with section 1030 of Title 21- Food
and Drugs, Chapter I – Food and Drug Administration, Department of
Health and Human Services, Subchapter J: Radiological Health
[Constraint on Req F3, specifies required compliance with health
standards]
Req N8: The system shall provide 14 3/4" Width x 8 3/4" Height x 15
3/4" Depth inside cooking area volume. [From step 1, obtained by
stakeholder interviews]
Req N9: The cooking time shall be adjustable between one second and
ninety minutes [Constraint on Req F1, obtained from stakeholder
interviews]

12/08/21 39 © 2009 Bahill

 The bridge
• The functional requirements section of this use
case is the bridge between the behavior of the
system and the DOORS requirements database.
• It helps the systems engineers to get the
requirements right.

12/08/21 40 © 2009 Bahill

 Use Case
Requirements
Specification

1 1
Use Case Model Supplementary
Requirements
Specification
Other UML 0..*
1..*
Diagrams
Use Case Report

1..* 1..* 1
Other Sections Sequence of Specific
Events Requirements
Section
trace

E.g. brief
description,
preconditions,
1..*
1..* 0..*
postconditions,
rules, etc. Functional Nonfunctional
Requirements Requirements

1..* 0..*

1..*

1..*
System Wide
Traditional Requirements Specification Requirements
12/08/21 41 © 2009 Bahill
 Ancestry Mission
Statement
model* Traces to Traces to

Concept of Business
Operations Model

Traces to Traces to

Use Case
Requirements
Specification

Traces to Traces to Traces to

Traditional
Test Design
Requirements
Procedures Model
Specification
12/08/21 42 © 2009 Bahill
 Goals versus requirements
• The Mission Statement, Concept of Operations
and Business Model contain goals, objectives,
capabilities, features, constraints and top-level
functions.
• Formal requirements are contained in
 Specific Requirements Sections of the Use Cases
 Supplementary Requirements Specification
 Traditional Requirements Specification (DOORS)

12/08/21 43 © 2009 Bahill

 Rating the requirements methods*
Shall
Use Hybrid
Criterion Statement
Cases Process
Method
Necessary 1 3 3
Verifiable 3 1 3
Unambiguous 3 2 3
Complete 2 3 3
Consistent 1 2 3
Traceable 2 2 3
Concise 3 1 3
Standard 3 1 3
constructs

1= poor, 3= good

12/08/21 44 © 2009 Bahill

 Use Cases from
“COTS-Based Engineering Design of
a Tradeoff Study Tool”

12/08/21 45 © 2009 Bahill

 Architecture of a tradeoff study tool
Limits, slopes, baselines and weights Alt-1 Alt-2 Alt-3 Alt-4 Alt-5
Criteria-1
Criteria-2
Criteria-3
SubCrit-3.1
SubCrit-3.2
SubCrit-3.3
Criteria-4

Criteria Module Input Module

Alt-3
Criteria-1
Alt-2
Criteria-2
Criteria-1
Criteria-3
Alt-1 Alt-1 Alt-2 Alt-3 Alt-4 Alt-5
Criteria-2
Criteria-1 SubCrit-3.1 Criteria-1
Criteria-3
Criteria-2 SubCrit-3.2 Criteria-2
SubCrit-3.1
Criteria-3 SubCrit-3.3 Criteria-3
SubCrit-3.2
SubCrit-3.1
Criteria-4 Criteria-4
SubCrit-3.3
SubCrit-3.2 Overall Score
Criteria-4
SubCrit-3.3
Criteria-4

Output Matrices Summary Module

12/08/21 46 © 2009 Bahill
 Use case diagram
ud TradeoffUseCaseDiag

Tradeoff Study Tool

Create a Tradeoff
Study

DOLLS

«include»

Complete Criteria «include»

Module

Tradeoff Analyst

PAL
Fill In Input Module

12/08/21 47 © 2009 Bahill

 Create a Tradeoff Study1
Iteration: 2.1
Brief Description: Tradeoff Analyst completes the four
modules of the tradeoff study tool and gives the results
to the decision maker. Every aspect of a tradeoff study
requires extensive discussion with the decision maker
and other stakeholders.
Added Value: This helps a decision maker to make better
decisions and it documents the process that was used to
make these decisions.
Level: User goal
Scope: Applies to a decision problem that is appropriate
for a tradeoff study.
Primary Actor: Tradeoff Analyst (this could be a person
or a team).
12/08/21 48 © 2009 Bahill
 Create a Tradeoff Study2
Supporting Actors: Tradeoff Analyst will get the tradeoff
study tool and documents from Company Resources.
Tradeoff Analyst will put the results of the tradeoff
study in the project assets library (PAL).
Frequency: Company wide, once a week
Precondition: A decision maker has asked Tradeoff
Analyst to perform a tradeoff study. Preliminary
criteria, weights, alternatives and criteria values must
already be defined and be in the hands of Tradeoff
Analyst.
Trigger: Tradeoff Analyst starts the process.

12/08/21 49 © 2009 Bahill

 Create a Tradeoff Study3
Main Success Scenario:
1. Tradeoff Analyst copies the company tradeoff study
spreadsheet into his or her computer.
2. Tradeoff Analyst selects the Criteria Module for
development.
3. Include Complete Criteria Module.
4. Tradeoff Analyst selects the Input Module for
development.
5. Include Fill Input Module.
6. The system transfers data from the Criteria Module
into the Output Matrices.
7. The system computes preferred alternatives using the
combining function chosen by Tradeoff Analyst.
12/08/21 50 © 2009 Bahill
 Create a Tradeoff Study4
Main Success Scenario (continued):
8. The system transfers data from the Output Matrices
into the Summary Module.
9. The system displays the Summary Module for
Tradeoff Analyst’s inspection.
10. Tradeoff Analyst looks at the preferred alternatives in
the Summary Module.
11. Tradeoff Analyst repeats steps 2 to 10 until he or she
is satisfied.

12/08/21 51 © 2009 Bahill

 Create a Tradeoff Study5
Main Success Scenario (continued):
12. Tradeoff Analyst performs sensitivity analysis.
13. Tradeoff Analyst submits the tradeoff study for expert
review.
14. Tradeoff Analyst submits the tradeoff study to the
decision maker and places it in the Process Asset
Library (PAL) [exit use case]

12/08/21 52 © 2009 Bahill

 Create a Tradeoff Study6
Unanchored Alternate Flow:
Tradeoff Analyst can stop the system at any time; all
entered data and intermediate results will be saved [exit
use case].
Postcondition: Tradeoff Analyst has planed a tradeoff
study.
Specific Requirements
Functional Requirements:
Note: Transferring data from the Criteria Module into
other modules and interchanging information with
Company Resources and the PAL are supplementary
requirements.

12/08/21 53 © 2009 Bahill

 Create a Tradeoff Study7
Functional Requirements (continued):
FR1-1 The system shall compute preferred alternatives
using the combining function chosen by Tradeoff
Analyst.
FR1-2 The system shall transfer information from the
Output Matrices into the Summary Module.
FR1-3 The system shall display the Summary Module.
Nonfunctional Performance Requirement:
NFPR1 At least six different combining functions shall be
available for use by Tradeoff Analyst.
Author/owner: Terry Bahill
Last changed: February 23, 2006

12/08/21 54 © 2009 Bahill

 Concrete inclusion use cases
The next two use cases are concrete
inclusion use cases to the Create a
Tradeoff Study use case.

12/08/21 55 © 2009 Bahill

 Complete Criteria Module1
Iteration: 2.1
Brief Description: Tradeoff Analyst enters data into the
Criteria Module and designs scoring functions. If this
inclusion use case is called by the base use case, then it
is context sensitive; the spreadsheet that is open is the
spreadsheet that is used. If the actor initiates the use
case, then the name of the spreadsheet to be used must
be queried.
Added Value: Tradeoff Analyst understands the criteria
and develops scoring functions.
Level: Low level
Scope: Criteria Module
Primary Actor: Tradeoff Analyst

12/08/21 56 © 2009 Bahill

 Complete Criteria Module2
Frequency: Company wide, once a week
Precondition: Criteria must already be defined and be in
the hands of Tradeoff Analyst.
Trigger: This use case is initiated by the Create a
Tradeoff Study use case or by the Tradeoff Analyst.
Main Success Scenario:
1a. When triggered by the Create a Tradeoff Study
use case, Tradeoff Analyst replaces criteria of the
template with problem domain criteria and describes
these criteria in the notes section.
2. Tradeoff Analyst works on the criteria one at a time
and may rewrite, decompose or derive criteria.

12/08/21 57 © 2009 Bahill

 Complete Criteria Module3
Main Success Scenario (continued):
3. Tradeoff Analyst selects limits, slopes and baselines
for the scoring function of each criterion.
4. The system draws a scoring function for each criterion.
5. Tradeoff Analyst readjusts limits, slopes and baselines
for each criterion. This requires discussion with the
decision maker.
6. The system redraws the scoring function for each
criterion.
7. Tradeoff Analyst assigns a weight of importance to
each criterion.
8. The system computes normalized weights.

12/08/21 58 © 2009 Bahill

 Complete Criteria Module4
Main Success Scenario (continued):
9. The system displays alternative combining functions
and accepts the function chosen by Tradeoff Analyst.
10. Tradeoff Analyst repeats this process until satisfied
with the results.
11. Tradeoff Analyst expresses desire to finish this use
case.
12. The system transfers criteria to the Input Module [exit
use case].
Anchored Alternate Flow:
1b. When triggered by the Tradeoff Analyst, Tradeoff
Analyst specifies the file to be worked on.

12/08/21 59 © 2009 Bahill

 Complete Criteria Module5
Unanchored Alternate Flow:
Tradeoff Analyst can stop the system at any time; all
entered data and intermediate results will be saved [exit
use case].
Postcondition: Tradeoff Analyst knows what the criteria
are and where they are stored.
Specific Requirements
Functional Requirements:
FR2-1 The Criteria Module shall accept scoring function
parameters from Tradeoff Analyst.
FR2-2 The Criteria Module shall create and graph scoring
functions.
FR2-3 The Criteria Module shall accept changes in scoring
function parameters and criteria from Tradeoff Analyst.
12/08/21 60 © 2009 Bahill
 Complete Criteria Module6
Functional Requirements (continued):
FR2-4 The Criteria Module shall accept un-normalized
weights from Tradeoff Analyst.
FR2-5 The Criteria Module shall normalize the weights.
FR2-6 The Criteria Module shall accept changes in
weights from Tradeoff Analyst.
FR2-7 The Criteria Module shall display alternative
combining functions and accept the function chosen by
Tradeoff Analyst.

12/08/21 61 © 2009 Bahill

 Complete Criteria Module7
Nonfunctional Performance Requirements:
NFPR2-1 Scoring function graphs must be updated within
100 milliseconds of a change in a parameter.
NFPR2-2 Computing normalized weights shall take less
than 100 milliseconds.
Business Rules:
BR-1. The weights entered by Tradeoff Analyst shall be
numbers (usually integers) in the range of 0 to 10,
where 10 is the most important.

12/08/21 62 © 2009 Bahill

 Fill Input Module1
Iteration: 2.1
Brief Description: Tradeoff Analyst enters criteria values
for the alternatives into the Input Module. If this
inclusion use case is called by the base use case, then it
is context sensitive, the spreadsheet that is open is the
spreadsheet that is used. If the actor initiates the use
case, then the name of the spreadsheet to be used must
be queried.
Added Value: These criteria values can be used to
compute preferred alternatives.
Level: Low level
Scope: Input Module
Primary Actor: Tradeoff Analyst
Frequency: Company wide, once a week
12/08/21 63 © 2009 Bahill
 Fill Input Module2
Precondition: Alternatives must already be defined and
their preliminary criteria values must be in the hands
of Tradeoff Analyst.
Trigger: This use case is triggered by the Create a
Tradeoff Study use case or by the Tradeoff
Analyst.
Main Success Scenario:
1a. When triggered by the Create a Tradeoff Study
use case, Tradeoff Analyst describes his or her
alternatives.
2. The system updates the Input Module.
3. Tradeoff Analyst concentrates on one row at a time
and fills in criteria values for the alternatives.

12/08/21 64 © 2009 Bahill

 Fill Input Module3
Main Success Scenario (continued):
4. Tradeoff Analyst reassesses the criteria values until
satisfied with the results.
5. The Input Module sends criteria values to the Criteria
Module [exit use case].
Anchored Alternate Flow:
1b. When triggered by the Tradeoff Analyst, Tradeoff
Analyst specifies the file to be worked on.
Unanchored Alternate Flow:
Tradeoff Analyst can stop the system at any time; all
entered data and intermediate results will be saved
[exit use case].

12/08/21 65 © 2009 Bahill

 Fill Input Module4
Postcondition: Tradeoff Analyst knows where the
alternatives are described and where their criteria values
are stored.
Specific Requirements
Functional Requirements:
FR3-1 The Input Module shall accept criteria values from
Tradeoff Analyst.
FR3-2 The Input Module shall accept changes in criteria
values from Tradeoff Analyst.
Author/owner: Terry Bahill
Last changed: February 25, 2006

12/08/21 66 © 2009 Bahill

 Supplementary requirements
• SR1 The system shall interchange information with
Company Resources and the PAL.
• SR2 The Criteria Module shall transfer information to
and from the Input Module.
• SR3 The Criteria Module shall transfer information to
and from the Output Matrices.

12/08/21 67 © 2009 Bahill

 Critique of the process
• A problem with the Hybrid Process is that it
produces specific, low-level, design
requirements.
• We do not know if these can be abstracted to
high-level customer requirements.
• The Brief Description and Added Value slots of
the use case might provide high-level
requirements.
• We need examples of using the process with
business use cases.

12/08/21 68 © 2009 Bahill

 Summary
• The hybrid process derives shall statement
requirements from the use case sequence of
events.
• These functional requirements are put in the
Specific Requirements section of the use case
report.
• These functional requirements can then be put
into a requirements database to support
traditional specs and tracing.

12/08/21 69 © 2009 Bahill

12/08/21 70 © 2009 Bahill
 How to print
• To print this file, do this one time.
• View
• Color/grayscale
• Grayscale
• Settings
• Light grayscale
• Close grayscale view

12/08/21 71 © 2009 Bahill