Writing high-quality Business Requirements

Some tips and guidelines to ensure your business requirements are of high-quality. This way your business requirements will form a solid and reliable basis for starting your project.

1. Preface

One of the key tasks for a business analyst is assisting the business in writing their business requirements (BR’s). This document wants to help them in writing high-quality business requirements, ensuring they do adhere to certain standards, so they can be used as the basis for starting the analysis of your project.

2. General Features

2.1 Categories

In general we can categorise requirements in two major categories:

• Functional
• Non-functional
• Usability
• Performance
• Scalability
• Security
• Availability & Recovery

You can always split up your functional requirements in functional groups, depending on the modules or functional blocks in your project.

2.2 Style
You can choose for an informal style when defining user requirements or you can rely on the paradigm as used when writing user stories:

As a (role) I want (goal/desire/something) so that (benefit/reason).
2.3 Structured
Structuring BR’s will increase the consistency and make it easier to avoid duplicate BR’s.

Is a certain structure applied to the business requirements?

• Grouped per category
• Numbering the BR’s allows to easily refer to a given BR and track their progress
• Use a descriptive name for each BR or underline the keywords in the description of the BR
• Use hierarchy levels to start with high-level requirements that can be gradually detailed in lower-level requirements

2.4 Clear & Unambiguous

• Requirements need to be clear and unambiguous so that you get what you actually need rather than what someone has assumed you need.
• Is a glossary of terms available to ensure everybody understands the same when using a term? A glossary will help to:
• Avoid using the same word in different meanings.
• Avoid using different words having the same meaning
• Avoid another misleading term is used
• The text should not allow for different interpretations, so a good level of detail is needed.
• It is critical that the BR’s are phrased in a consistent way, to avoid different interpretations if a requirement is worded many times and in different words.
• A good mixture of text and graphs is always the best way of describing what the business expects from the new application.
• No technical or architectural decisions should be put in the BR’s, only what the business expect from the system/application.
• Clear and unambiguous requirements have the advantage that they can be easily tested after implementation.

2.5 Representative

• Who created the BR’s is very important. For each BR you should document the person who requested the requirement. This way you know who to contact in case of any doubt or needed clarification.
• Do they really represent the business (management as well as users that will use the new application)?
• Do they represent all stakeholders (departments) that are involved in the business process?

2.6 Complete

• Business users tend to describe the exceptions of their business process and sometimes forget to describe the normal flow, since for them this normal flow is so obvious.
• Is for each business requirement indicated whether the BR is to be automated by the new application or that it is only a manual business procedure?
• Ensure that the AS-IS and TO BE business process are described or include time to describes these before the analysis can start. Use BPMN or UML activity diagrams.
• Are all involved departments/users involved?

2.7 Measurable

When deliverables of your project are being tested, you should be able to compare your business requirements with the deliverables you are testing. To ease this process, make sure your requirements are measurable. This is specifically important for non-functional requirements.

• Include exact time or quantity units
• Quantify your requirements

2.8 Prioritised and Phased

Users tend to say that everything they asked for needs to be available from day 1 in the new application. Define which requirements absolutely, positively have to be delivered in order for the system to be viable and your business case benefits to be realised. When changing priorities, ask yourself what the trade-off is if we prioritize this ahead of other requirements?

Following tasks should have a high priority for automation:

• Focus on tasks that will increase the ROI
• Costly tasks
• Complex tasks
• Labour-intensive tasks
• Tasks that are required because of regulation/legislation by an external body
• Tasks that are performed on a regular basis
• Concentrate on the normal flow: exceptions should have a low priority

Use any kind of categorisation to prioritise the BR’s

• For instance MOSCOW principle:
• Must
• Should
• Could
• Would
• Phasing: split up the project in phases and assign a phase for each requirement

2.9 Tools

Ensure your business requirements can be created, viewed and adapted by anybody involved in gathering the business requirements. A collaborative web tool is the best way to ensure everybody is invited to comment and clarify the requirements and to track progress. This way the quality and accurateness of your requirements will increase, since more users are involved in the process. . If on the other hand you only have an even professional excel sheet, you should at least create a shared workbook in MS Excel to allow collaboration between all people involved.

These tools have to support version control, metadata fields (like prioritisation, creator, responsible, phase...), e-mail notification and other features common to issue and bug tracking tools. I worked with JIRA from http://www.atlassian.com/ and open source product TRAC from http://trac.edgewall.org/ and they are perfect for the job.