Friday, July 7, 2017

BRD- Business Requirements Document

Many businesses have a process in place to assist with project management and implementation. One opportunity for improvement involves making reasonable estimates of how big a project is and how much it is going to cost. There are many different names for tools used with this process: business needs specification, requirements specification or, simply, business requirements. Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.
A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations. If an initiative intends to modify existing (or introduce new) hardware/software, a new BRD should be created. The BRD process can be incorporated within a Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) culture.
The most common objectives of the BRD are:
  • To gain agreement with stakeholders
  • To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
  • To provide input into the next phase for this project
  • To describe what not how the customer/business needs will be met by the solution
The BRD is important because it is the foundation for all subsequent project deliverables, describing what inputs and outputs are associated with each process function. The process function delivers CTQs (critical to quality). CTQs deliver the voice of customer (VOC). The BRD describes what the system would look like from a business perspective.
The BRD distinguishes between the business solution and the technical solution. When examining the business solution the BRD should answer the question, “What does the business want to do?” For example, the business wants to serve 100 bottles of red wine each night during a three-day conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution should support the business solution. For example, the company would need a wine grotto or refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees Fahrenheit.

Who Should Be Involved in the Creation of the BRD?

A number of teams and partners should create the BRD:
  • Project core team
  • Business partner(s)
  • Process owner(s) or representatives
  • Subject matter experts
  • Change/project/product management, quality department and/or IT management as needed or available

Prerequisites for BRD

Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC project. The BRD provides the opportunity to review the project charter to ensure that the objective, goals, scope, project team, and approvers are accurately reflected.
Prerequisite two is a current environment assessment created during the measure phase. This includes a detailed process map of the current environment highlighting areas that will be changed during the project. Detailed “as is” process maps should include:
  • Clearly defined start and end points of the process
  • Level two and three process functions
  • Defined areas of rework and non-value added steps
  • Cycle time, capacity and rework information for each process step as available
  • Baseline for each CTQ for the current environment
Prerequisite three is CTQs, identified in either the define or measure phases, and validated with baseline measurements, targets and specifications.
  • Current measures: Data that defines and describes current performance – sigma level of the CTQ includes a definition of how the product/service’s characteristic is to be quantified.
  • Target/nominal value: What is the aim of the product/service? If there was never any variation in the product/service, this would be the constant value.
  • Specification limits: How much variation is the customer willing to tolerate in the delivery of the product or service? Define upper and lower specification limits as required by the customer needs.
  • Allowable defect rate: How often are the producers willing to produce a product/service outside the specification limits?
Prerequisite four is the target environment assessment, created in the measure phase, and includes a detailed process map of the target environment including level two functions. When distinguishing between level two or three functions, group the process functions into the following categories:
  • People: People are processing information and making decisions [core team designs high-level design/low-level design (HLD/LLD)]
  • Systems: Systems is processing information and making decisions
  • Systems/people: System is processing information and people are making the decisions
    • Distinguish between employee and customer
    • Distinguish leadership requirement for associate in case decision making authority has to be moved up
  • Fishbone: For each process function for impact assessment

Overall Project Details and Best Practices

The BRD appendix can be used to list a number of project details – constraints, assumptions and dependencies, business rules, scope, measurements reporting and other topics critical to the project. Consider the following issues when looking at the overall project:
  • Are there any regulatory or geographic constraints (i.e., state law) to consider? If so, these constraints need to be clearly documented in the process detail table of the BRD or in the overall project details section of the appendix.
  • What assumptions or dependencies apply?
  • What business rules apply?
  • Are there any measurements or reporting requirements that apply to the project?

Best Practices

  1. Validate scope: review and refine the scope as needed based on a process detail table, identifying any changes to what is in or out of scope now that the requirements have been developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the scope of the project. Any changes to the project after this phase will be handled through a change control process.
  2. Create systems impacted document: Create a design-elements diagram for each level two or three process function for impact assessment for:
    • People
    • Process
    • Technology
    • Materials and supplies
    • Facilities
    • Product
    • Machinery and equipment
    • Others as necessary (depending on the organization)
  3. Definitions and acronyms: Define any terms not clearly understood by all.

Packaging the BRD

Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of sections follows:
  • Project overview including project charter information, scope, and objectives
  • Current environment assessment and systems overview (see additional details below)
  • Future process map
  • Process detail table
  • Overall project business rules and constraints
  • Impact assessment (fishbone for process functions)
  • Functional requirements (additional details below)
  • Data to be held (additional detail available below)
  • Schedule and budget
  • Terms and definitions
  • Approver information
  • Team information

Business Partner Sign-off

Business partners should be active participants in the development of the BRD, but a final review and sign-off is also essential.

Additional Details

