Business Analyst ... what documents?

A Business Analyst (BA) integral job is to prepare and maintain many documents during the course of a project. These documents fulfill various needs and cater to participants involved with different areas of the project.

The type and specifications are dependent on an organization's processes & policies, needs & expectations of the business, and the stakeholder requirements.

A Business Analyst is usually responsible for the following documents:

• Project Vision Document (PVD): Although this document is created by the client/project manager, business analysts are also expected to contribute to this document. PVD entails the purpose and intent of the product/software to be developed and describes on a high level ‘what’ business objective will be achieved.
• Requirement Management Plan (RMP): This document is used to document the necessary information required to effectively manage project requirements from project initiation to delivery. RMP is created during the Planning Phase of the project. Its intended audience is the project manager, project team, project sponsor, and any senior leaders whose support is needed to carry out the plan.
• Use Cases: Each and every project is an endeavor to achieve ‘requirements’ and the document which defines these requirements is a use case. A use case is a methodology used in system analysis to identify, define, and organize system requirements. A use case is created from the perspective of a user and achieves the objectives of organizing the functional requirements, iteration in nature, records scenarios of user-interaction with the system, and defines other aspects like negative flows, user interface (UI) elements, elements, etc.
• User Stories: In an agile development environment, a user story is a document describing the functionality a business system should provide and are written from the perspective of an end-user/customer/client. The user stories are not very descriptive and only captures ‘who’, ‘what’ and ‘why’ of a requirement in limited detail. If any requirement is too big for a single user story it’s broken down into a number of user stories making it easier for estimation and discussion. In such cases, the main user story will act as an Epic (parent) user story.
• Business Requirement Document (BRD): This document is created to describe the business requirements of a product/process and the intended end result that is expected from the product/process. It is one of the most widely accepted project requirement documents and is referred to throughout the development life-cycle for any project. BRD mainly focusses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it’s mainly centered around the business requirements. A BRD is created with the help of the project team (BA, client, subject matter experts, business partners) and is also used as a communication tool for other stakeholders/external service providers.
• Requirement Traceability Matrix (RTM): This document is used to record and track the relationship of the project requirements to the design, documentation, development, testing, and release of the project/product. This is done by maintaining an excel sheet that lists the complete user and system requirements for the system (in form of use cases) which are in turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc. An RTM is maintained throughout the lifecycle of the various releases in a project and it’s a vital document to track project scope, requirements, and changes in any project.
• Functional Requirement Specification (FRS) / Functional Specification Document (FSD): describes the intended behavior of a system including data, operations, input, output, and the properties of the system. In a BRD the requirements are high level but in an FRS/FSD, they are written in more details to capture each and every aspect of a requirement. Thus a functional specification document becomes a more technical, accurate, and descriptive requirement document. Owing to their technical nature, FRS/FSD are equally used by developers, testers, and the business stakeholders of a project.
• System Requirement Specification (SRS) / System Requirement Document (SRD): A detailed document containing information about ‘how’ the complete system has to function and enumerates hardware, software, functional and behavioral requirements of the system. This document elaborates on the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.
• Test case: Business Analysts are not explicitly asked to create test cases but they must understand what they constitute and how to create one, as they sometimes have to test functionalities by referring to the test cases.
• A test case is a document, which has a set of test data, preconditions, variables, and expected results created to verify and validate whether a particular piece of functionality is behaving as intended (or as documented in the requirement documentation). Thus, a test case becomes a standardized document that should be referred every time a requirement has to undergo testing.

All these documents are constantly referred through the project’s life-cycle for communication, reference, and revision.

As always, if there is anything I get help you with, I am just a few clicks away .....

I love to get IT done!