Requirements Volatility Topic:
Using Anchor Point Milestones
February 14, 2007
Tom Schroeder
FCS MGV Software Engineering Manager
BAE Systems, Ground Systems
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
1
Purpose
Frame a discussion about:
 What are the major software-intensive systems risks related to
Requirements Volatility with respect to experiences using Anchor Point
Milestones?
 What are the current best practices for addressing these risks?
 What are the top-priority research topics for addressing the risks?
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
2
Outline






Perspective - Company Background & Projects
Software Build 1 Lesson in Requirements
Idealized Software Build Life Cycle
Extending the Software Life Cycle to Systems and SOS Levels
Hard Questions to Answer about LCO’s and LCA’s
Sources of Requirements Volatility
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
3
Ground Systems – A Summary

Protected Fighting Platforms for Today’s Warfighter as well as
the Battlefield of Tomorrow
• Predominant Supplier to the U.S. Army Heavy Brigades with
•
•

Bradley, HERCULES, Paladin, M113
Mine-Protected Wheeled Vehicles
FCS Manned Ground Vehicles and Armed Robotic Vehicle
Key Technologies
• Advanced Protection and Mobility Solutions for Soldiers, Manned
•
•

Vehicles and Robots
Outstanding Program Management and Experienced Workforce
3,250 employees, including more than 600 technologists
World-Class Development Processes
• CMMI Level 5 Software and Systems Engineering Process
• Physics-Based Models & Real-Time Simulation Capabilities
• Rapid Prototyping of Complex Systems
 Lean, Cost-effective Production Facilities
GS is a modern, efficient, full-spectrum developer, integrator and supplier
of survivable, lethal ground combat platforms and advanced technologies
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
4
FCS Brigade Combat Team (BCT)
18 Integrated Systems + 1 Network + 1 Soldier
Infantry Carrier
Vehicle (ICV)
Manned Systems
Unmanned Aerial Vehicles
Class IV
Command and
Control Vehicle (C2V)
Class II
Class I
Class III
Mounted Combat
System (MCS)
Unattended Munitions
Unattended
Ground
Sensors
NLOS LS
Intelligent
Munitions
Systems
Reconnaissance and
Surveillance Vehicle (RSV)
Unmanned Ground Vehicles
Non-Line of Sight
Cannon (NLOS-C)
Non-Line of Sight Mortar (NLOS-M)
Small
(Manpackable) UGV
ARV Aslt
ARV RSTA
FCS Recovery and
Maintenance Vehicle
(FRMV)
Armed Robotic
Vehicle (ARV)
Medical Vehicle
Treatment (MV-T)
Medical Vehicle
Evacuation (MV-E)
ARV-A (L)
MULE
(Countermine)
MULE
(Transport)
FCS is about the 21st Century Soldier
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
Approved for Public Release, Distribution Unlimited, TACOM 20 SEP 2006, case 06-208.
5
Software Build 1 Objectives
 Build initial prototype vehicles for one vehicle type (“variant”), the NonLine of Sight Cannon (NLOS-C)
 Develop “threshold path” common components and software for a
common chassis.
• Hybrid Electric Drive Powertrain, Driving functions, Vehicle Management
• Power Distribution, Remote Interface Units, Servo Control Units
• Embedded Training
 Develop “threshold path” mission equipment and software for the
weapon and mission control functions
 Develop low-cost software and hardware “surrogates” to stand-in for
functionality that is not yet available, such as the sustainment system,
the displays and user interface system, etc.
 Develop and improve processes for software development and
integration
 Reduce risk for objective vehicles and software development
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
6
A Software Build 1 Lesson in Requirements


Systems Engineering selected a waterfall life cycle. Software Engineering selected an
iterative life cycle.
Software Engineering introduced a new event, Requirements Baseline Review (RBR) as a
handoff to receive the requirements allocated to Software from Systems & Subsystems.
RBR was not in the IMP, so it lacked completion criteria.
System /
Subsystem
Activity
Sys/Subsys Requirements Focus
Sys/Subsys Design Focus
DR1 (SFR)
DR2 (PDR)
RBR
Software Activity
Inception (Rqmts Focus)
Elaboration (Design Focus)
LCO
LCA
 At RBR, Software evaluated allocated Subsystem requirements. Quality issues resulted in
