Intro to Requirements

Thursday, September 8, 2022 9:53 PM

Requirement Definition
Requirements describe the necessary functions and features of the system we
are to conceive, design, implement and operate.
Performance Problem statement--> Requirement
definition--> Specification
Schedule
Cost
Other Characteristics (e.g. lifecycle properties))

Requirements are often organized hierarchically

At a high level requirements focus on what should be achieved, not
how to achieve it
Requirements are specified at every level, from the overall system to
each hardware and software component.
Critically important to establish properly
Many of the cost overruns presented in Lecture 1 are caused by over-
ambitious or missing requirements

Poor requirements example: MCO

Mars Climate Orbiter (MCO) was launched by NASA on December 11, 1998

Intended to study Martian climate, weather and surface changes and act as communications
relay back to Earth
However, disintegrated during orbit insertion on Sept 23, 1999 --> approach too
close --> requirements not followed

Units confusion problem: Ground Software produced output in non-SI units (lbf-sec) instead of
SI units: Ns
Calculation of total momentum produced by engine burns needed by GNC

Contract between NASA and Lockheed Martin did specify SI-units

This requirement was flowed down to the Software Interface Specification (SIS), but
not verified later and not implemented in the AMD

From the accident report:

“Items that the mission assurance manager could have addressed for MCO included ensuring
that the AMD file met the requirements of the SIS ..”

Good requirements example: DC-3

Requirements based on desired improvements to DC-2

Very simple
3 page RfP (McDonnell Museum)
Marathon phone call between Smith and Douglas

Key Requirements

Requirements Page 1
 Key Requirements
Range: 1000 miles
Cruise Speed: 150 mph
Passengers: 20-30
Depending on
configuration
Twin Engines
Rugged and Economical

Requirements Explosion since 1970s

More and more
requirements were
added as systems
grew in performance
and complexity

Requirements Page 2
Requirements VS specification
Wednesday, September 21, 2022 8:31 AM

Question?
Is there any difference in meaning between the words
“Requirements” and “Specifications”?
• No, they are essentially the same.
• Yes, requirements are the input to the design process,
while specifications are the output.
• Yes, specifications include the requirements, but also
contain other things such as blueprints etc…
• I am not sure.

Requirements vs. Specifications

• Requirements specify what the
• product or system shall/should do: Specifications describe how the
• Functions it shall perform system is built and works
• How well it should perform these
• Degree of automation of the system • The Form it is made of
(what operators must do) ○ Materials used in the system
• Compatibility with other devices etc ○ Overall dimensions
• Schematics, Blueprints etc…
• User Interface

• Large enough to accommodate big “Specification”

dishes • Stainless steel exterior
• 1,200 Watts of power to • Dimensions: 24” x 14” x
• reheat food quickly 19”
• One touch settings for • Weight: 45.5 lbs
• different food types (rice, • General warranty: 1 year
• pizza, frozen meals) … • Power cord: included
• Etc… • Etc …

Requirements Page 3
Technical Requirements
Wednesday, September 21, 2022 8:33 AM

Purpose of Technical Requirements Definition

• The Technical Requirements Definition Process

○ Is used to transform the baselined stakeholder expectations
(input) into unique, quantitative, and measurable technical
requirements (output)
• Requirements
○ Come in many flavors
○ Should be expressed as well-written “shall” statements that
can be used for defining a design solution

Importance of Technical Requirements

Development
• Establishes the basis for agreement between the stakeholders and
the developers on what the product is to do

• Reduces the development effort because less rework is

required to address poorly written, missing, and misunderstood
requirements.

○ Forces the relevant stakeholders to consider rigorously all of

the requirements before design begins
○ Careful review can reveal omissions, misunderstandings, and
inconsistencies early in the development cycle

• Provides a basis for estimating costs and schedules

○ The description of the product to be developed as given in
the requirements is a realistic basis for estimating project
costs and can be used to evaluate bids or price estimates

Requirements Page 4
Importance of Technical Requirements
Development

• Provides a baseline for verification

