As a Business Analyst we need to understand the requirements clearly, to understand the requirements as a Business Analyst we need to use techniques to understand the requirements. Let us observe Business Analyst elicitation techniques.
Elicitation is the process of digging out the information from the stakeholders. Requirements Elicitation serves the foundation in documenting the requirements.
Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping. … Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process.
What techniques do business analysts use?
S.W.O.T. stands for Strength, Weakness, Opportunities, and Threats. This is the most important technique used in business analysis. It is conducted by a group of people with different mindsets and perspectives in the company in order to access a changing environment and react accordingly.
What is elicitation in business analysis?
Requirements Elicitation. A Project’s Foundation
Requirements elicitation is the set of activities where information is given by stakeholders, users, and customers to be applied to the design of the initiative or the solution. Elicitation is a perpetual process during a project development.
What are the three main techniques of business analysis planning?
List of Best Business Analysis Techniques SWOT Analysis. The term SWOT stands for its four elements– … MOST Analysis. The term MOST stands for its four elements – … Business Process Modelling (BPM) … Use Case Modelling. … Brainstorming. … Non-functional Requirement Analysis. … PESTLE Analysis. … Requirement Analysis.
Which requirement elicitation is most popular?
Having said that, brainstorming, document analysis, interviews, prototyping and workshops are the most widely used requirement elicitation techniques.
Why is requirement elicitation a difficult task?
Why is Requirements Elicitation a difficult task ? Explanation: Users specify unnecessary technical detail that may confuse, rather than clarify overall system objectives. … Explanation: Requirements traceability provides bi-directional traceability between various associated requirements.
What is elicitation in teaching?
Elicitation is a technique by which the teacher gets the learners to give information rather than giving it to them. A teacher elicits the rules for the structure of the first conditional by asking learners to look at some examples, then writing ‘We make the first conditional in English with…?’ on the board.
Here I am listing down the real time challenges faced by the Business Analyst. There can be other challenges but here I am mentioning few which are facing by the Business Analyst in day to day life. I believe it may enough when you are trying a fresher, one or two experience.
Frequently changing requirements
Freeze requirements
Coordination with developers and testers
Change management-with respect to cost and time lines
Drive UAT phase – on time completion of UAT·
Manage Stakeholders availability for requirements and conducting meetings
Lack of training
People Management , Coordinating with different teams and different people.
Making sure status reporting is effective
Domain Knowledge
Overall making sure project health is in good shape and delivered as per the timelines without any issues.
Changing Requirements:Client may change their requirements very frequently. As a Business Analyst it is Very difficult to manage internal and external stake holders when they are frequently changing the requirements. We can’t accept every change request because already we committed the deadline of the project and committed the timelines to client and higher management and it may impact on project cost also. And development team also started work for committed requirements.
And it will take good amount of time to discuss and understand the requirement on the new change and feasibility of the same.
And we can’t say ‘No” to the client because it may impact on the project, so we need to convince client with proper reasons.
Before saying “Yes” or “No” as a Business Analyst we need to analyze what is the impact of this change and how much effort needed to deliver this change.
Every client may not change their requirements frequently but it may happen in general.
Freeze Requirements:
We need not to consider this as a tough challenge but sometimes client may make you struggle to give sign off and sometimes client will delay on providing the sign off. Because of this development may delay, and we can inform the same to client during the meetings.
This is not a tough challenge but for some reasons, client will not sign-off on the requirements or delay sign-off. The reason is, once client provide sign-off on the requirements, any changes will be charged additionally. So client will take some time to sign-off but this will again impact our project schedule.
However in real time, we start follow-up with client to get sign-off and we will commit the delivery dates once we get sign off from the client only. Unless we get signoff from the client on FSD we will not start work on this project. It will happen rarely but there is a chance to take place this scenario.
Challenges during Development:
This is also a common challenge for business analyst across organizations.
Developers will understand in a different way and do coding but when it comes to testing, testers might have understood in a different way and they will raise as a defect (bug) on developers. Developers will not easily accept the bug because they developed it and it will impact on their performance. Testers will argue it as a bug and finally it will be parked over Business Analyst. How to avoid these situations? Usually Business Analysts will share SRS / FSD containing requirements with developers and testers but Business Analyst should make sure that joint sessions to be organized with development team and testing team. Business Analyst should explain the requirements in joint session to both developers and testers and give them some time to read and understand. In case of any doubts Business Analyst should clarify then and there to avoid further confusions. And Business Analyst needs to conduct meeting with the internal stake holders frequently to get the project updates and to get to know whether team is facing any issues during development.
Change Management:
As we discussed previously once requirements are signed-off from client, any changes to the requirements will have impact on cost and schedule. So change management needs to be involved. i.e client should agree to provide more cost and additional time to deliver.
Most of the time, clients will not easily agree to the additional cost and time. This will require some sessions to convince clients. This will consume some effort.
However this is not exactly a challenge of Business Analyst, it will be project manager who will coordinate with customer for additional cost and time but since requirements are involved Business Analyst will also be engaged in change management process.
Challenges faced by the Business Analyst during UAT (User Acceptance Testing):
Once development and system testing is done from project execution team & before taking software / application go live, UAT has to be done. In the project execution your project Manager will reserve some time exclusively for UAT. In real time clients will not start UAT in time. So, any delay in UAT will have impact on project roll-out. So Business Analyst should drive UAT and make sure clients start testing from their end in-time. In case of any defects in UAT phase Business Analyst should quickly resolve with help of developers and testers. And if these are related to application functionality then business analyst needs to address it as soon as possible.
Again, just like getting sign-off on requirement documents, Business Analyst should get a sign-off on UAT as well. Client should confirm that UAT is performed and no pending issues.
Sample BA Document Templates
FREE DOWNLOAD
Send download link to:
Manage Stakeholders Availability for requirements:
Requirements’ gathering is most important phase in the SDLC. Business Analyst will arrange sessions with clients to understand the requirements. Most of the times Business Analyst will need business units, tech teams, Architects & other stakeholders to discuss about the problem statement and collect end customer needs but not everyone will be available at the same time.
Especially if company is into consulting, tech teams will be working on multiple projects. You need to match client’s time with every stakeholder which seems easy but really challenging.
If meetings get delayed, project plan will be affected and hence delivery/implementation date gets postponed, your client will not agree and difficult to convince.
Lack of training :
Sometimes you may face the client without proper training, as you do not have enough knowledge and enough training on product, you can’t convince the client and you can’t provide suitable solutions to client. Due to this client may lose confidence and trust on you. If you want to prove as a good business analyst it is very important to maintain good relationship with all the stake holders to things get it done smoothly.
Lack of Domain Knowledge
Domain knowledge is very important for business Analyst, so that business analyst can understand what client is trying to explain and what exact requirement of the client is. It will help us to explain the functionality to developers and internal stakeholders.
I hope it helped you to provide overview on Business Analyst Challenges
To know more about Business Analyst Challenges, you can browse on google.
Sample BA Document Templates
FREE DOWNLOAD
Send download link to:
Business Analyst Challenges: FAQs
What are the challenges faced by business analyst?
Getting Stakeholders To Make Time. Lack of Clarity. Inadequate Time Allotted For BA Work. Conflict Among Stakeholders.
What does a 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 is the role of business analyst in SDLC?
Role of Business Analyst during SDLC Process Then leads in analysis and designing phase, dictates in code development, then follows the testing phase during bug fixing as a change agent in the project team and ultimately fulfills the customer requirements
What are the qualities of a good business analyst?
Impressive Communication. Imagine hiring a business analyst who mumbles every time they speak. … The Ability To Solve Problems. A problem occurs within the company. … Critical Thinking. Finding the ideal solution doesn’t “just happen.” … An Analytical Mind. You don’t have to be born with it. … Process Modeling Knowledge
What does a BA do in Agile?
The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for.
Let us observe Business Analyst Role in product based company, When Business Analyst is working in product-based company, then he needs to understand the product of the company, like how it works and functionality of the product. Then only he can able to provide the suitable solutions to client. If Business Analyst not have the enough knowledge on his own product then he can’t convince the stake holders. Because of this stake holders may lose the confidence on the Business Analyst.
If you want to prove as a good business analyst, then you should build a good relationship with internal and external stake holders, it is possible when business analyst has knowledge on product.
Leet us discuss in detail below.
What is product-based company:
Business Analyst Role
IT company will have the concept and they invest time and money to build the product. IT company team will work to deliver this product. IT company initiates the development and company is the owner for this developed product. Then company sales team will sell the same product to multiple clients or customers. Customizations and configuration changes may be done as per the client requirement. Here Business Analyst needs to understand what changes to be done in existing product as per client requirement and where it fits. Business Analyst needs to understand that it should affect the functionality of the application.
Deployment will be done at client place: Business Analyst ensure to deployment should be done with out any issues, Business Analyst should coordinate with internal and external stake holders during deployment. Business Analyst should ensure that all the stake holders should be available during the deployment of the product, so that we can investigate and fix the issues or bugs if anything observed by the client during deployment.
Example for Product development IT companies: Oracle, IBM,
SAP, CRM etc.,
Briefly we will see here Business Analyst Role in Product
Development Company:
Understand the product features
Understand the product domain
Understand the client requirements
Understand what customizations are needed to this product to fit in the client requirements.
I feel this helps you to understand the Business Analyst Role in Product based company.
What is Application Development Company:
Here client will have the requirement, and client will coordinate
with IT company to develop the IT application. Client initiates the
development; IT company will share the updates and status of the development of
the IT application to the client during meetings and when client asked for
status of the development. Client is the owner of the developed application.
Client will be the only customer for this application
because application has been developed as per this customer requirements only
and client is the owner. Deployment will be done at the Clients place.
Business Analyst needs to understand the client industry and domain to provide suitable solutions.
I feel this helps you to understand the Business Analyst Role in Application Development company.
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
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
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)
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.
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:
Organizes the functional requirements,
Iterative in nature and updated throughout the project life-cycle
Records scenarios in which a user will interact with the system
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 .
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:
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 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
Identify Stakeholders. The first stage in stakeholder relations involves researching individuals and third-party organizations that may be relevant. …
Study Stakeholders. Once potential stakeholders have been identified, do your homework. …
Prioritize Stakeholders. …
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
Seek first to understand before being understood. …
Have empathy and think in win/win solutions. …
Set a good example as a project manager and leader. …
Be honest and open about project progress. …
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
Reduce project risks.
Manage your resources more effectively.
Facilitate team collaboration.
Gain buy-in.
Meet timelines.
Build trust and better relationships with stakeholders and communities.
Let us discuss about 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:
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
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.
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
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.
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.
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.
Difference between Waterfall and Agile Methodologies
Let us discuss and observe below in details what is the Difference between Waterfall and Agile Methodologies.
difference between Waterfall and AgileAdvantages of Waterfall Model:
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 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 Model:
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 Model
It is not useful method for small development projects.
It requires an expert to take important decisions in the meeting.
By reading above we can understand difference between waterfall and Agile.
Let us observe in table in details what are the difference between Waterfall and Agile
Difference between waterfall and Agile Methodologies
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.
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 hope it helped you to understand the difference between waterfall and agile.
In interview also they may ask what is the difference between waterfall and agile methodology.
If you need any clarifications on difference between waterfall and agile, you can post here.
