8R Framework for Requirements Management

---

Our 8R Requirements Management Framework provides a means of supporting the production of quality requirements.

It is not a methodology or process but a series of distinct activities that can be applied to agile or waterfall methods. 

Although there are dependencies between these activities, they do not need to be followed in a strict order.

Aim: To record what is being asked for, and who is asking for it, so that nothing gets missed.

 Perform fact finding activities with stakeholders to elicit or trawl for their requirements.

 Do not try  to produce  well formed requirements at this point and avoid getting in to a detailed discussion or analysis of the requirements, as this may take up too much of the time available and cause some requirements to be missed 

Aim: To produce a list or backlog of atomic or singular requirements with priority and acceptance criteria.

Examine the requests to reveal the individual requirements.

Split multiple requirements into singular atomic requirements, assign a priority to each requirement, identify non functional requirements, not forgetting associated non functional requirements.  Add acceptance criteria to each requirement. You may want to consider using the acceptance criteria to specify associated non functional requirements.

If you are working in a more agile environment you may want to prioritise the requests first and then start to decompose the requests into atomic requirements or users stories in order of priority.  

Aim: To organise the requirements into meaningful groups of related requirements.

The more stakeholders that have been involved in fact finding, the more likely it is that the same requirement will have been stated more that once and at differing levels of detail.

Look for  overlapping, duplicated and conflicting requirements; requirements that involve the same actors and the same business objects; and look for dependencies between requirements.

You can group related requirements together into releases, packages, epics or time boxes depending on the approach being taken. 

Determine the order in which each group of requirements is to be addressed.  Consider the priority of each requirement and the dependencies between them.

As the focus here is to group related requirements together, do not pay too much attention to the wording of the requirements  as that is to be considered next. 

Aim: To produce good quality, well formed requirements and log requirement quality issues.

Now we have meaningful groups of requirements we can address the requirements in each group in term.

Assess the quality of each requirement using the requirements quality criteria,.

Re write the requirement to resolve conflicting, overlapping and duplicated requirements and to ensure the requirements are well formed and SMART.  Where issues cannot be immediately resolved ensure it is logged so it can be addressed later.  

This may involve creating new requirements that replace the original requests or requirements.  It is good practice to use traceability to link the new requirement or requirements  to the original and not to delete the original as the requesting stakeholder may raise a query.  It is better to set replaced requirements as "Resolved", "Done" or similar  and relate or trace them to the new requirement.

Aim: To produce data and function models to graphically represent the requirements and business rules and log requirement quality issues.. 

This will solve some issues and identify others. Typical models would be a domain class diagram (or information model) and a use case diagram but there are others.

Trying to produce these models will identify issues arisinbg from gaps in your knowledge.  Add these issues to an issue log 

Aim: To resolve issues in the issues log.

Engage with stakeholders to resolve the issues identified.  

Aim: To confirm the requirements are ready to be developed 

In waterfall methods perform formal verification and validation reviews to confirm requirements or identity further issues and defects. Repeat by returning to previous appropriate activities if not yet validated. 

In agile methods requirements can be subjected to readiness reviews (three amigos), and reviewed during sprint planning and backlog grooming

Aim:  To make changes to reviewed requirements

Reconstruct or change requirement if necessary by following change management process after receiving formal change requests.