Effective Analysis and Documentation

Business Requirements Document - Examples

In this chapter, we present several business needs and examples of how they might be described in a Business Requirements Document.

Example #1

Business need: There is a new regulatory requirement, AA24, which we must comply with.

Current state: Since this is a brand-new requirement, it must be implemented from scratch. The only element partly implemented is customer due diligence—for the purpose of another regulatory requirement, gathering permanent residency data from all new customers during onboarding is currently in development.

Business goals and objectives: AA24 must be implemented to its full extent by the end of November 2018.

Success criteria

  • The bank will comply with the regulatory requirement to the required extent and within the required deadlines.

Constraints and Restrictions

  • Due to the November 2018 deadline, everything needs to be ready by the end of August because the final production release for the systems is in August. The next release is in December, which is too late.

Assumptions

  • If everything goes according to plan, the customer due diligence process will be implemented in Q3 2018, leaving enough time to merge this process with the AA24 implementation.
  • The final version of the regulatory requirement will not differ significantly from the current version, which forms the baseline for the AA24 implementation.
  • The customer due diligence process is being implemented within a project called CDD2018. This creates an assumption that the project will deliver the process on time, along with the related risk of non-delivery.

Business Risks

  • The CDD2018 project may not implement the customer due diligence process on time or to the quality required by AA24.
    • Impact: High impact. Without this process in place, the organization will not comply with AA24, which could lead to sanctions from the regulator.
    • Risk avoidance: The status of CDD2018 must be checked regularly by the AA24 implementation team to ensure the process matches AA24 requirements. Regular status meetings must be organized to confirm that everything stays on track and deadlines remain feasible.
  • The final version of the regulatory requirement might differ significantly from the current one. To implement the requirement on time, implementation must start before the final version is released. This introduces a risk of additional rework if significant changes occur late in the process.
    • Impact: Depends on the significance of the change and when it occurs.
    • Risk avoidance: The only viable approach is to attend regular meetings organized by the regulator and update plans accordingly.

Solution outline (not part of the BRD)

  • Modify the customer onboarding process
    • Add customer due diligence checks
    • Reject customers with negative check results
  • Regularly check customers for potential conflicts between their tax residency and permanent residency
  • Report customers with conflicts to the regulator

Example #2

Business need: Template management is complicated and error-prone because there is no single repository for document templates—they are spread across multiple locations and systems.

Current state: Two systems are responsible for generating documents and storing document templates. Old templates are stored in DocGen and can only be generated manually. New templates are managed by DocGenNET, and these can be generated by calling a service from other systems. There are also static documents that are not generated dynamically; they are simply stored in a shared folder from which anyone can print them.

Business goals and objectives

  • To establish a single repository where all types of templates are stored
  • To automate current manual template review and approval processes
  • To track the complete history of template changes

Success criteria: A solution meeting the described goals will be considered successful. No specific budget or deadline requirements are currently set.

Constraints and Restrictions

  • None

Risks

  • None

Solution outline (not part of the BRD)

  • Develop a new template management system or buy an off-the-shelf solution
  • Basic features:
    • Template management, including version tracking
    • Review process
    • Approval process
    • Document generation from templates, both manually and via a service for other systems

Example #3

Business Need: The core information system is becoming outdated, expensive to maintain, and sometimes impossible to extend.

Current state: The legacy information system is old, making every change unacceptably expensive, slow to implement, and prone to errors. Furthermore, some changes cannot be implemented at all due to the outdated architecture.

Business goals and objectives

  • To cut information system maintenance expenses by 15%
  • To cut average annual expenses on IS changes by 20%
  • To enable the implementation of changes previously evaluated as impossible or too expensive due to the outdated system

Success criteria: A solution meeting the described goals will be considered successful.

Constraints and Restrictions

  • There is an ongoing debate among board members regarding the IT strategy for the next several years. This includes whether to prefer custom-developed solutions or ready-made software. Results from this debate should be available by the end of Q3 2018. Requests for proposals (RFPs) should be sent to vendors only after these outcomes are known.
  • Due to company policy, the new system cannot be provided by a non-US company.
  • While there is no strict budget restriction for the solution and the final price will depend on vendor proposals, any price exceeding $1,000,000 will be subject to a formal approval process.

