Requirements quality criteria

---

Requirements Quality Criteria

Prioritised

Requirements should be prioritised. When requirements are first uncovered the priority may be unknown. If this is the case then you must work with the stakeholders to determine the priority.

There are many different techniques for prioritising requirements. MoSCoW is very common but High, Medium and Low are also used. Only one technique must be used and all stakeholders need to be clear about the meaning of each rating.

In an agile environment prioritisation needs to be performed as soon as possible and continuously reviewed. The concept of “Minimal Viable Product” can help with prioritising Requirements.

Acceptance criteria

Good quality requirements should have acceptance criteria so that we can confirm they have been delivered and also to give further information to the developers as to what they need to produce.

In agile development environments, acceptance criteria need to be present from the outset.

Owner 

Each requirement should have an appropriate and identifiable owner. This must be a senior stakeholder from the business area affected by the requirement with the authority to  confirm or sign off the requirement. 

They need to confirm the requirement is a true reflection of need, is fit for purpose and later to agree the requirement has been delivered. 

They are also the point of escalation, along with the sponsor, if there are any issues concerning the requirement.

A project can have a number of different requirement owners (but not too many) but in an agile environment there is one specified Product Owner who owns all of the requirements to performs these tasks.

It is essential that Product Owner collaborates effectively with the business and the project team and should be aware of how the business areas are affected by requirements, their priorities and the dependencies between them.

Atomic 

Each Requirement statement should be singular or atomic. We need to look for multiple requirements and break them down into singular atomic requirements.

No overlapping or duplicated requirements

 During a project we elicit requirements from a number of stakeholders or stakeholder groups so it is likely that different stakeholders will ask for the same requirement and at differing levels of detail.

We need to merge duplicated requirements, merge or separate overlapping requirements and identify requirements that are lower levels of detail of a higher level requirement.

Look for the same actor performing the same actions with the same business objects across the list of requirements or backlog.

Examine acceptance criteria to determine if any suggested tests  are similar or repeated.

Note: It is not good practice to delete requirements that are duplicated in case stakeholders want an update.  It is better to class them as "Done" or "Resolved" or similar and trace them to the updated requirements to maintain an audit trail.

In scope

 To be in scope, a requirement must support or contribute to meeting project objectives. These project objectives should in turn support or contribute to meeting business objectives.

This means you need to document or identify which objectives a requirement supports. This is sometimes referred to a Upwards Traceability. It is important therefore that objectives are stated, perhaps in a PID.

If you are using User Stories you can use the "in order that" part of the "as a -- I would like to -- in order that --" format of the User Story to identify objectives being met.

If you are recoding requirements in a catalogue or list then you could use a field for "Justification" or "Rationale" to explain how the requirement meets project objectives.

Some organisations like to keep a record of requirements that are out of scope, rather than delete them, in case the scope of the project changes. You can achieve this by setting the Priority of the requirement to "W" (won't have/would like to have) or have a status for "Out of Scope". If you are using a tool to record your requirements you will then be able to filter out these requirements.  

Not conflicting

Review the requirements in your list or backlog and look for requirements that conflict with each other, where the implementation of one will prevent or hinder the implementation of another.

Pay particular attention to Non Functional Requirements such as  speed (performance) and quality or differing access requirements to the same data from different stakeholders. 

For Functional Requirements check if the functionality required by one stakeholder to see if it conflicts with that of other stakeholders.

Discuss any potential conflicts with stakeholders taking project objectives and requirement priorities into consideration.

If you cannot resolve the conflict then escalate the matter to the appropriate authority

Consistent format

All requirements should be expressed in the same format. 

Every organisation should have a policy for what that format would be. In agile projects it is usual to record requirement statements in a User Story Format.  (As a ...., I would like to ...., in order that ....)

You should also make sure that you are consistent in how you handle levels of detail.  One approach is to include the low levels of detail in the requirement description, another is to keep the requirement description at high level and hold the lower levels of detail in supporting documentation such as a Use Case or flowchart, yet another is to have differing levels of related requirements.  Use whichever approach is suitable for your circumstances but avoid mixing approaches.

Also be consistent about how you reference or identify your requirements including how you identify related requirements or link high level requirements to related low level requirements

Clear, concise and unambiguous

 The meaning of a requirement should be clear from its description and any supporting comments. The same should apply to other requirements properties, especially Acceptance Criteria. 

This essentially means requirements should be well formed or clearly written.

We should make a special check to ensure a requirement is not open to different interpretations or is ambiguous.

Ambiguity is different to spot by the author of the requirement as they know what the requirement is supposed to mean. For this reason requirements need to be reviewed by third parties including representatives from different stakeholder groups.

Requirements can be reviewed informally and formally.

There are different types of formal reviews. Common types include Peer Reviews, Requirements Readiness (Three Amigo) Reviews, Stakeholder Verification and Validation Reviews.

In an agile environment the Three Amigos Review is common and regular "Show and Tell" can be used to clarify requirements.  You can also use sprint planning and backlog refinement to identify poorly written requirements.

Testable

Requirements must be able to be tested so we can determine if they have been delivered. 

We will write acceptance criteria for each requirement. Acceptance criteria should indicate what behavior should occur under various conditions and should be of sufficient quality to allow testers to produce test plans and test scripts. There are a number of formats for writing acceptance criteria.  These include:

Given, when, then  

Outputs expected from inputs 

A series of questions or tests that must be passed.

A key activity for business analysts or requirements engineers is to identify all the possible conditions that need to be tested.  An ideal technique to use for this is the scenario building workshop.

As well as having good quality Acceptance Criteria we should also make sure that the requirements statement or user story is testable in the first place. This applies to all requirements but is especially important for non-functional requirements. Statements such as the system should be quick need to be replaced with a specific response time

To ensure requirements are testable, representatives of the test team must have the opportunity to review them

Traceable

Traceability refers to the ability to trace or link a requirement backwards to its source, forwards to development/resolution and upwards to objectives.

In the early stages of requirements specification forward traceability will not be possible as no development work has taken place. However as development and test take place traceability information should be added.

Backwards and upwards traceability should be checked from the start. If a requirement cannot be traced to an objective it is potentially out of scope. If a requirement cannot be traced back to a source such as a person or a business process then why is it included? This could also indicate it is out of scope.

Solution Agnostic

Requirement should not suggest solutions. We should identify the core requirement from the business or user perspective and then determine the appropriate solution or if there is a solution in mind, to assess the suitability of that solution.

Feasible

We need to check that the requirement is feasible from technical, financial and the business perspective.

Status

Each requirement should have a meaningful status so delivery can be managed. Common examples are draft, verified, coded, tested, done.

Complete

make sure that each requirement has all the information needed.  Priority and acceptance criteria are key, but depending on the project other properties may be needed.  

In a waterfall environment you should check that all requirements are complete before moving into the design phase.

In an agile environment we should continuously check all the information needed is captured as the requirement is elaborated.