What are the Documents prepared by Business Analyst?

Let us see here documents prepared by Business Analyst during the project. Business Analyst will prepare so many documents as per Company standards; here we will see what the documents are mostly created by the Business Analyst during the project life cycle.

These documents prepared by business analyst to fulfill the various project needs and cater to audiences belonging to different spheres of a project.

Documents prepared by Business Analyst

As we know Business Analyst primary and most important role is to gather the requirements, analyze the requirements and document the same with proper approvals, Business Analyst should ensure not to miss any requirement. For example, if any requirement is out of scope of the project and it is not feasible then Business Analyst needs to inform the same to stake holders prior to prepare the documents and get approvals from internal and external stake holders. If any requirement is out of scope or not feasible in this project then he needs to explain the scenarios and consequences and what problems we will face because of this requirement to internal and external stake holders. Business Analyst can update the same in meetings with stake holders and it should be documented in the form of FSD or FRD.

Documents Prepared by Business Analyst

Documents Prepared by Business Analyst

The type and specifications a business analyst is expected to create in an organization depends upon many parameters like organization’s processes and policies, need and expectations of the business, and the stakeholder requirements. Detailed below are the common documents a business analyst is expected to created and they are extensively used throughout the project life cycle. Each of these documents has a specific template and it’s a part of the overall project documentation.

Let us observe what are the documents prepared by Business Analyst below

  • Project vision Document
  • Business Requirement Document
  • Functional requirement specification (FRS)/ Functional Specification Document (FSD)
  • User stories
  • Use cases
  • Requirement traceability matrix (RTM)
  • System requirement specification (SRS)/ System Requirement Document (SRD)
  • Test case

Project vision document: Project vision document will be prepared by client and project Manager, business analyst also expected to contribute to this document based on organization and project manager wish.

We will mention purpose of the product/software to be developed. We will describe what business objective will be achieved because of this product in high level.

The Project vision document contains: It may vary from organization to organization depends on organization and stake holders.

  • Introduction
  • Description of users in the system
  • Project stakeholders
  • Product Overview
  • Product Features
  • Product requirements
  • Constraints/Limitations
  • Quality/documentation requirements

Business Requirement Document (BRD)/ Business Requirement Specification Document. (BRS)

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 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.

The Business Requirement Document contains:

  • Document revision
  • Approvals
  • Introduction
  • Business goals and objectives
  • Stake holders
  • Business rules
  • Project background
  • Project objective
  • Project scope
  • In-scope functionality (Requirements)
  • Out-scope functionality (Requirements)
  • Business requirements
  • Data requirements
  • Functional requirements
  • Non_functional requirements
  • Assumptions
  • Constraints
  • Risks
  • Business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • Legacy systems
  • Proposed recommendations
  • List of acronyms
  • Glossary of terms
  • Related documents
  • Dependencies of existing systems

Functional requirement specification (FRS)/ Functional Specification Document (FSD) Functional Requirement Document (FRD)

A 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 much 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.

Functional requirement specification (FRS)/ Functional Specification Document (FSD) Functional Requirement Document (FRD) contains

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, Dependencies and document overview
  • Methodology
  • Functional Requirements
  • Modeling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface / Integration Requirements, Hardware/Software Requirements,
  • Performance
  • Glossary
  • Requirements Confirmation
  • Client Signoff  (Client provide sign off on mail if client satisfies with the approach)

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 login credentials of the user and redirect him to the dashboard in case of successful login.

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 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..

The Use Case document contains:

  • Actors
  • Description
  • Trigger
  • Preconditions
  • Normal Flow
  • Alternative Flows
  • Exceptions
  • Special Requirements
  • Assumptions
  • Notes and Issues

