1

29 October 2007

Neil SiegelSector Vice-President, TechnologyNorthrop Grumman Mission Systems

National Academy of Engineering

Integrating systems engineering

and software engineering

2

Contents

4 observations about integrating systems engineering and software engineering

3

1. Integration through the development model

System requirements

Requirements

S/W requirements

H/W requirements

System design

S/W design H/W design

System requirements

System

Element

S/W design H/W design

System design & validation

S/W requirements

H/W requirements

The “1994” revision seems to lead to:(a) better software / hardware trade-offs (b) smaller software implementations

Design

Traditional 1994 revision

4

2. Nature of the system requirements

Traditional approach: Both systems and software requirements are primarily functional requirements

My lesson-learned: Users often relate poorly to functional requirements

Resulting in lots of misunderstandings, misinterpretations A sign of a flaw: a system can meet all of the requirements, yet

still be deemed neither effective nor suitable Users seem to relate better to representations of their

desired business logic, e.g., “long mission threads” So, make the system requirements consist of those Plus: performance / capacity / port-to-port timing / reliability

5

3. Using operational measures to guide design

We tend to want to predict and measure the technical performance of our designs

We do this because our engineers often lack the domain knowledge create a mapping from operational parameters to technical parameters

We can’t run from this problem – we need to bring in the necessary domain knowledge to close this loop

Ideally, every design decision is driven by an assessment of its impact on operational performance and costs.

We normally skip too many steps, and depend on intuition that improved technical performance results in improved operational performance. There are too many counter-examples for that to remain a viable assumption.

6

4. A key systems engineering goal – often neglected

Achieving reliability in software We have long understood that simplicity is a hallmark of good

hardware design Data indicates that this is true in software, too Yet, we let software designs get very complicated, probably

because we do not treat designing for reliability in our software as a top-tier objective

Good systems engineering can bound the scope of the software effort, enabling the requirements to be met with simpler designs

This may be a key tool towards reducing the software-induced explosion of cost and schedule breaches

7

Summary

Have the system design and validation activity precede software requirements analysis

State the system requirements in representations that the operational users can understand

Use operational measures (not just technical measures) to guide design

Recognize that software reliability is a front-tier issue, and task systems engineering to help