The Importance of Establishing Requirements
You don’t have to be a process-heavy bureaucracy to do it well
There are many steps in the engineering process for producing a product, from ideation all the way through delivery to your customer. One of those important steps at the beginning is to ensure that you have a clear set of requirements.
Audience
This playbook is for those who don’t have a formal process yet for requirements management and is especially targeted for the scrappy startup trying to work quickly with limited resources and staff who may be tempted to skip steps.
Motivation
Establishing requirements ahead of your work is critically important for ensuring you’re going to get the product you need — on budget and on schedule. It defends you against scope creep where the scope you thought you were performing tends to grow — not because you like to spend lots of extra money and time, but because it’s easy to allow your story to morph as you perform the project. You think of features that the customer might want, or you think they really need. You can easily make the mistake of giving your customer something they don’t want — then they’re not satisfied and you lose them.
Surveys over the past decade by organizations such as the Program Management Institute (PMI) [ref 1] show that a third of project failures— not just going over budget or missing a deadline but failures — are because of ill-defined requirements. For those projects that didn’t fail, reviews suggest half of the project budget was wasted due to poor requirements management.
You’d think we’d all learn! But it is easy to do. Here are some reasons why. Check that none of them apply to you and you can beat the odds.
The trap of excuses.
Resources and processes are not in place. Surveys suggest only one-third of organizations’ leaders value requirements management as a critical competency [ref 1]. As a result, only about half of organizations have the required resources and processes in place. My intent is to convince you that requirements management is a critical activity to your success and performing it correctly does not have to take months of effort and will ultimately save you money and time.
Requirements are unknown. You may be in the early stages of development and profess you don’t yet understand your tech’s optimized capability or your customer’s needs and desires. You may be more in love with your tech than your customer and want to explore the performance rather than understand what the performance needs to be in order to ensure your customer needs are met. The problem here is that you might be focusing on the wrong performance metric to optimize. Early in development, you may not know all the requirements but you should at least know some key drivers so you know in what direction to take your product.
Everybody already knows the requirements. In some cases, this may be mostly true. However, your team may not be aligned on all of them or may misunderstand key drivers. Your designer may think his structural requirement is the most important whereas your thermal designer thinks her thermal requirement is most important. Now your team is working to solve different problems.
The task is simple so there is no need to “waste time” writing them down. The team knows what they’re doing. For example, you could be conducting a routine test — one with which maybe the team is very familiar. You trust that the team will do a good job. You trust that the team will be safe. You trust that the team has thought of everything. But in a startup environment, we are moving quickly and everybody’s wearing a lot of hats. Well-intentioned people make mistakes and forget critical things.
You don’t have enough budget and/or schedule! Spending time on requirements costs money — and takes time. It costs labor and takes time to write them down. It costs labor and takes time to review them. However, you don’t know your blind spots. That’s why they’re called blind spots after all. You can’t see that you’ve missed something. Inviting experts, which yes can be even more expensive, will help you identify those blind spots. Conducting a quick review where the team sits down with a non-advocate expert will ultimately save you money and time.
You fear becoming a bureaucracy. I think this is a valid fear. If you are not careful, you can fall down the hole of endless meetings, tons of paper, and frustrating unresolved TBRs (more on this acronym later). However, these are not reasons to avoid requirements management in its entirety. Through discipline, a few best practices, and eventually a good systems engineer, you can increase your project success rate while saving money and beating your schedule!
Where to start?
I recognize writing requirements is as much of an art as it is a science. There are entire books and professional organizations [ref 2] dedicated to this very important field within systems engineering. My goal is not to teach you how to write the perfect requirement here. My goal is to make sure you recognize that you need to spend some time on them. For those of you who are new to writing requirements or finally coming around to understanding the importance of writing them down, I offer some things to consider as a starting place.
Ask your customers. At Prime Movers Lab, we remind our founders to not fall in love with their tech. Rather, fall in love with your customers. What do they really want? Spend some quality time ensuring you understand this.
I used to work for Jeff Bezos at Blue Origin. He would tell a story around creating raving fans — and how we should focus on their requirements. He would tell us that nobody ever said, “Gee, I wish I had to pay more, or I wish my product took a long time to get, or I wish my product was late!” Inexpensive. Fast. And on-time. Those are great fundamental requirements. Your tech may be amazing but if your customer values other things — it doesn’t matter what your tech can do otherwise. He also emphasized that those requirements don’t change. Focus on the ones that don’t change to create a stable business.
Check your contract. Specific requirements can be found in contract documents, including statements of work and supplements like Data Requirements Descriptions (DRDs). If your work is funded by the government, you may also have Federation Acquisitions Regulation (FAR) requirements to flow to your team.
I was once surprised by a FAR commonly referred to as “Buy American” that limits the amount of government funds that can be used for non-domestic supplies to produce an end product. Luckily, in our small business, we had folks assigned to FAR sections according to their expertise. FAR reviews were conducted quickly and requirements were passed to the project team to ensure compliance. So we caught it! I ultimately had to pick some US-based suppliers to counter the funds I spent on specialty alloys produced only in Germany.
Identify what is most important. Don’t oversaturate yourself with a bunch of desires or nice-to-haves. Stick to what the customer really wants.
In some cases, you may decide to limit your scope. For example, if you have limited funding or schedule to prove out your tech like a Phase 1 Small Business Innovation Research (SBIR)grant, you may want to focus on just a few key feasibility questions. The requirements to address those feasibility questions will likely be a subset of the entire package required for the eventual Phase 3 commercial product.
In others, you may discover additional requirements for your ultimate business case that are really important, but not within your project budget. If so, you can have an up-front discussion and may consciously augment with approved, allocated internal funding.
Interface requirements. Identifying interfaces helps you to clearly define your system’s boundaries. Interface requirements also ensure agreement between stakeholders — i.e. who owns what and how they should “talk” to you. A simple diagram to augment your requirements list can speak volumes. As your project grows (in complexity, cost, etc.), you may choose separate, dedicated interface control drawings with values specified on the drawing or whole separate interface control documents.
Handling and storage requirements. These are another set of requirements that sometimes are considered too late. If a device is too heavy for a person to lift, then you’ll need to design features to interface with equipment like lifting hoists and overhead cranes. Not only should features be strong enough to carry their own weight, but they should also be located and designed to not interfere with design function, and/or any required installations.
Transportation loads should be considered if your hardware is sensitive to vibration and shock. Even if you design for what may be considered an extreme environment (like launching into space), your hardware may be excited by the vibrations transmitted during simple transportation in the back of a truck on the way to the launch pad!
Storage environments are another consideration. For example, I used Nafion (a type of fluoropolymer-copolymer) in acid scrubbers and humidity control systems. These membranes should be stored out of direct sunlight, and in clean, climate-controlled environments to ensure effective performance over their service life.
Designing for manufacturability (DFM). Too often, the design team will invite the manufacturing engineers late in the process, after the design trades are complete and they need a manufacturing engineer to sign-off on the drawing. DFM requirements are hard to write specifically. Usually, you want to employ tactics like minimizing part count and assembly operations, while maximizing standard parts, etc. The aim is to reduce manufacturing labor, ease procurement, and ease inspection. These all translate to reductions in cost, schedule, and risks for error. But “minimizing” and “maximizing” something can be difficult to verify.
To address this, you can have a requirement that shows the team did a DFM analysis to perform a trade between optimized product design and cost/time to manufacture. DFM varies across industries too because the product technology differs as does the manufacturing technology. Thus, your requirement may say something like:
Analysis shall be performed to assess DFM per [insert your favorite best practices guide or your own standard if you are a more mature organization with a process captured]
My Partner and Head of Manufacturing Bryan Bauw will write more on this topic in one of his future blogs!
Cost requirements. In a small team of eager engineers, it is easy to forget what I’ll call the non-functional requirements. Requirements are a way to help hold your team accountable for attributes like cost.
The end product shall cost no less than $x to produce
I remember early in my career a time when we had to build a testbed, and I didn’t write down the minimum viable product for the team. On the cost-constrained contract, I way overspent what was really needed. I got a (beautiful!) robust aluminum test stand when all I needed was McMaster-Carr nuts and bolts in plywood!
Safety and hazard requirements. I have been rightly accused of being overly optimistic. I didn’t often think about how someone can get hurt interfacing with the system or what could happen during a system failure (creating a hazard to facilities and/or people). Example considerations to get your safety and hazard juices flowing: touch temperatures, sharp corners, containment of explosive potential, protecting against arcing, and eliminating ignitions sources near oxygen-rich effluents.
One time, I was running a subscale spacecraft radiator test [ref 4], which required heated fluid at the inlet of the radiator (to simulate the heat removed, say, from a spacecraft cabin filled with people and computers). We attached heater tape to the radiator inlet tubing. A thermal controller signaled power to the heaters based on the radiator inlet fluid temperature. However, the fluid inlet temperature sensor failed (indicating room temperature and not the actual increasing fluid temperature). The heater controller of course didn’t know the sensed fluid temperature was wrong, so it dutifully pumped more and more power into the system to increase the temperature to reach our target inlet. The stainless steel tubing got so hot it melted (that’s hot!), vaporizing our coolant (a human hazard!). From then on, we included a test design requirement to independently monitor tube temperature such that if it exceeded a specified (high but safe) temperature, heater power was automatically shut off. Which brings me to ….
Test requirements. There are generally two flavors of test requirements. The first is to ensure you can collect data to evaluate the design. These development tests may require features that are independent of the hardware’s required functionality. For example, you may need to include a port for a temperature probe to validate a thermal analysis model. The analysis model can then be used to verify your final design (via analysis) and the awkward port is not required in the final hardware configuration.
The other is requirements on the design of the test itself (i.e. not the hardware) to ensure you achieve the test objectives and do so safely. For example, sometimes a performance requirement may not be directly measurable and thus other measurements are required to calculate performance. Consider the following requirement:
Radiator heat rejection (Q) shall be 1 kW +/- 0.1 kW
However, you can’t measure Q directly. Rather it is usually calculated:
Q = coolant mass flow rate x the change in temperature of the coolant
Thus, three measurements are required: the coolant mass flow rate, inlet temperature, and outlet temperature. Each of these sensors has an uncertainty associated with its measurement, which compounds! If the calculated measurement uncertainty is too large, the calculated performance may exceed the requirement due to uncertainty in the test! Thus, your test design must carefully consider sensor selection and its corresponding measurement uncertainties.
Writing good requirements.
There is a reason many are dubious about taking the time to write good requirements. Writing good requirements is hard. For those of us who are detail-oriented and strive for perfection, it’s easy to go down a rabbit hole and spend way too much time arguing over the nuances. Some of those nuances are important but you can quickly crossover and fight the enemy called “better” when “good enough” is… well… good enough!
I could write an entirely separate playbook dedicated to writing good requirements. There are many resources to help. One example is NASA’s systems engineering handbook [ref 5]. Your industry might have different resources. For those of you who are beginners or building startups that haven’t yet hired that valuable systems engineer, here is a list of my top mistakes to consider avoiding!
Write only one requirement per requirement. It’s easy to get into the trap of suggesting more than one requirement within a given statement. The risk is twofold: 1) You might miss part of the requirement during design execution. 2) Verifying you meet it gets complicated (tracking a “partially” satisfied requirement is tricky). Consider the (albeit simple) example:
Fluid temperature shall be 20ºC at 240 lb/hr
It is better written as two requirements:
Fluid temperature shall be 20ºC
Fluid flow rate shall be 240 lb/hr
Be specific vs vague. In order to give the team proper direction, you need to be specific in your values. In aerospace, we are always looking to minimize mass but writing a requirement that states the design “shall minimize mass” is useless direction (and it is difficult to verify — more on this later).
Specifying “less than” a max value is better. If you specify a specific target, don’t forget to include uncertainty. Hitting a number exactly is rare (impossible?) and providing a justified range of acceptability around that target communicates the importance (or not) of precision.
For example, in designing a heat exchanger in which a coolant will flow, minimizing the pressure drop across the heat exchanger lowers power on your pump driving the fluid through the system. Rather than just ask your team to minimize the pressure drop, provide a reasonable and valuable maximum tolerated value supported by analysis:
Pressure drop shall be less than 0.88 in H2O.
The flow rate through the system may be driven by an upstream system and we know the value but, of course, there will be fluctuations. Here we can specify a target with an allowable variation.
Flow rate shall be 35.8 cubic feet per minute +0/-4.8.
Early in product development, you may not exactly know the number. In this case, you can put a tag on it. If you are mostly sure, you can attach [TBC] for “to be confirmed.” If there’s still a lot of debate, you can attach [TBR] for “to be resolved.” TBR gets it written down and acknowledges there’s more work to be done (for example an analysis or a follow-up customer discussion). The point is, you’re not going to waste time worrying about whether the number is exactly perfect.
Another approach is to use design goals. I recommend this especially if you have in your technology development plan hardware iterations to allow for incremental improvement (e.g. gross experiments followed by demonstration hardware, prototypes, engineering development units, etc.). For example:
Power demand shall be less than less than 5W with a goal of less than 0.5W
Providing the ultimate goal informs the team how much work they have to do with a little relief knowing there will be other shots at the goal. Providing a design goal also gives context with respect to the other requirements to ensure a balanced approach in what you choose to be a driving requirement and push a lot of focus at that point in your development efforts.
Be careful not to specify the solution in the requirement! This is a trap I would fall into often, usually fed by a preconceived notion of what the design needed to be. A test you can give yourself is to ask, are there multiple ways to meet this requirement? If so, you’ve allowed your team the opportunity to be creative. If not, you could be over-constraining them.
There are times when it is appropriate to specify part of the design. For example, for the Boeing Starliner humidity control system we had a preliminary design in work, and I wanted to ensure the design was easily manufacturable as well as learn what machine tolerances were acceptable while hitting performance requirements [ref 6]. We designed a to-scale, sub-set manufacturing test article based on the design of the full-set unit. In this case, we did specify the material type to map specifically to the preliminary design.
Make requirements verifiable. A good requirement is verifiable with objective evidence that you can record and have validated by a non-advocate (like an expert not on your team, or your customer). There are typically four means for verification: analysis, demonstration, inspection, and test [ref 7]. As you write each requirement, I highly recommend you at least state which method you will use for verification (you can write the how later). This reduces the risk that you wrote a requirement that can’t be verified.
Provide rationale. You will thank yourself later! Specific numbers may result from various internal debates, long discussions with customers, or (better!) analyses. Not only is it common to not remember exactly from where the number originated, but those not familiar with those origins will also need the context to buy into the requirement. This is critical to ensure everyone is aligned! Providing rationale is also a great way to discover if you are over constraining or over stipulating the design. Here is an example test requirement of an internally reforming fuel cell that I was developing for in situ resource utilization (ISRU) on Mars [ref 8]:
Requirement: The test article shall use two different input gas compositions:
a. 99.99% pure H2 fuel and 99.99% pure O2 oxidizer
b. 99.99% pure CH4 (humidified per test procedures) fuel and 99.99% pure O2 oxidizer
Rational: H2 and O2 permit generation of a baseline polarization curve per industry standards. CH4 and O2 are expected from an ISRU-based propellant production system. Humidity will be added during testing to deter carbon deposition during the CH4 reforming. Determining the level of humidity is an objective of testing and is thus not specified.
Tailor your process as needed.
It is OK to tailor the effort to manage your requirements to match your scope! The amount of time that you spend should be commensurate with where you are in your project. In general, you may spend less time on projects that are smaller, less complex, have fewer cross-functional stakeholders, and have fewer interfaces.
Feasibility studies and analyses will likely only have a few driving requirements. Similarly, demonstration hardware may have only a few driving requirements. As the fidelity of your design increases, you might choose to spend more time on your requirements to make sure you have a complete set.
The criticality of the hardware may also influence the amount of time you spend on your requirements. For example, does human life depend upon it? Is the item of significant value? Consider the financial risk of conducting a set of quick, inexpensive experiments versus producing a million-dollar prototype. There is a schedule and budget risk when you consider a bad requirement resulting in additional design hours, assembly labor hours and part lead times. You might want to spend a little bit more time ensuring you correctly capture all of your requirements for the million-dollar prototype!
Review them — and often!
Now that your requirements are well-considered and written down, hold a review with your team and appropriate non-advocates. Non-advocates (relevant subject matter experts not directly impacted by the outcome of the review) can help check that the requirements are well-written, inclusive yet not overly restrictive, and appropriate for the scope and phase of the project. I often call this first review a Customer Requirements Review or CRR. Even if the work is internally funded, your CEO and founders are your customers! Take the time to ensure these requirements are captured and “good enough.”
Visit these requirements often to track progress to them and identify/agree with the team the need for requirement changes. This will help control scope creep! Reviewing them often keeps your eager business development colleagues from overpromising or your excited design team from adding features “because they can and wouldn’t it be cool!?”
When is it often? Any time you embark on a test design, an increment development design, documentation of a design analysis, etc. By the time you conduct your preliminary design review (PDR), TBCs and TBRs should be resolved and how to perform verification methods should be drafted. The PDR should explicitly call out these commits or changes, and review how verification methods are to be conducted. By the time you perform your critical design review (CDR), you should confirm how your design meets each requirement and you may even complete some requirement verification (like those verified by analysis). Others will require manufacture and qualification testing of the final design. You can build out a matrix pointing to the objective evidence as collected (an analysis report, a qualification test, an inspection report, etc.) for traceability.
You will always be checking for design compliance and scope creep — as well as discovery of poorly written or conflicting requirements because inevitably some will slip by you, usually because we all learn as we get smarter about our tech!
Prime Movers Lab invests in breakthrough scientific startups founded by Prime Movers, the inventors who transform billions of lives. We invest in companies reinventing energy, transportation, infrastructure, manufacturing, human augmentation, and agriculture.
Sign up here if you are not already subscribed to our blog.
References
[1] See Project Management Institute Thought Leadership at https://www.pmi.org/learning/thought-leadership. Specifically, The High Cost of Low Performance 2014 (2014) and Pulse of the Profession 2017 (2017).
[2] See the International Council on Systems Engineering (INCOSE) at https://www.incose.org/
[3] “Demonstration of a Stand-alone Solid Oxide Electrolysis Stack with Embedded Sabatier Reactors for 100% Oxygen Regeneration”, 41st International Conference on Environmental Systems, Paper AIAA 2011–5016, 17 July 2011–21 July 2011. Portland, Oregon, USA
[4] “Experimental Investigation of Stagnation and Recovery of Equal Length Tubes on a Facesheet”, 40th International Conference on Environmental Systems, paper AIA 2010–6162, 11 July 2010–15 July 2010, Barcelona, Spain
[5] NASA/SP-6105 NASA Systems Engineering Handbook, specifically Appendix C, How To Write a Good Requirement, https://www.nasa.gov/seh/appendix-c-how-to-write-a-good-requirement
[6] “Nafion Bundle Technology for Space Flight Humidity Control”, 45th International Conference on Environmental Systems, paper ICES-2015–153, 12–16 July 2015, Bellevue, Washington, USA
[7] [3] NASA/SP-6105 NASA Systems Engineering Handbook, specifically section 5.3 Product Verification, https://www.nasa.gov/seh/5-3-product-verification
[8] “Feasibility Tests of Oxygen Recovery Technology as an Internally Reforming Regenerative Fuel Cell”, 45th International Conference on Environmental Systems, paper ICES-2015–152, 12–16 July 2015, Bellevue, Washington, USA
