Post on 19-Dec-2015
1
29 October 2007
Neil SiegelSector Vice-President, TechnologyNorthrop Grumman Mission Systems
National Academy of Engineering
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