an intense three-month systems/software “RBR Recovery” effort, but LCO wasn’t allowed
to slip. Requirements rework was finally resolved during the first half of LCA, but it pushed
the LCA milestone out, reducing time for construction iterations.
Software Activity
RBR Recovery
LCO / DR2 Issues
LCO
Inception (Rqmts Focus)
During this period most
effort was needed to
develop SRSs and IRSs
February 14, 2007
LCA
Elaboration (Design Focus)
During this period, time for software
architecture work was too short,
resulting in an LCA slip
© 2007 BAE Systems Land & Armaments L.P.
LCA
Completion
7
Build 1 Common SW Schedule
2005
6
7
8
9
2006
10
11
12
1
2
3
4
5
6
7
2007
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12
SW Build 1 (Plan)
RBR
LCO
ER1
LCA
LCA
Start
LCO
ER2
ER3/TRR
B1 Common
SW Integration
Complete
ER3/TRR
B1 Common
SW Integration
Complete
LCA
Finish
SW Build 1 (Adjusted)
RBR
ER1
Develop LCA Required Documents
ER2
Detail External Interfaces
Develop SI Software Designs
Update MGV SW Architecture
Refresh LCA Design


An adjustment of iteration
durations was preferable to
inserting an iteration.
Turns out that systems and
subsystems engineering has
provided every subsequent
software iteration with necessary
updates, aka beneficial
“Requirements Volatility.”
February 14, 2007
Refresh LCA Documents
ER1 Software
Support Common Integ
Refresh ER1 Design
Refresh ER1 Documents
ER2 Software
Support Common Integ
© 2007 BAE Systems Land & Armaments L.P.
Refresh ER2 Design
Refresh ER2 Docs
ER3 Software
Support Common Integration
8
Build 1 LCO and LCA Statistics



LCO October 3-21, 2005
Participation by 68 Reviewers
• 10 IPT Areas Reviewed
• 55 Artifacts Reviewed
• 2059 Comments Received
60% of All Comments from SRS/IRS
• Most HIGH priority comments were



LCA Stage 1 February 16-27, 2006
LCA Stage 2 March 27–April 21, 2006
Participation by 83 Reviewers
• 11 IPT Areas Reviewed
• 68 Artifacts Reviewed
• 2499 Comments Received
submitted against the SRS/IRS
450
Undefined
800
400
Low
Medium
700
350
High
50
0
0
SRS
IDD
February 14, 2007
IRS
FR
SDD
SIP
ST
STP
Pr
ot
o
M
O
C
SA
D
Fe
as
i
TS
/
CO
P
100
SR
S
100
SI
P
Pr
es
en
ta
tio
n
150
200
D
200
300
isc
400
D
250
IR
S
500
bi
lity
300
Re
us
e
600
High
© 2007 BAE Systems Land & Armaments L.P.
Medium
Low
None
Arch
Design
Model
SADD
Positive Feedback
SDS
Common NLOS-C
SIP
SIP
Other
(blank)
9
A Software Build 1 Lesson in Requirements
 Why was LCO held steady?
• Award Fee tied to “successful LCO”
• Needed to hold schedule for some Subsystem software teams
• Systems/subsystems engineering functions would need support future
software iterations, although not explicitly in their plans to do so
 Why was LCA moved 6 weeks instead of adding a new cycle?
• Award Fee tied to “successful LCA”
• First part of LCA period dedicated to addressing requirements issue work
•
•
plans resulting from both RBR and LCO
Needed time to make software design progress to meet LCA criteria, and
customer willing to grant extension provided time made up in construction
iterations
An iteration no-go decision was not a viable option for the software teams
 Technologies in use were relatively mature, risks were manageable, and
