mors wg: requirements traceability and adaptation

Unclassified

1 Unclassified

Risk, Trade Space & Analytics in Acquisition 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

2 Unclassified


WG4 Participants David Johnson Tom Loper Chip Mueller Chris Pernin Patrick Cantwell Jim Carr Cindy Noble Willard Stratton

• Frank Swehosky • Alan Bohnwagner • Brett Johnson • Eric Harclerode • Mike Nieman • T. W. Jackson • Dr. Shlomo Argamon • Tony Mckheen • Julia Sharkey

Unclassified

3 Unclassified


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

4 Unclassified


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

5 Unclassified


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

WG4 Impact of Requirements Traceability

Unclassified

6 Unclassified


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

WG4 Impact of Requirements Traceability

Unclassified

7 Unclassified


WG 4 Findings • There is currently no requirements traceability, in enough detail, from the

CBA through the retirement of the system

• 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

Materiel Solution Analysis

Technology Development

Engineering & Manufacturing

Production & Deployment

Operations & Support

IOC FOC

Capabilities Based Assessment

A B C

ICD AoA CDD CPD

= Lack of detailed traceability

MDD

Unclassified

8 Unclassified


Materiel Solution Analysis

Technology Development

Engineering & Manufacturing

Production & Deployment

Operations & Support

IOC FOC

Capabilities Based Assessment

A B C

ICD AoA CDD CPD

• 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.

MDD

WG 4 Findings

Unclassified

9 Unclassified


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 o Requirements Identification o Requirements Utilization

Life Cycle

Lev

el o

f In

volv

emen

t

User

Acquisition

“A cynical observation”

Unclassified

10 Unclassified


WG4 Findings Collaboration “Requirements Engineering is a Team Sport”

Translators are needed between operators and developers Create and sustain Community of Practice

Unclassified

11 Unclassified


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

WG4 Findings

Unclassified

12 Unclassified


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

WG4 Findings

Unclassified

13 Unclassified


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

14 Unclassified


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

15 Unclassified


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

16 Unclassified


Corruption

IO

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.

.

mors wg: requirements traceability and adaptation

Technology

trade space

production

requirements traceability

tysons corner

sheraton premiere

acquisition community

vawg4 impact

acquisition unclassified 19