There are a number of items included in the BRD that require detailed documentation to ensure successful implementation. Following is a high-level overview of the types of detail to consider:
Sample questions for the current environment assessment and systems overview:
  • Who is the intended user?
  • How many users are there? Are they the same type of user or different?
  • What level of computer experience will the users have (or is needed)?
  • What is the required security?
  • Are there hardware constraints – networked or stand-alone?
  • What are the approximate numbers of records required initially plus the anticipated growth?
  • What technical support is necessary and available in-house?
  • What other systems need to integrate/communicate?
  • Backup. Describe the current back-up regime (e.g., tape back-up one/day). How will the new system fit with this? If this is not currently defined then think how much data could be inadvertently lost. For example would it be a major disaster if the last 30 minutes of work was lost, or could yesterday’s/last week’s data be retained?
  • Deliverables. What are the expectations – system, help files, documentation, full source code, training, support, etc.? Detail what is essential versus nice. Do not automatically ask for everything unless necessary. If the project manager is to maintain the system make sure he states that he requires the full source code – alternatively if the developer is to maintain the system consider settling for an escrow agreement (where the source is held by an independent third party). Be specific about tools necessary to help. If the developer is unwilling to provide the support necessary find someone else who will.
The functional requirements section should describe “what” the system is to accomplish rather than the “how.” Develop a prioritized list similar to the following:
  • A detailed description of the requirement including goals (e.g., produce a report of spend/department/year on demand with the user selecting the department and the financial year required), it is necessary to know how the company defines the financial year.
  • How important is this requirement (essential, preferred, nice to have, not essential, etc.)?
  • Any known design/implementation issues relating to this requirement?
  • Does this requirement interact with other requirements?

Data to be Held: Sample Advice

Describe expected data tables. Examples include customer records, contact details, machine records, etc. Provide as much detail as possible – a customer record might consist of a name, address, telephone number, fax, mobile number, region, business type, number of employees etc. Indicate any unique fields (such as a job number) and show how different tables relate to each other (very important). For example projects are related to customers through a customer number. Each customer can have none, one or many associated projects. Each project relates to one or more jobs. A job can exist independently of a project but will still be associated with a customer. A project will always have only one customer.
It is not usually necessary to define the tables in database terms (e.g., customer number is a long integer) but examples of the data to be held in the fields is useful (e.g., a typical job number might be FH/1234 where FH indicates the department undertaking the job and 1234 is a unique number. In practice a good database designer would then recognize that the “real” job number is actually the 1234 part and the FH is just an associated field). If the maximum size of any field is known – for example, a “Company Name” field is 100 characters – then include this. If there are any table definitions from existing systems then provide these indicating any required changes.


As with any tool, the BRD can have both benefits and failure modes. Benefits derived from a good BRD include reduced changes during the improve and control phases of DMAIC and reduced time to deployment. Failure modes from a poor BRD means the system developed will not meet business requirements. Creating a successful BRD requires planning and coordination. There are a few best practices that should be followed in this process. The team should hold a dedicated off-site session to complete the BRD with all required resources 100 percent available. Scheduling is the key to success here. As each tool/deliverable is completed within the methodology build the BRD. Allow a one-week deadline to finish action items from the off-site session and hold a final review session two to three hours after completion of action items.

Thursday, August 25, 2016

Common Business Analyst Deliverables

Common Business Analyst Deliverables

 Project Stage
 Document Name
 Brief Description
 Project initiation
 Vision document
Business case
Feasibility study
 The purpose is to:
·       Set out and gain consensus of the direction of the project and scope from the senior stakeholders.
·       Justifies the benefits and estimated costs.
·       It will provide enough evidence that the money is worth being spent, allow funding to be agreed or will show that it isn’t worth doing which then prevents further money being wasted.
·       It makes sure that the overall solution is agreed and that it will meet the business needs.
Business process mapping document
 It contains “as is” and “to be” business process diagrams.  The purpose of it is to:
·       Understand the business processes.
·       Help identify the problems and opportunities for change.
·       Understand the scope of the requirements as each requirement should relate to a process.  This is why it should always be done before the business requirements document.
·       Business stakeholders are more likely to be know their business processes better than their requirements.   Therefore this is a better starting point and further justification for doing this first.
 Business requirements document
 It contains a catalogue for all of the business requirements, a priority for each and a justification.
The purpose of it is to:
·       Gain a consensus and understanding of all of the business requirements in scope for the project
·       Understand which of the requirements are mandatory to the extent that if they weren’t delivered the project would not be worth doing.
·       Pre-requisite for being able to start system requirements to ensure trace-ability.
 Use case model
Context diagram
 It contains a use case model which is a UML (Unified modelling language) tool or a context diagram.
The purpose of it is to:
·       Identify system boundaries (which systems are in scope).
·       Identify the use cases (goals) for each of the systems in scope.  This is a summary of all of the things the system has to do.
·       Identify the human and system interfaces for each of the goals.
·       Allow estimation and planning depending upon the number of use cases and the complexity and size.
·       Pre-requisite for the system requirements.
 System requirements document
Functional requirements document
Use cases
User stories
User story boards
 It contains all of the requirements that need to be met by the project systems in scope.
The purpose of it is to:
·       Ensure the system requirements will meet each of the relevant business requirements and is understood and acceptable to the business stakeholders.
·       Ensure the system requirements are understood and acceptable to the IT stakeholders.
·       Allows developers to code the systems in scope according to the system requirements.
Non-functional requirements document
 It is really important that non-functional requirements are gathered early on and aren’t missed out.
