Every engineering project has requirements of some sort. Requirements encapsulate a common understanding of what is needed along with associated constraints and conditions. Requirements form the foundation from which development proceeds and downstream artifacts are generated. They are not optional.

But there is tremendous diversity in how to write requirements; each method has proponents and detractors. For example, some argue — for and against — writing requirements according to a template. Others argue — again, for and against — writing requirements that are atomic.

At QRA, we are proponents of both writing according to a template (essentially a style and format guide), and writing atomic requirements. Requirements are more fundamental so we discuss that here. Templates will be a future article.

By atomic requirements we mean “a natural language statement that completely describes a single system function, feature, need or capability including all information, details, and characteristics.”

The primary difference between atomic and non-atomic requirements is the concept of singularity. INCOSE (the International Council on Systems Engineering) also encourages the use of singular, or atomic requirements in their Guide to Writing Requirements.

The reason we are proponents of atomic requirements is that they mirror the rationale that many other organizations, professional societies, and individuals suggest. Atomic requirements are easier to understand and analyze and are more convenient for subsequent analysis and implementation. They do take more effort to write, but the built-in risk mitigation is often worth the effort.

Atomic Requirements also help with the following subsequent activities:

• Decomposition: The process of breaking down a requirement into its baser sub-requirements that would be required for the original requirement to be completed.
• Derivation: The process of writing requirements that were not explicitly stated in the stakeholder requirements, but they are required to satisfy one or more of the stakeholder requirements.
• Allocation: The process that takes place after decomposition and involves assigning lower-lever requirements to its higher-level counterpart. A higher-level requirement should be the sum of its lower-level requirements.
• Traceability: The ability to track and verify the relationships between different types of requirements, as well as between requirements and other items such as design documents, test cases, and code.
• Verification: The process of checking that the requirements are well-defined, complete, consistent, and unambiguous.
• Validation: The process of verifying that the requirements meet the stakeholders’ needs and expectations.

We discuss these benefits later in the article, but first, let’s look at an example.

Atomic Requirement Examples (and counter-examples)

Non-atomic requirements list multiple functionalities in one requirement. Sometimes this is obvious, and other times not.

Non-atomic requirement example:

Sometimes one step towards atomicity is taken by breaking out the steps explicitly:

[REQ-NA1] While the Garage Door is Open, the Garage Door opener shall

1. turn on the light,
2. display the open status on the display screen, and
3. wait in open mode.

Because this requirement specifies three different actions, it is non-atomic. For this (fake) example, it is pretty easy to make it atomic.

Atomic Requirement example:

An argument is sometimes made that making all requirements atomic means you now have many more requirements. Although it is true that the explicit number of requirements will increase, this is not really increasing the requirements. The non-atomic example above has the identical semantic content of the atomic example. It’s just that the atomic example explicitly enumerates each requirement, while the non-atomic requirement combines three into a single requirement.

In the atomic example, each requirement is clear, precise, and singular. The singularity aspect give additional benefits. It improves measurability, testing, naming, tracing, and accurate rankings. If you are looking to improve project execution, focusing on writing atomic requirements has a huge compounding effects. The greatest ROI may be found here.

Let’s dive deeper on the benefits of atomic requirements, starting with the most basic — better overall requirements.

Higher-Quality, Inclusive Requirements

Researchers Honig, Takada, and Noda studied (the lack of) atomic requirements specifically, and state that “the resulting text is more likely to be complete.”

It is difficult to write atomic requirements. The author must ask “is this a single requirement?” and “could something be missing?” for every possible requirement.  Often times when authoring, there is an inclination to rush onward to the next thought, the next requirement. Concentrating on one requirement at a time helps increase the likelihood of getting that requirement correct and high quality.

Quality requirements impact project ROI in a big way. The data doesn’t lie. See our case study on The High Impact of Poor Requirements.

Atomic requirements also contribute to requirement inclusivity. Sometimes, a project’s requirements and standards are written in paragraph form, with actual requirements sprinkled throughout the narrative in the form of “shall statements.” This format causes confusion as the reader is much more likely to miss a requirement or not assume responsibility for all included requirements. Atomic requirements ensure that all necessary requirements are included and clearly visible to all stakeholders.

Naming, Numbering, and Ranking

