Author: Arpan Rewatkar

Best of BATimes: BRD Vs FRD

Written by Arpan Rewatkar on January 18, 2023. Posted in Articles.

Documentation is the most important aspect for any BA.

The documentation is useful to depict the requirements and the detailed discussion about new features and change request if any. There are many different types of documents that a BA prepares. Some of the important ones are listed below –

Business Requirement Document (BRD)
User Stories
Use Case Specification Document
Functional Requirement Document (FRD)
Requirements Traceability Matrix (RTM)
Market Requirements Document (MRD)
Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst. It helps in understanding the business process and business events. A business events is a trigger that gives birth to the requirement. These requirements are then fulfilled by opting for IT solution.

Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and striking differences between BRD and FRD.

Business Requirement Document

BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
In other words it describes at very high level the functional specifications of the software
A formal document illustrating the requirement provided by the client
The requirements could be collected either by verbal or written or both
Created by a Business Analyst (usually) who interacts with the client
Entire work is executed under the supervision of the Project Manager
It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

To arrive at a consensus with stakeholders
To provide input into the next phase of the project
To explain how customer/business needs will be met with the solution
Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

document revision
approvals
RACI chart
introduction
business goals
business objectives
business rules
background
project objective
project scope
in-scope functionality
out-scope functionality
assumptions
constraints
risks
business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
legacy systems
proposed recommendations
business requirements
appendices
list of acronyms
glossary of terms
related documents

Now let’s try to dig more in FRD..

Functional Requirement Document

FRD highlights “Functional Requirements” i.e., functionality of the software in detail
Depending on the product, FRD document can be between 10 to 100 pages
It too describes at a high level the functional and technical specification of the software
Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
In a small and medium sized organizations a BA take care of this
Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
FRD is derived from the BRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an analyst after discussing with stakeholders and project manager ponder on questions like –

How we develop the expected requirement(s)?
What are the features and functionalities?
What are the tools and/or systems used and their dependencies?
How will the customer reacts when they start using the solution?
Any assumptions or constraints?

Most common objectives of FRD –

Depict each process flows for each activity interlinking dependencies
Holistic view for each and every requirements, steps to built
Estimating detailed risks for each new change request
Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
Methodology
Functional Requirements
Modelling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
Other Requirements – Interface Requirements, Hardware/Software Requirements,
Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. As in my organization all projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the documents then BA will design the same. But if there is a need for the continual delivery of working product then documentation will not be preferred.

However, documentation will remain a valid artefact of any project in distant future.

Published: 06/12/2017

Business Process Modeling

Written by Arpan Rewatkar on January 10, 2018. Posted in Articles. 1 Comment on Business Process Modeling

A Business Analyst is the core member of the project team. He is a star of any project. He is a friend of business.

He resolves complexity. He offers solution. He mitigates risk. He delivers value to the customer. In any project a ‘Value’ can be defined by two aspects –

Value is

fit for purpose (is the value delivered satisfies the business need?)
fit for use (is the value delivered correct?)

But delivering value to any stakeholder is not an easy task though. However a BA can build and maintain trust by delivering ‘work samples’ to stakeholders. Here work samples can be referred to any screenshot of the working product or it could be a trial version et cetra. A BA should be vendor neutral in order to maintain transparency among other team members and stakeholders.
In other words a BA should model the requirements and should model the process. How the process works in an organization and what needs to be done to improve the current process. Thus, a concept of Business Process Modelling (BPM) came into existence. Let’s try to figure out BPM.

BUSINESS PROCESS MODELING

Business process modeling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved.

It is performed by –

Business Analyst
Subject Matter expert (SME)
a team comprising both

(source – Wikipedia.org)

First we need to understand what a process is. A process is flow of events that occur in any business to gain monetary benefits without considering risk and losses. These risk and losses are not owned by the stakeholders. To model these processes for the benefit of business needs is a prime responsibility of a BA. Thus we can summarize by the figure that follows.

You can see that in a business process which is triggered by some business event has inputs like resource and information which gives rise to certain requirements. An actor could be anyone that initiates the business event which realizes the need of something. It could also be an issue that gives rise to the need to either improvise the current process or improve it. A business process should then satisfies the goals and some output which offers value to the stakeholders.

In other words, a Business Process Modeling is a set of activities that describe the order of activities from start to finish with some input and some output correspondingly. A BA can consider the business process model is the final output to meet business needs.

Components of Business Processing model includes –

a goal – every business process has a number of goals to achieve, these goals need to be able to meet business needs
input – input could be use case stories, product backlogs, requirements which are elicited, analyzed and validated
Message (information) – messages are used to complete the activity. In the business process, the message is not consumed, but as part of conversion process. There are various sources from where the messages are generated for instance, external resources, customers, internal organizational units and even other processes.
Resources – it can includes the staff, the machines and other architecture. Unlike the message, the resource is consumed and could be exhausted.
Output – each business process generates some outputs that meets the business needs. The output could be either physical object (for instance, a report or an invoice) or it can be the end of the entire business process.

In modelling language, the stakeholders are referred to as the actors. They can be a person, department, system, or an external entity to the organization. Few are the benefits of Business Process Modelling –

Ensures you understand how an organization runs & performs activities, and relates to the outside world
Identifies areas that are not well understood
Helps identify complex business processes
Helps with the training documentation

BPM Tools

There are 4 different types of tools used in Business Process Modelling –

Context Diagram – These are the high level framework of the interaction of the organization with external entities. Below is the sample context diagram :
a typical contextual diagram
It represents the flow of events with supplier and customer as an external entity. It illustrates the interaction of these entities with the restaurant.
Functional flow diagram – It is a step by step process which depicts the system’s operational flow. Also referred as block diagram. Below is the sample one indicating process step by step –
functional flow depicting each flows
We can see all the possibilities and assumptions have been considered in functional flow diagram. It could be under same department or multiple. But the separation can’t be seen.
Cross Functional flow diagram – Process flows are segregated within different aspects. Here it could be different departments or operations. In manufacturing industries the design department is different, assembling department is a separate entity and finally the testing department is altogether one. But the process flows are interconnected between all these different departments. Have a look at the below sample –

Cross functional-purchasing item sample
Here you can see processes are been transitioned from customer to sales department. The sales department contacting the warehouse for checking the availability of item and finally customer service for after sales support. Also referred to as ‘Activity Diagram’ and ‘Swim-lane Diagrams’.
Use Case diagrams – These are the user perspective modelling diagrams used to model the interaction of the user (actor) and secondary actor with the system. It represents only positive flows, no if-else statements and no negative flows. It is one of the most important tool for Business process modelling. Elements of Use Case diagrams include Actor (Primary/Secondary), use case(s), association, system boundary, system clock. Below is the sample-

use case-sample

Here a customer (actor) using ATM banking system (System boundary) for withdrawing, depositing money and checking balance (use cases).

A BA should note that he should use BPM tools to model the requirements. Thus modeling approaches should be

easy to read
capture the processes
be a foundation for other models
should represent the current state

The way to create effective models is to train the modelers ,explain modeling to business attendees (stakeholders or business sponsors) and check if work has already been done and starting with the known and then integrating details into the current one. This leads to another important aspect for BA which is ‘Change Request Management’.

BRD Vs FRD

Written by Arpan Rewatkar on December 6, 2017. Posted in Articles. 1 Comment on BRD Vs FRD