The purpose of it is to:
·       Set out non-functional requirements.  A non-functional requirement is a quality, constraint or behaviour that the system being built must meet.
·       To ensure the system being developed is adequate as involves a wider variety of IT stakeholders than the developers and a wider set of questions to the business stakeholders.  For example will the system have adequate enough capacity for the volumes of data anticipated.
 Data mapping document
 This document focuses on data requirements.
The purpose of it is to:
·       Identify all of the types of data required and agree a consensus of the names to be used and definitions.
·       Identify all of the relationships between each type of data and the data down to field/attribute level.
·       Provide a logical data model which can be used to work out a physical data model.
·       Ensure all of the data required can be met.
 RFP stands for Request for proposal. It is written when goods or services are required from an outside supplier where no products or expertise are currently available to meet the needs of the project within the company.
The purpose of it is to:
·       specify the needs and allows other companies to bid for the work.
 Evaluation scoring matrix
 This is written in conjunction with the RFP.  The purpose of it is to:
·       Agree the success criteria to ensure the best vendor is selected.
·       Allow all scorers to follow the same success criteria.
·       Provide objectivity to the process
 Options paper
 If problems are encountered the business analyst can write an options paper.  The paper should be short and:
·       Specify the problems encountered and the reasons.
·       What the potential options are to resolve the problem.
·       Make a recommendation with reasons
The purpose of it is to:
·       Allow problems and resolutions to be understood and agreed so the project can proceed.
 Design / testing / implementation
 Gap analysis document
 This may be carried out at several stages to ensure that what is being produced traces back to:
·       The requirements.
·       The scope.
·       The benefits expected.
 Testing / implementation
 Test strategy / test scripts
 Normally tester deliverables, however there may be occasions where the business analyst may contribute to writing the, be a reviewer, carry out testing or help co-ordinate with other testers and business users.
The purpose of it is to:
·       Ensure all of the different business scenarios will be met by the system being changed.
 Testing / implementation
 Training materials / new business processes
 Normally a trainer deliverable.  However there may be occasions where the business analyst may document new business processes and ensure training manuals are kept up to date.
 Testing / implementation
 Handover documentation
 If the business analyst encounters several problems during the delivery process they may be best placed to put a handover document together for various parties to ensure resolutions have been formally captured.  This is particularly important if any new manual workarounds get introduced as a result.

Tuesday, May 3, 2016

Ideas to improve documentation in AGILE

AGILE isn’t about documentation” I am sure many of us must have heard it. Believe me, it’s not the truth. There are many documents required to be created as a part of project management in AGILE. Product owners and scrum masters are the ones who primarily work on the documentation related tasks. But it is a collective responsibility of the team and you shouldn’t be surprised to see many documents being worked upon by the scrum team. When the main target (in AGILE) is to deliver the product in the shortest possible time, it becomes essential to know some ideas and tips that help practitioners spend less time on documentation without impacting its quality. Here are some cool tips –
  • Keep it short and simple (KISS): While in AGILE documentation, the idea is not to decrease the number of documents (or reduce the importance of documentation), the idea is to have crisp and short documents which will speak only about the key items that are essential for the document and not linger around providing unnecessary details.
  • Frequency of document updates: Number of updates happening in AGILE are much more than that in traditional processes. This is because updates keep happening almost in every iteration; however that in traditional mainly happens only in the beginning of the cycle. If you don’t see updates happening on the documents (or anyone document) then try to understand the reason behind it?
  • Pair review: Quality has to be maintained not just at the product level but also at the documentation level. It is hence important to review and improve documents. Pair review is a concept followed for the same purpose. These are informal reviews usually done within the team by other team member and suggestions are implemented in the document.
  • Automate exhaustively: Try to develop tools, (on excel / other office tools) that can automate the tasks for documents and save time. This saved time can be used in other project management / product development activities.
  • Non-functional requirements: Agile teams have a practice of treating the non-functional requirements as story points. Creating separate stories make those tasks appear as separate entities. However it is not the right practice to adopt. Making performance and other non-functional requirements core to the functionalities is the right strategy and that’s what managers should practice to save time in the cycle.
  • Avoid overlap: AGILE is about focusing most on the product that is being developed. Hence minimizing the number of documents, their contents and yet covering all essential aspects in the documents should be targeted. It hence becomes necessary to plan documentation in advance, have clear and crisp templates and avoiding overlap across multiple documents.
  • Simplify content display: A lot of times teams end up creating multiple documents because it becomes difficult for them to find the right content at the right time. Having easier ways to display documents and their contents is the key. Using technology and thus document management systems comes handy in such scenarios.
Thus these tips will help practitioners save a lot of time on the documentation and process related items and focus more on the final output i.e., product delivery and frequent updates (thus improvements). Business will see more features and functionalities in the product and will find more returns to their investments. End users would be happy to see better quality product with good performance and usability (points that are usually neglected due to lack of time in product development). Thus, these tips may not seem to show direct impact but will indirectly help business get more returns on their investments and help in improving the quality of the software.