FRIDAY, JULY 25, 2014
Font Size
Implementation Project Selection & Tracking Business Requirements Document: A High-level Review

Business Requirements Document: A High-level Review

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

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Comments

Megha 17-03-2010, 05:20

Thank you Mr. Stroud.

I am a recent Engineering graduate aspiring to be a Business Analyst and this article is very helpful. :)

Reply
Vaseela 12-04-2010, 08:53

Very useful information. Thank You.

Reply
Pamela 27-04-2010, 13:42

Thank you this is exactly what we needed.

Reply
priya 29-06-2010, 10:03

useful information. Thank you Mr. Stroud.

Reply
Vikram 05-08-2010, 15:37

There One should be able to understand the difference between Business Requirements and Functional Specifications.

Business requirements should focus on what the client wants, not how they want it. Once the complete requirements are gathered, the solution should be discussed. There may be more than one type of solution that will meet the resource availability, etc. and will help in estimating the time required to deliver the solution to the client.

Then the specifications should be written based on the solution to meet the requirements. This is where the business analyst arrange workshops with different teams involved in the project to discuss the UI design changes, DB changes, architectural changes, etc. These teams will comprise of developers, QA, DB, data security, etc.

Reply
devesh purwar 13-08-2010, 10:30

very nice article as in have a usefull knowledge for overall understanding of BRD.it provdes a gr8 insigth..
thanks

Reply
Sandeep 18-08-2010, 15:27

The article is wonderful, informative. Thanks.

Reply
Raju Joshi 31-08-2010, 09:29

Hi There Thanks for this wonderful article. This article gives me a brief understanding of BRD. Thanks for putting this article on WEB…

Regars,
Raju Joshi
TCS consultant…

Reply
Andrew 21-10-2010, 08:52

Thank You very much sir this is exactly what i needed

Reply
Xeruba 16-11-2010, 18:06

This IS an EXCELLENT document…thanks so much for so succinctly expressing your expertise. It provided the info I needed! I have an “environment” question though. How does one respond when things are done in a way that indicates people are doing enough to cross it off their “list of to do’s”, but aren’t providing whats essential to the BRD or the success of the project for that matter? For instance, I was off work sick for a week for a project for which I’m the customer. I and the PM had basically fleshed out the bus req’s early on, but the BRD was assigned to someone on the technical team to produce (???) He basically copied and pasted info into the BRD template from documents I created during the fleshing out process, training material, etc…but small things indicated he’s has no REAL understanding of the business need. Why would the PM assign him the BRD, and make it due the same day she has to present it to the Service Level Managers for sign-off? The core team has had no time to review it collaboratively and make needed adjustments. And what’s the best diplomatic way to respond…so I don’t offend the technical analyst, appear to question the judgement of the PM, but still ensure that the business needs are clear and properly represented?. Do I send emails expressing my concerns to the entire team. Do I sit tight and hope for the best. Do I talk with the PM offline, the technical analyst offline.Sigh, thx!

Reply
Richer Fortin 25-04-2011, 18:14

Very good article, Resumes very well the basics. Thank you,

Richer

Reply
Nash 11-06-2011, 17:13

A very good article for reference..

Reply
Krunal Jambhulkar 13-02-2012, 02:11

Good insight on BRD. Good article.

Reply
Ehsan Uddin Ahmed 04-05-2012, 11:31

Excellent work, highly appreciable

Reply
Anonymous 13-03-2013, 21:24

Useful information for business analysts to write business requirements for the better output from the project..

Reply
samalpha 04-10-2012, 15:53

Splendid article made most of my confusions go away abt the TOC of a BRD. Can you please elaborate the differences of Bus Req’s vs Technical Req’s and if the Functional req’s are the brifge between the both..?

Reply
Caroon 13-11-2012, 15:04

BRD: An accurate and complete description specifying what the end product will act/look like when completed and accepted is crucial to a project’s success.

Thanks.

Reply
Daniel 14-12-2012, 06:54

An example document would have been nice. I know you’ve effectively provided that in the “prerequisites”, but sometimes seeing the layout of an effective BRD can be easier to understand and comprehend.

Reply
Sandeep Kumar 26-02-2013, 22:16

Nicely Articulated, Kudos to you :)

Reply
Jason 26-09-2013, 03:56

need more examples here.

Reply
leo 17-02-2014, 21:38

thank you

any thoughts on secrecy on doc as required…governing laws.

Reply
hetshri mehta 24-02-2014, 07:16

dear sir/madam. Very nice concept regadind document but I also want some images of A documents because it is easy to us in understandig,,,,keep it up,, Thanks,

Reply
Roland O. Damissah 07-03-2014, 06:49

Very incisive and useful article.

Reply

Login Form