Requirement traceability matrix (RTM)

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 (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.

The RTM Contains:

  • Requirement ID
  • Requirement Description
  • Functional Requirement
  • Status
  • Architectural/Design Document
  • Technical Specification
  • Software Module
  • Test Case Number
  • Tested In

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 the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.

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

Test case

Although 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 which should be referred every time a requirement has to undergo testing.

Business Analyst will not prepare test cases but he sits with the QA team and ensure to all the requirements covered.

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

All the above documents prepared by business analyst and are part of the project/product documentation. These documents are constantly referred through the project’s life-cycle for communication, reference and revision.

Templates may differ to organization to organization and project. Hope this article helped you to provide overview on what are the documents prepared by business analyst .

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

What is Stakeholder Management/ Analysis

Stakeholder Management/ Analysis

Who are Stakeholders:  

Stakeholder Management

Who are involving the project directly or indirectly are called as stake holders. Ex: Development Team, Testing Team(QA), client, SME’s and Architect. Stakeholder management is very important to gather the requirements.

And as a Business Analyst we have coordinate and arrange multiple meetings and interviews with multiple teams to understand the requirements and to deliver the requirements as per planned schedule.

As a business Analyst we are responsible for certain things like,

  • Investigation of requirements
  • Elicitation of requirements
  • Analyzing the requirements
  • Communicating with internal and external stakeholders
  • Documenting the requirements

Stakeholder Management/ Analysis

Business analyst role is continuous improvement, continuously we have to concentrate on our skills and we have to upgrade as per industry to survive or to prove as a Business Analyst. Always Business Analyst needs to think how things can be better, and how we can provide better service or support to the client.

When we are analyzing the requirement we should also think about the impact on existing functionality and what are additional things are needed to meet customer expectations.

When we are communicating product delivery dates to client, we should ensure that we have to deliver on time which includes design, development and testing and all internal approvals, before committing due dates we have to understand exactly what is the requirement and how much man hours needed and what are the challenges we may face during producing the product. Because if you are unable to release the product on committed dates then client may lose confidence on you, so it is difficult to handle further. Before committing dates you should concentrate on design, development issues, Testing and issues and what are the dependencies on other teams.

To understand the situation and complexity of the problem clearly we can do interview stake holders, it helps us to understand the problem clearly and client also feel team is working on their issue, so client also may happy. Once we understand the problem clearly then we need to spend time with the internal teams to resolve the issue.

To understand the requirements clearly we have to coordinate with stake holders and subject matter experts, Subject matter expect will explain to us what the exact business requirement is and how they are expecting the functionality of the application.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

How to identify Stakeholders and How to get in touch with the Stakeholders: Stakeholder Management/ Analysis

Project Managers or Project directions can help us who are the stake holders and with whom we need to coordinately closely to understand the requirements clearly. Some of the stake holders are very important because they may impact on the project if they have any requirements.

Usually Project manager or Project director can decide who the stake holders are or in some of the cases stake holders can decide who can be the project manager. Project managers or Project directors should know who the stake holders are.

Once you start discussing with the stake holders then you can understand who can help us to understand the requirement clearly and what is the involvement of the stake holders in the project. Based on that you can identify and categorize the stakeholders.

Once you identify the stakeholders then we need to categorize them. Like..

  • How do they impact on the project.
  • What are their contribution on the project
  • What is the level of involvement and how do we need to communicate with them.

Once you get the requirements still you need clarity then you can discuss and coordinate with the Subject matter experts to understand the requirements in better way, but remember one thing, if we ask one question then subject matter experts will give multiple answers, then you need to pick the correct one which suits to your project and which is in scope. Scope like as boundary for us, if we cross the boundary then project manager may feel bad and it may impact on project delivery. Because it will impact on the budget, resources, scheduling and planning.

If you schedule any meeting with the stake holders, first you give overview of the project to the stake holders, so that we can expect the requirements within the scope. It will help us to keep them in control.  Once you get the requirements, ensure the document it and get the sign off from the client.

Identify the stakeholders, Identify of level of contribution in project, create a relationship and build a trust among the stakeholders. Because if stake holders do not have confidence or trust on you then they may refuse to discuss with you, it may impact on requirements gathering, so it is very much important to build a trust among the stake holders.

I hope it helped you to provide the overview of Stakeholder Management.

To know more about stakeholder management, you can browse on google to get more information and idea.

Stakeholder management and analysis plays very important role in Business Analyst daily tasks.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

FAQ’S

What Is Stakeholder Management?

Stakeholder management is the process of maintaining good relationships with the people who have most impact on your work. Communicating with each one in the right way can play a vital part in keeping them “on board.” This article is about how to communicate effectively with stakeholders.

What are the 7 principles of stakeholder management?

The 7 principles of Stakeholder Management!

Bucholtz and Carroll point out that the principles highlight action words that illustrate the spirit that should be used in engaging with stakeholders:

  • acknowledge.
  • monitor.
  • listen.
  • communicate.
  • adopt.
  • recognise.
  • work.
  • avoid.

What is an example of stakeholder management?

Examples include employees, customers, shareholders, suppliers, communities, and governments. Upstream stakeholders contribute to or approve the activities required to design, build and bring a product to market.

What are the 4 steps of stakeholder management process?

Four Steps to Stakeholder Relations

  1. Identify Stakeholders. The first stage in stakeholder relations involves researching individuals and third-party organizations that may be relevant. …
  2. Study Stakeholders. Once potential stakeholders have been identified, do your homework. …
  3. Prioritize Stakeholders. …
  4. Contact Stakeholders

What are stakeholder management techniques?

Five strategies for effective stakeholder management

  • Stakeholder mapping. Early in the project, conduct a thorough stakeholder analysis to identify your stakeholders. …
  • Influence is key. …
  • Identify the triggers. …
  • Look for opportunities. …
  • Proactive mitigation.

What are the 10 key principles of stakeholder management?

Key principles of stakeholder engagement

  • #1 Understand. …
  • #3 Consult, early and often. …
  • #4 They are human too. …
  • #5 Plan it! …
  • #6 Relationships are key. …
  • #7 Just part of managing risk. …
  • #8 Compromise. …
  • #9 Understand what success is.

What makes good stakeholder management?

Good communication keeps crucial stakeholders on board. Stakeholder management is the process of maintaining good relationships with the people who have most impact on your work. Communicating with each one in the right way can play a vital part in keeping them “on board.”

What is stakeholder management and why is it important?

Stakeholder management is an important activity that is used to gain mutual understanding of the objectives and expectations of all parties. It aids in developing a concept that will gain support from all the interested and affected parties enhancing the likelihood of a successful outcome

What is the objective of stakeholder management?

At its core, stakeholder management is the ability to create and maintain positive relationships through the appropriate management of individual needs, wants and expectations. Stakeholder management is a process that works best when planned and guided by underlying principles.

Why is stakeholder management skills important?

Stakeholder management is important since it is the lifeline of effective project relationships. This needs to involve establishing a sound relationship and understanding how their work is contributing to project success. You need to establish trust and maintain relevance

What is stakeholders management plan?

The stakeholder management plan defines and documents the approach and actions that will increase support and minimize the negative impacts of stakeholders throughout the life of the project. It should identify the key stakeholders along with the level of power and influence they have on the project

What is the first step for stakeholder management?

Stakeholder Analysis is the first step in Stakeholder Management, an important process that successful people use to win support from others. Managing stakeholders can help you, too, to ensure that your projects succeed where others might fail.

How do you build stakeholder management?

Six principles for building trusting stakeholder relationships

  1. Seek first to understand before being understood. …
  2. Have empathy and think in win/win solutions. …
  3. Set a good example as a project manager and leader. …
  4. Be honest and open about project progress. …
  5. Be proactive and take responsibility for your actions.

What are the four types of stakeholders?

The easy way to remember these four categories of stakeholders is by the acronym UPIG: users, providers, influencers, governance

What are the five steps to stakeholder engagement?

5 Essential Steps to a Stakeholder Engagement Plan

  1. Reduce project risks.
  2. Manage your resources more effectively.
  3. Facilitate team collaboration.
  4. Gain buy-in.
  5. Meet timelines.
  6. Build trust and better relationships with stakeholders and communities.

What are the Tools used by Business Analyst

Tools used by Business Analyst

Let us discuss about Tools used by Business Analyst

Tools used by  Business Analyst

Tools Used by Business Analyst:

Business Analyst needs to use some tools during the project to make stake holders to understand the requirements clearly.  Let us see some of the commonly and important Tools Used by Business Analyst:

A complicated BA role, Business Analyst  needs to gather the requirements from the client and he needs to ensure that no requirement should be missed. He should prepare the specifications very carefully, because development team will understand the requirements based on the artifacts shared by the Business Analyst, if they understand in different way then development team will deliver what they understand as per the artifact, so it may not be as per client requirement, it leads to project failure.

Every organization is using different tools as per company’s requirement, here we will observe the commonly used to tools.

As a practicing business analyst, I have come across many business analysis tools.

 I read so many articles and blogs in internet to understand what are the tools used by the Business Analyst to prove as a good Business Analyst. I found so many tools in internet, but practically it is very difficult to learn all the tools which I found in internet by the business analyst. Because A business analyst is one who deals with the requirements gathering, elicitation, analysis, and modeling on a day-to-day basis.

Hence, in this article, I focused on commonly  Tools Used by Business Analyst which are used by almost all organizations.

Fundamentally, BusinessAnalyst need following types of business analysis tools:

  • To track requirements
  • To manage the requirements
  • Design the requirements
  • Describe requirements in certain detail
  • Model requirements wherever feasible
  • To collaborate with internal and external stake holders.

Here I am going to mention which are the tools I am using to meet my requirements, am not intended you to learn only these tools and am not promoting any tools.

MS Excel:

Mostly I use Excel to create flow charts and as per the client requirement, can use Excel to track the requirements and for requirement traceability matrix. We can create multiple things with using Excel like Wireframes, Flow charts and to manage the requirements. Excel contains several built-in mathematical and financial functions which will be useful in data analysis

  • Pivot tables
  • Examining the trends in data
  • Sort and filter data
  • Creating charts or graphs

MS Word:

Will use Ms_Word to prepare the multiple documents like FSD , BRD, Release Notes and User Manuals. Most of the stake holders are using the Ms-word to prepare multiple documents.

MS PowerPoint:

Will use power point for presentations. With using powerpoint we can easily explain to stake holders.

Google Search:

If you stuck somewhere and not able to understand what to do and how to do, then Google search will help us to get basic idea. If we need any templates related to documentation also we can get the same with using Google Search.

Skype

We can use skype to schedule meetings and we can explain easily via screen sharing to the stake holders. We can easily coordinate with internal and external stake holders with using skype.

Ms _ Visio:

Ms_Visio can be used to draw UML diagrams. We can easily identify with UML diagrams that which actor is doing which task. It will help developers to understand the requirement clearly.

  • UML diagrams creation such as use case, sequence diagrams, and activity diagrams.
  • To prepare process flow charts
  • To create data models
  • To generate architecture diagrams

Ms_Project:

Ms_Project can be used to track the requirements.

JIRA :

Jira can be used to track the requirements, issues, Change requests. Most of the organizations are using JIRA tool.

Balsamiq, axure and Pencil :

Balsamiq and axure can be used to create mockups to understand the requirement clearly. And easily we can explain to stake holders. Balsamiq Mockups helps business to work faster and smarter. Moreover, it allows projects to host online. In addition to that, it works as a collaboration tool between team and clients.

I hope this provided you the overview of Tools Used by Business Analyst.

Here I mentioned common tools used by Business Analyst, if you want to know more tools used by Business Analyst then you can browse on google.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Tools Used By Business Analyst : FAQ

What are the tools for business analysis?

Microsoft Office Suite. The following applications of Microsoft office suite come under the best business analysis tools list – …
Google Docs. …
Rational Requisite Pro. …
Balsamiq. …
SWOT. …
Pencil. …
Trello. …
SmartDraw.

What are analytics tools?

What are business analytics tools? Business analytics tools are types of application software that retrieve data from one or more business systems and combine it in a repository, such as a data warehouse, to be reviewed and analyzed

Teams and Departments in Company

Teams and Departments in Company

Departments and teams in Software Organization

I feel it is important to understand different teams at high level.
There will be different teams in a software company, let us see Teams and departments in company in high level.

Pre-sales Team:

Sales, marketing team:  Presales Business analyst team and sales heads will interact with different clients to get the software project; this team is backbone of any company, because without this team will not get projects, without projects company can’t survive. Will discuss in details in next post how projects will be initiated and all.


Application team or Development Team: will have;

Business Analysts, also called as Business System Analyst – work mainly on requirements & client coordination. We will see more in detail in other section of this site.

Developers: Junior developer, senior software engineers, Technical leads, Application Architects, DBA’s.

Testing team: Junior testers, testers, Test lead, Test manager, this team will perform testing activities to ensure quality of software product or application.

Production Support / Implementation team: This team takes care of servers, any issues in the production, deploying (putting) code in production environment (Client place). Finance: Takes care of salaries, expenses & other Finance related activities

HR: Recruitment, Employee relations, Company Ethics and practices etc

Teams and Departments in Company

Agile vs Waterfall or Difference between waterfall and Agile

What are the differences between Waterfall and Agile?

Differences between waterfall and Agile Methodology / Agile vs Waterfall

To understand what are the differences between waterfall methodology (Agile vs Waterfall) and Agile Methodology, first we will understand what are the advantages and disadvantages of these methodologies then we will look into Agile vs Waterfall.

Before learning Agile vs Waterfall we will discuss what are the advantages and disadvantages of Waterfall and Agile Methodologies.

Advantages of Waterfall Methodology (Model):

https://www.bacareers.in/sdlc-waterfall/

  • It is one the easiest model to manage. Because of its nature, each phase has specific deliverable’s and a review process. In each phase we will get to know what to deliver and when to deliver.
  • Faster delivery of the project
  • Process and results are well documented and documentation plays important role in Waterfall methodology.
  • Easily adaptable method for shifting teams.
  • This project management methodology is useful to manage dependencies.
  • It works well for smaller size projects where requirements are easily understandable.

Disadvantages of Waterfall Methodology (Model):

  • This model is not suggestible for Large projects
  • If the requirement is not clear at the beginning, we can’t use waterfall methodology because every phase is dependent on previous phase.
  • Here next phase will start once previous phase completed.
  • Very difficult to move back to makes changes in the previous phases.
  • The testing process starts once development is over. Hence, it has high chances of bugs to be found later in development where they are expensive to fix.
  • There is no team work in this model.
  • Difficult to manage change requests in this model.

Advantages of the Agile Methodology(Model):

https://www.bacareers.in/sdlc-agile-scrum/

  • Agile teams are extremely motivated and self-organized so it likely to provide a better results from the development projects.
  • Client involves in every phase of the SDLC, so requirements are clear and if team needs any clarifications also we can close as soon as possible.
  • Agile software development method assures that quality of the development is maintained
  • The process is completely based on the incremental progress. Therefore, the client and team know exactly what is complete and what is not. This reduces risk in the development process.
  • Change requests are welcomed at any phase of the SDLC.

Disadvantages of Agile Methodology (Model):

  • It is not useful method for small development projects.
  • It requires an expert to take important decisions in the meeting.

What are the difference between Waterfall and Agile Model?

                                               Agile vs Waterfall

              Difference between Agile and Waterfall Methodologies/ Agile vs Waterfall

                                  Agile

              Waterfall

It separates the project development lifecycle into sprints.

Software development process is divided into separate phases.

It follows an incremental approach

Waterfall methodology is a sequential design process.

Agile methodology is known for its flexibility.

Waterfall is a structured software development methodology so most times it can be quite rigid.

Agile can be considered as a collection of many different projects.

Software development will be completed as one single project.

Agile is quite a flexible method which
allows changes to be made in the project development requirements even if the initial planning has been completed.

There is no scope of changing the requirements

Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once.

All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model.

Test plan is reviewed after each sprint

The test plan is rarely discussed during the test phase.

Agile development is a process in which the requirements are expected to change and evolve.

The method is ideal for projects which have definite requirements and changes not  expected.

In Agile methodology, testing is performed concurrently with software development.

In this methodology, the “Testing” phase comes after the “Build” phase

Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer’s demands.

This model shows a project mindset and places its focus completely on accomplishing the project.

Prefers small but dedicated teams with a high degree of coordination and synchronization.

Team coordination/synchronization is very limited.

Products owner with team prepares requirements just about every day during a project.

Business analyst prepares requirements before the beginning of the project.

Test team can take part in the requirements change without problems.

It is difficult for the test to initiate any change in requirements.

Description of project details can be altered anytime during the SDLC process.

Detail description needs to implement waterfall software development approach.

The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team

In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC.

Agile and Waterfall are very different software development methodologies and are good in their respective way. Organizations will follow the methodology which suits for the project and requirements how ever it is better to know the differences between Agile and Waterfall (Agile vs Waterfall).

  • Usually Waterfall methodology will be used for small projects where requirements are clear and there is no chance to change the requirements.
  • Usually Agile methodology will be used for large projects where requirements are not clear and client is changing the requirements frequently.
  • Documentation plays important role in waterfall methodology.

I feel it helps to understand difference between waterfall and Agile (Agile vs Waterfall ) For More about Agile vs waterfall…….

BRD Vs FRD, Difference between BRD and FRD Documents

BRD Document Vs FRD Document

Let us discuss BRD Vs FRD  herre and how to to  prepare the BRD and FRD.

BRD Vs FRD
BRD Vs FRD

Documentation is the most important aspect for any Business Analyst.

The documentation is useful to understand the requirements and the detailed discussion about new features and change request if any. Business Analyst will prepare many different types of documents. Some of the important ones are listed below –

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

Documentation helps in understanding the business process and business events throughout the project. A 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 differences between BRD and FRD.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

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.
  • A formal document illustrating the requirement provided by the client
  • In other words it describes at very high level the functional specifications of the software
  • The requirements could be collected either by verbal or written or both
  • Created by a Business Analyst 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
  • 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
  • list of acronyms
  • glossary of terms
  • related documents

Now let us look into FRD…

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Functional Requirement Document

  • FRD highlights “Functional Requirements” i.e., functionality of the software in detail
  • Depending on the product.
  • It will 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
  • Will get sign off from the client once we prepare FRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Business Analyst will prepare the FRD after discussing with the stake holders and Project Manager. He is the person analyze the requirements, to get clarity on requirements he will conduct multiple meeting session with internal and external stake holders. And he will concentrate on below questions mostly.

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

Most common objectives of FRD –

  • Draw flow charts for 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
  • Modeling 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. In my company client will share the BRD, based on the BRD we prepare FSD.

I hope now you understand the BRD vs FRD

BRD Vs FRD – Business Analyst Articles, Webinars

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

What is the difference between a BRD and FRD?

The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need. BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done

What is an FRD?

The functional requirements document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. The developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the FRD

What is difference between BRD and SRS?

It is obvious that BRS is the specification of the business processes and operations. Use Cases: SRS describes the interaction between the created product and the end users. It is the reason why this specification type includes use cases. … Specification sphere: SRS describes the peculiarities of the developed system

What is included in a requirements document?

Requirements documents should include these kinds of requirements: Business Requirements: Business requirements generally come from the customer of the project. They represent the product features, or what the end outputs of the project need to provide

What are two types of functional requirements?

Requirements generally fall into two typesfunctional and non-functional. The difference between them is fairly straightforward, nevertheless, in the this article we’ll define the two types of requirements and provide examples of each to point out more concretely the fundamental difference between them

What Business Analyst Skills are Important for a New BA?

Business Analyst Skills / Skills required for Business Analyst

Business Analyst Skills

Many people are looking for business analyst role, here we will see what are the skills needed  for business analyst role to prove as a good business analyst.

Before going to learn about Business Analyst, I feel it is good to know Business Analyst Skills

A good team player:  

Business analyst needs to interact with different teams and coordinate for the development activities, it is very important to a good team player, he needs to involve in the project in all the levels, for example: design, development, UAT and implementations.

A good listener: 

Business Analyst should have patience and listening skills. He should listen what others are saying, should not disturb when others are saying something during discussions are meetings. Only when you listen, you understand your clients better and of-course the requirements.

Good Communicator: 

Generally people relate communication to speak in English, this is not correct. A good communicator will not only speak good English but also ensures the communication is well received by the intend audience. This is very important, because when you are communicating with stakeholders and you are using very tough words then communication may not reach to the stake holders and they may think in different way. Communication should be simple and understandable.

Quick learner: 

if you are working in a new domain should be able to understand quickly. Understand the problem statements of clients, pain points of the business process etc. Because if we are unable to understand what client is saying then we can’t communicate the same to internal stake holders and we can’t provide solutions to the client.

And continuously we need to concentrate on updating our skills like domain knowledge or related software knowledge, coding and development is not a mandatory skill for business analyst, but still if we have some knowledge then we can easily manage the stake holders.

Many people looking for Business Analyst role has a wrong understanding, they think – just because Business Analyst is a non technical role, they can be business analyst. This is totally wrong.

Some people also think that, Business Analyst job is to do only documentation; hence it is very simple and easily doable job. Again this is a wrong understanding.

List of activities performed by the business analyst mentioned in another post.

My intention is to make you understand what are Business Analyst Skills it does not mean that only mentioned are Business Analyst Skills, these are most important Skills to deal with the stakeholders.

Skills of Business Analyst

Business Analyst Skills

Business Analyst Skills

Can read below to understand Business Role and Responsibilities in project.

Business Analyst Role in Agile Project

Business Analyst Daily Tasks

Business Analyst Role in project

Day to day activities of Business Analyst

Business Analyst Skills : FAQs

What does an Business Analyst do?

The analyst is involved in the design or modification of business systems or IT systems. The analyst interacts with the business stakeholders and subject matter experts in order to understand their problems and needs. The analyst gathers, documents, and analyzes business needs and requirements.

What should business analyst learn?

Business analyst are experts in the field of business analysis which is the task of understanding the changing business needs, assessing the impact of these changes, capturing, analysing and documenting requirements and supporting the communication and delivery of requirements with clients and stakeholders.

What are the 3 most important skills of a business analyst?

Nine Key Skills That Every Good Business Analyst Needs
Understand your objectives. Being able to interpret direction is important. …
Good verbal communication skills. …
The ability to run stakeholder meetings. …
Be a good listener. …
Hone your presentation skills. …
Be excellent at time management. …
Documentation and writing skills. …
Stakeholder management.

What does a business analyst do day to day?

Day in the Life of a Business AnalystBusiness Analysis is the responsibility of knowing when a business’s needs change, assessing the business impact of those changes, obtaining, examining and recording requirements, and maintaining the communication and delivery of the requirements to relevant stakeholders

What are the BA tools?

The Axure tool provides the capability to produce wireframes, prototypes, and create documentation. This tool is used by professionals like business analysts, product managers, and IT consultants around the world

What are the skills needed for a business analyst?

Professional business analysts can play a critical role in a company’s productivity, efficiency, and profitability. Essential skills range from communication and interpersonal skills to problem-solving and critical thinking.

Business Analyst Tasks

Let us observe Business Analyst Tasks

Business Analyst Tasks
Business Analyst Tasks

It is very important to know business analyst tasks, Business Analyst key role is to Analyze, communicate, Document and validating the requirements. Let us discuss Business Analyst Tasks and  what he does during the project/ Business Analyst needs to listen carefully when discussing with stake holders and should not interrupt when they are sharing about issues / Problems or requirements.

As a Business Analyst we may speak with the SME’s and end users to understand exactly what the requirement and exactly what client is expecting, so that Business Analyst can provide suitable solutions to the client.

Key Responsibilities of the Business Analyst: / Business Analyst Tasks

  • Understand the Project
  • Identify the scope
  • Goals of the project
  • Identify the Decision makers
  • Identify the Stake holders
  • Issues / Problems
  • Flow diagrams and mockups
  • Track the Requirements
  • Manage the Requirements
  • Resolve the issues if team stuck up with some issues
  • Communicating with all the stake holders
  • Documentation

Each requirement should be delivered without any issue.

To understand the requirements clearly, we may conduct multiple meeting sessions with the stakeholders. Business needs to document the requirements in the form of BRD/FRD.

Before arranging the meetings, we should have proper Agenda of that meeting.

  • Workshops
  • Brainstorming sessions
  • Focus groups
  • JAD sessions
  • Walkthroughs
  • BRD: Business Requirement Document
  • FRD: Functional Requirement Document

  • As a Business Analyst we should ensure to participate all the Stake holders, Decision Makers and Subject Matter Experts in the meeting.
  • Ask the correct questions to understand the requirements clearly.
  • And we should ensure to meeting should not be go off track and ensure to be in on track.
  • And ensure to everyone engaged in the meeting.
  • Note down the Meeting of the minutes and circulate with all the stake holders who are involved in this project.
  • And assign the tasks to the respective team and ensure to complete the task on committed time lines.

I hope this article helps to understand Business Analyst Tasks

FAQ’S

A Day in the Life of a Business Analyst

Investigating goals and issues.
Analyzing information.
Communicating with a broad range of people.
Documenting findings.
Evaluating solutions.
Implementation.

What tasks does a business analyst do?

Business analyst job description

Creating a detailed business analysis, outlining problems, opportunities and solutions for a business. Budgeting and forecasting. Planning and monitoring. Variance analysis.

What are the roles and responsibilities of business analyst in given phases?

Business analyst activity includes the following stages:

Identify customer needs, understand the problem he wants to solve. Develop idea independently or with a help of a team. Develop the idea into requirements specification to create future product.

What are the 3 most important skills of a business analyst?

Core Skills
Communication Skills. Business analysts must be good communicators. …
Problem-Solving Skills. …
Critical Thinking Skills. …
Analysis & Communication Techniques are Both Key Sets of Business Analyst Skills. …
The Key Analysis Techniques. …
Business Analysis Tools. …
Relationship-Building Skills. …
Self-Managing.

What are the skills required for business analyst?

Top 7 Business Analyst Skills that are High in Demand!
Competent Verbal Communication. …
Good Listening Skills. …
Ability to Understand Delegated Objectives. …
Being able to Run Meetings with Stakeholders. …
Knowing the Objectives Well. …
Being Diligent with Time Management. …
Documenting and Writing Reports.

Can I become a Business Analyst ?

Can I become a Business Analyst:

Can I become a Business Analyst

Generally when we are looking for BusinessAnalyst career, our first question in our mind is “Can I become a Business Analyst and what are the skills needed to become a BusinessAnalyst. Here we will look into the BusinessAnalyst skills what are needed.

Yes, anyone can become BA irrespective of knowledge and skills, but we need to learn and understand who BA is and what are the skills needed to prove as a good BA.

Soft skills :

  • Communication skills : Communications skills means not only speaking in English, As a BA we need to know what to talk and what not to talk. BA should be able to communicate with team what he captured from the client and stake holders properly.
  • Problem solving skills
  • Listening Skills
  • Team work and collaboration

Domain Knowledge:

When we are communicating with stake holders, they will expect the same level of knowledge from us, so if we have domain knowledge then it will help us to understand client needs, issues and system functionality.  It will help us to provide suitable solutions to client.

For example, if we are working on the banking project and we do not have knowledge on banking then it is difficult to understand what client is saying and expecting from us.  So, there is a chance to understand the client requirements in different way, if we understand in different way then we will communicate the same to our internal stake holders.  So, team will work on the same. It may lead to project failure.

Here intention is not to say everyone should have domain knowledge and without domain knowledge we can’t be a good BA, if you can able to understand client needs and can communicate to internal stake holders and provide suitable solutions to client then we can prove as a good BA.

but if you have domain knowledge then it is good for you to understand the business needs and issues easily.  And we can easily communicate with end users.

In addition to that BA needs to understand what are challenges we may face and what are the business challenges.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Analysis/Technical skills.

This will help to run project without any operational issues.

For Ex:

  • Risk Analysis,
  • Gap Analysis

Is  technical skills needed for Business Analyst:       

Definitely it is a advantage if you have some technical knowledge, but it is not mandatory to become a BA major role to understand and gather the requirements from the client and he should be able to convey the same with technology team, and provide suitable solutions to achieve client goals.

If you are storing in domain knowledge and have experience in some domain then you need to concentrate on SDLC approaches, how it works and how to manage the stake holders and how to convey the requirements to technology team.

If you are a technology person and wants to become a Business Analyst then need to concentrate domain knowledge, how to manage the stake holders.

If you are a fresher and wants to become a Business Analyst, then needs to concentrate on both Domain knowledge and SDLC.

Can I Become a Business Analyst

Can read below to understand Business Role and Responsibilities in project.

Business Analyst Role in Agile Project

Business Analyst Daily Tasks

Business Analyst Role in project

Day to day activities of Business Analyst

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Business Analyst FAQs

What qualifications do you need to become a business analyst?

Business Analyst Education Degree Requirements
For entry-level business analyst positions, you may only need a bachelor’s degree. Some employers require business analysts to have a master’s degree in business administration. You may also need to have experience in the industry in which you plan to consult.

Is business analyst a good career path?

The good news is that the business analyst career path is very diverse, so based on your interest and qualification one can choose the most suitable path. Some options…… Operations Manager, keeping the fundamentals of the role of a business analyst in place, one can branch out as an operations manager

How do I become an IT analyst?

Learn how to become a technical analyst.
Should I Become a Technical Analyst?
Step 1: Earn a Bachelor’s Degree. A bachelor’s degree in an IT field can help prepare potential technical analysts for their career. …
Step 2: Gain Work Experience. …
Step 3: Obtain a Voluntary Professional Certification.

What does an IT systems analyst do?

systems analyst is a person who uses analysis and design techniques to solve business problems using information technology. Systems analysts may serve as change agents who identify the organizational improvements needed, design systems to implement those changes, and train and motivate others to use the systems.

error

Enjoy this blog? Please spread the word :)