overcoming customer constraints on requirements documents presented by: robert smole presented by:...

Overcoming Customer Constraints on Requirements Documents

Overcoming Customer Constraints on Requirements Documents

Presented by:Robert Smole

Presented by:Robert SmoleNovember 5, 2008November 5, 2008

Sub-Optimization of Systems Engineering

Sub-Optimization of Systems Engineering

2

AgendaAgenda

• Introduction

• Problem

• Approach

• Results

• Wrap Up

• Introduction

• Problem

• Approach

• Results

• Wrap Up

3

IntroductionIntroduction

• Systems Engineering– Means to enable the realization of

successful systems – best practices– Considers both the business and the

technical needs of all customers - constraints

• What happens when the ‘business needs’ constrain the ‘best practices’?

• Systems Engineering– Means to enable the realization of

successful systems – best practices– Considers both the business and the

technical needs of all customers - constraints

• What happens when the ‘business needs’ constrain the ‘best practices’?

4

Why Sub-Optimal?Why Sub-Optimal?

• Find a balance.

• Approach: Sub-optimal SE.

• Agenda: Communicate the value of SE.

• Goal: …to realize a successful system.

• Find a balance.

• Approach: Sub-optimal SE.

• Agenda: Communicate the value of SE.

• Goal: …to realize a successful system.

SystemsEngineering

Best Practices

CustomerConstraints

5

Size: Length-1092ft, Weight-97,000tonsCost: Approx. $5-6 Billion Construction time: 6-7 years Design time: Approx 6 years from Concept

A mobile, nuclear powered, survivable, A mobile, nuclear powered, survivable, sea-based super structure, capable of sea-based super structure, capable of accommodating approx 5000 accommodating approx 5000 personnel, managing 75+ air combat personnel, managing 75+ air combat vehicles, and conducting joint vehicles, and conducting joint operations. operations.

Nimitz Class CVN

HIGHLY COMPLEX AND CHALLENGING PROGRAMS DEMAND SYSTEMS ENGINEERINGHIGHLY COMPLEX AND CHALLENGING PROGRAMS DEMAND SYSTEMS ENGINEERING

6

Requirements Analysis

Requirements Model

R

Functional Analysis• Define high level FA from ORD• Define mission/operational performance• Decompose functions to lowest level• Allocate performance requirements to functions

• Develop FFBDs• Develop Operational Threads (sortie)

Operational Scenarios,Conceptual Behavior Models

F1 F5

F2 F3

F4

Physical ArchitectureAnalysis

• Define System Structure• Define Internal/External Interfaces • Determine Island Alternatives• Establish product baselines• Define system design constraints• Allocate functions to systems/components

Common Island Component Models

Components

Interfaces

System

• Analyze Design & Assess Risk• Cost Assessment• Conduct trade studies• Select Best Design Solution• Automatic Document Generation• Provide Metrics Reports

Product Evaluation and Document Generation

Analysis ResultsSRDs

• Determine common missions• Review top level requirements documents• Decompose ORD• Derive Ship system Requirements• Flowdown to system requirements•Derive Functional / Performance Requirements

R2R1

R1-1

NGSB-NN: Model-Based SE ApproachNGSB-NN: Model-Based SE Approach

7

Does our system as-designed and as-built meet the system requirements as-validated?

Verification

Develop Physical Solution

Develop Functional Solution

Perform Requirements Analysis

Requirements ProcessRequirements Process

Does the customer agree with our

interpretation of the requirements?

Validation

8

ProblemProblem

• Update a System Requirements Document

• Not configuration managed within the CASE tool.

• Contained some or all of: “will”, “shall”, “may”, & “should” within requirement text.

• Requirements within functional statements.

• Requirements not singular (more than one “shall”).

• Requirements not “stand alone”.– Definitions within the body of the document, not in appendix.– SRD used an outline format - multiple indents.

• Interface requirements not mapped to interfaces on diagram.

• Update a System Requirements Document

• Not configuration managed within the CASE tool.

• Contained some or all of: “will”, “shall”, “may”, & “should” within requirement text.

• Requirements within functional statements.

• Requirements not singular (more than one “shall”).

• Requirements not “stand alone”.– Definitions within the body of the document, not in appendix.– SRD used an outline format - multiple indents.

• Interface requirements not mapped to interfaces on diagram.

9

Communicate FunctionCommunicate Function

Function1

Function2

Communicate Orders 3

Function4

Function5

AND AND

10

Improper Use of the CASE ToolImproper Use of the CASE Tool

Function1

Function2

Communicate Orders 3

Function4

Function5

Requirement(s) Requirement(s) Requirement(s)

Requirement(s) Requirement(s)

Liabilities: Traceability, Verification, Decomposition

11

Requirements Imbedded within FunctionsRequirements Imbedded within Functions

3.1.3 Communicate Orders1) The _____ subsystem shall be the primary means of

communicating orders. 2) The _____ subsystem with interfaces to the _____ shall provide

supplementary communications.a) Main Deck Communications Capability

