Scribd Logo
Upload

Welcome to Scribd!

  • 236 views

    Business Requirements Document (BRD) Template: Project/Initi Ati Ve Month 20YY

    Uploaded by

    Sonesh Gaur
    This document provides a template and guidelines for a Business Requirements Document (BRD) for a new project. It includes sections for document revisions and approvals. The introduction describes the project objectives, background and business drivers. It defines the in-scope and out-of-scope functionality as well as assumptions, constraints, risks and issues. Current and proposed business processes are outlined along with visual process flow diagrams. Finally, priority-ranked functional requirements are specified and linked to use case documentation. The BRD template is designed to clearly communicate the requirements and scope of the new project to stakeholders.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Business Requirements Document (BRD) Template: Project/Initi Ati Ve Month 20YY

    Uploaded by

    Sonesh Gaur
    236 views9 pages
    This document provides a template and guidelines for a Business Requirements Document (BRD) for a new project. It includes sections for document revisions and approvals. The introduction describes the project objectives, background and business drivers. It defines the in-scope and out-of-scope functionality as well as assumptions, constraints, risks and issues. Current and proposed business processes are outlined along with visual process flow diagrams. Finally, priority-ranked functional requirements are specified and linked to use case documentation. The BRD template is designed to clearly communicate the requirements and scope of the new project to stakeholders.

    Original Title

    BRD Template

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document provides a template and guidelines for a Business Requirements Document (BRD) for a new project. It includes sections for document revisions and approvals. The introduction describes the project objectives, background and business drivers. It defines the in-scope and out-of-scope functionality as well as assumptions, constraints, risks and issues. Current and proposed business processes are outlined along with visual process flow diagrams. Finally, priority-ranked functional requirements are specified and linked to use case documentation. The BRD template is designed to clearly communicate the requirements and scope of the new project to stakeholders.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    236 views9 pages

    Business Requirements Document (BRD) Template: Project/Initi Ati Ve Month 20YY

    Uploaded by

    Sonesh Gaur
    This document provides a template and guidelines for a Business Requirements Document (BRD) for a new project. It includes sections for document revisions and approvals. The introduction describes the project objectives, background and business drivers. It defines the in-scope and out-of-scope functionality as well as assumptions, constraints, risks and issues. Current and proposed business processes are outlined along with visual process flow diagrams. Finally, priority-ranked functional requirements are specified and linked to use case documentation. The BRD template is designed to clearly communicate the requirements and scope of the new project to stakeholders.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 9

    Business Requirements Document (BRD)

    Template
    Project/Initi ati ve
    Month 20YY
    Version X.XX

    Company Information
    BRD
    1 Document Revisions
    Version
    Date Document Changes
    Number
    05/02/20xx 0.1 Initial Draft

    2 Approvals
    Role Name Title Signature Date
    Project Sponsor
    Business Owner
    Project Manager
    System Architect
    Development Lead
    User Experience
    Lead
    Quality Lead
    Content Lead

    2
    BRD
    3 Introduction
    3.1 Project Summary
    3.1.1 Objectives
    [These should describe the overall goal in developing the product, high level descriptions of what
    the product will do, how they are aligned to business objectives, and the requirements for
    interaction with other systems.]
     Deliver a Widget Interactive Naming System (WINS) that synchronizes naming and linking of all
    widgets in all systems across the enterprise.
     Avoid duplication of widget names and reduce time to production for existing projects.
     Support text searching on widget names or business descriptions.
     Sync widget names and changes to Windows and Linux platform administration tools.
     Tracks changes to widgets including new widgets, modified widgets, and widgets to be archived.

    3.1.2 Background
    [Provide a brief history of how the project came to be proposed and initiated, including the
    business issues/problems identified, and expected benefit of implementing the project/developing
    the product.]
    Timely and accurate synchronization of widget names will reduce development levels of efforts across the
    enterprise by eliminating duplicate names of widgets in development and deployed. Acme uncovered seriously
    high levels of errors across testing environments, production error messages, and increased rework due to lack
    of knowledge about widgets already in production.

    3.1.2.1 Business Drivers


    [List the business drivers that make development of this product important. These can be
    financial, operational, market or environmental.]
     Customers are looking for faster updates to information on the [product] website, and may
    consider competitors if needs are not met.
     Development group requires a scalable solution to track the widgets being deployed into all
    environments to better manage resources.

    Template provided at no charge by TechWhirl.com


    You are free to use and customize as needed
    BRD
    3.2 Project Scope
    [Describe what work is in scope for the project, and specifically what work is out of scope…
    beyond the current budget, resources and timeline as approved by the project stakeholders. This
    is designed to prevent “scope creep” of additional features and functions not originally
    anticipated.]

    3.2.1 In Scope Functionality


     Create name records for widgets by category
    o Supply Chain
    o Production Lines
    o Internal web apps
    o External web apps
     Ability to create/delete widget names restricted by role
     Search by name, team, date, last modified
     Synchronize widgets across product/operations lines
     Provide audit trail
     Reporting on new, modified, and archived widgets by time period and team

    3.2.2 Out of Scope Functionality


     Create widgets for subsidiary company product lines
     Search by approver, or rationale
     Archiving of widget objects

    3.3 System Perspective


    [Provide a complete description of the factors that could prevent successful implementation or
    accelerate the projects, particularly factors related to legal and regulatory compliance, existing
    technical or operational limitations in the environment, and budget/resource constraints.]

    3.3.1 Assumptions
     Inventory of existing widgets completed by Q1.
     Testing data comprises scrubbed production data as of December 31.

    3.3.2 Constraints
     Impending changes to privacy regulations may impact data dictionary design.
     Timeline for enterprise platform updates will impact execution of testing plan.

    3.3.3 Risks
     Previously approved Q2/Q3 development projects may limit availability of development and QA
    resources, necessitating outsourcing or additional budget requisitions to meet the anticipated
    timeline.
     .

    3.3.4 Issues

    BRD
    4 Business Process Overview
    [Describe how the current process(es) work, including the interactions between systems and
    various business units. Include visual process flow diagrams to further illustrate the processes
    the new product will replace or enhance.
    Use case documentation and accompanying activity or process flow diagrams can be used to
    create the description(s) of the proposed or “To-Be” processes.]

    4.1 Current Business Process (As-Is)


    At any point during or after deployment of web apps or web sites (internal or external) to support business
    activities, development/support teams may create and deploy widgets.
    1. CMS / database administrators for the employee portal use the CMS tool to create widgets.
    They can test widgets in the designated staging environment, then register them and deploy to
    production.
    2. Development teams may deploy widgets to development and testing environments set up for
    their development projects. They must check widget code into and out of the source code repository
    according to their projects’ development schedule.

    4.2 Proposed Business Process (To-Be)


    1. Technical Lead searches repository
    3. If widget is not found, user creates a new widget name record.
    4. WINS validates that all fields have been completed.
    5. WINS confirms that no similar widgets exist
    6. User confirms record to be created.
    BRD

    1. User searches repository to locate existing widget description.


    7. WINS displays record
    8. User selects Edit to open and modify record
    9. WINS validates all fields completed correctly
    10. User confirms changes.
    11. WINS confirms changes and updates Audit table.
    BRD
    5 Business Requirements
    [The specific business requirements elicited from stakeholders should be listed, categorized by
    both priority and area of functionality to smooth the process of reading and tracking them.
    Include links to use case documentation, and other key reference material as needed to make the
    requirements as complete and understandable as possible. You may wish to incorporate the
    functional and non-functional requirements into a traceability matrix that can be followed
    throughout the project.]
    The requirements in this document are prioritized as follows:

    Value Rating Description


    1 Critical This requirement is critical to the success of the project. The project will not be
    possible without this requirement.
    2 High This requirement is high priority, but the project can be implemented at a bare
    minimum without this requirement.
    3 Medium This requirement is somewhat important, as it provides some value but the
    project can proceed without it.
    4 Low This is a low priority requirement, or a “nice to have” feature, if time and cost
    allow it.
    5 Future This requirement is out of scope for this project, and has been included here
    for a possible future release.

    5.1 Functional Requirements

    Req# Priority Description Rationale Use Case Reference

    General / Base Functionality

    A new Master Widget Single repository simplifies


    repository shall be created management of widget
    FR-G-001 1 to house the name records development across 30+ global
    and links to the widget development teams
    objects.

    A widget shall be defined in ID+Name eliminates duplicate


    the repository via a unique widget name records
    FR-G-002 1
    identifier and name
    combination.

    FR-G-003

    FR-G-004

    0
    BRD
    Req# Priority Description Rationale Use Case Reference

    FR-G-005

    Security Requirements

    Widget creation in the


    repository shall be limited to
    FR-S-001 1
    users with Team Lead or
    System Administrator,

    Reporting Requirements

    The system shall generate a


    FR-R-001 2 weekly Report of Widget
    Name Status Changes

    Usability Requirements

    User interface for the WINS


    repository shall be
    FR-U-001 1 responsive, allowing for
    proper display on tablet,
    laptop, and desktop devices.

    Audit Requirements

    Any change to a widget


    name record shall be
    FR-A-001 1
    appended with user ID and
    date/time stamp.

    5.2 Non-Functional Requirements


    [Include technical and operational requirements that are not specific to a function. This typically
    includes requirements such as processing time, concurrent users, availability, etc.]

    ID Requirement

    NFR-001 The WINS repository shall accommodate up to 100 users concurrently.

    NFR-002 The WINS repository shall be designated at Level 2 for availability and SLA purposes.

    NFR-003

    NFR-004

    NFR-005

    1
    BRD

    You might also like