Requirements Allocation in Systems Engineering

Requirements flowdown allocates system functionality to subsystems.

Assuming that the systems engineering has resulted in a good job of defining the requirements for the system, the requirements management problem is still not complete. What of these subsystems? What requirements are to be imposed on them? In some cases, the process is one of assigning a system-level requirement to a subsystem. (For example, "Subsystem B will execute the wind speed algorithm and drive the heads-up display.") This requirements flowdown process is primarily a matter of making sure that all system requirements are fulfilled by a subsystem somewhere or by a set of subsystems collaborating together.

On Derived Requirements

Sometimes we discover that we have created a completely new requirements class ” derived requirements ” that must be imposed on the subsystem(s). Typically, there are two subclasses of derived requirements.

1. Subsystem requirements are those that must be imposed on the subsystems themselves but do not necessarily provide a direct benefit to the end user . (For example, "Subsystem A must execute the algorithm that computes the wind speed of the aircraft.")

2. Interface requirements may arise when the subsystems need to communicate with one another to accomplish an overall result. They will need to share data, power, or a useful computing algorithm. In these cases, the creation of subsystems also further engenders the creation of interfaces between subsystems (see Figure 7-4).

   Figure 7-4. Interface between two subsystems

   

But are these derived requirements "true" requirements? Do we treat them the same as other requirements? They don't seem to meet the definitions in Chapter 2 (although they may well meet the definitions of design constraints that we'll provide in Chapter 20).

The important thing to recognize is that these requirements, although crucial to the project success, are derived from the systems decomposition process. As such, alternative decompositions would have created alternative derived requirements, so these requirements are not first-class citizens in the sense that they do not reflect requirements that came from the customer. However, from the viewpoint of a subsystem supplier, they are first-class citizens because they reflect requirements imposed by the supplier's customer (the system developer).

No magic answer exists. How we treat these requirements is based on the development team's role in the project, the systems decomposition, and other technological factors. The important thing is "to know how we got here" and to treat derived requirements appropriately to the case since they will ultimately affect the ability of the system to do its job, as well as the maintainability and robustness of the system.

A Quiet Revolution

In industry after industry, the intelligence of the device has moved from the hardware components to the software components .

Systems engineering has traditionally been a discipline applied primarily to physical systems, such as aircraft and airframes, brakes and brake pads, power supplies and power-consuming devices, and so on. However, during the last twenty or so years , a quiet revolution has occurred in the systems engineering of complex systems. Gradually, in transportation, telecommunication, industrial equipment, medical equipment, scientific instruments, and many others industries, the systems and devices have become smarter and smarter . To meet this increasing demand for complexity and sophistication, more and more of the delivered functionality has become allocated to software subsystems rather than to hardware components. Software is softer , after all, and many algorithms for measuring, metering, assaying, and detecting are much easier, or at least much cheaper in terms of parts cost, to implement in software than they are in hardware. More important, they are much easier to change as they evolve .

So, in industry after industry, the innate intelligence of the device has moved from the hardware components, where they were previously implemented in a combination of electrical and electronic systems, mechanical systems, and even physical chemistry systems, to the software components, where they are implemented in software or firmware on microprocessors or complete minicomputer subsystems.

When Generations Collide: Graying Baby Boomer Meets Generation X-er

For decades, systems engineers were some of the most senior project engineers in the industry. Battle-scarred and field- tested , many of these senior systems engineers were specialists in specific disciplines, such as mechanical and electronic engineering, and many were some of the best generalists on the team. They had witnessed the largest disasters and had experienced many triumphs. Older and wiser, they knew the specific application domain ”radios, airplanes, HVAC, robotics , materials-handling equipment ”incredibly well and were also aware of the differing technical, economic, and political facets of technology implementation.

Suddenly, a new breed of individual invaded their turf. These newcomers ”the programmers , or on a good day, software engineers ”were relatively inexperienced in complex systems and didn't know weight and balance or global systems optimization from their navels, but they could make a microprocessor sing in assembly language. In addition, they seem to have been formed from a different gene pool, or at least a different generation, which added the complexities of culture and generation clash to the systems engineering process. Many interesting situations developed.

For a while, the turf battle was even, and the systems engineers made the ultimate calls for systems partitioning and allocation of functionality. However, in many industries, software technology gradually took over, and systems engineering became dominated, at least in part, by the need to engineer for flexible software functionality within the system. There were a number of solid technical reasons for this transition. Over time, a number of facts became obvious.

• Software, not hardware, determines the ultimate functionality of the system and the success of the system in the end user's hands and in the marketplace .

• Software, not hardware, consumes the majority of the costs of research and systems development.

• Software, not hardware, is on the critical path and, therefore, ultimately determines when the system goes to the marketplace.

• Software, not hardware, absorbs most of the changes that occur during development and can even evolve to meet the changing needs of a system deployed in the field.

And perhaps most surprisingly:

• The cost of software development and maintenance, taken in the aggregate and amortized over the full life of the product, has become material to, or in some cases equal to or greater than, the contribution of hardware costs of goods sold to that holy grail of systems manufacturers: total manufacturing costs .

Many systems must now be optimized for software, not hardware, capability.

This last one was a killer because it meant the systems engineers had to consider optimizing the system not for hardware or manufacturing costs but for development, maintenance, evolution, and enhancement of the software contained in the system . This changed the game significantly, for now, the systems engineering had to be performed with one eye on the computers to be used. Often, this meant:

• Maximizing the system's ability to execute software by providing more than adequate computing resources, even at the expense of cost of goods sold, adding more microprocessors, RAM, ROM, mass storage, bandwidth, or whatever resources the system requires to execute its software

