5 Guidelines for writing good business requirements

This article is about providing some guidelines for writing good business requirements.  Consequences for not getting this right could lead to the project failing as the solution provided will be dependent on this being correct and interpreted in the right way.

1. Resist temptation to write down the requirements in narrative form too early

Techniques such as using diagrams and ensuring requirements are not written down too early will be beneficial.  It is important to understand the context and the end to end business process.  Failing this could lead to missing requirements.  It is important to understand the scope before delving into the detail.

If writing business requirements for a project the business has no experience of it will be easier to walk through the business processes first.

This is for three reasons.

1. They will understand their business processes better and this exercise will help them to understand their requirements.
2. A discussion can be had to agree the to be process as it is better to build the requirements on an improved process rather than one that may have problems.
3. Allows for exceptions and alternative flows to be discussed that might uncover further requirements not thought of otherwise.

Diagrams demonstrate understanding with a lesser chance of being ambiguous.  It can make it clear very quickly what is missing or what has not been understood.  It is quicker to draw a diagram and what can be portrayed in a diagram on one page could take up pages if written in narrative.  Therefore, making sure the scope and what is required being written in a fast form will save much more time than writing narrative straight away.

This is supported by the number of techniques available which are diagram based such as:

• Process modelling techniques such as BPMN (Business process modelling notation),
• the numerous number of UML diagrams available such as use case models, activity diagrams, state model diagrams and
• unstructured diagrams such as mind maps.

 

2. Ensure requirement is unambiguous and testable

Your stakeholders will have a more complete internal representation of what they wish to communicate than what can be put into words.  This will equally apply to yourself.  Consequently, this will shorten the description.  The business will also not necessarily know the amount of detail required.

It is difficult to write requirements without assumptions creeping in.  It can be obvious what is meant by one person but then may be interpreted differently by another.  This may mean information in a requirement is missing, distorted or generalised.

To reduce the risk of above guidelines are:

• Check the requirement is verifiable. Is it stated in such a way that is can be tested or demonstrated.  The success criteria must be evident.
• Avoid subjective words. See below for some examples.  If any of these are used, then further effort is required to remove the ambiguity as too many interpretations could be made.
  • Appropriate
  • Efficient
  • Effective
  • Reliable
  • Compatible
  • Normal
  • User friendly
  • Quickly
  • Enhance
  • Minimize
  • Maximize
  • Sufficient
  • Adequate
  • Support
  • But not limited to
• Ensure it is possible to write a test to prove each requirement and ensure tolerances are stated in a requirement.

 

3. Ensure requirements are clear and concise

It can be tempting, especially for someone new to requirements elicitation or has a lot of business knowledge in the scope of the project to make the mistake of showing off their knowledge.  This can lead to irrelevant information and make it difficult to understand what the requirements are.  It can also lead to duplication making the requirements difficult to read and understand.  It may also make the requirements document far lengthier than it needs to be and reduce the likelihood of it being read.

To reduce the risk of above guidelines are:

• Ensure each requirement reference relates to a single requirement
• Check each requirement no more than 30-50 words in length
• Ensure requirement is mum proof. Would your mother understand it?  If someone who was new to the project read the document, they need to understand what has been written.
• Avoid use of acronyms or ensure they are included in a glossary.

 

4. Check for consistency throughout the requirements document

Requirements are often elicited from a more than one stakeholder or from more than one source.  This can lead to different terminology being used which could mean the same thing, requirements conflicting, or requirements being duplicated.

To reduce the risk of above guidelines are:

• Ensure conflicting requirements are resolved by holding a meeting with the stakeholders involved to agree a resolution.
• Check the same terminology is used throughout the requirement specification. Showing the types of data in a conceptual or logical data diagram can help ensure all terms are understood.  You may need to get the stakeholders together to all agree on a single term to be used.
• Check requirements are not duplicated. Techniques to overcome this involve grouping requirements together to help identify similarities.

 

5. Ensure each requirement is attainable and necessary

There is a great deal of cost associated and time involved with reviewing requirements and setting out options and solutions as a result.  There is no point in writing down requirements that can not be achieved in the timescales and budget or does not relate back to the project scope or problems to be resolved.  Requirements elicitation should be thought of as a funnel.  Just because someone specifies a requirement does not mean it should end up being in the document.   It can be very tempting to write down requirements just in case they can be met even though they are not essential.  This can however cause delays in being able to start work on meeting the essential requirements or make it difficult to understand what is required first.

To reduce the risk of above guidelines are:

• Establish the consequences if the requirement was excluded.
• Check each requirement relates to the scope and resolution of a problem or goal.
• Make sure the requirements are not implementation specific as there may be more than one method for meeting the requirement, some may be more attainable than others.
• Consider whether it is worth putting the requirements that are not attainable or needed in a separate appendix to show they were considered and why they were not taken forward.
• Get early involvement from solution SME’s early on to investigate feasibility.
• Understand the priority order of the requirements in terms of business value and the order in which they are required.
• Avoid stating what requirements should not be met. This can cause confusion.  If there are requirements identified for future phases add them as an appendix.

Thoughts? Questions? Please share in the comments.

If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes.  The book is available from www.koganpage.com and all major print and e-book retailers.