Business Requirements Document Essay

Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s). The BRD should remain solution independent. In the context of the project scoping for hardware procurement and installation, this is about identifying and documenting the business requirements of customers, employees, and vendors early in the development cycle to guide the design of the future state. Business requirements are captured by analyzing the current business activities and processes of the as-is state (current process) and defining a target state (to-be process) that will deliver the planned business outcomes that contribute to the organizational objectives. Objectives of the BRD: Stakeholders to gain agreement with stakeholders about what will and will not be delivered Vendors to provide a foundation to communicate to a vendor (or in-house provider) what the solution needs to do to satisfy the customer’s and business’ needs Sponsors to provide input into the business case development phase of the project Customers to describe ‘what’ (not ‘how’) the customer/business needs will be met by the proposed solution Business Requirements Document (BRD) describes the high level requirements that senior management would understand, for example, SS relationship: The BRD is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The BRD describes what the system would look like from a business perspective, distinguishing between the business solution and the technical solution. Business requirements often include: business context, scope, and background, including reasons for change key business stakeholders that have specific requirements success factors for a future/target state constraints imposed by the business processes or other systems business process models and analysis defining either ‘as-is’ and ‘to-be’ business processes glossaries of business terms, local terminology or acronyms Data flow diagrams to illustrate how data flows through the information systems (different from flowcharts depicting algorithmic flow of business activities). A broad cross section of the business should be involved in the development of the BRD. Categories of Business Requirements There are five levels of requirements that are typically captured at different stages of the BRD development. These are: Level 0 business requirements High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to be realized or problems that they want to be solved. Level 1 User (Stakeholder) requirements Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe levels of interaction with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements. Level 2 Functional (solution) requirements Usually detailed statements of the behavior and information that the solution will need. Level 3 Quality-of-service (non-functional) requirements Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include reliability, testability, maintainability, availability requirements. They are also known as characteristics, constraints or the non-functional requirements, and Level 4 Implementation (transition) requirements Usually detailed statements of capabilities or behavior required to enable transition from the current state to the desired future state. Examples include recruitment, role changes, and migration of data from one system to  another. The success of a BRD is dependent on the agreement of the business to the need for change and the expected business outcome(s). The BRD provides the opportunity to review the project charter to ensure that the objective, goals/outcomes, scope, project team, and approvers are accurately reflected. Prerequisites for BRD Important pre-requisites for a successful BRD are set out below: A current environment assessment. This includes a detailed process map of the current environment highlighting areas that will be affected by the project. The detailed â€Å"as is† process maps should include: clearly defined start and end points of the process; level 1 and level 2 requirements and stakeholder process functions; defined areas of rework and redundant business processes to be removed; cycle time, capacity and rework information for each process step as available, and Baseline for critical metrics for the current environment. Critical quality or performance metrics validated with baseline measurements, targets and specifications. These include: data defining and describing current performance such as how the product/service’s characteristics are to be quantified; specifying the target for the product/service performance and the acceptable tolerances, and The allowable tolerance for service levels, for example how often the product/service is allowed outside the specification limits. The target environment assessment, including critical quality or performance metrics validated with baseline measurements, targets and specifications. These include: data defining and describing the expected performance such as how the product/service’s characteristics are to be quantified; specifying the target for the product/service performance and the acceptable tolerances, and The allowable tolerance for service levels, for example how often the product/service is allowed outside the specification limits. A detailed process map of the target environment. The following figure 4 illustrates a useful way of framing a process flow. Example of a process flow Other BRD considerations The BRD contains a number of project details – such as constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project. The following should be considered in the context of the overall project and, where appropriate, clearly documented. Any external constraints (e.g. regulatory, legal or locational constraints). Constraints and assumptions relating to the complexity of business requirements, interdependence with other systems, timing of events, the scalability of technical options, reporting requirements and any service limits that may apply. Constraints and assumptions relating to the user numbers (staff and customers), users’ existing capability and training required, degree of user support required IT skills availability and location. An example of the difference between a constraint and an assumption is: an assumption could be the number of users that an online service will have: 10,000 logged-on users per day and no more than 5,000 at any given time, and A constraint relating to the number of users may be that the system has a maximum capacity of 20,000 logged-on users at a given time. Reference CONCEPTUALISE ICT projects technical guidance Business case development; The Secretary Department of Treasury and Finance 1 Treasury Place Melbourne Victoria 3002. Copyright  © State of Victoria 2012.