MORS WG: Requirements Traceability and Adaptation

Risk, Trade Space & Analytics in Acquisition Unclassified
19-22 September 2011 | Sheraton Premiere at Tysons Corner, Vienna, VA

Working Group 4
Requirements Traceability and Adaptation
David E. A. Johnson, Center for Advanced Defense Studies
COL (Ret.) Tom Loper, USA AC, Ultra Electronics
Mr. Chris Pernin, Rand
Mr. Ervin “Chip” Mueller, AMSAA
19-22 Sep 2011

Unclassified 1


WG4 Participants
 David Johnson • Frank Swehosky
 Tom Loper • Alan Bohnwagner
 Chip Mueller • Brett Johnson
 Chris Pernin • Eric Harclerode
 Patrick Cantwell • Mike Nieman
 Jim Carr • T. W. Jackson
 Cindy Noble • Dr. Shlomo Argamon
 Willard Stratton • Tony Mckheen
• Julia Sharkey

Unclassified 2


WG4 Background
Definition and Terms of Reference

Traceability– linking attributes across a process or system– is necessary in
order to ensure:
 what is built meets original intent
 as the world changes, 1st, 2nd, and higher-order effects can be
captured and appropriate decisions made in a timely manner.

Unclassified 3


WG 4 Objectives

•Assess how well requirements traceability is integrated into acquisition life
cycle

•Assess potential improvements, analytical methods and decision processes
to enhance the use of bi-directional traceability

•Discuss and record issues related to regulation and governance that may
impinge on adaptation of requirements and use of traceability techniques

•Develop recommendations for how to enhance traceability in current
requirements processes

Unclassified 4


WG4 Impact of Requirements Traceability
If Not Done / Not Done Well
 Reference points, direction and context are subject to varied opinions
and interpretations.
 Leads to designs that don’t satisfy requirements. And don’t have
military utility that was originally envisioned.
 Leads to disconnects & mis-matched activities & methods (design,
dev., cost, T&E, …)
 Difficult to revise direction/to integrate
 Difficult to maintain schedule – admin
 Result in increased costs to construct ∆s, fix the mess, etc.
 Limit trades available, increase risks and result in failed management

Unclassified 5


WG4 Impact of Requirements Traceability
When Done Right
 Provides a more complete initial set of purpose/objectives (starting
point).
 Provides direction and context to System concept & development
(common view for User, Developer, DM, Analysis, T&E)
 Provides structured framework for analyses (CBA, AoA, Cost, Trades,
Risk)
 Captures internal & external incidents & the impact on requirements
and system development.
 Allows more structured approach to develop consensus changes
 Communicates the measures (cost, performance, schedule, new trades, new risks)
of interest
 Enables delivery of cost-effective systems that have positive military
utility 6
Unclassified


WG 4 Findings
• There is currently no requirements traceability, in enough detail, from the
CBA through the retirement of the system
M
D
D A B C IOC FOC
Capabilities Based Materiel Solution Technology Engineering & Production & Operations
Assessment Analysis Development Manufacturing Deployment & Support

ICD AoA CDD CPD

• CBAs and AoAs should be the primary analytic steps in the requirements
traceability process
• ICDs are often separated from the CBA
• AoAs are not used as a “linking” process between ICDs and CDDs

= Lack of detailed traceability
Unclassified 7


WG 4 Findings
• Requirements traceability must begin with the required capabilities
and end with the retirement of the system from the force
• Requirements traceability needs analytic updates based on
information changes with regard to: cost, schedule, performance,
assumptions, environment, threat, risk, etc.

M
D
D A B C IOC FOC
Capabilities Based Materiel Solution Technology Engineering & Production & Operations
Assessment Analysis Development Manufacturing Deployment & Support

ICD AoA CDD CPD

Unclassified 8


WG4 Finding
Numerous Requirements Management Software tools exist. WG4 identified
problem areas that limit the effectiveness of requirements management.
These areas are:

o Requirements Collaboration
“A cynical observation”
o Requirements Identification

Level of Involvement
o Requirements Utilization

Acquisition

User

Life Cycle
Unclassified 9


WG4 Findings
Collaboration

 “Requirements Engineering is a Team Sport”

 Translators are needed between operators and
developers

 Create and sustain Community of Practice

Unclassified 10


WG4 Findings
Identification
 Key Performance Parameters (KPPs) Must be re-examined
throughout the life cycle
 By User
 By cost and OR analyst
 By acquisition side
 Requirements are dynamic, explicit and implicit
 Plan for Requirements Uncertainty and Risk
 “Capability”/”Requirement” volatility can kill the program
 Document Constraints and Assumptions early and evaluate iteratively
 Capabilities, requirements, parameter, specifications require different
attributes for completeness

Unclassified 11


WG4 Findings
Utilization
 Process is not recursive enough and should be more flexible
 AoA is early trade space discussion, and should be continuous throughout
 Requirements volatility is an uncertainty/risk and impacts cost estimates
 Requirements volatility can indicate changes to assumptions and constraints that
should be documented and addressed
 Linkage between requirements , acquisition and programming needs improved

Unclassified 12


WG4 Findings
The traceability matrix for each requirement should include:

 Requirements source
 Rationale (context for raw requirement(s))
 Threat, environmental conditions, scenario
 Cost curve*
 Schedule
 Utility/performance curve
 Test needs
 Traceability should ‘work’ up, down, & horizontally

* Capture point value, if possible capture curve – likely not available at MS A

Unclassified 13


WG4 Findings

Cost estimation data, methods, values, and curves should be maintained
and updated within the traceability matrix. This will facilitate

 Earlier and more frequent analyses of costs and consideration of cost
drivers and their effects on program performance

 Tighter linkage between program cost estimates throughout the acquisition
process, including
 Cost Analysis Requirements Documents
 Independent Cost Estimates
 Earned Value Management

Unclassified 14


WG 4 Summary
 Requirements are a team sport – operational community, acquisition
community, budget community, test community, logistics community
 Analytic Rigor is needed – AoA should form the basis of periodic relook
 Performance Utility Curve, Cost Curves
 Recursive Analysis – Operational changes (threat, mission) to
Acquisition community,
 Recursive Analysis - Acquisition community changes (affordability,
schedule) to operational community
 Realistic Performance Thresholds
 Affordable, rapid acquisitions will require less aggressive technical
solutions
 Lower Performance Thresholds
 More Performance Trade-space

Unclassified 15


Final Thoughts
Requirements Analysis must support periodic
assessment of Risk, Cost, and Trade-space analysis to
permit the Department of Defense and the Services to
achieve operationally effective and affordable systems
delivered to the Warfighter in a reasonable time.

Corruption
.

IO

Unclassified 16

MORS WG: Requirements Traceability and Adaptation

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a MORS WG: Requirements Traceability and Adaptation

Semelhante a MORS WG: Requirements Traceability and Adaptation (20)

Último

Último (20)

MORS WG: Requirements Traceability and Adaptation