vehicle schedules too important to move
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
10
Idealized Software Build Life Cycle
Start
DI 1.1
SW
Year 1
Year 2
SIT
SwLCO
DI 1.2
Inception
Phase
SW
SIT
DI 1.3
SW
SIT
SwLCA
DI 1.4
DI b.c
IOC
LCA
LCO
SI
SIT
SW
SwLCA
SwLCO
TRR
Acronyms and Abbreviations
Development Increment, Build b, Increment c
Initial Operational Capability
Life Cycle Architecture Milestone
Life Cycle Objectives Milestone
Software Item
Software Subsys/Sys Integration & Test
Software Engineering (incl. SI-Level Int & Test)
Software LCA
Software LCO
Test Readiness Review (SI Level)
February 14, 2007
Elaboration
Phase
SW
SIT
DI 1.5
SW
SIT
DI 1.6
SW
Construction
Phase
SIT
TRR
DI 1.7
© 2007 BAE Systems Land & Armaments L.P.
IOC
SW
SIT
DI 1.8
SW
SIT
Transition
Phase
11
Idealized Systems and Software Integrated Build Life Cycle
Start
DI 2.1
S/SS
Year 1
SW
SwLCO
DI 2.2 S/SS SW
Consider introduction
of Systems LCO and
DI 2.3 S/SS
LCA events.
Software support
would be a subset of
DI 2.4
Systems Engineering
total scope.
SIT
SW
S/SS
Acronyms and Abbreviations
Development Increment, Build b, Increment c
Initial Operational Capability
Life Cycle Architecture Milestone
Life Cycle Objectives Milestone
Systems/Subsystems (IPT) Engineering
Software Item
Software Subsys/Sys Integration & Test
Software Engineering (incl. SI-Level Int & Test)
Software LCA
Software LCO
Systems/Subsystems LCA
Systems/Subsystems LCO
Test Readiness Review (SI Level)
Inception
Phase
SIT
SyLCA
DI 2.5
February 14, 2007
By adding Systems & Subsystems
requirements and design engineering
stages synchronized with Software
development increments, upstream
work products can be worked
iteratively to support Software.
SIT
SyLCO
DI b.c
IOC
LCA
LCO
S/SS
SI
SIT
SW
SwLCA
SwLCO
SyLCA
SyLCO
TRR
Year 2
SwLCA
SW
SIT
Software can provide valuable
implementation feedback to Systems
& Subsystems teams, with preplanned learning adjustments.
S/SS
SW
SIT
S/SS
SW
DI 2.6
Construction
Phase
SIT
TRR
DI 2.7
S/SS
DI 2.8
© 2007 BAE Systems Land & Armaments L.P.
Elaboration
Phase
IOC
SW
SIT
S/SS
SW
SIT
Transition
Phase
12
Systems Lifecycle
System
System
Rqmts
Design
February 14, 2007
Subsystem
Rqmts
Subsystem
Design
Software
Rqmts
Software
Design
© 2007 BAE Systems Land & Armaments L.P.
Software
Code!
13
Systems Lifecycle
System
Rqmts
February 14, 2007
System
Design
Subsystem
Rqmts
Subsystem
Design
Software
Rqmts
© 2007 BAE Systems Land & Armaments L.P.
Software
Design
Software
Code!
14
Systems Lifecycle
Requirements are “realized” through design processes to become the next tier’s requirements which in turn are “realized” …
System
Rqmts
PIDS
SE AL0.2
Model
System
Design
Subsystem
Rqmts
SSDD
CIDS
ICD
‘L3’ Rqmts
in DOORS
SE AL1
UML Model
Subsystem
Design
SSDD
‘L4’ Rqmts
in DOORS
SE AL2
UML Model
February 14, 2007
SRS
IRS
Software
Design
SDD
IDD
Sw Integ
Threads
SW UML
Model
Work Products
= Influences
Software
Rqmts
SW Item
Design
Model
SADD
DDMs
SWARCH
Notes
© 2007 BAE Systems Land & Armaments L.P.
DDMs
Software
Code!
to the world
of integration
Code
SVD
What is the
turn-around
time to
change
requirement
s with this
process?
SDS
15
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
16
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
17
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
18
Workflow Integration
Construction Iteration ER1
(~4 months)
SW Mgmt & Env
Construction Iteration ER2
(~4 months)
SW Mgmt & Env
Improvement
SW Rqmts
SW Design
nt
SW I&T
Improvement
T Env
CMN SW I&T Env
Improvement
MN SW Int
CMN SW Int
Improvement
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
February 14, 2007
VNT SW I&T Env
Improvement
Improvement
VNT SW Test
© 2007 BAE Systems Land & Armaments L.P.
Improvement
VNT SW I&T Env
Improvement
VNT SW Int
Improvement
Improvement
CMN SW Test
Improvement
CMN SW
Improvement
CMN SW Int
Improvement
CMN SW Test
Improvement
SW I&T
Improvement
CMN SW I&T Env
Improvement
Improv
SW C&UT
Improvement
SW I&T
Improvement
Improvement
SW Design
Improvement
SW C&UT
Improvement
Improvement
SW Rqmts
Improvement
SW Design
Improvement
SW C&UT
Improvement
SW Mgmt & Env
Improvement
SW Rqmts
Improvement
Construction Iteration ER3
(~4 months)
Improvement
Improvement
Improvement
VNT SW Int
Im
VNT SW Test
19
Workflow Integration
Construction Iteration ER2
(~4 months)
SW Mgmt & Env
VNT SW Int
VNT SW Test
February 14, 2007
SW Design
VNT SW I&T Env
CMN SW Int
VNT SW Int
VNT SW Test
© 2007 BAE Systems Land & Armaments L.P.
CMN SW Test
SW I&T
CMN SW
VNT SW I&T Env
Improvement
Improvement
CMN SW I&T Env
SW C&UT
Improvement
Improvement
Improvement
Improvement
Improvement
CMN SW Test
SW I&T
Improvement
VNT SW I&T Env
SW C&UT
CMN SW Int
Improvement
CMN SW Test
SW Design
CMN SW I&T Env
Improvement
MN SW Int
SW I&T
Improvement
T Env
SW C&UT
Improvement
Improvement
SW Design
SW Rqmts
Improvement
SW Rqmts
Improvement
Improvement
SW Rqmts
SW Mgmt & Env
Improvement
SW Mgmt & Env
Construction Iteration ER3
(~4 months)
Improvement
Construction Iteration ER1
(~4 months)
VNT SW Int
VNT SW Test
20
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
21
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
SSys AL2 Rq
SSys Design
SSys Spec/Alloc
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
22
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Construction Iteration ER3
(~4 months)
Sys PIDS/AL1 Rq
Sys Design
Sys Spec/Alloc
SSys AL2 Rq
SSys Design
SSys Spec/Alloc
SW Mgmt & Env
SW Rqmts
SW Design
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Int
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
23
Workflow Integration
Construction Iteration ER1
(~4 months)
Construction Iteration ER2
(~4 months)
Sys PIDS/AL1 Rq
Sys PIDS/AL1 Rq
Sys Design
Sys PIDS/AL1 Rq
Sys Design
Sys Spec/Alloc
Sys Design
Sys Spec/Alloc
SSys AL2 Rq
Sys Spec/Alloc
SSys AL2 Rq
SSys Design
pec/Alloc
SW Mgmt & Env
SSys AL2 Rq
SSys Design
SSys Spec/Alloc
SSys Des
SSys Spec/Alloc
SW Mgmt & Env
SW Rqmts
SW Rqmts
SW Design
SW C&UT
SW Design
SW C&UT
SW I&T
T Env
SSy
SW Mgmt & Env
SW Rqmts
SW Design
MN SW Int
SW C&UT
SW I&T
CMN SW I&T Env
CMN SW Test
CMN SW Test
VNT SW I&T Env
VNT SW Int
VNT SW Test
CMN SW
CMN SW Int
CMN SW Test
VNT SW I&T Env
SW I&T
CMN SW I&T Env
CMN SW Int
February 14, 2007
Construction Iteration ER3
(~4 months)
VNT SW I&T Env
VNT SW Int
VNT SW Test
© 2007 BAE Systems Land & Armaments L.P.
VNT SW Int
VNT SW Test
24
Idealized System of Systems Build Life Cycle
Start
DI 2.1
SOS
Year 1
S/SS
SW
SOSLCO
DI 2.2
SIT
SyLCO
Year 2
SOSIT
SOS
S/SS
SW
SIT
SOSIT
DI 2.3
SOS
S/SS
SW
SIT
DI 2.4
DI b.c
IOC
LCA
LCO
S/SS
SI
SIT
SW
SOS
SOSIOC
SOSIT
SOSLCA
SOSLCO
SwLCA
SwLCO
SyLCA
SyLCO
TRR
SOS
Acronyms and Abbreviations
Development Increment, Build b, Increment c
Initial Operational Capability
Life Cycle Architecture Milestone
Life Cycle Objectives Milestone
Systems/Subsystems (IPT) Engineering
Software Item
Software Subsys/Sys Integration & Test
Software Engineering (incl. SI-Level Int & Test)
Systems of Systems Engineering
SOS Initial Operational Capability
SOS Software Integration & Test
System of Systems LCA
System of Systems LCO
Software LCA
Software LCO
Systems/Subsystems LCA
Systems/Subsystems LCO
Test Readiness Review (SI Level)
February 14, 2007
Very difficult to achieve!
SwLCO
SOSLCA
DI 2.5
Year 3
SyLCA
SOSIT
SwLCA
Elaboration
Phase
S/SS
SW
SIT
SOSIT
SOS
S/SS
SW
SIT
SOSIT
DI 2.6
SOS
S/SS
SW
SIT
Construction
Phase
SOSIT
TRR
DI 2.7
Inception
Phase
IOC
SOSIOC
SOS
S/SS
SW
SIT
SOSIT
DI 2.8
SOS
S/SS
SW
SIT
© 2007 BAE Systems Land & Armaments L.P.
SOSIT
Transition
Phase
25
Problems with SOS Staging

