Lecture 5 - Requirements

1
2
 Topics
• Requirement Grammar
• Proper formation of requirements
• Definition of verification, certification,
qualification, validation
• Testability of requirements - ITAD
• Decomposition
• Level A, B, C
• Traceability matrices

3
 What is a requirement ?
• A requirement is a declarative statement of what a
system must do in order to meet its mandatory function
• A requirement must be able to be understood by itself
– It can reference other requirements or be in context of other
requirements
• A requirement must be stated so that the designed and
constructed system can be examined to determine if the
requirement was met or not
• A requirement does not proscribe how the system must
be designed or constructed.
– It only states what it is mandatory for the system to do
• Requirements should not be phrased in negative
statements
– Except for trivial cases it is impossible to examine a system to
determine if a negative statement has been met by a system
– “Impossible to prove a negative”

4
 Requirement Grammar
• English grammar has been perverted somewhat
for requirements specifications
• The word “shall” is normally grammatically only
used for first person declarative statements (“I
shall” or “we shall”) and the word “will” is used
for second and third person declaratives (“you
will”, “he, she or it will”)
• For requirements specifications, the word “shall”
indicates a requirement and the word “will”
indicates a non mandatory goal or desire

5
 Requirement Quiz – Specification for a
hypothetical “Astonisher Aircraft Model 505”

Statement Is this a Valid Requirement ?

Why ?
The Astonisher Aircraft 505 shall
carry 200 passengers and
baggage.
The Astonisher 505 shall never
crash.

The Astonisher 505 will carry 2000

lbs of fuel.

The Astonisher 505 shall be the

most comfortable aircraft in
service by the year 2010
6
 Requirement Quiz – Specification for a
hypothetical “Astonisher Aircraft Model 505”

Statement Is this a Valid Requirement ?

Why ?

The Astonisher Aircraft 505 shall Yes – proper use of shall,

carry 200 passengers and requirement can easily be
baggage. determined by inspection
The Astonisher 505 shall never No – uses a negative in a
crash. requirement - although avoiding
crashes is a valid goal, how can
you ever prove that it will never
crash
The Astonisher 505 will carry 2000 No – uses the term will indicating a
lbs of fuel. goal

The Astonisher 505 shall be the No – can’t determine comfort.

most comfortable aircraft in Comfortable to whom ? In what
7
service by the year 2010 way ?
 Fixing the statements – Specification for a hypothetical
“Astonisher Aircraft Model 505”

Statement Better Requirements Statement

The Astonisher Aircraft 505 shall Fine as is

carry 200 passengers and baggage.
The Astonisher 505 shall never The Astonisher 505 shall contain a
crash. Ground Proximity Warning System
to reduce the risk of Controlled
Flight Into Terrain (CFIT).
The Astonisher 505 will carry 2000 The Astonisher 505 shall carry 200
lbs of fuel. lbs of fuel.

The Astonisher 505 shall be the The Astonisher 505 shall contain
most comfortable aircraft in service provisions for 50 percent more
by the year 2010 legroom than the minimum required
to carry a 95% american male
population 8
 Requirement Numbering
• All requirements are numbered for
unambiguous identification
• Sometimes the paragraph number where
the requirement resides in the requirement
specification is used
• Other times a simpler sequential
numbering is used

9
 Verification, Validation and Certification

Verification – Determination that an item meets its requirements

Validation – Determination an item meets its intended purpose in its
operating environment
Alternate definition – for models (e.g. Aerodynamic database),
design environments and simulations, validation is the
determination that the item accurately reflects the subject being
modeled ( i.e. it is a valid model or database)
Alternate definition – for software, validation is the determination
that requirements are correct and complete (i.e. it is a valid
requirement)
Certification – a formal documentation of the verification and
validation process. Certification requires review and assessment of
verification and validation records by a certifying authority.

10
 Example of Verification of Invalid
Software Requirement
• If the requirements are wrong, it is possible to verify that
the software is designed per requirement even though
the requirement is wrong
• For example
– Let’s say that for a function, the software must compute the
hypotenuse of a right triangle
– Proper equation is sqrt(side a^2 + side b^2)
– But if the requirements were in error and stated sqrt(a+b) it
would be possible to code the software and test the software to
requirements but the software is invalid
• This type of requirement error is very different from a coding error
• A coding error is where the code doesn’t correctly implement the
requirement