1) The _____ subsystem shall be the primary means of communication for the coordination of operations on the Main Deck.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

b) 2nd Deck Communications Capability1) The _____ subsystem shall be the primary means of

communication for the coordination of operations on the 2nd Deck.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

c) Engine Room Communications Capability1) The _____ subsystem shall be the primary means of

communication for the coordination of operations in the Engine Room.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

3.1.3 Communicate Orders1) The _____ subsystem shall be the primary means of

communicating orders. 2) The _____ subsystem with interfaces to the _____ shall provide

supplementary communications.a) Main Deck Communications Capability

1) The _____ subsystem shall be the primary means of communication for the coordination of operations on the Main Deck.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

b) 2nd Deck Communications Capability1) The _____ subsystem shall be the primary means of

communication for the coordination of operations on the 2nd Deck.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

c) Engine Room Communications Capability1) The _____ subsystem shall be the primary means of

communication for the coordination of operations in the Engine Room.

2) The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

12

ConstraintsConstraints

• The overall document format and layout had to remain consistent with the original document which was not consistent with standard SRD formatting.

• Definitions and lead-in statements had to remain in their relative location (could not move the definitions to an appendix).

• “May” was acceptable - there are some design targets that are not ‘hard’ requirements (they don’t have to meet these).

• The overall document format and layout had to remain consistent with the original document which was not consistent with standard SRD formatting.

• Definitions and lead-in statements had to remain in their relative location (could not move the definitions to an appendix).

• “May” was acceptable - there are some design targets that are not ‘hard’ requirements (they don’t have to meet these).

13

ApproachApproach

• Moved all the ‘requirements’ from Word to Excel.

• Parsed the ‘requirements’ from the functions.

• Separated multiple shall statements. (singular requirements)

• Placed definitions in Requirement Objects and marked the Verification Method as ‘n/a’ to identify it as ‘not a requirement’.

• Standardized on the use of “shall” to denote requirements.

• Moved all the ‘requirements’ from Word to Excel.

• Parsed the ‘requirements’ from the functions.

• Separated multiple shall statements. (singular requirements)

• Placed definitions in Requirement Objects and marked the Verification Method as ‘n/a’ to identify it as ‘not a requirement’.

• Standardized on the use of “shall” to denote requirements.

14

ApproachApproach

• Allowed the use of “may” for design targets (these are not requirements).

• Used the spreadsheet to provide a comparison to the baseline.

• Decided on an iterative approach to ‘fix’ the SRD.– Further changes to structure (ie, interface linking) in

future revisions.

• Migrated requirements to the CASE Tool (Cradle) and used this tool to generate the Rev B SRD.

• Allowed the use of “may” for design targets (these are not requirements).

• Used the spreadsheet to provide a comparison to the baseline.

• Decided on an iterative approach to ‘fix’ the SRD.– Further changes to structure (ie, interface linking) in

future revisions.

• Migrated requirements to the CASE Tool (Cradle) and used this tool to generate the Rev B SRD.

15

Result (example)Result (example)

3.1.3 Communicate OrdersThis function communicates orders

a) Communicate Orders - 1The _____ subsystem shall be the primary means of communicating orders.

b) Communicate Orders - 2The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

c) Main Deck Communications Capability - 1The _____ subsystem shall be the primary means of communication for the coordination of operations on the Main Deck.

d) Main Deck Communications Capability - 2The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

e) 2nd Deck Communications Capability - 1The _____ subsystem shall be the primary means of communication for the coordination of operations on the 2nd Deck.

………

3.1.3 Communicate OrdersThis function communicates orders

a) Communicate Orders - 1The _____ subsystem shall be the primary means of communicating orders.

b) Communicate Orders - 2The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

c) Main Deck Communications Capability - 1The _____ subsystem shall be the primary means of communication for the coordination of operations on the Main Deck.

d) Main Deck Communications Capability - 2The _____ subsystem with interfaces to the _____ shall provide supplementary communications.

e) 2nd Deck Communications Capability - 1The _____ subsystem shall be the primary means of communication for the coordination of operations on the 2nd Deck.

………

16

Communicate Function - RevisitedCommunicate Function - Revisited

Function1

Function2

Communicate Orders 3

Function4

Function5

AND AND

17

Proper Use of the CASE ToolProper Use of the CASE Tool

Function1

Function2

Communicate Orders 3

Function4

Function5

Requirement(s) Requirement(s) Requirement(s)

Requirement(s) Requirement(s)

Allows: Traceability, Verification, Decomposition

18

Wrap UpWrap Up

• Considerations– New Design? – Roll-over Design?– Commercially Available Products?– Integrating Other Systems?– System Complexity?

• Essentials– Interface Requirements.– Traceability.– Verification.

• Non-Essentials– Document Format/Layout.

• One step at a time = progress toward full SE

• Considerations– New Design? – Roll-over Design?– Commercially Available Products?– Integrating Other Systems?– System Complexity?

• Essentials– Interface Requirements.– Traceability.– Verification.

• Non-Essentials– Document Format/Layout.

• One step at a time = progress toward full SE

19