○ Organizations can develop their validation and verification plans much
more productively from a good requirements document.
○ The requirements document provides a baseline against which
compliance can be measured.
○ The requirements are also used to provide the stakeholders with a basis
for acceptance of the system.

• Facilitates transfer of the product to new users.

• Serve as a basis for later enhancement or alteration of the

finished product.

Requirements Page 5
Requirements types
Wednesday, September 21, 2022 8:34 AM

Types of Requirements
Functional Requirements define what functions need to be done to
accomplish the mission objectives

• Example: The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch
and yaw axes.
○ This statement describes a high level function that the TVC must perform.
○ Statement has form of Actor – Action Verb – object acted on

Performance Requirements define how well the system needs to perform

the functions
• Example: The TVC shall gimbal the engine a maximum of 9 degrees, +/- 0.1 degree

Constraints are requirements that cannot be traded off with respect to cost,
schedule or performance
Example: The TVC shall weigh less than 120 lbs.

Interface Requirements
Example: The TVC shall interface with the J-2X per conditions specified in the CxP 72262 Ares
I US J-2X Interface Control Document,

Environmental requirements
Example: The TVC shall use the vibroacoustic and shock [loads] defined in CxP 72169, Ares 1
Systems Vibroacoustic and Shock Environments Data Book in all design, analysis and testing
activities.

Other-illities requirement types described in the SE Handbook include:

human factors, reliability requirements, and safety requirements.

Attributes of Acceptable Requirements

Requirements Page 6
Attributes of Acceptable Requirements
A complete sentence with a single “shall” per numbered statement

Characteristics for each Requirement Statement:

• Clear and consistent – readily understandable
• Correct – does not contain error of fact
• Feasible – can be satisfied within natural physical laws, state of the art
technologies, and other project constraints
• Flexibility – Not stated as to how it is to be satisfied
• Without ambiguity – only one interpretation makes sense
• Singular – One actor-verb-object requirement
• Verify – can be proved at the level of the architecture applicable

Characteristics for pairs and sets of Requirement Statements:

• Absence of redundancy – each requirement specified only once
• Consistency – terms used are consistent
• Completeness – usable to form a set of “design-to” requirements
• Absence of conflicts – not in conflict with other requirements or itself

Requirements Page 7
Constraints and Goals
Thursday, September 22, 2022 11:03 AM

Requirements set constraints and

goals in the design and objective
space
->When designing systems we
always have tradeoffs between
performance, cost, schedule and risk
-> “Shall” … Requirements help
set constraints and define the
boundaries of the design space and
objective space
-> “Should” … requirements set
goals once “shall”
requirements are satisfied
->Two main spaces:
-- Design Space – the things we 1. “The house shall sleep
decide as engineers between 4 and 6 people”
--Objective Space – the things our 2. “The total build cost should
systems/products achieve and what be less than $550K”
3. “The house shall have at
our customers care about least 3 bedrooms”
4. “The house should have a
fireplace”

Requirements Page 8
Req. Decomposition
Thursday, September 22, 2022 11:04 AM

Requirements Decomposition, Allocation and Validation

Requirements are decomposed
in a hierarchical structure starting
with the highest level requirements.

These high-level requirements are

decomposed into functional and
performance requirements and
allocated across the system.

These are then further decomposed

and allocated among the elements
and subsystems. This complete set
of design-to requirements is
achieved.

At each level of decomposition

(system, subsystem, component,
etc.), the total set of derived
requirements must be validated
against the stakeholder expectations
or higher level parent requirements.

Requirements Page 9
Requirements Margins Management
Due to uncertainty during early design, must use
appropriate requirements margins (e.g. for mass, power,
memory etc…)

Margins are reserves, that are not allocated to subsystems

but are controlled by project managers

For example mass growth has been experienced in almost

all vehicle development programs

Mass growth can typically range from 10-60%

Depends on novelty of the project

Technical Requirements Definition Best

Practice Process Flow Diagram

Requirements Page 10
Requirements Page 11
Requirement Capture
Thursday, September 22, 2022 11:06 AM

Requirements Capture: Documents vs. Database

Where / how are requirements captured?

Low cost “easy” solution: Create a document (e.g. in MS Word or Excel)

