In his article “The Systems Engineering Mindset, Problem Solving and Critical Thinking,” James Lackey makes the case that the principles of Systems Engineering can and should be practiced by everyone. In this article I’d like to expand on his point by taking a Systems Engineering tool and applying it to everyday life: Requirements.
We are all familiar with requirements: the new bike must have at least 10 speeds, the new shirt must fit properly, the apartment door must be able to be locked. For Systems Engineers, or anyone who deals with a complex system, requirements play a very important part: communicating to all stakeholders what needs to be done, and establishing a baseline for testing.
Suppose you are building a still, for historical research of course. You’ll need a bunch of different custom made parts. The top level requirement would be “We shall build a functioning still.” That tells everyone involved in the project what it is your building and also establishes a baseline test – to produce alcohol.
Next step is to dive deeper: What type of alcohol will be produced? How much alcohol needs to be produced in a day? Will we need to move the still? Does the still need to fit into an enclosed space, and if so, does that impose a height constraint? The answer to each of those questions is a requirement:
- The still shall produce moonshine
- The still shall be capable of producing 1 liter of moonshine per hour
- The still shall be portable
- The still shall be less than 2 meters tall
Note the format. Each requirement has the word shall in it. Each requirement is unambiguous. Each requirement can be verified. Good requirements are clear, concise and verifiable (I’ll say more about in the the V&V article). A separate comment might explain why the requirement exists:
- The still shall be less than 2 meters tall.
The still has to fit through a 2.1 meter door.
Here’s an example of a poorly written requirement:
- The still should produce lots of moonshine which is movable
How much is lots of moonshine? Which is movable, the still or the moonshine?
Chances are you won’t need to write requirements for your still. But projects that require large cross functional teams do benefit from a formal requirements document. It’s the best way for every team member to understand what is needed. And well written requirements establish testing to verify that the project does what it is required to do.