Requirement Basics

A Bit More Detail

Every thinking animal on the planet uses requirements to guide their lives. They only want certain foods, they won’t go outside some region, and they look for certain qualities in their mates. It makes them efficient and keeps them focused on success. System engineers are only building on this natural tendency. 

Some people don’t like requirements and think they slow you down. Don’t listen to them! Bad requirements slow you down and no requirements end programs. Good requirements make everyone’s lives easier and help programs move quickly, especially at the end when you’re trying to prove to the customer they should give you more money.

Tautologically, a good requirement has a few requirements:

1. They say what should be done, not how it’s done: If you order food at a restaurant, you don’t go into the kitchen and tell them how to cut and cook things. You can tell them you want it hot or with extra cheese, but nobody wins when you micromanage. In fact, you may get terrible service and slow everything down.
   
   
2. They matter: If you order your food then tell them that they have to wear red shoes while cooking it, people are going to get mad. This sounds dumb, but these types of terrible requirements show up all the time. Make sure every requirement leads to a better product.
   
   
3. They give thresholds and margins: You could order your food and demand it’s precisely 32.3 degrees Celsius or you won’t accept it. It would be easier for everyone, though, if you agreed it had to be at least 32 degrees and not higher than 36 degrees.
   
   
4. They’re concise: Keep it short and simple. Long requirements lead to confusion.
   
   
5. They’re focused: One requirement should talk about one thing and one metric to judge it by. Don’t try to squeeze everything into one big requirement because you think it’s easier to manage. It makes it much more difficult to prove you’ve done the job when three things are wrapped up into one.

Good & Bad Requirement Example

Here are two good requirements for cooking chicken that meet the outline above:

1. The chicken shall be cooked to at least 165 degrees Fahrenheight (73.9 degrees Celsius)
   
   
2. Thermometers shall be calibrated to National Institute of Standards guidelines
   
   

Some people may want to combine this into one requirement, such as:

1. The chicken shall be cooked to at least 165 degrees Fahrenheit as determined by a thermometer calibrated to National Institute of Standards guidelines.

This would be a mistake! Don’t try to pack things in to lower your requirement count; make one requirement about what success looks like and one requirement on how to measure success.

For instance, what if you decide later that you don’t want to use that thermometer standard and the customer agrees? Because you’ve tied calibration to a meat temperature, you’ve got to change this requirement. And, since even medium-sized programs can have thousands of requirements, you could find yourself changing requirements again and again as the reality of building something complex punches you in the face.

This is a trivial example. Needing to change requirements happens often, though, and it can be an expensive and time consuming process. Plus, customers start losing trust in you if you keep asking to change things.

Traceability

Requirements need to link together to tell a complete story. One way programs do this is by having levels of requirements.The top level has the most important requirements directly from the customer and then lower level requirements derive from those and get more detailed. The way things flow from high level requirements down to lower level requirements is called traceability.

As an example, suppose the top level requirement is the customer wants a cucumber sandwich. The requirement could look like:

1. The restaurant shall provide a cucumber sandwich by 6 PM

But the customer does not want onions that it comes with, so you have a new requirement:

1. There shall be no onions on the sandwich

It wouldn’t make sense to call someone and, without ordering a sandwich, tell them you don’t want onions. They’re going to ask if you want to order a sandwich before you start changing things.

In this scenario, the second requirement is a lower level “child” of the top level “parent” requirement. In your software or spreadsheet where you write your requirements, you would link the child to the parent so you could trace things like why a requirement exists.

Big spacecraft programs can have dozens of top level requirements. Then a second level could have hundreds of child requirements that support delivering the top level requirement. And that level can have its own child level and so on. Big programs may have five or six (or more!) of these levels that result in thousands of requirements.

Curated Videos

1. https://www.youtube.com/watch?v=fGmFoKuu_Ag
   NASA and Saylor Academy produced a whole series on systems engineering. This episode talks through how you would build up a requirement using a real world example from Apollo.
   
   
2. https://www.youtube.com/watch?v=Yl_BYtuLfLg
   This is a second video on requirements from NASA and Saylor Academy. This one talks about traceability and how requirements must flow down from each other.

Curated Links

1. https://pressbooks-dev.oer.hawaii.edu/epet302/chapter/2-3/
   The University of Hawaii maintains a free online textbook for small satellites. This page on requirements covers the topic, provides examples, and has a few exercises at the end to test your understanding.
   
   
2. https://www.incose.org/docs/default-source/Working-Groups/infrastructure-wg-documents/003-requirements-management-pamphlet.pdf?sfvrsn=902c82c6_8
   The International Council on Systems Engineering (INCOSE) has put together a cheat sheet of sorts on requirements. Their list of what makes for a good requirement is at the end of the second page.
   
   
3. https://www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf
   Appendix C of NASA’s (great) Systems Engineering handbook has a list of what makes for good requirements.