0. Analysis Dashboard
VAPTEC TECHNOLOGIES
Business Requirements Document (BRD)
Document details
1. Version Control
Revision History
| Version # | Date | Authorization | Responsibility (Author) | Description |
|---|---|---|---|---|
2. RACI Chart for this Document
RACI stands for Responsible, Accountable, Consulted and Informed. These are the main codes that appear in a RACI chart, used here to describe the roles played by team members and stakeholders in the production of the BRD. The following table describes the full list of codes used in the table:
| Code | Meaning | Description |
|---|---|---|
| • | Authorize | Has ultimate signing authority for any changes to the document. |
| R | Responsible | Responsible for creating this document. |
| A | Accountable | Accountable for accuracy of this document. |
| S | Supports | Provide supporting services in the production of this document. |
| C | Consulted | Provides input. |
| I | Informed | Must be informed of any changes. |
| Name | Position | • | R | A | S | C | I |
|---|---|---|---|---|---|---|---|
3. Executive Summary
a. Overview
This one-paragraph introduction explains the nature of the project.
b. Background
This subsection provides details leading up to the project that explain why the project is being considered. Discuss the following where appropriate: marketplace drivers, business drivers, and technology drivers.
c. Objectives
This subsection details the business objectives addressed by the project.
d. Requirements
This is a brief summary of the requirements addressed in this document.
e. Proposed Strategy
This subsection recommends a strategy for proceeding based on alternatives.
f. Next Steps
Action: Describe the specific action to be taken.
g. Responsibility
State who is responsible for taking this action.
h. Expected Date
State when the action is expected to be taken.
4. Scope
a. Included in Scope
This is a brief description of business areas covered by the project.
b. Excluded from Scope
This subsection briefly describes business areas not covered by the project.
c. Constraints
These are predefined requirements and conditions.
d. Impact of Proposed Changes
| Business Use Case | New? | Desired functionality | Current functionality (If a change) | Stakeholders / systems | Priority |
|---|---|---|---|---|---|
5. Risk Analysis
A risk is something that could impact the success or failure of a project. For each risk, document:
- Likelihood
- Cost
- Strategy. Strategies include:
- Avoid: Do something to eliminate the risk.
- Mitigate: Do something to reduce damage if the risk materializes.
- Transfer: Pass the risk up or out to another entity.
- Accept: Do nothing about the risk. Accept the consequences.
a. Technological Risks
This subsection specifies new technology issues that could affect the project.
b. Skills Risks
This subsection specifies the risk of not getting staff with the required expertise for the project.
c. Business Risks
This subsection describes the business implications if the project is cancelled.
d. Requirements Risks
This subsection describes the risk of erroneous requirements. List areas whose requirements are most likely to be incorrectly captured.
e. Other Risks
6. Business Case
Describe the business rationale for this project. This section may contain estimates on cost/benefit, return on investment (ROI), payback (length of time for the project to pay for itself), market share benefits… Quantify each cost or benefit so that business objectives may be measured after the implementation.
7. Timetable
| Milestone | Date | Responsibility |
|---|---|---|
8. Business Use Cases
Complete this section if the project involves changes to the workflow of the end-to-end business process. Document each end-to-end business affected by the project as a business use case. If necessary, describe the existing workflow for the business use case as well as the new, proposed workflow.
a. Business Use-Case Diagrams
Business use-case diagrams describe stakeholder involvement in each business use case.
b. Business Use-Case Descriptions
Describe the workflow of each business use case with text and/or an activity diagram. If you are documenting with text, use an informal style or the use-case template described in the “User Requirements” section.
9. Actors
a. Workers
List and describe stakeholders who act within the business in carrying out business use cases.
| Department / Position | General impact of the Project |
|---|---|
b. Business Actors
List and describe external parties, such as customers and partners, who interact with the business.
| Actor | General Impact of Project |
|---|---|
c. Other Systems
List computer systems potentially impacted by this project. Include any system that will be linked to the proposed system.
| System | General Impact of Project |
|---|---|
d. Role Map
The role map describes the roles played by actors (users and external systems) that interact with the IT system.
10. User Requirements
Describe requirements for automated processes from a user perspective.
a. System Use-Case Diagrams
System use-case diagrams describe which users use which features and the dependencies between use cases.
b. System Use-Case Descriptions
During Initiation, only short descriptions of the use cases are provided. During Analysis, the following template is filled out for each medium to high risk use case. Low risk use cases may be described informally. This template may also be used to document the business use cases included earlier in the BRD.
c. Use-Case Description Template
i. Use case
(The use-case name as it appears on system use-case diagrams.)
Perspective: Business use case / system use case
Type: Base use case / extension / generalized / specialized
-
Brief description
Briefly describe the use case in approximately one paragraph.
-
Business Goals and Benefits
Briefly describe the business rationale for the use case.
-
Actors
- Primary Actors — Identify the users or system that initiate the use case.
- Secondary Actors — List the users or system that receive messages from the use case. Include users who receive reports or on-line messages.
- Off-Stage Stakeholders — Identify non-participating stakeholders who have interests in this use case.
-
Rules of Precedence
- Triggers — Describe the event or condition that “kick-starts” the use case: such as User calls Call center, Inventory low. If the trigger is time driven, describe the temporal condition, such as end-of-month.
- Preconditions — List conditions that must be true before the use case begins. If a condition forces the use case to occur whenever it becomes true, do not list it here — list it as a trigger.
-
Postconditions
- Postconditions on Success — Describe the status of the system after the use case ends successfully. Any condition listed here is guaranteed to be true on successful completion.
- Postconditions on Failure — Describe the status of the system after the use case ends in failure. Any condition listed here is guaranteed to be true when the use case fails as described in the exception flows.
-
Extension Points
Name and describe points at which extension use cases may extend this use case. Example: Preferred Customer.
- Priority
-
Status
Your status report might resemble the following example:
- Use-Case brief complete: DD/MM/YYYY
- Basic flow + risk alternative complete: DD/MM/YYYY
- All flows completed: DD/MM/YYYY
- Coded: DD/MM/YYYY
- Tested: DD/MM/YYYY
- Internally released: DD/MM/YYYY
- Deployed: DD/MM/YYYY
- Expected Implementation Date
- Actual Implementation Date
-
Context Diagram
Include a system use-case diagram showing this use case, all its relationships (includes, extends, and generalizes) with other use cases and its associations with actors.
ii. Flow Of Events
- Basic Flow
Insert basic flow steps.
- Alternate Flows
The alternate flow name should describe the condition that triggers the alternate flow. It is a step number in the basic flow where interruption occurs.
- Exception Flows
An exception flow is one that causes the use case to end in failure and for which “postconditions on failure” apply. This is a step number in the basic flow where interruption occurs.
iii. Special Requirements
- Nonfunctional Requirements
List requirements not visible to the user during the use case — security, performance, reliability, and so on.
- Constraints
List technological, architectural and other constraints on the use case.
iv. Activity Diagram
If it is helpful, include an activity diagram showing workflow for this use case, or select parts of the use case.
v. User Interface
Initially, include description/storyboard/prototype only to help the reader visualize the interface, not to constrain the design. Later, provide links to screen design artifacts.
vi. Class Diagram
Include a class diagram depicting business classes, relationships, and multiplicities of all objects participating in this use case.
vii. Assumptions
List any assumptions you made when writing the use case. Verify all assumptions with stakeholders before sign-off.
viii. Information Items
Include a link or reference to documentation describing rules for data items that relate to this use case. Documentation of this sort is often found in a data dictionary. The purpose of this section and following sections is to keep the details out of the use case proper, so that you do not need to amend it every time you change a rule.
ix. Prompts and Messages
Any prompts and messages that appear in the use case proper should be identified by name only, as in Invalid Card Message. The Prompts and Messages section should contain the actual text of the message or direct the reader to the documentation that contains the text.
x. Business Rules
The Business Rules section of the use-case documentation should provide links or references to the specific business rules that are active during the use case. An example of a business rule for an airline package is “Airplane weight must never exceed the maximum allowed for its aircraft type”. Organizations often keep such rules in an automated business rules engine or manually in a binder.
xi. External Interfaces
List interfaces to external systems.
xii. Related Artifacts
The purpose of this section is to provide a point of reference for other details that relate to this use case, but would distract from the overall flow. Include references to artifacts such as decision tables, complex algorithms and so on.
11. State Machine Diagrams
Insert state machine diagrams describing the events that trigger changes of state of significant business objects.
12. Nonfunctional Requirements
Describe across-the-board requirements not covered in the use-case documentation.
a. Performance Requirements
- Stress Requirements — This subsection of performance requirements describes the degree of simultaneous activity that the system must be able to support. For example “the system must be able to support 2000 users accessing financial records simultaneously.”
- Response-Time Requirements — This subsection of performance requirements describes the maximum allowable wait time from the moment the user submits a request until the system comes back with a response.
- Throughput Requirements — This subsection of performance requirements describes the number of transactions per unit of time the system must be able to process.
b. Usability Requirements
Describe quantitatively the level of usability required. For example “A novice operator, given two hours of training, must be able to complete the following functions without assistance…” Also refer to any usability standards and guidelines that must be adhered to.
c. Security Requirements
Describe security requirements relating to virus protection, firewall, the functions and data accessible by each user group…
d. Volume and Storage Requirements
Describe the maximum volume (example: the number of accounts) that the system must be able to support, as well as random access memory (RAM) and disk restrictions.
e. Configuration Requirements
Describe the hardware and operating system that must be supported.
f. Compatibility Requirements
Describe compatibility requirements with respect to the existing system and external systems with which the system under design must interact.
g. Reliability Requirements
Describe the level of fault-tolerance required by the system.
h. Backup / Recovery Requirements
Describe the backup and recovery facilities required.
i. Training Requirements
Describe the level of training required and clearly state which organizations will be required to develop and deliver training programs.
13. Business Rules
List business rules that must be complied with throughout the system. For example, an inventory might have a rule that whenever inventory falls below a trigger level, an automatic order is placed with the supplier. If an external rules engine is being used, this section should refer the reader to the location of these rules.
14. State Requirements
Describe how the system’s behavior changes when in different states. Describe the features that will be available and those that will be disabled in each case.
a. Testing State
Describe what the user may and may not do while the system is in the test state.
b. Disable State
Describe what is to happen as the system goes down. Clearly define what the user will and will not be able to do.
15. Static Model
During Initiation, only strategic classes are modeled.
a. Class Diagrams: Entity Classes
Insert class diagrams representing classes of business objects and relationships among the classes. This section centralizes rules that govern business objects, such as the numerical relationships between objects, the operations associated with each class and so on.
b. Entity Class Documentation
Insert documentation to support each of the classes that appear in the class diagrams. Not every class needs to be fully documented. First do a risk analysis to determine where full documentation would most benefit the project.
c. Class Name
- Alias: List any other names by which the class is known within the business domain.
- Description:
- Attributes:
| Attribute | Derived? | Derivation | Type | Format | Length | Range | Dependency |
|---|---|---|---|---|---|---|---|
When your requirements are complete up to this point, submit them to appropriate people and to developers. You can then work on the test plan, implementation plan and end user procedures.
16. Test Plan
To standardize the testing, you should develop a test plan document for analysts to follow when constructing project test plans. Although every project is different, the following may be used as a guideline. Each project should consider the following stages during testing:
a. Submit the requirements to the technical team
The technical team completes development. Concurrently, the BA builds numbered test scenarios for requirements-based testing. Consider using decision tables to identify scenarios and boundary value analysis to select test data. The technical team conducts white-box testing, to verify whether programs, fields, and calculations function as specified. The BA or technical team specifies the required quality level for white-box testing, such as multiple-condition testing.
b. Perform requirements-based testing
The BA or dedicated QA (Quality Assurance) staff administers or supervises tests to prove or disprove compliance with requirements. Ensure that all formulae are calculated properly. Describe principles and techniques to be used in black-box testing, such as structured testing guidelines and boundary value analysis.
c. Conduct system testing
Ensure that the integrity of the system and data remain intact. For example:
- Regression test: Retest all features.
- Stress test: Test multiple users at the same time.
- Integration tests: Make sure that the changes do not negatively affect the overall workflow across IT and manual systems.
- Volume test: Test the system with high volume.
d. Perform user acceptance testing
Involve the end users at this stage. Choose key users to review the changes in the test environment. Use the testing software as a final check.
17. Implementation Plan
a. Training
- Specify who is responsible for training.
- Specify who is to be trained.
- Specify how training will be done.
b. Conversion
Specify existing data that must be converted. Promote programs to new release. Grant privileges to the users.
c. Scheduling of Jobs
Advise Information Systems (IS) operations which jobs to add to the production run. Specify the frequency of the run: daily, weekly, monthly, quarterly, semi-quarterly or annually. Ensure that the job is placed in the correct sequence. Advise IS operations of the reports to be printed and the distribution list for reports and files.
d. Rollout
Advise all affected users when the project is promoted.
18. End User Procedures
Write up the procedures for the affected department. Distribute this document to them in addition to providing any hands-on training.
19. Post Implementation Follow-up
Follow up within a reasonable time frame after implementation to ensure that the project is running successfully. Determine whether any further enhancements or changes are needed to ensure success of the project.
20. Other Issues
21. Sign-Off
| Name | Role | Signature | Date |
|---|---|---|---|
∑ Usage
How many people have used this BA Analysis Tool.