13-09-2015 Door: Suzanne Robertson & James Robertson

Atomic Requirements: where the rubber hits the road

Deel dit bericht

What are Atomic Requirements?

When you have a requirement that is measurable, testable, traceable and detailed enough to define all aspects of a need without further breakdown then you have an atomic requirement. You can think of the atomic requirements as the lowest level requirements. In fact the collection of atomic requirements specifies what we require the solution to do. 

When there are too many atomic requirements to hold simultaneously in a human brain – say around 10 on a good day - then there is a need for higher-level groupings of requirements.  The higher-level groupings of requirements that you choose to maintain depend on the communication points that you have in your project. Some useful high-level groupings are Business Use Cases (BUCs), Product Use Cases (PUCs), Work Scope, Product Scope, Features, Components, Sub Components. Whichever high level groupings you use it must be possible to trace each atomic requirement to the higher-level groups that include it.

Why have Multiple Attributes?

An atomic requirement concerns a number of different stakeholders for a number of different reasons. In order to understand things like where it comes from, what it means, who cares about it, why it matters, how to test it, what else will be affected by changes the requirement needs a number of attributes. The business person or subject matter expert focuses on a business description of the requirement. The developer wants to know why the requirement is important along with a precise quantification of what it means. The tester needs to have a testable measurement of the requirement. The business analyst needs to know how each requirement affects other requirements. The maintainer needs to know how this requirement affects requirements that are already implemented. 

Each stakeholder has a stake in particular attributes of the requirement according to his role and responsibility.

The Attributes

The Volere Requirements Shell, also referred to as a Snow Card, identifies a number of attributes that together compose one atomic requirement.

Requirement #:                                                    Requirement type:                           Event / Use Case #'s: 
Fit Criterion:  
Customer Satisfaction:                                                    Customer Dissatisfaction: 
Priority:                                                    Conflicts: 
Supporting Materials:  

Table 1: The Volere requirements shell identifies all the attributes of an atomic requirement.

The following provides some notes on each of the attributes of an atomic requirement.

Requirement Number

A unique identifier for this requirement. The only purpose of this identifier is as an identifier for this requirement. Do not include hybrid meanings (like the status, or the importance or whatever) in this number – it will only end in tears. If you want to record other facts about the requirement then have a separate attribute.

Requirement Type

The type of the requirement as defined in the Volere requirements template. In summary the types are: Functional, Constraint and Non Functional (there are many non functional sub types). The reason for requirements type is to help you find the requirements and to be able to group the requirements to facilitate the involvement of appropriate specialist stakeholders like usability experts, security experts, performance experts and so on.

Business Event Number

Traces this requirement back to the relevant business event/s that define the scope of the work that is relevant to this project.

Business Use Case (BUC)

Traces this requirement to the business use case/s that contain this atomic requirement.

Product Use Case (PUC)

Traces this requirement to the product use case/s to which this requirement has been allocated.


A one sentence description that states this requirement from the perspective of someone who is concerned with this part of the work/business.


A justification of why this requirement is important. This should help to identify the expected benefit of having a solution to this requirement.


The person who raised this requirement.

Fit Criterion

A measurement of the requirement such that it is possible to non-subjectively test whether the solution fits the original requirement.

Customer Satisfaction

On a scale from 1 to 5 how much benefit will result if a solution that fits this requirement is delivered?

Customer Dissatisfaction

On a scale from 1 to 5 how much damage will there be if we cannot deliver a solution that fits this requirement?

Customer Satisfaction and Customer Dissatisfaction are a tool for helping people to think about the value of the requirement and keeping them aware that the definition of a requirement does not necessarily guarantee a solution.


The decision on what priority is assigned to the requirement. This is quantified using the scale that best suits your organisation. For example you could use: High, Medium, Low OR 1,2,3, OR (MoSCow) Must, Should, Could, Won’t OR Implementation Version Number OR any other scheme that suits you.


Other requirements that cannot be implemented if this requirement is implemented as specified. The purpose of this is to encourage people to identify decisions and choices that need to be made before implementation.

Supporting Materials

Pointers to documents, examples and people that illustrate and can explain more about the background of this requirement.


The attributes that you choose to keep track of to trace the lifecycle of this requirement within your organisation. For example you might have checkpoints for requirements like: project phases, review checkpoints, inclusion in documents, name of approver, date of approval, date of implementation and so on. The number of historical attributes you choose to record varies depending on the size, complexity and fragmentation of your project.


We keep track of the dependencies between requirements by maintaining the discipline of a data dictionary. Every term used in a requirement is defined in the dictionary and we check that the terms are being used consistently within the project. The dictionary acts as a central communication point for the project team.

Atomic Requirement Example

The following is an example of an atomic requirement for the Library Loans case study that we have used in other articles in this series.

Requirement #: 29                                                 Requirement type: Functional                      Event / Use Case #'s: 2/2.3
Description: The product shall identify all outstanding books on loan to a Borrower
Rationale: Need to know which book loans are overdue when making a decision about whether to extend a loan
Originator: Aislinn Weatherspoon, Chief Librarian
Fit Criterion: The Outstanding Book Loans for a Borrower are those where the Loan Expiry Date is before or equal to Today's Date
Customer Satisfaction: 5                                                  Customer Dissatisfaction: 5
Priority: V1                                                Conflicts: 
Supporting Materials: Library loan conventions paper January 2008
History: June 25, 2009 Passed Quality Gateway review

Table 2: An example of the attributes of an atomic requirement.

The example in figure 2 shows the attributes for a functional requirement.  Note how each of the attributes adds to the understanding of the details of the requirement.  The customer satisfaction and dissatisfaction are both 5 which indicates that this is a core requirement. In other words if it is not met then there is no point in building the product.

Last Word

People often ask whether we recommend writing requirements onto physical snow cards. If you are running a requirements discovery workshop then the actual cards are a useful device. They also work rather well if you want to have a detailed discussion about a specific requirement. However, given the volume of requirements and the complexity of keeping track of levels it makes sense to use automation for completeness and consistency checking and for maintaining traceability. 

Many business analysts use a combination of a word processor, a spreadsheet and a drawing tool to automate parts of their requirements specification. Other people make use of their existing database software or their Intranet. If you have a consistent understanding of the attributes of atomic requirements and their traceable connections to higher level groupings then you are in a position to choose what to automate given the facilities available to you.





Suzanne Robertson & James Robertson

Suzanne Robertson en James Robertson zijn oprichters van The Atlantic Systems Guild, een denktank die bekend staat om zijn vernieuwende technieken op het gebied van systems engineering, en zijn gezamenlijk de grondleggers van de Volere requirements methode, template, checklists en technieken. James verzorgde jaren lang verscheidene trainingen bij Adept Events op gebied van business analyse en requirements engineering.

Alle blogs van deze auteur