Assumptions

  • It is assumed that only the core system will be replaced.
    • No other system replacements are being considered.
    • Other systems will remain in place, meaning the new system must be ready to integrate with them.

Risks

  • Implementing a new core information system presents a high risk; if not done properly, it could disrupt the entire company.
    • A certified project manager will be required on our side to manage the entire initiative.
    • At least 20% of senior managers' time will be allocated to this project to ensure current processes are documented accurately and there is enough time to think through how processes can be optimized using modern technologies.

Possible solutions (not part of the BRD)

  • Upgrade the current information system to a newer version provided by the same vendor
  • Implement a new information system from scratch
  • Keep the current information system (requires a detailed financial analysis)

Example #4

Business Need: Processing requests for the disbursement of funds is complicated and takes too long, leading to customer complaints.

Current State: The process and system were designed when all disbursement requests originated at a physical branch. Since then, the option to initiate requests via online and mobile banking has been introduced; however, the backend process is not optimized for digital channels.

Business Process: [diagram]

Workflow in the Application: [diagram]

Identified Inefficiencies: ...

Business Goals and Objectives

  • To cut the average time needed to process a single disbursement request by 20%
  • To make the process more straightforward, allowing junior officers to process requests as well
  • To cut the number of customer complaints regarding fund disbursements by 10%

Constraints and Restrictions

  • There is a separate process that triggers automatically once the disbursement process ends. This process is currently being reviewed. Because it relates directly to disbursements, its review must finish before final decisions are made regarding the disbursement process.
  • Every new process in the company must be implemented within the process framework called FLEXi. If it is decided that the process should be rebuilt from scratch, FLEXi must be used.

Business Risks

  • Fund disbursement is a critical process because it involves releasing money from the bank. To minimize the chance of critical mistakes, the new process must be thoroughly reviewed with all managers and team leaders and tested more rigorously than other processes.

Example #5

Business Need: Customers complain that our competitors offer parcel tracking, which we lack. This has become a standard service, and we are falling behind our rivals.

Current State: Currently, customers are only notified once a parcel is picked up by the driver. An SMS notification is usually sent to let the customer know the expected delivery time window.

Business Goals and Objectives

  • To catch up with competitors, customers must be notified of the current status of their delivery immediately after it changes.

Success Criteria

  • The company must provide the same level of parcel tracking as our main competitors.
  • The number of customer care inquiries regarding delivery status must decrease by 50% during the first 6 months post-deployment.

Assumptions

  • It is assumed that it is technically feasible to track deliveries (meaning data is stored and accessible) and expose this information to customers in some format.

Business Risks

  • None

Example #6

Need: When a user chooses to delete a document, the system should ask for confirmation. For example: "Are you sure you want to delete this document?". Users frequently delete important documents by accident.

Current State: At the moment, the system deletes documents instantly without asking.

In this case, the presented need is not a business need; it is a user requirement. Because it is a requirement from a specific user group rather than something critical to the entire organization, a formal BRD is not required. However, it remains a need that shares attributes with business needs, so its description usually includes the same components: current state, assumptions, constraints, risks, and possible solutions. A BRD-like document can be created for operational requests, but it should not be titled a BRD or claim to describe high-level business needs.

Example #7

Need: According to a new regulatory requirement, the DocGen system must be modified so that the Purchase Contract document (ID: DOC-577) includes a new paragraph stating that the client signed the contract at the branch voluntarily and not under pressure.

This example is also not a business need, as stakeholders have stated a solution rather than an underlying need. They are essentially saying: “Just change the template in the DocGen system and you’re done. Easy.” If the analyst accepts this at face value and “just changes it,” they have failed in their role. What if, besides signing a printed paper contract at a branch, customers can also request the product online, generate the contract as a PDF, and sign it via SMS? What if this PDF version is generated in a different system using a different template format and must be modified too? Will the proposed solution deliver full value? Clearly not. The bank would end up with customers signing contracts that lack the mandatory legal statement.

Instead, a skilled analyst would look at the problem from a higher perspective and rephrase it: "A new regulatory requirement mandates that we include a statement in every purchase contract ensuring the client declares the contract was signed voluntarily and not under pressure." This statement automatically triggers an analysis of all potential impacts, resulting in a solution that covers every system and artifact that needs to change.