11
12
 ITAD – Inspection, Test, Analysis, Demonstration

13
From NASA/SP-2007-6105 Rev 1 Systems Engineering Handbook
 Types of Testing

From NASA/SP-2007-6105 Rev 1 Systems Engineering Handbook 14

 System Test
• Aerodynamic – typically subscale wind tunnel or drop model
• Acceptance – tests performed on each article as it is produced.
Used to verify workmanship not design capability
• Acoustic – submitting a design to a fluctuating pressure environment
– typically performed once for a design using large low frequency
speakers
• Burn-In – accumulating time on a production article to clear failures
due to infant mortality – see attached chart on bathtub curve for
reliability
• Characterization – typically performed once per design to
determine design capability
• Component – test on a single component versus integrated
assembly
• Electromagnetic Compatibility – to prove elements of a design don’t
interfere with other elements of a design and that they work together
(transmitter- receiver)
• Electromagnetic Interference – determine susceptibility to
interference or determine likelihood to emit interference

15
Burn-In Testing takes hardware to here prior to delivery

16
 System Testing (cont’d)
• Environmental – compatibility with design environment
(temp, pressure, vibration)
• Drop – typically to prove design capability for handling or
workmanship as an acceptance test
• Flow – flow liquids or gases through a system
• Functional – verify function of the system
• Go/No-Go – a test that may simply read static values
such as supply voltages and temperatures or may
actually function a system to determine its readiness to
perform an operation
• High/Low Voltage Limits – a check of voltages against
operating limits – normally a type of go/no-go test
• Integration – verifying performance when multiple design
elements are connected together
17
 System Testing (cont’d)
• Leak Test – load a system with liquids or gases and
pressurize to operational pressure to determine leak
rate. May be used in a cabin or crew volume for
pressurized cabins.
• Life Time/Cycling – typically a one time design
component test where a component is functioned
(usually between two states such as on/off, open closed,
started/stopped) to prove or determine the time between
failures
• Manufacturing/Random Defect – usually inspection or
functional test of a subset of components in a production
run
• Nominal – testing under normal operating conditions and
modes
• Off-Nominal – testing under unusual conditions or
operating mode
18
 System Testing (cont’d)
• Parametric – holding multiple operating settings constant and then
varying one parameter at a time to determine system response to that
one parameter
• Performance – similar to characterization test
• Pressure Cycling – pressurizing and de-pressurizing a system to
determine fatigue and fracture limits of structures
• Pressure Limit – Demonstrate static load capability – also called a burst
test
• Qualification – testing performed once per design that shows that a
design meets its requirements
• Structural – proving that structure meets static or dynamic loads. Also
used to describe test techniques to determine the structural dynamic
modes
• System – also called integrated tests although system tests may be one
subsystem at a time
• Thermal Cycling – heating a cooling cycles to simulate day/night or
seasonal cycles
• Thermal Vacuum – tests combining thermal with vacuum environment
(no convection for heat transfer)
• Vibration – can be design qualification for a maximum vibration
environment or a workmanship test at a lower g level for each 19
component
 How do we develop requirements ?
• Worst technique – a bunch of people
representing different stakeholders in a room
thinking stuff up (unfortunately also the most
common technique)
• Better – add expertise in critical disciplines,
historical data, comparison to other systems,
technical standards
• Even Better – add simulation and analysis
(technical, cost, schedule)
• Best – evaluate requirements through prototype
designs

20
 Decomposition example
• Requirement – To be able to transport 300
passengers and luggage from New York to
London without refueling in 8 hours or less

21
 Defining Equation – Breuget Range
Equation for jet engine aircraft

 V   L   Winitial


Range     ln
 C   D   W final


V True Cruise Speed in Knots
C Engine specific fuel consumption in lb fuel/hr/lb of thrust
L / D aircraft lift to drag ratio at cruise conditions
Winitial total aircraft weight at start of cruise
W final total aircraft weight at the end of cruise

So Range is a function of engine efficiency (naut mi/lb fuel/lb thrust),

aerodynamic efficiency (lift/drag) and
structural efficiency (lbs fuel  structure/lb empty structure) 22
 Requirements Analysis

• Typically we would perform a requirements analysis around possible

