Revisions to the Business Requirements Document should reflect at least the following information:

Describe those strategic goals and objectives that the project under consideration is intended to fulfill. If a strategic mission and vision document or statement is available, it should be included here for reference. Also describe what is clearly out of scope for this project and, therefore, for this BRD.

Keep in mind the audience for whom this is written, to ensure that the proper level of detail is maintained throughout. An organizational chart for the affected business unit(s) should be included.

Enter sufficient detail to orient the reader as to the context surrounding this initiative—especially whether this is a phase of a multiphase project, whether prior efforts have failed (and why), and whether subsequent activity or phases are planned.

Describe the process(es) employed for producing this BRD. Specifically, indicate whether research, interviews, surveys, focus groups, or the like were employed. Also indicate whether business use cases were employed and where they are available for review.

Indicate the names of individuals who were contacted for this BRD, classify them in the following three stakeholder categories, and specify which have approval authority for this BRD:

Identify the business-level performance improvements that are needed and that the organization expects the project to satisfy. Examples would be reduced cost, increased customer satisfaction, enhanced efficiency, better quality, stricter regulatory compliance, increased marketplace performance, etc. Include all long-term (strategic), short-term (tactical), and on-going (operational) factors that help to clearly define these business-level requirements.

Describe the performance improvements to individual business processes and systems that will help users more successfully perform their tasks as a result of the project. Examples would be “easy access to customer support any time of day” or “a simpler way for customers to exchange information with the organization”. These requirements are typically described from the user’s point of view and in nontechnical user terms. As a result, they are often assembled in a narrative form and supported by various graphic models, such as work flow charts, use case diagrams, activity (swim lane) diagrams, and the like.

Specify the operational behavior of business processes and systems that will lead to satisfying the user requirements described above. In particular, this includes how users will interact with manual or automated systems that will be part of the project deliverables. The following are examples: providing clients with 24-hour Internet access to customer service staff (instead of having to make telephone calls only during the day); providing patients with CDs that contain their x-rays (instead of large films that require special light readers); and enabling students to complete only one application form for any state college in the same state (instead of a unique form at each institution). All three instances describe functional interaction with the organization’s business processes that will satisfy the above user requirement for simpler transactions and in turn meet the above business-level requirement of improved customer satisfaction.

Detailed technical specifications are not included here, because they will be developed later in the project during the solution design and construction phases. However, this section should contain sufficient information on the needed functionality so that solutions being developed and tested during the project can be repeatedly compared against the users’ expectations.

Nonfunctional requirements include anything that enhances the success and value of the project deliverables to the users. This includes training, documentation storage and retrieval, security, service-level agreements, integration with other business processes, and any other aspects of successful performance that users typically take for granted and do not request directly.

Specify the content, format, source, frequency, and intended audience of any and all reports that are expected as deliverables of this project. These can include regularly scheduled reports, ad hoc inquiries, and audit reports.

Beginning with the most basic assumptions—such as sufficient funding, staffing, and executive support—this section specifies all vital areas of the project that are presumed to be constant and therefore warrant close oversight and continual updates.

Specify the relationship that this project has to other projects, to phases of an overall program, and to any upstream or downstream elements that the project can affect or be affected by.

Any limitations on the project, for example, schedule, budget, labor resources, partner availability, etc., must be listed here. They set the boundaries within which the project is expected to operate.

Clearly delineate the process for identifying, managing, escalating, and retiring risks that can impact the project. Keep in mind that risk equals uncertainty, and that all uncertainty, whether small or large, deserves identification and management as the project is formulated and then executed.

Existing technology and its impact on the envisioned project should be outlined here, together with any newer technology to be considered.

Although the BRD is not intended to provide final solutions—as that is the domain of the project itself and its Statement of Work—nevertheless, any information available on pilot programs, proof of concept work, or rejected solutions should be included here. This will ensure that such historical knowledge is part of future project work, thus forestalling possible duplication of effort.

Once the final BRD is approved with signatures from key stakeholders, changes to it should only occur under strict change management control. Details of such a control process should be reflected here, including what constitutes a change, as well as how its impact should be evaluated prior to seeking approval from the original approvers of the BRD.

For completeness and convenience to readers, include in this section all appropriate supporting documents, such as the Project Charter, Business Case, Requirements Work Plan, Process Modeling Diagrams, etc.