Separate Requirements from Design Decisions

The distinction between requirements and design decisions is one of the key notions of System Engineering. Once you get this distinction and why it's so important, you'll understand what all the fuss is about.

In the broadest sense, a requirement is simply something that has been dictated to the designer; and a design decision is a choice that the designer has made. Requirements generally dictate what the thing has to do, while design decisions decide how it will do it. The two often get confused, partly because in a complex system hierarchy, high level design choices impose requirements on the system sub-components; so something that is a design choice at one level becomes a requirement at the next level down. However it is important to separate the two at each level. Each engineering task involves inbound requirements, design choices, and outbound requirements imposed on other modules or manufacturing processes. The process works best when every engineer thinks of their work as transforming inbound requirements into outbound requirements and deliverables via the design process.

I often find that much of the discussion in design reviews actually relates to requirements rather than to design decisions. It often becomes obvious that different reviewers have different ideas about what the item in question is supposed to do (i.e. the requirements), let alone how it is supposed to do it (i.e. the design). These disputes can only be resolved by stepping back to the requirements and reaching agreement on those before proceeding. In complex systems, requirements tracking can be a big effort, and there are tools available to help with this.

Sometimes the initiative to integrate system engineering into a companies' development process comes bottom up from one or more of the engineers, rather than top-down through management. Even if you're a junior engineer working in an engineering environment that doesn't use system engineering principles like the separation of requirements from design decisions, you can still apply this principle to your own work. If you're an engineer in such a situation, and your company has no formal (or even informal) requirements tracking process, I recommend that you start your new designs by listing your understanding of the requirements at the start of your design documents and initiating design reviews of your work. You'll find that your design reviews will flow much more easily by having engineers review your idea of the requirements. When others around you start to see the benefit, it will start to catch on; and before long you'll have transformed the efficiency of your organisation. Be the change you want to see in the world. And guess who other engineers will start coming to for advice on how to improve their processes? You.

Even in a System Engineering environment, concurrent engineering can require a designer to start work before the input requirements have “trickled down” to them. In the worst case, system engineering can turn into a cop-out where engineers complain that they never got their input requirements in time. In such a case, the engineer usually just starts designing anyway; which isn't actually a bad thing considering that you want to be doing concurrent engineering. The difference here is to get them to document their best guess at what the requirements are, and review them (hopefully with the system engineer in attendance) before they dive too deep into design.

---

Social Bookmark this page: