Sound advice - blog

Tales from the homeworld

My current feeds

Sat, 2011-Sep-24

Systems Design - Requirements as Design

When as a , 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 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:

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 .


Sat, 2011-Sep-24

An Overview of Systems Engineering

Over the last few years I have made the transition from focusing on software architecture to . It's a field that incorporates a number of different roles, processes, and technologies. No, it's not systems administrator with "engineer" patched on the end. This field does not have much in the way of overlap with qualifications such as Microsoft Certified Systems Engineer. To avoid confusion I often talk about being an INCOSE-style systems engineer. The International Council on Systems Engineering is the peak body for this kind of work.

There are two basic ways to look at what a systems engineer does. One is is top down while the other is bottom up. The bottom up perspective is roughly

When we build complex systems we quickly reach a level where one small, well-disciplined team is not sufficient to deliver it. A systems engineering team is one that sits above several nuts and bolts delivery teams. Their job is to coordinate between the teams by:

  • Instructing the teams as to what they each individually will need to build
  • Taking input from the teams as to what is feasible, and adjusting the overarching design as needed to deliver the system as a whole
  • Taking product from the individual teams and assembling it into a cohesive, verified whole in line with the design and end user requirements.

The top down perspective is a little more like this

Customers need complex systems built that no one team can deliver. Someone needs to sit as the customer representative ensuring that a customer delivery focus exists at every level of the design. That means,

  • Having someone who can connect low level design decisions to real customer requirements and need
  • Being able to eliminate gold plating in excess of the user need
  • Ensuring that the product at the end really does meet the user need

Systems engineering works across all engineering disciplines to coordinate their activities and to align them to customer needs. It adds a technical chain of command to a large project alongside the project management chain of command that maximises efficiency and minimises risk. While the core focus of project management is on controlling scope and budget, the core focus of technical management is on controlling quality, value, and delivery efficiency. Together project and systems disciplines work to control project risk.

INCOSE defines Systems Engineering as:

an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

  • Operations
  • Performance
  • Test
  • Manufacturing
  • Cost & Schedule
  • Training & Support
  • Disposal

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

Systems engineering is a recursive approach to deliver large projects that meet stakeholder needs.