INCOSE Spring 09
Adaptation of Commercial and
Defense Systems Requirements
Engineering Processes for Streamlined
Acquisition Programs
L. Keith Robinett
L-3 Communications
William D. Miller
Stevens Institute of Technology
April 4, 2009
INCOSE Proprietary Information
Limited Distribution
1
Topics
• Role and Value of Requirements
• Requirements Engineering Methods
and Best Practices
• Requirements Engineering Process
for Streamlined Acquisition Programs
Role and Value of
Requirements
NDIA Top Five Systems
Engineering Issues
1. Lack of awareness of the importance, value, timing,
accountability, and organizational structure of Systems
Engineering (SE) on programs
2. Adequate, qualified resources are generally not available
within Government and industry for allocation on major
programs
3. Insufficient SE tools and environments to effectively
execute SE on programs
4. Requirements definition, development and management
is not applied consistently and effectively
5. Poor initial program formulation.
NDIA, 2003
NDIA Program
Recommendations
1. Increase awareness of SE importance in early
acquisition phases. Realize that systems engineering is
not a “tailor able” option for programs.
2. Establish program to incentivize SE positions within the
Government
3. Research, identify and encourage use of SE tools for
architecture design and development
4. Synchronize directives for consistent requirements
development and development approaches in the
acquisition and requirements communities
5. Emphasize use of SE practice in initial program
formulation phases.
NDIA, 2003
US DOD and NDIA Top Five
Systems Engineering Issues
1. Key systems engineering practices known to be effective are not
consistently applied across all phases of the program life cycle
2. Insufficient systems engineering is applied early in the program
life cycle, compromising the foundation for initial requirements
and architecture development
3. Requirements are not always well-managed, including the
effective translation from capabilities statements into executable
requirements to achieve successful acquisition programs
4. The quantity and quality of systems engineering expertise is
insufficient to meet the demands of the government and the
defense industry
5. Collaborative environments, including SE tools, are inadequate
to effectively execute SE at the joint capability, system of
systems (SoS), and system levels.
NDIA, 2006
US DOD and NDIA Systems
Engineering Recommendations
1. Ensure effective SE practices are
institutionalized into program planning/execution
2. Ensure SE efforts are allocated schedule and
effort in early program life cycle phases
3. Ensure systems engineering practices and
resources are applied to define capabilities
required to satisfy the needs of the warfighters.
NDIA, 2006
Requirements Engineering
Methods and Best
Practices
Operational Requirements
1. Where will the system be used?
2. How will the system accomplish its mission objective?
3. What are the critical system parameters to accomplish
the mission?
4. How are the various system components to be used?
5. How effective or efficient must the system be in
performing its mission?
6. How long will the system be in use by the user?
7. What environments will the system be expected to
operate in an effective manner?
DAU, 2001
Systems Engineering Process
Standards in Common Use for
Commercial & Defense Systems
1. ISO/IEC 15288 Systems engineering – system life cycle
processes (ISO, 2002)
2. EIA-632 Processes for Engineering a System (EIA,
1999)
3. IEEE 1220-2005 IEEE Standard for Applications and
Management of the Systems Engineering Process
(IEEE, 2005).
Relationships Among
Standards and Documents
EIA-632 Systems Design
Process
EIA, 1999
Requirements Engineering
Process for Streamlined
Acquisition Programs
Streamlined Acquisition
Programs
1. Refers to defense programs for sustainment and/or
upgrade of a previously delivered (legacy) system
2. Baseline system performance is typically known and
well-understood for most legacy systems
3. In many cases, requirements for legacy systems are not
available
4. Extensively modified legacy systems bear little
resemblance to the original system
5. Streamlined acquisition programs often add functionality
to legacy systems via relatively short program schedule,
referred to as a Quick Reaction Capability (QRC).
Streamlined Acquisition
Program Activities
Evolutionary acquisition achieved via incremental requirements
determined from continual communication with customers and
stakeholders
Activities required to upgrade a system (DAU, 2001):
1. Benchmark the modified requirements for the upgrade and the
entire system
2. Perform functional analysis and allocation on the requirements
3. Assess the system capability and performance before the
upgrade
4. Identify and manage cost and risk factors
5. Develop and evaluate alternatives for the modified system
6. Prototype the chosen alternative
7. Verify the improved performance and new functionality.
Streamlined Acquisition
Program Approach
Start with traditional SE Vee model (Mooz and Forsberg, 2006)
Apply agile methodology to make SE processes as lean as possible to meet
QRC timelines
Requirements principles for streamlined acquisition programs (Wiegers,
2001):
1.
2.
3.
4.
5.
6.
7.
Don’t dig your hole any deeper
Practice new requirements engineering techniques
Reconstruct requirements selectively
Couple requirements development and testing
Follow your change process
Inspect down the traceability chain
Start now.
Use agile methods within the Vee mode for new functionality, followed by
traditional systems engineering methods for full system functionality
Agile Systems Engineering
Agile systems engineering is defined as “rapid user and
stakeholder requirements management, including
concept selection, architecture development, system
integration, verification, and validation in a
development environment characterized by swift
adaptation to changes, non-hierarchical baseline
management, and a notable absence of low-value
bureaucracy.”
Agile Key Characteristics
Turner, 2007
Streamlined Acquisition
Program Process Flow
Proposed process flow for airborne ISR streamlined acquisition program
Streamlined Acquisition
Process Flow Description
1.
Stakeholder or user needs for new system functionality are documented via Capability Requirements (CRs)
that capture top-level needs and are used as basis for the derived product bid notes used to provide
cost/scope estimates and product requirements used as input to the product development phase
2.
Functional test verifications provide a means to verify performance to requirements for individual
Configuration Items (CIs)
3.
Product integration verifies the subsystem products meet the product requirements while capability
integration verifies the new functionality at the system level meets the capability requirements
4.
New functionality is then integrated with the legacy functionality during mission systems integration
5.
System verification continues during ground test and validation is performed during flight test
6.
Agile processes are utilized for the new development efforts thru capability integration efforts, while a
traditional systems engineering process is used for mission system integration, ground test and flight test
7.
The preference is for completion of capability integration for all new functionality before mission system
integration begins, but that is not always feasible because some capabilities are completed before others.
8.
The risk is the system will not be mature enough for ground test, resulting in cost and schedule impact
9.
The rule of thumb is to perform as much integration testing in the lab as possible because it becomes more
difficult (and costly) to “integrate on the aircraft”.
Streamlined Acquisition
Requirements Metrics
1. Requirements trends
2. System definition change backlog trends
3. Requirements validation trends
4. Requirements verification trends
Streamlined Acquisition
Program Requirements
Process Flow
Customer/stakeholder involvement at each successive requirements phase
Streamlined Acquisition
Program Requirements
Process Flow Acronyms
Streamlined Acquisition
Requirements Flow Description
1.
Requirements engineering begins with the concept and user
requirements captured at a very high level in the Statement of Work
(SOW), followed by generation of the capability requirements and the
product requirements
2.
The interaction between each successive phase is bi-directional
indicating the recursive activities performed as the system
requirements are defined at each lower level and potential refinement
of requirements at the preceding higher level
3.
There is customer involvement at each successive requirements phase
4.
The proposed systems engineering process satisfies the key
characteristics of agile
Streamlined Acquisition
Program Modified Vee Model
Hybrid Systems Engineering
Vee Model
1.
For requirements allocation side of the Vee, the new capability requirements are assimilated into the
legacy system task list and the capability requirements are decomposed into product requirements,
followed by the product design and implementation phase
2.
The integration side of the Vee begins with Functional Test Verification (FTVs) to verify the
implementation satisfies the product requirements where the FTVs are formal “selloff” events from
developers to systems engineers and customers
3.
Agile methodology is utilized for the development/implementation/validation of the new functionality;
multiple FTVs can be held for each Configuration Item (CI) as new functionality is added; multiple agile
“loops” can be followed for each CI until the full functionality is implemented
4.
Product integration is accomplished when the suite of CIs required for each specific capability are
ready for product integration; following successful product verification, the full capability is integrated
during capability integration; the process is repeated until the capability is completed integrated
5.
Once all the new capabilities are integrated, the agile process is completed and is followed by an
overall traditional systems engineering process to verify and validate the new capability with the
existing legacy system functionality
6.
The mission system integration and ground test verify the full system capability against the system
task list
7.
System performance is validated against the system task list during flight tests
Conclusions
1.
Systems engineering processes for commercial and defense
programs are similar as both are governed by standards in
common use, i.e., ISO/IEC 15288, EIA-632 and IEEE 1220
2.
Detailed processes for requirements engineering include
elicitation of customer/stakeholder requirements and metrics to
assess quality of the requirements engineering process
3.
Hybrid systems engineering process incorporating both agile
and traditional systems engineering processes is used for
streamlined acquisition programs.
Questions?
L. Keith Robinett
L-3 Communications
William D. Miller
Stevens Institute of Technology
Keith.Robinett@L-3COM.com
wmiller@stevens.edu