Appendix B
Sample Business Requirements Document—Use Cases
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 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 and by the customer to confirm that this solution will satisfy their needs.
Project Scope
Provide an overview of the organization or project 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. This document represents the scope of the project. If a feature is included, it is assumed to be of high priority and included in this release.
Describe the solution in high-level 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. Also list any current system document that was used to describe the as-is process or was used in re-engineering solutions.
Examples:
Business Case (Location or URL)
Charter (Location or URL)
Supplemental Business Requirements (Location or URL)
Use Cases (Location or URL)
Stakeholder Summary
List the results of the stakeholder analysis completed by the project manager. 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 if the reason that this project was undertaken and the phase to which this project applies (if applicable). Use 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. Give a description of the major components of the system.
An example is a use case diagram serving as the problem domain model. This represents scope of the 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:
Figure 3-1—Use Case Diagram
The summary may also be stated in a matrix
Figure 3-2—Use Case Inventory
Approaches
State the recommended and alternative approaches to solve the business need. The intended audience is either the customer or senior management.
Discuss the business metrics that will be improved by the implementation of the solution in specific and measurable terms.
Assumptions
Project assumptions clarify gray areas in the project. List any known assumptions or special requirements 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.
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—Actor Goals
Feature Description
Describe the business solution behavior requested by the users.
The following are sample business scenarios that are included in the first release of the Donation Tracking system.
1.1. Give donations
1.1.1. As-Is
An individual donation is either received over the phone or in the mail. This information is written down on a donor form if received over the phone. Only actual donation information is entered into the accounting system. Fields are not verified for accuracy.
1.1.2. To-Be Description and Priority
An individual donor who is verified to have information listed in the Fundraising Tracking System will be able to provide payment information. An individual donor may change the donation amount, change the donation payment method or cancel their donation. This must be in the first release of the project.
1.1.3. To-Be Stimulus/Response Sequences
Stimulus: Donor agrees to provide a donation
Response: Phone rep asks donor for details of the payment
Stimulus: Donor requests a change in donation amount
Response: If donation amount is found, system allows phone rep to modify a previous donation amount.
Stimulus: Donor requests a cancellation of a donation amount
Response: If donation amount is found, system allows phone rep to cancel a previous donation amount.
1.1.4. To-Be Give Donations Functional Requirements
(Functional requirements for changing and canceling donations are not provided in this example.)
1.2. Register for email newsletter
TBD
1.3. Create, View, Modify and Delete Marketing Content
TBD
1.4. Report Requirements (Ad hoc and Scheduled)
TBD
Risks
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 to 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.
List high-level use case information (further information will be provided in the requirements phase as each iteration of the use cases are completed).
A sample use case is provided below.
B-1 Give Donation
1. Description
An internal user enters information provided by a donor into the Fundraising Tracking System (FTS).
2. Actors
1. FTS Users
2. FTS
3. Security Management (SM) API
3. Pre-conditions
Donor has an existing record
User access to FTS Give Donation function in SM API
7. Post-conditions
1. Successful transaction screen displayed
2. Donation posted to accounting
3. Credit card charged
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.
IT Operations Impact
Describe at a high-level the hardware and software required for operational locations at which the application will be used. Provide a 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.