1 29 October 2007 Neil Siegel Sector Vice-President, Technology Northrop 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 designH/W design System requirements System Element S/W designH/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