“The two most important requirements for major success are: first, being in the right place at the right time, and second, doing something about it.”– Ray Kroc
What is a Business Requirements Definitions document?
Knowing what your stakeholders want is best captured in a detailed document called by most project managers as a Business Requirements Definitions (BRD). If by chance you have not created or updated a company-provided template today, I will describe what is typically found in these types of documents and how they are used. If you are already familiar with the BRD, you know that it is one of the early deliverables that will need to be produced if you are going to start your project on the right foot.
Furthermore, BRD documentation is a comprehensive set of business or technical requirements describing a certain condition or capability that should occur. Regardless of if you are producing a new product or creating a new service or implementing a new system having solid requirements are key to being able to deliver success. This documentation is typically compiled by the project manager or business analyst working with the right business or technical leads most familiar with the desired end product or outcomes. A completed BRD should be formally reviewed and approved by the sponsor before the project moves forward to ensure stakeholder alignment.
A final thought to all project managers is that once you complete the BRD remember to go back and review and update it from time to time as you find any requirements changing as its contents will be used during the design sessions later in the project.
What it includes
The following sections are what you would find in most Business Requirements Definitions documents. Starting with the document purpose, followed by a high-level project overview, project resources, assumptions, and constraints these will provide context to the stakeholders, project team members, and end-users as they begin to understand the document. These are all fairly standard items found in any typical project and therefore most easily understood. Below, however, are the more detailed sections of use cases and business requirements, with explanations that might be new to project teams.
Use cases fields explained
Use cases are used to document intended behaviors or outcomes from an end-user perspective. Think of it as a process flow explaining the detailed step-by-step interactions. Some of the following are the typical fields found within the use case overview. Identifying number, name, the person creating it, date created, the person completing the last update, and date. You will then typically find the following fields used to describe the actual process. User name, description, pre and post-conditions, normal course description, exceptions, frequency, any special requirements, or business rules. Some people also include a process map diagram to illustrate the sequence of steps visually.
Business requirements capture
The actual business/ technical requirements have input from the following areas; Business user, end-user, scalability, security, support, service level, and reporting. Templates usually have these areas broken down into different sections for capturing the information with fields that include some type of numerical identifier, the actual function or feature or requirement, use case identifier number if applicable, then finally a notes section to capture any explanations or other comments.
Final thoughts…..
Leading a project without a good set of requirements is like going on a trip in your car without a map or GPS to guide you to your ultimate destination. Start off on the right foot by taking the time to meet with your business and technical experts to understand the end-user goals and objectives, thus creating the requirements document that will make you and the project successful. It will also decrease the chances of delivery of an un-useable or unwanted product or solution.
Similar Content:
-
4 Steps to effective project requirements gathering
-
How to create a winning requirements traceability matrix
-
Tips on how to identify project requirements
-
Edward Witchey joins PMWorld 360 Magazine and covers project planning and business requirements