to capture and revise the requirements. Use hyperlinks to link
requirements.

This works okay for smaller projects with dozens or a few hundred
requirements (e.g. about 3 levels of decomposition --> (7+/-2)^3 = 125 -
729

For larger projects with >1,000 requirements need to use a relational

database

Commercial Tools, e.g. DOORS are available (but can be

expensive)

Example of hierarchical requirements with links

R1.0 The system shall fit into a volume not exceeding 1.0 m^3
R1.1 The system width shall be between 0.5m and 1.0m (.9m)
R1.2 The system height shall be between 0.5m and 1.0m (1.0 - 1.1)
R1.3 The system depth shall be between 0.5m and 1.0m (0.5 - 1.0)
R2.0 The system shall be made entirely from Aluminum 6060 alloy
R2.1 The system shall not contain any internal voids or cavities
R3.0 The shape of the system must be a cube
R3.1 The angles between sides shall be 90 deg +/-1 deg
R3.2 etc…

Requirements Page 12
Derived requirement (linked)
R4.0 The mass of the system shall not exceed 2,700 kg
R4.1 The center of mass of the system must be located at least 0.25
meters from the edge of its volumetric envelope

R4.2 The mass of the system must be verified using a Mettler-Toledo

XYZ Bench Scale

Requirements Page 13
Req. Allocation
Thursday, September 22, 2022 11:07 AM

Requirements Allocation
Decompose system requirements into lower levels of
design.
Define all the lower level functions which must be performed to satisfy
the requirement

Create architecture of sub-components to provide those functions

Allocate a level of performance to each lower level function

Specify interface requirements to other sub-systems

Closure - Ensure that satisfaction of the set of requirements

at the lower level will guarantee satisfaction of the higher
level requirement.

Requirements Page 14
Requirements Allocation Process

Requirements Page 15
Concept Question
Thursday, September 22, 2022 11:08 AM

Concept Question
A balloon shall lift a payload of 1,000 kilograms, including its
own mass.
It can use either helium (ρHe=0.2 kg/m3) or hydrogen (ρH=0.1
kg/m3) as a lift gas. The standard density of air is ρAir=1.3
kg/m3.

rb= radius of balloon, mb = mass of balloon

Which of the following requirements is infeasible?

• The balloon shall have a radius of 6.1 meters. The balloon shall use
99.9% pure helium as a lift gas.
• The balloon shall have a radius of 5.9 meters. The balloon shall use
99.9% pure hydrogen as a lift gas.
• The balloon shall have a radius of 5.9 meters. The balloon shall use
99.9% helium as a lift gas.
• The balloon shall have a radius of 6.1 meters. The balloon shall use
99.9% hydrogen as a lift gas.
• All these requirements are okay.
• None of these requirements are feasible.

Requirements Page 16
Concept Question Solution

Requirements Page 17
Requirement problems
Thursday, September 22, 2022 11:09 AM

Common problems with requirements

• Writing implementations (“How”) instead of
requirements (“What”)
○ Forces the design
○ Implies the requirement is covered
• Using incorrect terms
○ Avoid “support”, “but not limited to”, “etc”, “and/or”
• Using incorrect sentence structure or bad grammar

Common problems
• Writing unverifiable requirements
○ E.g., minimize, maximize, rapid, user-friendly, easy,
sufficient, adequate, quick
• Missing requirements
○ Requirement drivers include

Functional Performance Interface

Environment Facility Transportation
Training Personnel Reliability
Maintainability Operability Safety

• Requirements only written for “first use”

• Over-specifying

Requirements Page 18
Verification
Thursday, September 22, 2022 11:09 AM

Verification
• Every requirement must be verified to ensure that the proposed
design actually satisfies the
○ requirement by
○ Examination,
○ Test,
○ Demonstration, or
○ Analysis

• Requirements documentation specifies the development phase

and method of verification

System Requirements Review (SRR)

• SRR is primarily a human / social peer-review process

• Main goal of SRR: Vet the requirements as written. Find

any missing, misstated, redundant or otherwise unsatisfactory
requirements.

Requirements Page 19
What happens at SRR ?
• SRR typically occurs rather early in a program, during Phase A
(Concept and Technology Development) and before Phase B
(Preliminary Design)

• Typically need to have the top two levels of requirements (L0 =

mission requirement / CONOPS), that is L1 (major systems) and
L2 (major subsystems) clearly defined

• Requirements need to be written down, validated and accessible

to everyone on the team (document or database)

• Requirements are put under formal configuration management

(=version control) at this point. Adding, deleting or modifying
requirements requires management approval. Systems Engineers
are very involved.

Requirements Page 20
Volatility
Thursday, September 22, 2022 11:10 AM

Requirements Volatility
Requirements Volatility is the degree to which
requirements continue to change during a project,
even post-SRR

% of addition, removal, modification of requirements per

time period
Variety of causes of requirements volatility (see below),
generally undesirable

Requirements Page 21
Software requirements
Friday, October 7, 2022 9:23 AM

1. Requirements Capture
• The goal of Requirements Capture is to understand, prioritize and document what the
customer really needs and to define the system scope and boundaries.

• The following activity diagram shows the process of how to reach this goal. Two
workflows; “Develop a Vision” and “Capture Requirements” cover the requirements
capture discipline.
• UC (use case) , UI (user interface)

1.1 Develop a vision

The goal of this workflow is to get an overall picture of the system to be build. Perform the
following activities:
1.1.1 Write a System Charter
Goal: Provide an overview of the Project and allow Management to decide whether to
continue or not (Go /NoGo). It is also a kind of letter of intention.

Structure:
► Introduction: Executive summary of the System Charter.
► Goals: Answers the question WHY the defined FR & NFR are delivered.
► Funct. Req.: A short description of what the system will do.
► Non Funct. Req.: A short description of the constraints that apply to the system as well

Requirements Page 22
► Non Funct. Req.: A short description of the constraints that apply to the system as well
as of the environment, users and other non functional issues.

1.1.2 Work on Domain Model

Goal: Allow the customer and the development team to synchronize their understanding
of the problem domain.

This model helps the development team to formulize its understanding. It doesn’t contain any
analysis conclusions. It is an informal model that does not need to be maintained!

1.2 Capture Requirements

The goal of this workflow is to capture the functional as well as the supplementary requirements of the
system. A requirement is either something the stakeholder asks for, something the team has a need of or
something that results from other requirements. In any case a requirement does not represent a solution!

1.2.1 Capture Functional Requirements (=> Create Use Case Model)

Goal: Describe how the user is going to use the system as opposed to describing the systems
functionality.

The Use Case Model fully specifies all functional system requirements. A Use Case describes a complete
course of interactions taking place between an initiating actor, the system and other participating actors.
It produces an observable result, having a value for the initiating or any other participating actor.

Process:
1. Find actors (start with the initiators) and describe them (Definition, Role, Responsibility)
2. For each actor find the use cases he may initiate.
3. Draw an initial use case diagram.
4. Specify goal & description for a subset of 2 (the architect performs UC selection).
5. Specify pre & post conditions for a subset of 4.
6. Specify basic flow, exceptional flows, alternate flows of 5. Use activity and sequence diagrams to
visualize your flows.
7. Rework UC-model e.g. draw several diagrams each focusing on a group of use case such as core,
utilities, services or any other classification. This grouping may be
shown with packages.
8. Structure the use case model by identifying <<extend>>, <<include>> relations or
generalizations between use cases.

1.2.2 Capture Supplementary Requirements

Goal: Capture additional requirements and constraints that have an impact on
how to construct the system.

Supplementary requirements can be classified as:

Requirements Constraints
Usability Design
Reliability Interface
Performance Physical
Supportability Implementation

Requirements Page 23
2. Analysis
The goal of analysis is to find a logical solution to all Use Cases(FR). This solution is documented
in an analysis model whose static view is shown with class diagrams and whose dynamic view is
shown using sequence and communication diagrams as well as through state machine diagrams.

The requirements analysis workflow has three activities: “Architectural Analysis”, “Use Case
Analysis” and “Consolidation of the Analysis Model”. The micro process is used iteratively during
the first two activities

2.1 Architectural analysis:

Goal: Define a candidate architecture in terms of classes and their relations and
stereotypical interactions in order to set the stage for the subsequent activity; “Use Case
Analysis”

2.1.1 Identify key abstractions (Classes)

Process:
1. Create a list of class candidates using one of the following techniques:
· Text analysis -> nouns, or noun phrases become class candidates.
· Brain storming sessions -> document classes using CRC-cards.
· Looking for: Places, interactions, roles, organizations, events, people, ..
· Using experience, analysis patterns, frameworks
· Use case realizations
2. Filter the candidates list to ~ 50 by eliminating candidates if:
· Two candidates represent the same concept
· The candidate represents a too general concept
· The candidate is an attribute or operation of another candidate
· The candidate is derived from another candidate
· The candidate is just irrelevant
· The candidate describes an implementation issue
· The candidate is not in scope
· .
Eliminated class candidates are not deleted. They serve as a repository of class names during
analysis, design, implementation and later increments.

3. Draw an initial class diagram

No emphasis on associations specifications or inheritance yet. The purpose of this diagram is to
get a graphical representation of the "surviving" classes. Often as a result of the drawing,
additional candidates can be eliminated.

Requirements Page 24
 2.1.2 Describe remaining classes through
· Definition describes the class in terms of what it represents.
· Role describes what the class is doing for other classes.
· Responsibility describes what the class is doing without being asked to

2.1.3 Work on class relations

Process:
1. Elaborate the analysis model by focusing on the associations.
· Ask if an association between classes are missing or superfluous.
· Label the association.
· Specify multiplicity.
· Specify aggregation semantics.
· Consider if aggregation is strong => Composition.
· Consider to replace label by Role Names.
· Provide textual description of the association specifying constraints and rules.
· Consider to add association classes. 32/39=0.8205
2. Elaborate the analysis model by working on generalization relations and assure that:
· Each generalization represents an is_a and not only an is_kind_of relation.
· Generalization trees are balanced.
· The derived classes extend and not restrict the base classes.
· The substitution principle is satisfied.
· Behavioral compatibility between derived and base classes is assured.
· Delegation was considered as an option.
· The right generalization was modeled (e.g. do 2 derived classes relate to the same
physical reality, or can an object change to another object during its lifetime?)

Requirements Page 25
2.2 Use Case analysis:
Goal: Prove that the static model (elaborated during architectural analysis) is capable of satisfying the
functional requirements. => model the dynamic system aspects.

Process:
1. Create a use case realization for each use case.

2. Supplement use case descriptions with eventually missing details required in order to offer a solution.

3. For each use case realization, draw at least one class diagram showing the classes
needed to realize the use case. Then draw at least one sequence diagram holding an
object for each of the required classes. This sets the stage for the next step.

4. Find operations for the classes involved in the use case. Do this using the following
approach:
· Create modeling mass by inventing operations for the classes. You do this by reading the class
description and deriving operation from the class’s role and responsibility.
· Draw sequence diagrams showing the required interaction, in order to satisfy the main flow as well as
the critical exceptional and alternate flows. In this process you will use operations identified in the
previous step, but you will also identify many missing operations.
· Focus again on the individual classes and identify additional missing operations.
· Model the state dependent behavior of the classes by drawing state machine diagrams. During this
process additional operations may be identified.

5. Complete class descriptions and assure that the operations fit the role and responsibility description of the
class.

6. Describe operations and identify class attributes

2.3 Consolidate and Review Analysis Model

Process:
1. Consolidate the analysis model As several designers could have worked
concurrently on several use case realizations, it may be that new classes have
been found or the same classes have been modified.

Therefore:
· Collect new classes and integrate them into the global analysis model
· Merge duplicate classes describing the same concept.
· Update the use case realizations accordingly.

2. Review the analysis model:

· Does each class have a definition, role, responsibility?
· Does each class have at least one operation?
· Does each diagram have a documentation?
· Is each operation documented?
· Has each association a multiplicity?
· Are all selected UC implementable with the existing classes, operations,
relations?

Requirements Page 26