A Brief Introduction to Requirements

Despite the wide adoption of modern agile practices, formal engineering requirements remain important in many organizations. Formal requirements are often defined early in a project (i.e. before design and implementation), though they often evolve throughout the product lifecycle. They are important because project and industries that define formal requirements specifications tend to hold engineering teams accountable to meeting those requirements. Formal requirements can derive from industry regulation and compliance standards such as FAA regulations, FCC requirements, NIST cybersecurity standards, HIPPA compliance, PCI standards, etc. or be defined by engineering teams in collaboration with customers to capture project-specific constraints.

Writing Good Requirements

A requirement always has a “shall” or a “must” statement. The terminology tends to vary by organization or industry, but for our purposes a requirement should always use “shall”. A shall statement specifies a well-defined constraint on the system. The mnemonic SMART (Specific, Measurable, Attainable, Realistic, and Testable) provides a guideline for a well-written requirement.

I prefer to simplify this to three things:

1. Specific / Measurable – The requirement should be specific and preferably be quantitatively measurable. There should be a clear pass/fail answer of whether the requirement is met.
2. Attainable / Realistic – The requirement should be realistically achievable within the constraints of physics, cost, schedule, and within the context of other requirements.
3. Testable – There should be a way to test the requirement to verify if the requirement is met.

Every requirement should have all these characteristics. If not, something is missing and the requirement may not be achievable or verifiable.

Verifying Requirements

Requirements can be verified using one of four methods: analysis, inspection, demonstration, and test.

Analysis involves utilizing quantitative engineering analysis to verify that a system meets a given requirement. An example may be verifying an aircraft’s lift requirement using computational fluid dynamics (CFD) software or something simpler like a script to calculate that the battery life of a system meets the runtime requirement. The advantage of analysis is that it is generally cheaper than verifying a requirement through testing.

Inspection involves observing the system as-built or as-designed. For example, a requirement specifying that “the car shall be red” can be verified by looking at the built car. Or, inspection can look at a CAD model or design document to verify something like “the aircraft shall have a maximum wingspan of 3m”.

The lines between demonstration and test are a bit blurrier, but the description I was once given was that anything involving something more complex than a ruler or a stopwatch is a test, otherwise it’s a demonstration. In other words, a test involves specialized equipment, data collection, or data analysis. A demonstration doesn’t require anything special. For example, demonstration might be used to verify a requirement that states “the car shall be able to complete a lap in 1-minute” or “the airplane shall fly”. No specialized equipment is needed. On the other hand, something like “the system shall be able to withstand a pressure of 150 kPa” might require specialized test equipment to subject the system to specific pressures.

Derived Requirements

One of the hardest things when getting started with requirements is deriving more detailed technical requirements from higher level functional requirements. This often involves developing a more detailed understanding of the system concept or performing some preliminary analysis.

For example, a functional requirement specifying that a submarine needs to submerge to a depth of 100 meters gives us enough information to derive specific design constraints. Using the pressure equation, $P = \rho g h$, we find that the pressure will be ~981 kPa. Similarly, an imaging requirement for a satellite mission might constrain the orbital parameters or drive requirements for the imaging payload.

The takeaway is that deriving requirements often requires additional analysis of the system behavior to define more specific constraints.

Summary

The key to writing good requirements is to make sure they are specific and verifiable. Review the final requirements spec with internal and external stakeholders to validate that they cover all of the system needs and map clearly to functional needs and logical components. It’s important to think about verification when writing requirements and to look at each requirement within the context of the bigger picture to make sure the entire requirements specification is achievable.