Business Requirements Document: a High-level Review

	Bookmark This Page Email This Page Format for Printing Cite This Article Submit an Article Read More Articles
	Related Tools & Articles Identifying High-Level Requirements Using SIPOC Diagram Voice of the Business, Customer, Process and Employee Sustaining Results From Six Sigma
	Discussion Forum "Decide whether you want to view your business analysts as a function or as a process. If viewed as a function, you could have specific controls: timely/periodic analysis of performance data, identification and completion of improvement projects etc." Contribute to this Discussion

B

New from iSixSigma Business Innovation in the 21st Century ebook Cost Analysis Requirements Document Project Example Improving Aircraft Engine Disassembly Project Example

y J. DeLayne Stroud

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:

• To gain agreement with stakeholders
• To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer's and business’ needs
• To provide input into the next phase for this project
• To describe what not how the customer/business needs will be met by the solution

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.

Who should be involved in the creation of the BRD?

A number of teams and partners should create the BRD:

• Project core team
• Business partner(s)
• Process Owner(s) or representatives
• Subject matter experts
• Change/project/product management, quality department and/or IT management as needed or available

Prerequisites for 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:

• Clearly defined start and end points of the process
• Level two and three process functions
• Defined areas of rework and non-value added steps
• Cycle time, capacity and rework information for each process step as available
• Baseline for each CTQ for the current environment

Prerequisite three is CTQs, identified in either the define or measure phases, and validated with baseline measurements, targets and specifications.

• Current measures: Data that defines and describes current performance – sigma level of the CTQ includes a definition of how the product/service's characteristic is to be quantified.
• Target/nominal value: What is the aim of the product/service? If there was never any variation in the product/service, this would be the constant value.
• Specification limits: How much variation is the customer willing to tolerate in the delivery of the product or service? Define upper and lower specification limits as required by the customer needs.
• Allowable defect rate: How often are the producers willing to produce a product/service outside the specification limits?

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:

• People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)]
• Systems: Systems is processing information and making decisions
• Systems/people: System is processing information and people are making the decisions
  • Distinguish between employee and customer
  • Distinguish leadership requirement for associate in case decision making authority has to be moved up
• Fishbone: For each process function for impact assessment

Overall Project Details and Best Practices

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:

• Are there any regulatory or geographic constraints (i.e., State law) to consider? If so, these constraints need to be clearly documented in the process detail table of the BRD or in the overall project details section of the appendix.
• What assumptions or dependencies apply?
• What business rules apply?
• Are there any measurements or reporting requirements that apply to the project?

Best Practices

1. Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process.
2. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for:
   • People
   • Process
   • Technology
   • Materials and supplies
   • Facilities
   • Product
   • Machinery and equipment
   • Others as necessary (depending on the organization)
3. Definitions and acronyms: Define any terms not clearly understood by all.

Packaging the BRD

Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of sections follows:

• Project overview including project charter information, scope, and objectives
• Current environment assessment and systems overview (see additional details below)
• Future process map
• Process detail table
• Overall project business rules and constraints
• Impact assessment (fishbone for process functions)
• Functional requirements (additional details below)
• Data to be held (additional detail available below)
• Schedule and budget
• Terms and definitions
• Approver information 
• Team information

Business Partner Sign-off

Business partners should be active participants in the development of the BRD, but a final review and sign-off is also essential.

Additional Details

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: 

• Who is the intended user?
• How many users are there? Are they the same type of user or different?
• What level of computer experience will the users have (or is needed)?
• What is the required security?
• Are there hardware constraints – networked or stand-alone?
• What are the approximate numbers of records required initially plus the anticipated growth?
• What technical support is necessary and available in-house?
• What other systems need to integrate/communicate?
• Backup. Describe the current back-up regime (e.g., tape back-up one/day). How will the new system fit with this? If this is not currently defined then think how much data could be inadvertently lost. For example would it be a major disaster if the last 30 minutes of work was lost, or could yesterday's/last week's data be retained?
• Deliverables. What are the expectations – system, help files, documentation, full source code, training, support, etc.? Detail what is essential versus nice. Do not automatically ask for everything unless necessary. If the project manager is to maintain the system make sure he states that he requires the full source code – alternatively if the developer is to maintain the system consider settling for an escrow agreement (where the source is held by an independent third party). Be specific about tools necessary to help. If the developer is unwilling to provide the support necessary find someone else who will.

The functional requirements section should describe “what” the system is to accomplish rather than the “how.” Develop a prioritized list similar to the following:

• A detailed description of the requirement including goals, e.g., produce a report of spend/department/year on demand with the user selecting the department and the financial year required – it is necessary to know how the company defines the financial year.
• How important is this requirement (essential, preferred, nice to have, not essential, etc.)?
• Any known design/implementation issues relating to this requirement?
• Does this requirement interact with other requirements?

Data to be Held: Sample Advice

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.

Summary

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% 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.

About the Author: J. DeLayne Stroud is a Six Sigma Master Black Belt project manager with DeLeeuw Associates, a division of Conversion Services International. He retired from Bank of America in 2005 with more than 20 years of experience as an executive in project and change management in the banking industry. He has led multiple Six Sigma initiatives including Design for Six Sigma and Lean initiatives. During his career, Mr. Stroud was a senior project manager in some of the largest mergers and change initiatives in the history of the financial services industry, including former banks such as General Bancshares, Boatmen's Bank, Centerre Bank, Barnett Bank and BankAmerica. He can be reached at jstroud@deleeuwinc.com.