29 October 2007
Integrating
systems engineering
and
software engineering
Neil Siegel
Sector Vice-President, Technology
Northrop Grumman Mission Systems
National Academy of Engineering
1
Contents
 4 observations about integrating systems engineering
and software engineering
2
1. Integration through the development model
Traditional
1994 revision
Requirements
System
System requirements
System requirements
S/W
requirements
H/W
requirements
System design & validation
Element
Design
System design
S/W design
H/W design
S/W
requirements
H/W
requirements
S/W design
H/W design
The “1994” revision seems to lead to:
(a) better software / hardware trade-offs (b) smaller software implementations
3
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
4
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.
5
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
6
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
7