Organizing Requirements of Complex Hardware and Software Systems


Although this book focuses primarily on software requirements, it's important to recognize that they are only one subset of the requirements management process in most system development efforts. As we described in Chapter 7, some systems are sufficiently complex that the only reasonable way to visualize and to build them is as a system of subsystems , which in turn are visualized as systems of subsystems, and so on, as shown in Figure 15-1. In an extreme case, such as an aircraft carrier, the system may be composed of hundreds of subsystems, each in turn having hardware and software components .

Figure 15-1. A system of subsystems


In these cases, a system-level requirements set is created that describes the system, such as fuel capacity, rate of climb, or altitude ceiling, as well as the system-level use cases that describe functional behavior, without knowledge of or reference to any of its subsystems. As we described in Chapter 7, once the requirements for the system are agreed on, a further systems engineering activity is performed. Systems engineering refines a system into subsystems, describing the detailed interfaces among the subsystems and allocating each of the system-level requirements to one or more subsystems. The resulting system architecture describes this partitioning and the interfaces among the systems.

The system design process itself creates new classes of requirements.

Next, requirements are developed for each subsystem. These should describe the external behavior of the subsystem completely, without reference to any of its subsystems. This process causes a new class of requirements, derived requirements, to emerge. This type of requirement no longer describes the external behavior of the system, except in the aggregate, but instead describes the exterior behavior of the new subsystem . Thus, the process of system design creates new requirements for the subsystems of which the system is composed. In particular, the interfaces among these subsystems become key requirements: essentially , a contract between one subsystem and another, or a promise to perform as agreed to.

Once these requirements are agreed on, system design is performed again, if necessary, by breaking down each of the subsystems into its subsystems and developing requirements for each. The result is a hierarchy of requirements sets, as shown in Figure 15-2.

Figure 15-2. Hierarchy of requirements resulting from system design


At every level, requirements from the previous level are allocated to the appropriate lower-level systems. For example, the fuel capacity requirement is allocated to the fuel control subsystem and to the fuel storage subsystem, and new requirements are discovered and defined as appropriate.

As seen in Figure 15-3, the lowest -level systems, that is, those that are not further decomposed, usually correspond to software-only or hardware-only subsystems. Further, any of the requirements in Figure 15-3 may need to undergo an evolutionary process as details become better understood .

Figure 15-3. Hierarchy of resulting requirements, including software and hardware



Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: