Skip to main content

Business Requirements Document (BRD)

Project teams should use the Requirements Working Group (RWG) Business Requirements Document (BRD), which is available as a Word doc and a Google Doc; it should undergo rigorous review. The template does not dictate project methodology but only prescribes how to go about producing requirements. Project teams should use the RWG process: Elicit, Analyze, Document, Review, Approve. Management should be engaged, involved and approval is essential.

Benefits

  • Doing a better job up front, paying less, and minimizing rework later
  • Using resources more efficiently and speeding up turnaround on reviews
  • Providing more clarity and less confusion and automating the process
  • Improving communication among all stakeholders
  • Increasing buy-in for requirements and happiness with outcomes

All software initiatives must have a set of requirements documented in the template that the RWG has created, using the process that RWG has designed. All requirements must be tracked and approved and adhered to, deviations to which must be documented for the purpose of change.

1. Elicit

This step is completed by the Business Analyst and stakeholders (sponsors, users, technical).

Inputs

  • Project charter
  • Executive summary checklist
  • Interview questionnaire
  • Unfixed defects
  • Known issues/open tickets
  • As-is process map
  • Gap analysis

Outputs

  • Initial list of use cases
  • Initial list of requirements
  • Gap analysis (if applicable)

2. Analyze and Organize

This step is completed by the Business Analyst, users (or user reps), Project Manager, development team, Business Owner/System Owner, and Quality Assurance.

Inputs

Outputs

  • Refined requirements list
  • Alternative views of requirements such as decision tables/trees, models, flow charts, and screenshots/prototypes/mockups
  • Use cases/scenarios
  • Test cases

3. Write

This step is completed by the Business Analyst.

Inputs

  • Project scope/charter
  • Requirements in the form of business flow, questionnaire, use cases, test cases, prototypes, etc.
  • Application and data input
  • Security requirements
  • Business Requirement Document Template

Outputs

  • Formal requirements document that includes organized functional requirements, high-level technical and infrastructure requirements, security requirements, data dictionary, etc.

4. Formal Review and Prioritization

This step is completed by the Business Analyst, customers (all levels of organization represented), technical staff, and other stakeholders.

Inputs

  • Well written and organized set of requirements in model and/or text form

Outputs

  • An agreed upon, prioritized set of requirements ready for design and implementation

5. Approval (Baseline)

This step is completed by the Business Analyst, sponsors, and/or delegated SMEs/Business Owners.

Inputs

  • Reviewed, formal, and version-controlled document stored in central repository

Outputs

  • Acceptance statement; any requirements after this step would be handled separately as Change Requests
  • Approved baseline requirements document ready for the design team

Business Requirements Gathering Checklists

Use theses helpful checklists to ensure you're not missing anything.

Roles and Responsibilities

Actors Roles Responsibilities
Customer/Client Funds the project or acquires a product to satisfy their organizations' objectives. Allocates funding. Reviews requirements to make sure the resulting product will meet the business objective. Provide a clear business vision and scope.
Users Interact directly with the product (software). Provide the business analyst with input so they are fully informed when preparing the business requirements — in both the needs analysis and document review stages.
Business Analyst Takes the lead in identifying and organizing a working group if the subject-matter experts (SMEs) residing in the client's group or department who understand the user tasks and goals, and how they align with the business objectives. Leads all requirements gathering sessions and reviews and prepares the business requirements. Works with the SMEs, users, and client to prepare functional specification and/or system requirements. Identified expected user classes. Elicits and analyzes needs from all user classes. Works with the SMEs and users to prepare complete business requirements. Interprets and documents related business rules (policies, regulations, etc.). Defines quality attributes. Reviews documented requirements with system analyst or development lead, as applicable, and corrects problems before submitting to development group. Prepares functional specifications.
Developer Designs, codes, implements, and maintains a software product. Provides complete and non-problematic code.
Project Manager Plans the project. Reports to management the project status and any risks or concerns. Manages the project, guides project participants, negotiates implementation priorities with client, ensures that the project is finished on time, and manages the project's resources.

Requirements Tracking

Using the JIRA workflow for requirements issue type is strongly recommended (but not required). Project Managers can request this be included in their JIRA projects when they're created. This enables project teams to document and track requirements in JIRA using the workflow, and project dashboard widgets can be used to roll up requirements status.

There are two useful outcomes from entering requirements in JIRA:

  1. Tracking Purposed — Entering issues in a JIRA ticket allows us to track where the requirements are in the 5 step process. Ideally, tie each issue (requirement) back to the original BRD (in Confluence/Google Shared drives).
  2. Traceability — By entering requirements in JIRA, other issues of various issue types, e.g., Bug, Change Request, Tack, etc. can be tied back to the original requirement issue in JIRA. This provides a good way to organize issues and ensure that all issues can be traced back to on of the project requirements. (And, in turn, the Zephyr test case, since JIRA and Zephyr are integrated.)

Assumptions:

  1. The Business Analyst will be the owner (Assignee) of an issue in the first 3 steps of the workflow (Elicit, Analyze, and Write), while the Project Manager will be the assignee of the issue in the last 2 steps (Review and Approve). This person would be responsible for moving the issue through the workflow in a manner that reflects the current status of the BRD.
  2. Requirements will not be converted into any other issue type. In so doing, a custom form that collects only information that is relevant to requirements is used. Other issue types such as Bugs, Change Requests, Enhancements, and Tasks can (and should) be linked to the appropriate requirement.
  3. Once a requirement has been approved and a Baseline Requirement date is established, no additional charges should be allowed to the requirement. If changes need to be made after that point, this should be done using the Change Request issue type.

Training

The webinar version of In Search of Excellent Requirements is available to any employee of Stanford University. Restrictions of use are outlined below; please honor them.

  • Employees of the Licensee may print the magazine articles and other reference documents included in this course ware and may freely share them with other employees of the Licensee. These materials may not be sold or licensed to any third party. They may be posted on the Licensee's Intranet site.
  • Employees of the Licensee may use the templates included in this course ware to create project documents, modifying the templates as desired to best suit each project's needs.
  • Employees of the Licensee may use the other process assets included in this course ware for their own project, modifying the documents as desired.
  • Other than as provided above, the Licensee may not make any portion of this course ware or any representations derived from it, available to any third party in any printed or electronic medium, including but not limited to live presentation, audio or video recording, CD, DVD, computer- or Internet-based training, Web-based seminars, radio or television broadcasts, hard copy, PDF, or PowerPoint.
  • The Licensee may not sub license, sell, or transfer this course ware to any third party, with or without compensation.

Analysis Diagrams

Agile Requirements

Books

IIBA

Other Groups