values to understand cost versus benefit
• New York to London – 3103 naut mile
• Historical search (Schaufele’s The Elements of Aircraft Preliminary
Design, Aries Publications, 2000)
– L/D for large commercial transports varies between 15.0 and
18.2
– Typical weights ratios for a commercial airliner varies from 1.2
(Airbus 310-200) to 1.8 (Boeing 747-400)
– Typical cruise airspeed is 460 knots – 7 hour flight
– Typical jet engine fuel rate is .6 lb/hr/lb of thrust
• Range of Performance
– Every variable picked at best for range = 8130 nmi
– Every variable picked at worst for range = 2078 nmi
• Design Solution with max L/D, everything else minimum value,
range = 2543 nmi
• Design Solution with max structural efficiency, everything else
minimum, range = 6759 nmi
23
 One Possible Solution

• A potential solution is
– Empty weight = 392,000 lbs,
– Passenger Weight = 88,00 lbs (275 lbs per passenger
(passenger, baggage, food, water, other personal
items) plus 20 person crew),
– Fuel weight = 389,000 lbs with a resulting weight ratio
of 1.8 (Boeing 747)
– L/D = 15.0, Cruise Speed = 460 knots, Fuel rate = .8
– Range = 5069 nmi – requirementt + 60%
• 50% margin in this equation would be normal at
the start of a design

24
 Requirements Decomposition

Range Requirement
300 passengers
for 3103 n mi
in 8 hrs

Aerodynamic Propulsion
Efficiency Structural Efficiency Fuel
Requirement Efficiency Requirement Capacity
L/D=15 Requirement C = .8, Requirement
Cruise airspeed = Weight Ratio = 1.8 Cruise airspeed = 389,000 lbs
460 knots 460 knots

25
 Bottom Line
• The best requirements have modeling or
analysis that substantiate them.
• Sometimes the best place to explain the
rationale or model substantiation is in in
requirements document right beneath the
requirements. Such rationale is usually in
italics.
• The purpose of decomposition is to
understand how top level requirements
flow into requirements for lower level
components
26
Satellite Requirements Decomposition – Space Telescope

27
 A,B and C Requirements & Derived Requirements

• Several levels of requirements normally exist in a system

• Level of detail distinguishes the levels of requirements
• Typically level A are system top level requirements – e.g. aircraft shall have 300 NM range
• Level B are intermediate level of detail – aircraft shall carry 389,000 lbs of fuel
• Level C are typically design-to requirements – aircraft shall carry fuel in 5 fuel tanks, 2 in
wing and 3 in fuselage to allow proper cg management at any fuel loading

• Derived requirements are those which are not explicitly stated but which can be
determined from application of engineering or mathematical principles to the stated
requirements
– E.g. fuel tanks in the wing shall be able to carry 100,000 lbs of fuel

• INCOSE Def - Derived Requirements. Those characteristics typically identified during

synthesis of preliminary product or process solutions and during related trade studies and
verifications. They generally do not have a parent function and/or performance requirement
but are necessary to have generated system elements accomplish their intended function.

• Carnegie Mellon CMMI definition - "Requirements that are not explicity stated in the
customer requirements, but are inferred from contextual requirements (e.g. applicable
standards, laws, policies, common practices, and management decisions), or from
requirements needed to specifiy a product component. Derived requirements can also
arise during analysis and design of components of the product or system.

28
 TBD and TBR
• A generally bad practice but sometimes you just have to do it
• TBD – to be determined – placed in a requirements statement
– Example - The aircraft will be able to fly TBD miles unrefueled
• TBR – to be resolved – placed after a requirements statement that is not
finalized or over which there is controversy
– Example – The aircraft will be able to fly unrefueled around the world (TBR)
• Typically TBD’s and TBR’s are catalogued in a table at the end of a
requirements document and tracked to resolution
– A plan should exist to get to resolution on each one
• In many cases a TBD or TBR represents something that people feel there
should be a requirement about, but about which there is not sufficient
knowledge to write a firm requirement
• Often projects have unresolved TBDs – this is an opportunity for bad things
to happen
– Shuttle requirements still have many TBDs after 30 years of flying
– Requirements with TBDs don’t really help anything – they don’t drive design and
they can’t be verified
• This should be viewed as a stopgap measure at best

29
 Traceability Matrices
• This is a table that links requirements to other
items such as
– Top level driving requirements or lower level more
detailed requirements
– Verification plans or verification tests
• There is not much engineering in this, it is book-
keeping
• They should be done at key milestones to make
sure everything tracks
• They are good hygiene but no more than that

30
Any Questions ?

31