Chapter 4: Documentation Skills for Business Analyst
Documentation is one of the integral job functions of a business analyst and throughout the course of a project, prepares many documents. These documents are created to fulfill the various project needs and cater to audiences belonging to different spheres of a project.
The type of documents business analyst created depends on the various things like organization processes and policies, business needs, stakeholder requirements etc. Mainly below are the documents that are created by a business analyst. Each of these documents has a specific purpose and template and it is a part of the overall project documentation.
Business Requirement Document (BRD)
A Business Requirement 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 document and is referred throughout the development life-cycle for any project. A BRD mainly focuses on answering what is the business solution as opposed to how to achieve the business solution and thus it is mainly centered on the business requirements. A BRD is created with the help of the project team such as BA, client, subject matter exerts, business partners and is also used as a communication tool for other stakeholders and external service providers. Business Requirement Document (BRS) is explained in detail in Chapter 7.
User stories
A user story is a method used in agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
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 capture 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.
Some examples of user stories are:
User Story Example 1:
As an end user I should be able to login to online banking portal and perform fund transfer transaction.
Acceptance Criteria for the above user story:
- User is able to login to online banking portal.
- User is able to perform fund transfer transaction.
User Story Example 2:
As an end user I should be able to login to Customer Service Portal so that I can view my personal details (Name, Email, Phone, and Address) and update my personal details.
Acceptance Criteria for the above user story:
- User is able to login to Customer Service Portal.
- User is able to view the personal details (Name, Email, Phone, and Address).
- User is able to update the personal details (Name, Email, Phone, and Address).
Guidelines for writing User Stories
- Avoid ambiguity in requirement (Requirement should be clear).
- Avoid too many details.
- Avoid too broad level of details.
- User story document should be user focused, avoid writing technical and implementation details in user story.
Use cases
In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal. The actor can be a human or other external system.
A use case is created from the perspective of a user and achieves the following objectives.
- Records scenarios in which a user will interact with the system.
- Defines other aspects like negative flows, UI elements, exceptions, etc.
A Use case consists of the following:
- Use case ID - Specifies unique ID for use case.
- Use case name –Specifies name for the use case.
- Brief Description – A brief description describing the scope of the use case.
- Actors – A list of the types of users who can engage in the activities described in the use case.
- Preconditions – Anything that can be assumed to be true when the use case begins.
- Basic Flow – The set of actions the actors take to accomplish the goal of the use case and a clear description of what the system does in response to each user action.
- Alternate Flows – Capture the less common user or system interactions, such as change password and answering a security questions.
- Exception Flows – The things that can happen that prevent the user from achieving their goal, such as system error messages and login failure due to wrong user name and/or password.
- Post Conditions – Condition that must be true when the use case is complete.
Use Case Example: Money withdraw transaction from ATM.
| Use Case ID | U101 |
| Created By | Created_Person_Name |
| Created Date | dd-mmm-yyyy |
| Last Updated By | Last_Updated_Person_Name |
| Last Updated Date | dd-mmm-yyyy |
| Use Case Name | ATM(Automated Teller Machine) – Money Withdrawal Transaction |
| Brief Description | End user Withdraws Money from ATM |
| Actors | Customers, ATM Technicians, Bank |
| Pre-Conditions | Functioning ATM is available |
| Basic Flow | Customer withdraws money successfully |
| Alternate Flows | Customer cancels transaction, Customer makes wrong selection, Customer enters Invalid amount |
| Exceptions Flows | Insufficient Fund, System Error |
| Post-Conditions | Money withdrawal successful and amount debited from the customer account |
Download Sample Use Case Template
Use Case Diagram: Sample use case diagram for ATM transaction
Business Analyst may need to create the following documents also, based on the organization processes and project requirements. Hence it is required for business analyst to know how to create the below documents as well.
Following documents are generally created by the other teams such as system analysts, test analysts and project manager
Requirement Traceability matrix (RTM)
The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols.
A Requirement traceability matrix 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 which lists the complete user and system requirements for the system which are in-turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc.
It is a vital document to track project scope, requirements and changes in any project.
Download Sample Requirement Traceability Matrix Template
Test case
Test cases are generally created by test analysts. A Test Case is a set of actions executed to verify a particular feature or functionality of the software. A test case is a set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
Download Sample Test Case or Test Plan Template
Functional requirement specification (FRS)
Functional Requirement Specification (FRS) in systems engineering and software development is a document that specifies the functions that a system or component must perform. It is also called as Functional Specifications Document (FSD).
System requirement specification (SRS)
A software requirements specification (SRS) is a description of a software system to be developed. It includes functional and non-functional requirements, and may include a set of use cases that describe user interactions that the software must provide. It is a detailed document containing information about how the complete system has to function and enumerates hardware, software, functional and behavioral requirements of the system. It is also called as System Requirement Document (SRD).
Project vision Document
A Project vision document defines the high-level scope and purpose of a program, product, or project. Project vision document is generally created by the client/project manager, business analyst are also expected to contribute to this document. A Project vision document describes 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
The Requirements Management plan is used to document the necessary information required to effectively manage project requirements from definition, through traceability, to delivery. The Requirements Management Plan 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.
Posts
