Business Analyst

Documents
 Business Analyst Documents

Documentation is one of the integral job functions of business analysts and they,
throughout the course of a project, prepare many documents. These documents
are created to fulfill the varied project needs and cater to audiences belonging to
different spheres of a project.
• Business Requirement Document (BRD)
• Requirement traceability matrix (RTM)
• Functional requirement specification (FRS)/ Functional Specification Document
(FSD)
• System requirement specification (SRS)/ System Requirement Document (SRD)
 Business Analyst Documents

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 documents and is referred to 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’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.
 Business Analyst Documents

The Business Requirement Document contains:

– Project Background
– Business goals and objectives
– Stakeholders
– Requirement scope
– Functional requirements
– Data requirements
– Non-functional requirements
– Interface requirements
– Business glossary/Definitions
– Dependencies of existing systems
– Assumptions
 Business Analyst Documents

Functional Requirement Specification or Functional Specification Document

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
many 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.
 Business Analyst Documents

• The Functional requirement specification (FRS)/Functional Specification Document (FSD) contains:

– Product Context
– Assumptions
– Constraints
– Dependencies
– Functional Requirements
– User Interface Requirements
– Usability
– Performance
– Manageability/Maintainability
– System Interface/Integration
– Security
– Requirements Confirmation/sign-off
 Business Analyst Documents

System Requirements Specification (SRS) or a Software Requirements Specification is a document or set of

documents that describe the features of a system or software application. It includes a variety of elements
which define the intended functionality required by the stakeholders and customer to satisfy the end users.
• In addition to that, an SRS provides a high-level idea of the system and its behavior, the main supported
business processes, the assumptions and the key performance parameters for the system. The key elements
of an SRS are:
• Scope of Work
• Functional Requirements
• Non-Functional Requirements
• Dependencies
• Data Model
• Assumptions
• Constraints
• Acceptance Criteria
 Business Analyst Documents

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.
• SRS/BRD elaborates on the requirements from the perspective of observational
behavior only and doesn’t consider technical or design bias.
 Business Analyst Documents
The System requirement specification (SRS)/ System Requirement Document (SRD) contains:
– Product Perspective
– Product Functions
– User Characteristics
– General Constraints
– Assumptions and Dependencies
– External Interface Requirements
– Functional Requirements
– Classes / Objects
– Non-Functional Requirements
– Inverse Requirements
– Design Constraints
– Sequence Diagrams
– Data Flow Diagrams (DFD)
– State-Transition Diagrams (STD)
– Change Management Process
 Business Analyst Documents

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 that
lists the complete user and system requirements for the system (in the 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.
 Business Analyst Documents
• Test Case Document

Business analysts are not 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 to every time a requirement has to undergo testing.
 Business Analyst Documents
The components of a test case are:
– Test Case ID
– Test Scenario
– Prerequisite
– Test Data
– Test Steps
– Expected Results
– Actual Result
– Status
– Remarks
– Test Environment
 Business Analyst Documents
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.
• Some examples of user stories are:
– The system shall be able to sort the values in ascending and descending order
– The application must allow the user to enter his name, date of birth, and address.
– The system shall verify the user’s login credentials and redirect him to the
dashboard in case of a successful login.
 Business Analyst Documents
• Use cases
Each project is an endeavor to achieve ‘requirements,’ and the document that
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 following
objectives:
1. Organizes the functional requirements,
2. Iterative in nature and updated throughout the project life-cycle
3. Records scenarios in which a user will interact with the system
4. Defines other aspects like negative flows, UI elements, exceptions, etc..
 Use-Case
A UML use-case describes a sequence of actions, performed by a
system that provides value to an actor.
The use-case describes the system’s behavior under various conditions
as it responds to a request from one of the stakeholders, called the
primary actor.
A use-case specifies the flow of events in the system.
 Business Analyst Documents

The Use Case document contains:

– Actors
– Description
– Trigger
– Preconditions
– Normal Flow
– Alternative Flows
– Exceptions
– Special Requirements
– Assumptions
– Notes and Issues
 Business Analyst Documents

• Project Vision Document

Although mainly the client/project manager creates a project vision document, business
analysts are also expected to contribute to this document. A Project vision document
entails the purpose and intent of the product/software to be developed and describes
‘what’ business objective will be achieved on a high level.
• The Project vision document contains:
– Introduction
– Description of users in the system
– Project stakeholders
– Product Overview
– Product Features
– Product requirements
– Constraints/Limitations
– Quality/documentation requirements
 Business Analyst Documents
• Business Requirement Document (BRD)
• Functional Requirements Document (FRD)
• Software Requirements Specification (SRS)

• All these documents talk about the requirements but the difference is they
are based on;
• Who creates them?
• What level of information is available in these documents?
• In what stage these documents are being created?
• Who uses these documents?
• What’s the purpose of the document?
 Business Requirement
Document
• BRD is created during the initial phase of the project.

• It contains the high-level business requirements that could be easy to

follow by business stakeholders, managers, board of directors, etc.

• It is a functional business requirement that is written in a well-

structured manner without any technical jargon.

• It is one of the output from the requirement elicitation process

 Functional Requirements
Document
• FRD is a formal statement of an application’s functional requirements.
• Detailed requirements in technical terms and technical diagrams
(UML, Data Flow) that will be referred by the technical team for
further development of the system.
• FSD is the basis for the development and Testing team to plan their
development strategies and build the test scenarios.
• It contains;
o Descriptions of data to be entered into the system
o Descriptions of operations performed by each screen
o Descriptions of work-flows performed by the system
o Descriptions of system reports or other outputs
o Who can enter the data into the system?
 Software Requirements
Specification
• SRS is a complete description of the behavior of a system to be
developed.
• It describes all the user interaction with the system with the help of
use cases.
• SRS contains all the functional and non-functional requirements along
with the use cases that the software must meet.
• It includes complete business requirements, system properties,
constraints, and behaviors e.g. system’s reliability, response time,
storage requirement, etc.
• Might not find this document in small projects as BRD and FSD are
enough to develop a system.
 Difference Between BRD, FRD,
SRS
•