- 3.1 Failure Story: Sequential RPV Systems Engineering and Development
- 3.2 Success Story: Concurrent Competitive-Prototyping RPV Systems Development
- 3.3 Concurrent Development and Evolution Engineering
- 3.4 Concurrent Engineering of Hardware, Software, and Human Factors Aspects
- 3.5 Concurrent Requirements and Solutions Engineering
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5 Concurrent Requirements and Solutions Engineering
With respect to the content of the Feasibility Evidence Description view of the ICSM in Figure 0-6 in the Introduction, the term “requirements” includes the definition of the system’s operational concept and its requirements (the “what” and “how well” the system will perform). The term “solutions” includes the definition of the system–hardware–software–human factors architecture elements, and the project’s plans, budgets, and schedules (the “how” and “how much”).
For decades, and even today, standard definitions of corporate and government system development and acquisition processes have stipulated that the Requirements activity should produce complete, consistent, traceable, and testable requirements before any work was allowed on the solutions. Initially, there were some good reasons for this sequential approach. Often, requirements were inserted that were really solution choices, thus cutting off other solution choices that could have been much better. Or in many situations, developers would generate solutions before the requirements were fully defined or understood, leading to numerous useless features or misguided architectural commitments that led to large overruns. At the time, most systems were relatively simple and requirements were relatively stable, so that the risk of spending more time specifying them was less than the risk of expensive overruns.
However, the sequential requirements-first approach is a poor fit to most human approaches to practical problem solving. Figure 3-5 shows a representative result from a study of how people work when developing solutions, concurrently obtaining insights all the way from operational concepts to low-level solution components 11.
)
FIGURE 3-5 Human Problem Understanding and Solving: An Elevator (Lift) System Example
For more complex systems, teams of people will be similarly exploring and understanding multiple levels of problems and solutions and coordinating their progress, capitalizing on many insights that are not available if they are locked into a sequential, reductionist, requirements-first approach. Also, they will have difficulties in developing key evidence such as business cases for the system, which require both estimates of system benefits (needing information about the requirements), and estimates of costs (needing information about the solutions).
Further, as systems become more complex and human-interactive, users become less able to specify their requirements in advance (“Which decision aids do I want to see on the computer screen or in the cockpit? I don’t know, but I’ll know it when I see it”—the IKIWISI syndrome). Also, as users gain experience in interactively using a system, new requirements emerge that may not be supportable by the architecture developed for the initial requirements (e.g., capabilities to cancel or undo commands, produce trend analyses, or decision outcome predictions).
Such hard-to-specify or emergent requirements are addressable via prototyping or solutions exploration, but these are not allowed in literal interpretations of sequential, requirements-first approaches, which tend to get ossified by layers of regulations, specifications, standards, contracting practices, and maturity models. One of the authors (Boehm) found himself in the difficult position of having led much of the effort to define the sequential, waterfall-oriented TRW Software Development Policies and Standards in the 1970s, along with training courses, review criteria, and corporate public relations materials—and then trying to convince projects in the 1980s to use counterculture techniques such as human-interface prototyping (“Prototyping is not allowed. It’s developing solutions before we fully define the requirements”).
The ICSM’s principles and practices such as evidence- and risk-driven decision making provide ways to evolve to concurrent versus sequential requirements and solutions engineering. These considerations will be covered in the next chapter. Also, further details such as evidence-based process guidance are covered in Chapter 13. In addition, methods, processes, and tools for concurrent-engineering risk assessment and award-fee contracting are provided on the ICSM website at http://csse.usc.edu/ICSM.