• Providing adequate communication interfaces between subsystems and ensuring that the communications mechanism chosen (Ethernet, Firewire, serial port, or single data line) is extensible, via the addition of software, not hardware

In turn , this change affected the requirements management challenge in two ways.

1. Each of these dimensions creates new requirements that the hardware system must fulfill in order for a successful solution to be built.

2. The bulk of the requirements problem moved to the software application.

Fortunately, at least for the latter point, that is the subject of this book, and we hope to prepare you well for this particular problem.

Avoiding the Stovepipe System Problem

This is all, or at least mostly, well and good. Dealing with systems of complexity requires nontrivial approaches, and a system of subsystems is a means to this end. Surely, the alternatives are worse ; we would end up with incredibly complex systems that no one could possibly understand, with indeterminate behavior, and design based on shared functionality, poor partitioning, and threaded code in such a way as could never be unraveled. Systems engineering seems like a good thing.

How does this affect requirements management? When the final tally is made, we may discover that subsystem requirements are far more numerous than external requirements, or those that affect the behavior of the system in the user's environment. In the end, we will invest far more in prioritizing, managing, and identifying the subsystem requirements than those that affect the end user. This doesn't seem like a completely positive thing.

And what happens if we don't do a good job of systems engineering? The system will become brittle and will resist change because the weight of the requirements assets will "bind" us to the implementation. Our subsystem requirements have taken control of our design flexibility, and a change in one will have a ripple effect in other subsystems. These are the "stovepipe" systems of legend, and such systems resist change. In their interfaces, the problems may be worse. If the interfaces are not properly specified, the system will be fragile and will not be able to evolve to meet changing needs without the wholesale replacement of interfaces and entire subsystems on both sides.

When Subsystems Are Subcontracts

A further complication often arises. Since subsystems are typically developed by different teams ”after all, that's one of the reasons we create subsystems ”the subsystem requirements and interfaces tend, in effect, to become contracts between the teams. ("My subsystem delivers the results of the wind speed computation in exactly this format. . . .") Indeed, in some cases, the subsystem may be developed by a subcontractor whose pay stub has a different logo from yours. In this case, our requirements challenge has left the system and technical context and has instead become a political "football." ("Darn. The requirements cannot be changed unless the contract is renegotiated.") Soon, the project can be all "bound up in its shorts." A word of warning: Many large-scale system efforts have met their death at the hands of this problem.

Addressing the Conundrum

What should we do? Well, doing a good job of systems engineering must be a primary goal when dealing with software applications that have system-level complexities. As you participate in this activity for software- intensive systems, you may want to consider the following recommendations.

• Develop, understand, and maintain the high-level requirements and use cases that span the subsystems and that describe the overall system functionality. These use cases will provide context for how the system is supposed to work and will make sure that you "don't miss the forest for the trees." They will also help ensure that the systems architecture is designed to support the most likely usage scenarios.

• Do the best possible job of partitioning and isolating functionality within subsystems. Use object technology principles ”encapsulation and information hiding, interface by contract, messaging rather than data sharing ”in your systems engineering work.

• If possible, develop software as a whole, not as several individual pieces, one for each physical subsystem. One of the characteristics of stovepipe systems is that on both sides of the interface (well or poorly defined), the software needs to reconstruct the state of key elements (objects) needed for making decisions on both sides; unlike hardware, the allocation of requirements to both sides does not represent a clear partition.

• When coding the interfaces, use common code on both sides of the interface. Otherwise , there will likely be subtle variations, often blamed on "optimizations," that will make this synchronization of states very difficult. Then, if the boundary between the two physical subsystems later disappears ”that is, systems engineering finds out that processors are good enough to support both subsystems A and B ”software engineers will have a hard time "merging" the two bodies of software.

• Define interface specifications that can do more than would be necessary to simply meet the known conditions. Invest in a little extra bandwidth, an extra I/O port, or some integrated circuit real estate to provide room for expansion.

• Finally, see whether you can find one of those graybeards to help you with your systems engineering. They've been down this path before, and their experience will serve you wisely. Besides, you might help close another generation gap in the process!

A Story: On Partitioning Large-Scale Software Systems into Subsystems for Distributed Development Teams

In class one day, Bill, an experienced software manager, approached us and stated his problem. We had the following dialogue.

B ILL :	We are building a large-scale application that runs on a single host system. Our development resources consist of two separate teams of 30 people each; one team lives on the east side of the river in New York City, and the other lives on the west side. The two teams have different managers and different competencies. How can we divide the work and create a system that will run when we are done?
U S :	Well, Bill, one way to think of this problem is as a systems engineering problem. That is, figure out how you would partition the system into two sensible subsystems. Call them East and West, and allocate requirements to the subsystems as if they were in separate physical systems. Define an interface, complete with the definition of common classes and common services to be used, that allows the two subsystems (applications) to cooperate to accomplish the overall system functionality.
B ILL :	But won't I have then created an arbitrary system that is not driven by true architectural concerns?
U S :	True enough, in the technical sense. However, separating concerns along project team logistical lines and specific competencies may be just as important.
B ILL :	But won't I also create artificial interfaces and a potential stovepipe system?
U S :	Yes, in a sense, but we'd recommend that you have the interface code for both sides developed by only one team. Otherwise, there will be a lot of redundant work done between the two teams. In so doing, you will indeed create new requirements for the system, including interfaces that would otherwise not have been necessary, or at least not as formalized as you will now make them. And yes, it's important to be aware of the stovepipe problem and to do everything you can to minimize coupling between systems and to minimize the political issues that are likely to result.