Synchronizing development to similar iterations across many organizations,
each with its own development processes, is extremely difficult
• Unsynchronized workflows increase the number “surprise” requirements changes

Greater numbers of participants tend to stretch out the iterations to make the
same amount of progress.
• Takes time to discover who to coordinate with, and if they have tasking to do so
• Organizations change, people move around, responsibilities shift, POC’s change
• Potential O(2) effect with more interactions and interfaces

Interface and scope negotiation across many associate teams adds activities
and stretches iterations.
• To make progress, teams are forced to make unilateral decisions
• From SOS perspective, may be sub-optimal or not even viable system-wide



Coordinating compatible requirements to achieve viable functioning threads
across associate contractors for small increments is difficult.
Incremental SOS use of tactical software can be prohibitively expensive in
terms of numbers of computers, simulators, emulators, and plant models
needed prior to long-lead time dedicated hardware being available.
Intellectual property protection, licensing, and legal involvement increases.
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
26
Hard Questions to Answer about LCO’s and LCA’s
What level of completion of Systems Engineering work products is needed for
Software to have a successful LCO?

A typical answer from Software: All requirements allocated to software need to
be specified. Reasons:
• If Software doesn’t keep up the pressure on Systems Engineering, the Requirements
•

provided to Software will be incomplete. LCO could fail.
If Software doesn’t have a complete set of requirements, Software will be unable to
complete SRS trace tables to parent requirements.
Obvious problem of handoff adequacy and criteria definition
• Software can try to create a risk that all necessary requirements will not be available
•
•
 “Cry Wolf” approach sure to fail at the Risk Review Board
