Appendix A
Sample Business Requirements Document
Logo
Organization Name
Project Title
Business Requirements Document (BRD)
Draft Version: 1.0
Date Prepared:
Prepared by:
The signatures below confirm that this document has been reviewed and is complete and accurate for the project.
Purpose
Describe the project scope and the phase to which this project applies.
This business requirements document (BRD) describes the functional requirements for release 1.0 of the (insert solution, system or project name here). This document is for use by the members of the project team that will design, construct and verify the system or process. If a feature is included, it is assumed to be of high priority and included in this release.
Project Scope
Provide an overview of the organization or project-level standards, guidelines and expectations.
The (insert solution, system or project name here) will provide (organization name) with the following business and high level feature requirements. Describe the solution in textual terms.
Project Client
Provide the name of the sponsor or the client.
Provide the funding source and name. Describe any background information on the project approval or release of funds to the project.
Provide an overview of the budget constraints and the source of the constraint.
The budget for this system is not to exceed $x, including hardware, software capital equipment, expensed equipment or license purchases.
Project Schedule
Provide an overview of the schedule constraints and the source of the constraints.
The system must be complete within (insert constraint here) months but does not need to include all the (list follow-up phase features or lower priority features here).
Related Documents
List all documents that exist relating to this project, such as: program documents, document and model templates, defect checklists, glossaries, and standard operating procedures/work instructions.
Examples:
1. Business Case Location or URL
2. Charter Location or URL
3. Supplemental Business Requirements Location or URL
4. Use Cases Location or URL
Stakeholder Summary
List the stakeholder analysis completed by the business analyst. Identify how representative stakeholders were involved in the requirements discovery (pre-project) process. State how conflicts in stakeholder group interests were resolved.
Business Need
This describes a high-level summary of the reason that this project was undertaken and the phase to which this project applies (if applicable). State in natural (non-technical) language. The intended audience is either the customer or senior management.
The (insert solution, system or project name here) is a new system or process that replaces the current manual processes for (continue to provide a high-level business overview of the need).
Business Solution Overview/Problem Domain Model or Business Process Model
This provides a high-level summary of the business solution described in this document. The intended audience is either the customer or senior management. It may be necessary to provide a graphical representation of a high-level business solution describing system boundaries or major components. Provide a textual description of the major components of the system. An example is a context diagram which represents the scope of a business solution at a high level. It identifies actors and events outside the system that interact with it, without describing internal structure. A problem domain model may look like the following:
State the recommended and alternative approaches to solve the business need. The intended audience is either the customer or senior management.
Metrics
Discuss the business metrics that will be improved by the solution in specific and measurable terms.
Assumptions
Project assumptions clarify gray areas in the project scope. List any known assumptions or special requirements that have been made regarding the project that may influence this agreement. Assumptions are made to fill knowledge gaps; they may later prove to be incorrect and can have a significant impact on the project.
Constraints
Any known constraints imposed by the environment or by management should be noted. Typical constraints may include: fixed budget, limited resources, imposed interim and/or end dates, predetermined software systems and packages and other predetermined solutions.
User Summary
Provide the user analysis completed by the business analyst. Identify how representative users were involved in the requirements discovery process. State how conflicts in user needs were resolved.
Users of the Product/Process
List the user names, roles and their domain knowledge expertise and their technology experience. Describe any other relevant information that impacts requirements. List the prioritization of the users groups. List the user participation in the requirements elicitation, analysis, specification, validation and documentation processes.
User Environment
Describe how the user environment impacts the requirements.
Insert the completed table here. This provides additional information on the high-level commitments made in the use case inventory listed above.
Figure 4-1—Classes
Constraints, assumptions and dependencies
List all business, product line or technical assumptions and constraints for the requirements life cycle process.
Assumptions
Project assumptions clarify gray areas in the project scope. Any known assumptions that have been made regarding the project that may influence this agreement should be noted in the table below. Assumptions are made to fill knowledge gaps; they may later prove to be incorrect and can have a significant impact on the project.
Any known constraints imposed by the environment or by management should be noted. Typical constraints may include: fixed budget, limited resources, imposed interim and/or end dates, predetermined software systems and packages and other predetermined solutions
Required Design Constraints
Overview
Describe the project scope and the phase to which this project applies.
The (insert solution, system or project name) is a new system that replaces the current manual processes. An example is provided below.
5.1 Fundraising Tracking System (FTS)
5.1.1 General Requirements
1. Assumption: FTS only allows a donation to be entered by an internal user. There is no capability to provide this function via the web in the 1st release of the product.
2. Donor, gift and corporate grants business rules are described in supplemental section
3. The system shall have a configurable gift eligibility table of:
a. Gift offering programs
b. Marketing scripts
c. Assumption: This table will be maintained by IT. Business tool owners may open support cases to ask IT to implement changes requested by marketing.
4. The system shall display the following screen elements for each donor (pending UE review):
a. Donor Name
b. Donor Address
c. Previous donation history
d. Previous gift history
1. The system shall display the following non-editable screen elements for each donor (pending UE review):
a. Donor name
i. First name
ii. Last name
iii. Middle initial
iv. Salutations
v. Name of spouse
vi. Any credentials
b. Donor address
i. Street
ii. 2nd Street
iii. City
iv. State
v. Zip Code
c. Email address
d. Types of donation payment options
e. Donation amount
i. Single donation
ii. Donation amount by month
1. Start date of donation
2. End date of donation
2. The system shall review the entered donor information and:
a.Confirm there is a record
5.1.3 Register for email newsletter (TBD)
5.1.4 Create, View, Modify and Delete Marketing Content (TBD)
Any future events that if they occur will positively or negatively impact the project.
Open and Closed Issues
Describe the supplemental requirements required by the users.
The following are sample supplemental requirements.
1. Access Management Requirements
1.1. Roles and Permissions
1.1.1. Describe, at a conceptual level, who will have access to the system or its components and what type of access they will have
1.2. System Impacts
2. External Interface Requirements
2.1. Usability Requirements
2.1.1. The Fundraising Tracking System will provide help links to explain usage of each page.
2.1.2. Wireframes (available before requirements phase exit)
2.1.3. Field-level descriptions (available in design phase)
2.2. Hardware Interfaces
2.2.1. TBD
2.3. Software Interfaces
2.3.1. The Assistance Inc. accounting systems
2.3.1.1. To allow a phone rep to check whether there is a record for a donor on file
2.3.1.2. To transit new donor name and address information
2.3.1.3. To update donor name and address information
2.3.1.4. To transmit the donation amount
2.3.1.5. To change or cancel the donation amount
2.4.1. The FTS shall send shipping an email message to send a gift to a donor
2.4.2. The FTS shall send donor an email message to a donor for a donation commitment
2.4.3. The FTS shall send donor an email message to a donor for a donation acknowledge and details of the donation payment.
2.4.4. The FTS shall send donor an email message for a donation payment failure.
3. Security Requirements
3.1. Specify in business language the security or privacy constraints that the system must respect or adhere to.
4. Performance Requirements
4.1. State in business terms user or system requirements that designers need to consider.
5. Software Quality Attributes
5.1. State the product quality characteristics that are important to stakeholders. Some to consider are maintainability, supportability, interoperability, availability (if not covered under performance).
6. Business Rules
6.1. An agreed-upon procedure, guideline, regulation or standard that leads to a decision on how a system should respond to a condition. Business rules document the policies that the business must follow. These rules may be documented as text, or created as a matrix of conditions and business solution responses. These are not functional requirements in themselves, but they may require functional requirements to execute the rules.
Appendix C: Business Solution Cost Estimating
Project Hardware
Describe the hardware that is available or needs to be purchased for the project development. Describe what networks are available for possible use for the project. If the hardware platform is to be purchased then a technical architecture describing what is necessary should be documented.
Project Software
Describe the application and system software that is available or needs to be purchased for the project development.
Operations Impact
Describe at a high-level the hardware and software required for operational locations at which the application will be used. Provide assumptions for hardware/software, cabling, and connectivity purchases. Describe headcount required to administer or operate the hardware/software purchased.
Business Operations Impact
Describe at a high-level the resources, facilities, training, desktop tools, servers, printers, etc. required for operational locations at which the application will be used. Describe the organizational requirements (new organizational structures, new capabilities, training, etc.) to operate business solution.