The Importance of Requirements in the System Engineering and Integration (SE&I) Process
What do I need? What must be accomplished? ◦ This is the essence of a requirement ◦ Seems simple enough
Every personal buying decision ◦ A requirement exercise ◦ If you can’t clearly define what you need, it’s unlikely you’ll be satisfied with the resulting purchase
You’re asked to give a presentation ◦ You aren’t given the date, place, time, subject,
attendees, or intent ◦ What are your odds of success?
2
Consistency The only way to get what you want Enables Faster, Better, Cheaper (if it can happen at
all) The alternative has proved repeatedly to be ugly
80% of product defects are rooted in poor
requirements
3
Rework and “Gold Plating” ◦ Schedule delays ◦ Cost growth
Examples ◦ Y2K “bug” ◦ Waste Management Inc. ($100M) ◦ FAA Advanced Automation System ($2.5B) ◦ Boeing 747 – 767 aircraft 777 – success (~15% spent on requirements definition) ◦ NASA’s labor distribution and tracking system
4
Culture ◦ Fix it later ◦ Pressure from management
Corporate Management Myths ◦ Everyone can write requirements ◦ Everyone knows what this project is all about ◦ Nothing can be done about bad requirements
Customers ◦ May not understand their own needs ◦ Poor communications ◦ Requirement developers forced to make assumptions ◦ May describe solutions, not needs
5
Scope Product
Develop Operational Concepts
Identify Interfaces
Write Requirements
Capture Rationale
Level Requirements
Assess Verification
Format Requirements
Baseline Requirements
Requirements Definition Process
6
7
Where Do Requirements Fit In?
Define Requirements
Design
Manufacture
Verify
Operate
8
Define the Scope FIRST ◦ Scope = What is germane to the project? What is the Need? What are the Goals and Objectives? What are your assumptions?
Document them explicitly Validate – reject/modify those that cannot be validated
◦ State the Business Case ◦ Operations Concept How will the product be developed, tested, deployed, and used?
◦ What are the Boundaries and Constraints? Cost, schedules, expertise, ethics, politics
◦ Must communicate Scope clearly and review regularly ◦ No clear Scope? (International Space Station) Multiple restarts Wasted dollars
◦ No boundaries? Divergence
◦ Work done before Scope definition: largely wasted ◦ Scope definition must be COMMONLY UNDERSTOOD
9
Scenarios describing how a product will be: ◦ Used ◦ Manufactured ◦ Tested ◦ Installed ◦ Stored ◦ Decommissioned
Software = use cases Spacecraft = Ops Plan or Design Reference
Mission (DRM)
10
Why develop Ops Concepts? ◦ Addresses the two major classes of requirement errors: Missing requirements Conflicting requirements
◦ Relatively easy to generate ◦ Almost everyone can understand them ◦ Builds consensus among stakeholders ◦ Reduces requirement debates later on ◦ Illuminates user interfaces ◦ Customers, users, fabricators: “Is the product feasible?” ◦ Lays the foundation for future verification testing
11
A complex system is made up of subsystems ◦ System = Highest Level ◦ Write System Level requirements first
Subsystems ◦ Number of lower levels = f(System complexity) ◦ Can’t write subsystem requirements until the
System function is well understood This problem plagued CEV
12
13 13
Requirements Flowdown at NASA Mission
Objectives
Level I Mission Reqts
Programmatics • Cost • Schedule • Constraints
Defined System Functional
Requirements Environmental
And Other Design Requirements and
Guidelines
Institutional Constraints
Assumptions System
Performance Requirements
Subsystem A Functional and Performance Requirements
Subsystem X Functional and Performance Requirements
Allocated Reqts Derived Reqts
NASA Headquarters
Implementing NASA Center
Level II
Level III
Why worry about requirement levels? ◦ Keeps low level requirements out of high level
documents May constrain System design options May prevent achieving optimum design ◦ Facilitates tracking and traceability Are the higher level requirements implemented at the
lower levels? Are there lower level requirements not justified by
higher level requirements? Potential “Gold plating” Are there missing requirements at the higher level?
14
15 15
Requirement Levels
System
Design
Design Design
Simulations Prototypes Models
Hardware Software Test
Equipment
System requirements define what the system must do.
System design: how the System will work and defines its segments.
Segment requirements define what each segment must do.
Segment design: how each segment will work and defines its
subsystems.
Subsystem requirements define what each subsystem must do.
Design
Allocation ◦ Identify the subsystems that will satisfy
System requirements ◦ Subsystem requirements must be
traceable to a “parent” requirement at the System level (or the next highest level) ◦ Orphans: lower level requirements not
justified by a higher level requirement
16
17
Allocation of Requirements
Reqt #33
Reqt #671
Reqt #366
Design
System Specification
Hardware Software Test
Equipment
Space Shuttle ◦ Development: 1970 – 1981 ◦ Service: 30 years
Max Faget had a vision ◦ We will build America’s next spacecraft ◦ Launch like a rocket, land like an airplane ◦ Reusable ◦ Low G-levels (3 Gs max) ◦ “Shuttle” back and forth to LEO Carry satellites Resupply Space Station Retrieve and service satellites
◦ Will have a crew of x, weigh y, and land at speeds < z ◦ Faget tasked a small team to flesh out his vision
Was the lack of ‘pervasive’ technology beneficial? ◦ Requirements were hand written ◦ Typed by secretaries (who served multiple engineers) ◦ Were reviewed up the line by a knowledgeable person
18
Took 25 years to complete ◦ Not all due to requirements issues ◦ Politics played a significant part
Two major restarts ◦ $500M overrun resulting in contractor change ◦ Political redirection to include international partners Primarily directed toward saving Russia Ended up saving the Space Station
Requirements written by a large team ◦ Shuttle lessons were consciously ignored ◦ Requirements integration a nightmare
Even Station users were invited to write requirements No experienced leader No well defined scope (vision) – open ended Ultimately, the Prime Contractor wrote the requirements
for NASA’s approval
19
20
Program Structure at NASA
ANTARES Project
ARES Project
ORION Project
Level III
Level II
X
X
X
A good requirement clearly states a verifiable and attainable need ◦ Need – someone has to deem it to be necessary ◦ Verifiable – by analysis, test, or demonstration ◦ Attainable – budget, technical, schedule ◦ Clear – cannot be misunderstood
Use standard requirement terminology ◦ Shall => Requirements ◦ Will => Statements of Fact ◦ Should => Goals
Shall is a powerful word ◦ Identifies requirements that must be verified ◦ Every Shall is contractually binding
21
Bad assumptions Specifying implementation instead of
requirements Describing operations instead of writing
requirements Using incorrect or ambiguous terms * Bad grammar or poor sentence structure Unverifiable requirements Using unverifiable words * Omitting requirements Over specifying requirements
22
Ambiguous words ◦ support ◦ et cetera (etc.) ◦ but not limited to ◦ and/or
Unverifiable words ◦ flexible small ◦ adequate large ◦ user-friendly easy ◦ appropriate quickly ◦ fast light-weight
23
Requirement # Document Paragraph Shall Statement Verification Success
Criteria Verification
Method Performing
Organization Result
xy.01 A401022012.08
2.1.3.1 In succession, for each axis, GN&C system shall command translation jets on for two secionds. S/C shall then coast for two seconds. GN&C shall then command Vs/c = 0 cm/s ± 0.1 cm/s.
S/C translates parallel to the active axis and final velocity is within the specified range.
Analysis and simualtion
GN&C TPS xx1
xy.02 A401022012.08
2.1.3.2 In succession about each axis, GN&C system shall rotate s/c 180 degrees (± 2 degrees) from its current orientation and hold that position for 30 seconds ± 0.05 degrees.
S/C rotates to the correct angle and is able to maintain its attitude within the specified range.
Analysis and simulation
GN&C TPS xx2
24
What Managers Say ◦ Adjust schedule ◦ Ambitious ◦ Aggressive ◦ Challenge ◦ Exciting ◦ Historical ◦ Learning experience ◦ Less than candid ◦ Opportunity ◦ New opportunity ◦ Project transfer ◦ Pessimistic ◦ Resource constrained ◦ Scenario ◦ Strong personality ◦ Strongly encouraged ◦ We
What Engineers Hear ◦ Slip Schedule ◦ Unlikely ◦ Very unlikely ◦ Dirty job that no one wants ◦ Frightening ◦ No one remembers why ◦ Mistake ◦ Boldface lie ◦ Problem ◦ Surprise ◦ Start project over again ◦ Most likely to occur ◦ Not getting done ◦ Fairy tale ◦ Obnoxious ◦ Ordered on pain of death ◦ You
25