Systems could create a risk that all the Systems work products will not be available
for software
 “Hit Me” approach never seems to emerge, either
What should the completeness and completion criteria be?
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
27
Hard Questions to Answer about LCO’s and LCA’s
What level of completion of Systems Engineering work products is needed for
Software to have a successful LCO?

A typical answer from Systems: All requirements allocated to software will be
specified, with traceability to upper-level models. Other documents will be made
available as reference (work in progress) leading up to System PDR:
• System Architecture which may include applicable DDM's, such as Vehicle
Electronics Architecture, System/Subsystem Schematics, Specialty Engineering
Reports (Security, HFE/MANPRINT, Safety, Maintainability), Sustainment and
Training Design Concepts
Thread based performance analyses
•
• Current Version of Common Subsystem and Variant Level S/SDD's
• Vehicle External ICD’s - Interfaces to all C4ISR, Sustainment, and Training supplied
subsystems.
• Vehicle Internal ICD’s – Interfaces to MGV Subsystems
• HW Configuration Item Specifications (HW CIDS - as available)
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
28
Hard Questions to Answer about LCO’s and LCA’s
What level of completion of Software Engineering work products is needed
for Software to have a successful LCO/LCA?
 To pass the LCO/LCA, what percent of the software requirements need
to be documented? How is that measured?
• What is the answer if there are a lot of requirements but the risks are
relatively low?
• What is the answer if there exist some risks, but feasibility analysis indicates
they are manageable.
 At what point should the requirements be baselined?
• Defines what to measure volatility against
• Drives how much time is spent in various SCCB’s reviewing requirements
changes during development iterations
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
29
Requirements Problems Specific to Software Intensive Systems
 Lines between systems engineering and software engineering activities