The singularity of an atomic requirement lends itself well to naming, numbering, and ranking. As projects increase in size, naming, numbering, and ranking become important to a project’s success. Atomic requirements with unique identifiers allows for easy ranking; users can quickly assess importance or priority.

If an engineer were to attempt to rate the non-atomic Garage Door requirement above, they may have some trouble. Maybe the Garage Door light is deemed critical in this project, but the display screen is not. There isn’t a way to indicate this importance using the non-atomic requirement. An engineer will have to decide if the light makes the display important enough to rank higher, or if the needless display screen would lower the importance of the Garage Door light. Neither of these options accurately ranks this requirement.

Tracking requirements and requirements churn is also simpler with atomic requirements. With non-atomic requirements, a single change now covers multiple functions, and the engineer must now spend more time investigating which function is actually affected by this single change. But with atomic requirements, the affected functionality is clear, because each requirement only has a single functionality. Understanding, measuring, and tracking requirement waste is the first step in limiting this churn.

Verification

Verification also becomes simpler and more clear in the presence of atomic requirements — one requirement, one verification method.

INCOSE highlights this within their guide succinctly “…the system verification information defined for a requirement can be far more precise when that requirement addresses a single capability, characteristic, constraint, or quality factor. A need or requirement with multiple thoughts is difficult to allocate and to trace to a parent or source … A non-singular need or requirement is neither Verifiable nor Correct.”

There are many ways to verify a requirement, with the most common being, test, analysis, inspection, or demonstration. To verify a non-atomic requirement, a verification method for each component must be specified; there is no guarantee that a single method is either applicable or desirable for all the components of a non-atomic requirement. Writing a non-atomic requirement may be quicker for you, but it makes life more difficult, expensive, and error prone for the verification team.

And it goes further. At some point, for most engineering projects, a determination must be made whether the requirements have all been verified in the implementation. For an atomic requirement, the acceptance criteria, the method of testing, and the test results (e.g., pass/fail) are all clearly tied to specific (singular!) functionality under investigation. Not so with non-atomic requirements. For the non-atomic requirement REQ-NA1 above, there are in fact eight possible outcomes, most of which are partial passes and partial failures:

Only result 1 and 8 can be assigned a full pass of a full failure. Dealing with results 2 – 7, amidst change requests, time pressures, and distributed teams … here lie dragons!

With the atomic requirements REQ-A1, REQ-A2, and REQ-A3, the verification is simpler, more compartmentalized, and more definitive. Only 6 possibilities, with no interactions between them:

The added verification complexity with non-atomic requirements is not just that there are more possibilities, it is also that the components interact with each other; there are (false) dependencies between the functionalities that are there only by virtue of the requirement being non-atomic. Project are complex enough with adding gratuitous complexity.

Atomic requirements provide the means to test exactly what the engineer must implement. When testing atomic requirements, you get a clear pass or fail each time. If your test is inconclusive, your requirement is most likely not atomic and needs to be broken down further.

De-scoping

When resources begin to run tight on projects, atomic requirements become useful once again. When searching for capabilities to “de-scope,” atomic requirements allow engineers to triage with precision. But when multiple functionalities are traced to one requirement, or when requirements are written in a casual, paragraph style, de-scoping becomes a process of untangling and rewriting compound requirements. Well-written, uniquely identified requirements allow de-scoping to be carried out quicker, taking strain and stress off engineers.

In our non-atomic Garage Door requirement example, perhaps the project has experienced scope cuts, and now there will be no display screen, yet the light remains.

Non-Atomic Example:

While the Garage Door is open, the Garage Door opener shall turn on the light, while displaying open status on the display screen.

If you cut the entirety of this requirement from the project, you lose the important Garage Door light functionality. De-scoping in this case requires the rewriting of this requirement into its atomic state; only the first functionality remains.

Atomic Example:

While the Garage Door is open, the Garage Door opener shall turn on the light.

While the Garage Door is open, the Garage Door opener shall display open status on the display.

Conclusion

Design is complex enough, without introducing additional avoidable complexity. Make your requirements simple and precise. Atomic requirements allow for precise, clear, and more manageable requirements that benefit a project throughout its life cycle. Enjoy high-quality requirements, with improved numbering, naming, ranking, and verification with a keep-it-simple mindset. Begin project optimization at the foundational stages and get the most out of your requirements.

Get Started With QVscribe