Business Analysis Templates, Business Writing, How to Write

How to Write ‘Atomic’ Business Requirements

Posted on by Anthony James
20
Mar

An atomic requirement is a single, indivisible requirement that cannot be broken down further into smaller requirements. It’s the most granular and fundamental unit of a requirement that is necessary for the system or product being developed.

“If you don’t start with a good requirements definition, no matter how brilliant the execution, the results will be sub-optimal.” – James Everett

Last week, I ran a training course teaching business analysts and product managers on how to tighten up the requirements process. Four out of the ten sessions days focused on atomic requirements.

As part of the course, I prepared a checklist to help them write, edit, and review each other’s work. I’ve distilled some of the key points. Let me know if you find these useful.

Requirements must be exact

Precise requirements are essential for effective testing and validation. If requirements are vague or imprecise, it becomes challenging to determine whether the system or product meets the intended specifications. Exact requirements provide clear criteria against which to test and verify that the final deliverable meets the stated needs.

Requirements must be unambiguous

Exact requirements leave no room for misinterpretation or ambiguity. Ambiguous requirements can lead to confusion, misunderstandings, and incorrect implementations, which can be costly and time-consuming to rectify later in the project lifecycle.

Requirements must be atomic

I say atomic (i.e. super specific) as one of the issues that popped up in the training was the tendency to blend two requirements together. In the coming weeks, we’ll look at how to tease out atomic requirements.

Atomic requirements facilitate traceability – the ability to trace requirements through the entire development lifecycle. This ensures each requirement is addressed and implemented, and it helps in change management, impact analysis, and verification processes.

However, many business analysts often struggle with this task, particularly when starting out.

One common mistake is focusing too much on phrasing and formatting rather than the actual substance and meaning of the requirements.

The key to writing better business requirements lies in three main strategies:

1. Use Actionable Verbs

Requirements should be written as clear, actionable statements. Start each requirement with an appropriate verb to convey the specific action or change needed. For example:

  • Add three new fields: Age, Date, and Location.
  • Enable users to enter up to 25 characters in the Employee field.
  • Delete the obsolete Date field.

Using strong verbs at the beginning makes it easy for readers, including non-native English speakers, to quickly grasp what needs to be done.

2. Remove Unnecessary Filler

Inexperienced analysts may try to compensate for their lack of confidence by overwriting or using excessive jargon or industry terms. This can lead to convoluted, bloated requirements that obscure the core meaning.

Instead, streamline your requirements by removing filler text and unnecessary phrases. Paradoxically, shorter and more concise requirements are often easier to understand.

3. Develop a Deep Understanding of the Subject Matter

Perhaps the most critical factor in writing effective requirements is thoroughly understanding the product, service, or system you’re documenting.

Unless you have a solid grasp of the subject matter, it’s nearly impossible to ask the right questions, gather the necessary information, and formulate meaningful requirements.

The maxim holds true – You can’t write what you don’t understand!

So, before diving in, take the time to gather as much information as possible. Arrange demos, install and use the software, and consult with subject matter experts.

Don’t let a product specialist show you the ‘happy path’. Play with it. Find bugs. See if you can break it.

In other words, imagine you’re a first-time user with no context. “So, how do I get this to work?”

Once you know how it works, you’ll be better equipped to articulate exact requirements which can be transformed into user stories.

“Requirements are the most important thing to get right in a software product. You can recover from poor coding or bad software architecture with effort. You cannot recover from not knowing what it is you’re trying to build.” – Steve McConnell, “Code Complete”

The Finer Points

One thing I’ve noticed over the years is that the most successful business analysts see their role as a type of vocation. Maybe that’s too strong a word, but it feels a bit like that.

Getting each requirement ‘word perfect’ is the driving force behind their work. It reflects a mindset that seeks precision.

Doing this takes practice and commitment. If you use actionable verbs, remove unnecessary filler, and internalize the subject matter, the quality of your requirements will stand to you.

Learn More

Anthony James