and work products are blurred
• System/Subsystem/Component Engineers can over-specify requirements,
•
resulting in limited or no opportunities for software engineers to optimize the
technical solution
Software Engineers conversely may make decisions on what should
properly be the purview of systems requirements, and may result in an
incomplete system solution
 What are proper requirement sets for various domains and levels is
often open to interpretation
• Especially when multiple organizations and cultures must interact
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
30
Volatility Concerns from Using UML for Requirements

UML sequence diagrams created by Systems Engineering to develop interfaces
and logical behavior requirements pose challenges
• A sequence represents only one path through a use case
• A full set of alternative use cases cannot be easily expressed in this form

Textual requirements in a DBMS serve as the “official” allocation of
requirements to software
• Some problems translating between use case steps and “shalls”
• Complete alternative use case specification always a problem
 In one case, factoring out alternative use cases into a use case or DDM titled
“Handle Operational Problem” is a concern.
– The Mother of all use cases/DDM’s.

Software teams are strongly encouraged to use full-up text-based use cases to
specify behavior
• Emphasis on handling all conditions and alternative/exception behavior
•
•
•
 Can be major feasibility driver!
Non-behavioral requirements sections of SRS must be completed
Everyone has a requirement to follow Software Design Standards (Architecture
Decisions) to address horizontal consistency.
UML is used for software design and detailed interface design
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
31
Measuring Requirements Volatility
 Mechanics of counting requirements changes
• Add requirement
• Delete requirement
• Modify requirement
 Modify can also be achieved by a delete followed by an add
 What is the requirements count measurement worth? What else could
be measured with more value?
• Consider statistics of implementation risk exposure, or estimated cost to
•
•
implement considering each requirement
Other measures: have observed ratios of SLOC/Requirements Counts from
9 to 300 for different SI’s on BAE Systems programs.
Have seen great volatility in requirements measurements caused by simply
revising same requirements to be more understandable
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
32
Source of Requirements Volatility: Requirements vs. Design
Two approaches, sometimes conflicting:
 Requirements are essential attributes of a system to meet the stakeholders
needs
• The requirements should represent an aspect of essential system behavior
• Similar systems should have similar levels of specification
• Avoid overconstraining the specification

Requirements describe whatever the stakeholders want
• A requirement can be specified at any level of the system
• A requirement for one system might be a design choice for a similar system,
depending on who the stakeholders are
Underlying assumption:
 The designer for a given system scope is granted authority to select and
optimize design elements to meet the requirements
 This requires negotiation and trust between the stakeholders
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
33
Sources of Requirements Volatility

Actors and Goals
• All actors were not considered
• All goals/subgoals of the actors and system were not considered

Stakeholders and Interests
• All stakeholders’ interests were not considered when the system was specified
 The system must enforce or protect these interests
 Frequent cause of requirements changes

Architecture-derived requirements
• Aspects of the selected architecture that must be specified for correct operation and
•

to meet quality attributes
Can be a strong driver of lower-level requirements
General causes of change
• A stimulus or condition that the system needs to respond to needs to be changed
• The system response to a stimulus or condition needs to change
• An architectural decision or constraint causes a change
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
34
Sources of Requirements Volatility
 The requirement was not obvious, unknown, or sometimes even
unknowable at the time of specification
 Sufficient resources to complete the baseline work were not available
 All aspects of the requirements effort were not performed
 Without feedback, the systems/software analyst polishes the
requirements until they are perfect (this can go on forever)
 Emergent behavior not predictable
 Changes in forces driving the market, threat, technology, needs
 Architectural and system quality attributes potentially drive foundational
changes throughout the system
 Middleware layers that are not transparent to functionality change
 COTS products that bring along their own set of requirements and
constraints
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
35
Some Mechanisms for Coping with Requirements Changes
 Build an architecture that is specifically designed to accommodate
changes within specified limits
•
•
•
•
Product line architecture approach
Extensible design patterns
Will cost more up front, payoff comes later
Cost/benefits analysis and estimation modeling needed to justify
 Prioritize requirements implementation as dependent variable
• SAIV, CAIV
• Hard to say no, but must make decisions
• Potential research areas: decision analysis approaches, strategies, toolsets,
decisions with uncertainty, decision-maker utility functions for consistency
and attitude towards risk
 Reserve budget (cost/schedule) for requirements changes as a function
of project parameters. How should this be calculated?
February 14, 2007
© 2007 BAE Systems Land & Armaments L.P.
36