Many businesses have a process in place to assist with project management and implementation. One opportunity for improvement involves making reasonable estimates of how big a project is and how much it is going to cost. There are many different names for tools used with this process: business needs specification, requirements specification or, simply, business requirements. Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.
A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations. If an initiative intends to modify existing (or introduce new) hardware/software, a new BRD should be created. The BRD process can be incorporated within a Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) culture.
The most common objectives of the BRD are:
The BRD is important because it is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The process function delivers CTQs (critical to quality). CTQs deliver the voice of customer (VOC). The BRD describes what the system would look like from a business perspective.
The BRD distinguishes between the business solution and the technical solution. When examining the business solution the BRD should answer the question, “What does the business want to do?” For example, the business wants to serve 100 bottles of red wine each night during a three-day conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution should support the business solution. For example, the company would need a wine grotto or refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees Fahrenheit.
A number of teams and partners should create the BRD:
Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected.
Prerequisite two is a current environment assessment created during the measure phase. This includes a detailed process map of the current environment highlighting areas that will be changed during the project. Detailed “as is” process maps should include:
Prerequisite three is CTQs, identified in either the define or measure phases, and validated with baseline measurements, targets and specifications.
Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories:
The BRD appendix can be used to list a number of project details – constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project. Consider the following issues when looking at the overall project:
Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of sections follows:
Business partners should be active participants in the development of the BRD, but a final review and sign-off is also essential.
There are a number of items included in the BRD that require detailed documentation to ensure successful implementation. Following is a high-level overview of the types of detail to consider:
Sample questions for the current environment assessment and systems overview:
The functional requirements section should describe “what” the system is to accomplish rather than the “how.” Develop a prioritized list similar to the following:
Describe expected data tables. Examples include customer records, contact details, machine records, etc. Provide as much detail as possible – a customer record might consist of a name, address, telephone number, fax, mobile number, region, business type, number of employees etc. Indicate any unique fields (such as a job number) and show how different tables relate to each other (very important). For example projects are related to customers through a customer number. Each customer can have none, one or many associated projects. Each project relates to one or more jobs. A job can exist independently of a project but will still be associated with a customer. A project will always have only one customer.
It is not usually necessary to define the tables in database terms (e.g., customer number is a long integer) but examples of the data to be held in the fields is useful (e.g., a typical job number might be FH/1234 where FH indicates the department undertaking the job and 1234 is a unique number. In practice a good database designer would then recognize that the “real” job number is actually the 1234 part and the FH is just an associated field). If the maximum size of any field is known – for example, a “Company Name” field is 100 characters – then include this. If there are any table definitions from existing systems then provide these indicating any required changes.
As with any tool, the BRD can have both benefits and failure modes. Benefits derived from a good BRD include reduced changes during the improve and control phases of DMAIC and reduced time to deployment. Failure modes from a poor BRD means the system developed will not meet business requirements. Creating a successful BRD requires planning and coordination. There are a few best practices that should be followed in this process. The team should hold a dedicated off-site session to complete the BRD with all required resources 100 percent available. Scheduling is the key to success here. As each tool/deliverable is completed within the methodology build the BRD. Allow a one-week deadline to finish action items from the off-site session and hold a final review session two to three hours after completion of action items.