Systems Design - Requirements as Design

When designing a system as a systems engineer, we are not drawing diagrams for parts or identifying software classes to implement. We are typically operating at a level that includes at least a composition of software and hardware components. Requirements are the problem space for many engineers. From these requirements we synthesise a design that is appropriate for the engineering discipline we work within. For systems engineers involved in producing a design from requirements the solution space is often remarkably similar to the problem space: It is formalised as a set of requirements specifications.

Requirements Analysis, Logical Design, and Physical Design

When beginning to develop a system we go through the following processes:

Requirements Analysis is the process of establishing a system requirements baseline. This process is worthy of its own discussion and can generally be separated from the system design processes. I include it for completeness because it is something that the systems engineering team for a particular system or subsystem will include in their list of responsibilities.

After the team has established requirements baseline (sometimes known as the Functional Baseline) the real design processes begin. Different systems engineering standards and manuals will draw this differently. I’ll lay out what I was taught, what I practice, and what I believe to be the most effective approach:

  1. Come up with a physical design of the system (this is referred to in the diagram above as synthesis)
  2. Come up with a logical design of the system (this is referred to in the diagram above as functional analysis)
  3. Perform trade studies, analyses, and other activities

The nature of the “physical” design of the system depends on what system is being designed and at what level. The objective is to build up a model of “things”, and the connections between these things. Generally we talk about the “things” of a system as being subsystems. Some examples:

  • The subsystems of an aeroplane might include airframe, engines, fuel delivery, navigation, and so on and so forth
  • The subsystems of an enterprise IT system might include various business applications, services, a virtualised networking and virtual machine hosting infrastructure, and again so on and so forth

The identification of subsystems is important, and is not arbitrary. The normal kinds of engineering principles apply such as reuse, cohesion, coupling, information hiding, etc. The physical design usually cannot be derived purely from systems engineering practice or training. It is necessary to understand the type of system being built, and preferably to have some experience as to how the teams that will be responsible for delivering each subsystem are likely to relate to each other and how well the physical design facilitates those interactions.

The connections between subsystems are also critical to identify at this juncture. Firstly, they can be an effective measure of how effective the physical design is minimising coupling and maximising cohesion. Secondly, like the subsystems themselves these interfaces are not going to come out fully formed based on the design of the systems team. They will need to be refined and designed by the teams responsible for each side of the interface. Identifying them now and determining what they need to achieve will ensure that the design of interfaces (like the design of the subsystems themselves) is linked to actual customer need to avoid both gold plating and underengineering outcomes.

As well as connections between the subsystems, the system will have some interfaces that need to be allocated down to subsystems. These external system interfaces will each either need to be allocated down to a single subsystem to complete design of and implement or will need to be split into multiple interfaces and allocated down to multiple subsystems.

Once the physical design of subsystems and subsystem interfaces has reached at least a first sketch stage, the logical design will need to kick in. This process is straight from the systems engineering textbooks:

  • Choose a system requirement (starting with the most architecturally significant ones)
  • If this system requirement is met by only one subsystem: Copy the requirement down as a requirement on that subsystem
  • If this system requirement is met by a combination of subsystems: Come up with a design as to how the requirement is met by the subsystems. Common designs include:
    • The requirement is met independently by each subsystem: Copy the requirement down as a requirement on each subsystem
    • The requirement is met independently by each subsystem but they consume some kind of shared resource (cost, weight, tolerance, memory usage, CPU consumption, network bandwidth consumption, etc): Define how much of the resource each one gets. Copy the requirement down as a requirement on each subsystem with their allocation in place as part of the requirement. Note that some of the budget may be set aside for contingency and released incrementally over the course of the development.
    • The requirement is met by one subsystem providing input to another subsystem: Allocate a new requirement to each subsystem that defines their particular role in the interaction. If no physical interface exists between the subsystems, create one. Add a requirement on the interface to communicate the input from source subsystem to destination subsystem.

Requirements may not be the only element of the logical design. The design may include information models, models of processes that need to be performed, and a variety of other features. In the end, however, requirements allocated to subsystems and subsystem interfaces are the primary output of systems design. These are assembled into the allocated baseline for handover to the engineering teams for each of the subsystems. The engineering teams themselves may be systems engineers who will perform further requirements analysis and systems design, or it may be a domain-specific engineering team who will take the design straight from these subsystem requirements to specific drawings or code.

It may seem strange to operate as a team for whom requirements are both the problem space and the solution space of the engineering effort. I know back in my early days as a software engineer we had great insulated arguments about avoiding including design detail in requirements, and of course that’s true: We don’t want to include design detail of a particular system in that system’s requirements. That will often add risk to the project by limiting the design choices that can be made. What we do want to do is specify requirements on subsystems that reflect their role in an overall system requirement, in compliance with the system design.

To a systems engineer requirements are not simply a vehicle for stating what a particular system or subsystem must do. A list of requirements is a list of design decisions that have been made about the required properties of the system or subsystem in order for it do meet the need of the customer in the context of other subsystems and other systems. Requirements are complete to the extent that the recorded set of requirements results in a low risk that a solution developed to be compliant with these requirements fails to meet the underlying customer need.

Not all properties of a subsystem need to be identified as subsystem requirements. For example, the amount of memory provided by a hardware subsystem to a particular subsystem may not be defined at this level. Instead, we might specify the maximum cost of the hardware and the software as well as the level of performance required and other related factors. In doing so we can defer some of these decisions to the technical teams that are best placed to make the decisions. These deferred decisions that have an impact between subsystems will need to be specified as part of the Interface Design Descriptions agreed between the subsystem owners in compliance with subsystem and interface requirements.

As well as dealing with the traced requirements directly, a number of analyses may throw up new requirements. For example, a functional failure analysis may question what happens when a particular kind of input across a particular subsystem interface arrives late, out of order, corrupted, or not at all. New requirements may appear in the allocated baseline out of this process, either for the source subsystem and interface to ensure that these things do not occur or for the recipient subsystem to deal with the situation if it does occur. With these new requirements also come new verification requirements as to what testing or other steps need to occur on the subsystem before it is accepted for system integration testing.

After an initial design baseline has been developed that is believed to meet the system requirements, a series of trade studies can be performed to compare the properties of the baseline design to alternatives that may exist. After a number of iterations of this process the development of the subsystems themselves can begin in earnest. It is helpful during these trade studies or later when customer requests or subsystem development activities throw up questions or problems with requirements to maintain effective traceability between system and subsystem requirements across multiple levels of systems engineering activities. This allows the impacts of requirements changes to be quickly assessed across the project as a whole in order to manage change. This change process can also be assisted by ensuring that a specific individual is responsible for each system and subsystem requirements specification. When these individuals get together to sign off on the impact of a change, they are known as a Change Control Board.

Benjamin