Introduction

At QRA, we champion precision in requirement writing through methods to streamline and enhance the requirements process. We are proponents of writing according to a template, a system outlined in our comprehensive EARS (The Easy Approach to Requirements Syntax) Series – see EARS Templates Parts 1, 2, and 3. We also advocate for writing atomic requirements, a concept outlined in our blog, Atomic Requirements 101: A Comprehensive Guide with Examples.

An atomic requirement is “a natural language statement that completely describes a single system function, feature, need or capability including all information, details, and characteristics.”

Simply put, atomic requirements are singular statements that have all the relevant information you need in one sentence.

Incorporating atomic writing aligns with widely endorsed requirement best practices, including the INCOSE (International Council on Systems Engineering) Guide to Writing Requirements. This approach ensures that each requirement stands alone and is clear, precise, and singular. Atomic requirements translate into increased measurability, enhanced testing procedures, improved naming conventions, effortless traceability, streamlined verification processes, and potential for reusability.

If atomic requirements are so widely accepted as a standard in requirement writing – why isn’t this practice consistently used across requirement engineering industries, and why are we here at QRA talking about it so much?

We frequently engage in discussions with requirement writers and teams who express reservations about the necessity of writing atomic requirements. It’s not uncommon for organizations to be comfortable with their existing processes and view the transition to singular writing as a potential challenge to avoid or have the capacity to tackle. We understand these concerns, and as highlighted in our blog, it’s true that crafting atomic requirements does take more effort to write. However, the investment is justified when you recognize the advantages, such as risk reduction and enhanced clarity, comprehension, analysis, and implementation.

Let’s just be honest with each other. It’s not fun to completely revamp the way you have been doing things as an individual, a team, an organization, or an industry.

In this use case, we will investigate how to write atomically, the issues with non-atomic requirements, and dive into some examples of atomic and non-atomic requirements

How to Write Atomically

First things first, writing atomic requirements is an essential aspect of developing clear, precise, and manageable requirements, that turn into clear, precise, and manageable projects. For a deeper understanding of why adopting atomic writing is imperative, please refer to our blog, Atomic Requirements 101: A Comprehensive Guide with Examples.

In the blog, we go into detail about the benefits you can expect in your projects from writing atomically. Our primary focus in this Use Case is to equip you with the know-how to write atomically, so you can easily implement these changes into your work. By following these steps in (Table 1: Steps for Writing Atomic Requirements), you can be on your way to writing consistent atomic requirements from the outset. Now let’s examine the problem with non-atomic requirements and why authors and teams frequently resort to using a paragraph, bullet point, or grouped requirements.