Business Requirements define the scope of a project and enable everyone involved in a project to agree what will be delivered and what they can expect from the completed project. It constitutes the formal agreement between client and provider but in order to be valuable it must be based on a thorough analysis of the requirements to ensure the project delivers what the client needs.
A business requirements specification states what will and will not be included as part of the project and defines what can be expected from the completed project. Such documents are required for completely new projects and also for those that build on existing products or business procedures.
The advantage of analysing business requirements before beginning any project is that it gives the opportunity to generate real improvements to a business not just change.
Projects within large organisations are almost always started in response to some need or some current failing. Substantial resources are then used to complete projects so they must deliver what was actually needed or they will have been a waste of time and money. Good business requirements analysis will help to avoid this situation by precisely defining the requirements to meet a specific business objective.
Gathering Business Requirements
There are a number of tried and tested techniques for gathering the information for a Business Requirements Document. Some of the main methods are reviewed below. Always remember that people in different roles will view the project from their own perspective and will not always see the bigger picture. Business analysis will look at these different perspectives and present the overall best solution.
Brainstorming
Brainstorming can lead to numerous ideas on a certain subject in a short space of time. Dedicate a single hour in a meeting room with no access to phones or email to get full involvement from all the participants. Include people from every area involved in the project but avoid groups larger than around 15 people in order to stay focussed on the task.
Use any combination of whiteboards, paper, iPads to get a flow of ideas going. Note every idea down initially and then begin discussions on which ideas might provide a solution to the business need. Avoid being side-tracked onto topics that will not help to solve the business need.
Interviewing
Interviewing members of staff involved in a project is very effective for obtaining information that might not always come out in a group. However, it is important to know which people to select for interview and to remain focussed on the topic. Prepare questions in advance of the analysis interviews and ensure they are open questions so that interviewees must provide a full answer.
Storyboarding
Storyboarding is a way of breaking down a project into small chunks and concentrating on only one element at a time. It is used to organise tasks, communicate clearly (and unambiguously) and to identify areas where more analysis is required.
Prototyping
Many people cannot visualise a completely new product so it can be useful to create a prototype to help clients visualise what the final product will be like. Prototypes will often reveal problems and usability issues as well as assumptions made on the part of the client.
Interpreting Business Requirements
When the business requirements have been gathered it is then possible to decide what can actually be delivered and also which features or functions are not required to reach the business objective. They can then be prioritised to ensure the most important tasks are completed first.
The Business Requirements Document
Requirements always need to be documented in straightforward language that is easy to understand and unambiguous. Keep the writing simple and do not use technical jargon without including a clear definition of what it means. This document should include enough information so that the new product can be built, tested and delivered to the client.
Every documented requirement must be quantifiable and be able to be tested to confirm that it meets the business objective. Any feature or function that does not contribute to the final outcome of the project should not be in the Business Requirements Document.
The success of any project depends on thorough business requirements analysis so all stakeholders in a project should formally accept the final document before the project progresses too far.
