Every project needs a business requirements specification document because it is the formal agreement between the client/end-users, the business owner/stakeholder and the project manager. It states exactly what will and will not be included in a project and what the end-user can expect once the project is completed. This is true for projects that are an extension of an existing status quo, such as enhancements to a software system, just as much as to projects involving brand new scenarios such as the development of new corporate policies.
Fully analysing your business requirements before embarking on a new project will lead, not only, to improvements but to a transformation of the business. So instead of ending up with a new business process, policy or system you could actually enable a substantial change in the business.
All new projects in the workplace are instigated in response to a business need or a business failing. Huge amounts of time and resources are usually expended to fulfil the business need but there is often a mismatch between what is delivered and what was actually needed. A thorough business requirements analysis can help to avoid this scenario by defining and clearly documenting the requirements for a specific business objective. It is the process that enables a clear and precise definition of the scope of a project and by breaking down the business needs into specific tasks it helps to assess the resources needed to complete the project.
Gathering Requirements
What are the best ways of getting started on the analysis process? Fortunately there are some well-recognised techniques for gathering the information needed in a Business Requirements Document. This list is not exhaustive but gives an overview of possible methods to use.
In all of these methods of gathering information, it is important to recognise that individuals from different business areas will only view the project from their own perspective and may not see the bigger picture. The analysis is intended to understand the different perspectives and document exactly what the project should achieve.
Brainstorming
Brainstorming is one of the best ways to produce lots of ideas on a particular topic in a short space of time. Set aside an hour in a relaxed environment with no distractions and invite people from all areas involved in the project. But keep the group to no more than 12 people for it to be most focussed and most effective.
The business analyst should encourage participation and a flow of ideas, which are written down on a whiteboard, flipchart, post-it notes etc. When there are plenty of thoughts, ideas and suggestions written down, the analyst then helps to determine which ideas are likely to provide the best solution and, therefore, require further discussion.
Storyboarding
Business Analysts use storyboarding to break down a project into small elements in order to focus on one element at a time. This helps to easily identify where information is lacking and where further analysis is required. It also helps in organising the work and communicating in unambiguous language to the end-users.
Interviews
Interviewing key personnel involved in the project is an extremely effective way of eliciting relevant information but it is important to interview the right people and also to make sure the interview questions stay focussed on the topic in question.
So before embarking on an analysis interview the questions should be prepared to ensure they are open questions (i.e. ones that require more than a one-word or brief answer) and that they cover the key points of: Function, Features, Preferences and User Expertise.
Prototypes
It is often difficult for people to visualise a product, process or system when it is completely new. So for projects which are not an extension of improvements of something that already exists, it is useful to produce a mock-up or model of the product or system to help end-users or clients to visualise what the final product will look like. Prototypes can help to identify inconsistencies, potential problems and usability issues.
Prototypes are most effective once some or all of the other techniques have been used to gather a full idea of the business requirements.
Interpreting the Requirements
Once all the requirements have been gathered and are documented at a high-level of detail it is necessary to determine which requirements can actually be delivered and which requirements are unnecessary to the fulfilment of the business objectives.
Some requirements are more important than others so they must all be prioritised to identify those which are fundamental to delivering a product, system or service and those which are “nice-to-have”.
It is also vital to assess the impact that the new project will have for existing processes and staffing skills and levels. For example, will members of staff need to be re-trained or will some roles become redundant?
Documenting the Detailed Requirements
Requirements must always be written down in language that is easy to understand, precise and unambiguous. Use simple language wherever possible, particularly if the document is not written in the first language of any of those who will be reviewing it. Avoid technical jargon whenever possible, but where it is necessary, clearly state exactly what a term means.
The document must contain sufficient detail that the new product, process or service can be created, tested and ultimately become a “live” product.
All of the requirements must be measurable or quantifiable and it must be possible to test the new product to verify that it meets the business objectives. Every individual task in the requirements document must contribute, even if indirectly, to the end result.
This check-list covers the basics of a Business Requirements Document but writing effective requirements using industry standards and best practices is a topic in its own right that is covered in detail on most project management courses:
- Clear, unambiguous wording
- Sufficiently detailed to create the product/process
- Test cases and conditions can be easily defined
- It is possible to achieve the desired final product/process
- Design independent
- Each requirement can be tracked in the final product/process
- Every requirement is necessary to satisfy the business objectives.
Agreement and Sign Off
Before embarking in earnest on the project work it is vital that the project manager gets the signed agreement of the business requirements document from the stakeholders. This is their formal commitment that the document accurately and thoroughly describes the business needs.
Business Requirements Analysis is covered in detail on project management courses in all recognised methodologies such as APMP, PRINCE2 and PMP. Professional project management training is a vital element in the success of the analysis and documenting of the project scope in every type of project.