it:ad:documentation:brd:home

IT:AD:Documentation:BRD

Summary

The BRD is used to list the Business requirements which are the what must be delivered to provide value to the Business.

It does not yet specify how it is to be provided.

. Consequently, the topic of business requirements often arises in the context of developing or procuring software or other system; but business requirements exist much more broadly. That is, 'business' can be at work or personal, for profit or non-profit.

BRD's usually lead to FRD, and NFRD.

The BRD contains the business requirements that are to be met and fulfilled by the system under development. These requirements specify "what" the system must do in order to fulfill the requirements of the business. They often take the form of "The system shall..." Each requirement, or group of similar requirements, is typically accompanied by a business rationale. The business rationale explains "why" the business requirement is necessary. This is often important later if analysts or developers have questions regarding the purpose or validity of the requirement. The rationale can be used to support the need for the business requirement or clarify ambiguous language by providing a context for the requirement. In addition to a rationale, constraints can be provided for each requirement along with other supporting reference material.

* confidentiality

  • Document Information
    • Document Purpose
    • Scope
    • Audience
      • eg: Project sponsor
      • eg: Stakeholders
      • eg: PM
      • eg: Architects
      • eg: Developers
      • eg: Testers
      • eg: Trainers
    • Related Documents / References
    • Glossary / Frequently Used Terms
    • Reviewers
    • Document Sign Off
      • Change History
      • Requirements Change History (redundent)

      * Overview (this canme from VisaView Requirements)

    • Summary
    • Project Objective
  • Contents
  • Background
    • Problem Statement
      • eg: Business had identified app as unstable.
      • eg: Business have identified app as costly to maintain.
    • Business Objectives
      • eg: Better usability: remediation / bugs
      • eg: Decommision old stuff
      • eg: Lower support cost: Upgrade to current Technologies
      • eg: Lower risk: vendor supported versions
      • Policies /Legislation / Regulations
      • CONSULTATION / StakeHolders
      • eg: Used by Dept #1, #2, etc.

      * Current State

    • Tools / Processes / Systems Used
      • eg: Titles of Workflows / Processes
      • eg: Titles of Tools / WebSite names
  • Future State
    • Fit to Business Unit Strategy
      • eg: Strategy Goals achieved
        • eg: Decrease cost
        • eg: Increase Revenue
        • eg: Lower Risk
        • Scope
        • inScope:
        • eg: Upgrades
        • eg: Remediation
        • eg: Migration
        • eg: Decommision
        • Out of Scope:
        • Potential Future Scope:
        • Boundaries
        • Constraits
                  * ...
                  * eg: will comply with E Gov...Interoperability Framework
                  * eg: will be consistent with New Zealand Government Web Guidelines
                  * eg: consistent with Open Web Application Security Project (OWASP)
              * Dependencies
                  * ...
          * Sucess FACTORS
              * eg: Meeting business objectives (see above)
              * eg: Meeting user capability expectations (remediation, etc)

          * Business Requirements

        • eg: classified by Mandatory, Desired, Optional
        • eg: tied back to a Busines Requestor
        • Tough to do…
        • eg: classfied by Type
        • BP: Business Process
          • A BP is a collection of related, structured activities or tasks that produce a specific outcome with business impact.
        • F: Functional
          • Define a function of a software system or its components
          • Described as a set of inputs, behavior, outputs
        • C: Compliance
          • THe act of adhering to a standard or regulation.
          • eg: Security standards,
          • eg: Usability standards, etc.
        • L: Legal
          • eg: adherence to legislation
        • LF: Look and Feel
          • look: (color, shape, layout)
          • feel: behavioral (menus, buttons, etc.)
        • High Level Business Requirements
        • HLR-xx … (Priority = Mandatory, Desired, Optional)
        • Detailed Business Requirements
        • BRQ-xx …

        * Non Functional Requirements

    • User Experience
    • Reliability
    • Performance
    • Supportabilty
    • Compliance
    • Security
    • Scalability
    • Installation
  • Impacts, Risks and Issues
    • Impacts
      • Operations
        • eg: New Documentation Required
        • eg: New Logins
      • Environment
      • Databases
      • Impacted Parties
      • Risks
      • eg: events that may throw things off.
      • Issues

      Appendix

    • A: Options
      • eg: Possible Technology Solutions (PTS-xx)
  • /home/skysigal/public_html/data/pages/it/ad/documentation/brd/home.txt
  • Last modified: 2023/11/04 03:40
  • by 127.0.0.1