Requirements engineering and quality

This article covers requirement quality or

what does a good requirement look like? 

how we can measure the quality of a requirement?.

It also explains the context of requirements and warns against over use.

If you would like an introduction to Requirements Engineering – see Requirements Engineering – an introduction

Word of warning

Although our end goal is a quality set of requirements, it is critical that we maintain a dialogue with the stakeholders. Always accept the requirements provided by the stakeholders as a draft and and work towards improving them. Part of the process of producing quality requirements will be to educate the stakeholders as to what constitites a quality requirement.

Quality criteria

The structure of our requirement statements should conform to an agree standard which gives us a goal that drives some of our questions. There are two good approaches to requirements structure defined in Writing Better Requirements (Ian Alexander) and Mastering the Requirements Process (Suzanne and James Robertson – they have a requirement template available here – Volere requirement ‘snowcard’).

There are some key elements to consider for any requirement

• the class of users to which it applies
  Note: a glossary will be necessary to ensure any terms are fully explained and agreed by all
  e.g. The bank clerk shall be able to assess a customer’s credit worthiness
   
• any constraints that may apply
  e.g. The bank clerk shall be able to assess a customer’s credit worthiness within 30 seconds of entering their personal details
   
• must be verifiable
  Would you be able to write a test that verifies this requirement undisputably?
   
• makes only one simple statement with no alternatives stated
  e.g. The bank clerk shall be able to assess a customer’s credit worthiness and resolve any issues that arise with their manager
  This requirement is NOT simple and should be broken into two separate requirements
  The bank clerk shall be able to assess a customer’s credit worthiness
  The bank clerk shall be able to resolve any issues that arise with their manager
   
• makes no reference to the solution or design of the system
  e.g. The bank clerk will receive an email informing them of the customer’s credit score
  This requirement indicates that the response is received by email. This raises questions which may drive out the actual requirements.     Email suggests that receipt of the credit score is not time critical as the turn around time of an email cannot be guaranteed. This may be a constraint that is more generous with regard to time e.g. can receive a response before the account is opened but not necessary within seconds 

  Email also suggests this is undertaken away from the customer’s view. Is it important that the customer does not see the credit score?

  Possible requirements:
  The bank clerk will be informed of the result of the credit score within one hour
  The credit score will not be revealed to the customer
  

• doesn’t use terms that are vague or open to interpretation
  e.g. The bank clerk will be able to offer products to customers whose credit score is good
  The term ‘good’ is vague. However, depending on the project,  it may be agreed by all the project stakeholders that this is sufficent for a high level requirement and the detail can be explored later.

The house style should be used where requirements are expressed in a similar manner as it is quicker to see any shortcomings.

For example, it can be agreed whether to mention the system or solution at all (e.g. ‘The system shall’). Also, decide on the use of the word ‘shall’, ‘should’, ‘could’ ,’would’ or ‘will’. The words ‘will’ or ‘shall’ are preferred as anything else suggests the priority which is a separate attribute.

In addition to the actual text of the requirement, there are other key elements that every requirement needs:

• requirement id - this should be unique
   
• priority - this could be critical, high, medium or low, or must, could, should or would (from MoSCoW method)
  It is not so important what the names of the priorities are as long as they are understood and agreed by the stakeholders. As a rule of thumb, no more than a third of requirements should be mandatory. 
   
• owner
  there will usually be one (or more) stakeholders who are, effectively, owners or originators of a requirement. This usually means they have a vested interest in its delivery and should be consulted on any changes or its removal. 

There are some other attributes which are optional but should be considered depending on the specific project:

• status
  This is useful if the requirements are being considered by a group of people and they need to reach consensus on whether a proposed requirement should be submitted. Possible statuses would include – draft, reviewed, approved, rejected
   
• rationale
  The requirements will become very pared down, simple statements which don’t shed any light on why the requirement exists. This field can be used to capture the reason why the requirement exists which is useful when the project objectives are changed
   
• dependency
  This shows relationships between requirements where one is dependent on another. 
   
• parent requirement
  This allows a hierarchy of requirements to be developed. i.e. high level based on business objectives and child requirements which flesh out the detail
   
• category
  It may be useful to group related requirements together.  For example, there may be a business unit responsible for regulatory issues and another for legal. Ensure this adds value and is not confused with Owner.

The big picture

Typically, the requirements should be presented as part of a larger document that provides context and describes other relevant information.  This would include, as a minimum, the following:

• the business context, including the strategy and objectives
   
• relevant business process(es) – current and planned (or ‘to be’ and ‘as is’)
   
• the scope of the project
   
• broad description of the user population
   
• stakeholders 

• glossary or definition of terms
   
• assumptions, issues and risks
   
• dependencies (other projects or existing processes and systems)

This document may contain other supporting information such as a high level use case model(s) (see Use Cases – an Introduction) and business object model(s) which show the key business entities and their relationships. 

Requirement statements vs other forms of expressing requirements (e.g. use cases)

It is important not to use the simple requirement statement described above for the finest detail of system behaviour or characteristics. There is a risk of producing a very large document which is in essence a series of declarative statements that describe the desired system behaviour.

This is not appropriate when defining all of the system behaviour as there are much more ‘user friendly’ models for defining behaviour (e.g. use cases, prototypes for illustrative purposes) or entities, data and relationships (e.g. business object models/domain models, state transition diagrams) for defining data.

It is the job of the business analyst to interpret and he/she should be able to select the moset effective means of communication and should not rely on prescriptive approaches as there is no one approach that works in all situations.

Requirements engineering is very effective at introducing formality which drives better quality and provides an effective means of measuring and ensuring delivery. However, there are more effective techniques to communicate the detailed system behaviour in support of the requirements.

Related Links

You might find the following links useful:

‘Writing Good Requirements’ from Software Development Magazine

‘Quality Requirements Checklist’ from Journal of Object Technology regarding quality of quality requirements - useful, academic article. Also see Nonfunctional requirements for more on quality requirements

Good requirements within this article from Wikipedia - concise table describing good requirements within this article

Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further