fbpx

Business Analysis Quick Notes

We compiled all the Business Analysis Jargon in simple words so you can prepare for your Business Analysis Interview in no time. 

Business Analysis

Business analysis is a practice of enabling change in an organization by identifying and defying the needs of a business—then, recommending changes and providing solutions that deliver value for the stakeholders.

Business Analyst

Business analysts work as liaisons among stakeholders to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.

Roles and Responsibilities of a Business Analyst:
Below is the shortlist of the business analyst’s job responsibilities:
• Discovers, synthesizes and analyzes enterprise information
• Understands enterprise problems, opportunities, and goals in the context of the requirements
• Analyses needs and solutions
• Device’s strategies and drives change
• Facilities stakeholder collaboration

Software Development Life Cycle (SDLC)
SDLC or the Software Development Life Cycle is a process that produces software with the highest quality and lowest cost in the shortest time possible.

Phases of SDLC:
In detail, the SDLC methodology focuses on the following phases of software development:

  • Requirement gathering and analysis
  • Design
  • Implementation or coding
  • Testing
  • Deployment
  • Maintenance

Role of BA in each phase of SDLC:

Stakeholders:
A stakeholder is a party that has an interest in a company and can either affect or be affected by the business.

Types of Stakeholders:
Stakeholders can be internal or external to an organization.

Internal stakeholders are people whose interest in a company comes through a direct relationship, such as employment, ownership, or investment.

External stakeholders are those who do not directly work with a company but are affected somehow by the actions and outcomes of the business. Suppliers, creditors, and public groups are all considered external stakeholders.

RACI Matrix
A RACI chart, also known as a RACI matrix or RACI model, is a diagram that identifies the key roles and responsibilities of users against major tasks within a project.
RACI is an acronym for responsible, accountable, consulted, and informed.
Responsible: Who is responsible for doing the actual work for the project task.
Accountable: Who is accountable for the success of the task and is the decision-maker. Typically, the project manager.
Consulted: Who needs to be consulted for details and additional info on requirements. Typically, the person (or team) to be consulted will be the subject matter expert.
Informed: Who needs to be kept informed of major updates. Typically, senior leadership.

Requirement Gathering
Requirements gathering is the process of determining what your projects need to achieve and what needs to be created to make that happen.

Business Requirement Analysis
A business requirements analysis is all about identifying, analyzing, and documenting the key requirements related to a business problem that needs to be solved or an organizational objective that needs to be met.

Types of Requirements

Business Requirements
Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objectives while remaining solution independent.

User Requirements
User requirements should specify the specific requirements that the user expects/wants from software to be constructed from the software project. A user requirement should be Verifiable, Clear and concise, Complete, Consistent, Traceable, Viable.

System Requirements
System requirements deal with defining software resources requirements and prerequisites that needs to be installed on a computer to provide optimal functioning of an application.

Functional Requirements
These are product features or functions that developers must implement to enable users to accomplish their tasks. functional requirements describe system behavior under specific conditions.

Non-Functional Requirements

Defines how the system should perform.

Transition Requirements
Transition Requirements describe capabilities that the solution must fulfill in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.

Requirement Elicitation
Requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as “requirement gathering”.

Elicitation Techniques

Interviews: In this technique, the interviewer directs the question to stakeholders to obtain information. One-to-one interview is the most used technique.

Joint Application Development (JAD): A JAD Session enables customers and developers to quickly come to an agreement on the basic scope, objectives, and specifications of a project or in case, not come to an agreement which means the project needs to be re-evaluated.

Brainstorming: Brainstorming is used in requirement gathering to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems and clarify details of opportunities.
Document Analysis: Reviewing the documentation of an existing system can help when creating an AS-IS process documents, as well as driving gap analysis for scoping of migration projects.

Focus Group: A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs/opportunities/problems to identify requirements or can be gathered to validate and refine already elicited requirements.

Interface analysis: Most systems require connections with other applications, hardware, and peripheral devices to function properly. Interface Analysis helps to identify interfaces between solutions/applications to determine the requirements for ensuring that the components interact
with one another effectively.

Observation: By observing users, an analyst can identify a process flow, steps, pain points, and opportunities for improvement. Observations can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), whereas active observation is more effective at getting an understanding of an
existing business process. Either approach can be used.

Prototyping: Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution – a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process
continues until the product meets the critical mass of business needs or for an agreed number of iterations.

REQUIREMENTS ANALYSIS

Pareto analysis: The Pareto Principle states that 80 percent of a project’s benefit comes from 20 percent of the work. Or, conversely, 80 percent of problems can be traced back to 20 percent of causes. Pareto Analysis identifies the problem areas or tasks that will have the biggest payoff.

Fish Bone analysis: A fishbone diagram is a visualization tool for categorizing the potential causes of a problem. This tool is used in order to identify a problem’s root causes. Typically used for root cause analysis, a fishbone diagram combines the practice of brainstorming with a type of
mind map template.

SWOT Analysis: SWOT stands for Strengths, Weaknesses, Opportunities, and Threats, SWOT Analysis is a simple tool that can help you to analyze what your company does best right now, and to devise a successful strategy for the future.

GAP analysis: A gap analysis is the process companies use to compare their current performance with their desired, expected performance. This analysis is used to determine whether a company is meeting expectations and using its resources effectively.

Feasibility Study: A feasibility study is an assessment of the practicality of a proposed plan or project.

Analyze Current State: The analyze current state task is used to understand the reasons for the changing enterprise needs and how that would affect the organization.

Define Future State: A “to be” business process defines the future state of a business process in an organization.

Business Case: A business case is a project management document that explains how the benefits of a project overweigh its costs and why it should be executed. Business cases are prepared during the project initiation phase and their purpose is to include all the project’s objectives, costs, and benefits to convince stakeholders of its value.

Project Objective: Project objectives are what you plan to achieve by the end of your project

Project Background: Background is one of the key characteristics of a project to explain why to initiate the project, what prerequisites are, and what results are supposed to be obtained at the successful completion.

Project Drivers: A person or team who is responsible for setting the direction for the project.

REQUIREMENTS DOCUMENTATION:

Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.

Business Requirements Document (BRD):

The business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.

Functional Requirements Document (FRD):

The Functional Requirements Document (FRD) is one way to express functional specifications and define the requirements and functional solution
the direction of the software solution.

Software Requirements Specification (SRS): A software requirements specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements.

Scope of Work Document (SoW): A statement of work (SOW) is a document that provides a description of a given project’s requirements. It defines the scope of work being provided, project deliverables, timelines, work location, and payment terms and conditions.

Requirements Traceability Matrix (RTM): A requirements traceability matrix is a document that demonstrates the relationship between requirements and other artifacts. It’s used to prove that requirements have been fulfilled. And it typically documents requirements, tests, test results, and
issues.

Work breakdown structure (WBS): It is a visual, hierarchical, and deliverable-oriented deconstruction of a project. It is a helpful diagram for project managers because it allows them to work backward from the final deliverable of a project and identify all the activities needed to
achieve a successful project.

Use Case Documents: A use case is a written description of how users will perform tasks on your website.

Validation: The process of evaluating software at the end of the revision life cycle to ensure compliance with software requirements.

Verification: The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process.

Manual Testing: The process of manually testing software for defects.

Automation Testing: Automated testing is a method in software testing that leverages automation tools to control the execution of tests instead of a human tester. It then compares actual test results with predicted or expected results. Automated testing offers greater efficiency and faster time-to-market for your projects.

Test Plans: A Test Plan is a detailed document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform testing for a software product

Test Cases: A test case describes the conditions and variables under which a tester will examine if a digital product works correctly in small, comprehensible test steps. It is a set of actions executed to verify a particular feature or functionality of the software application.

Test Scenarios: A Test Scenario is a statement describing the functionality of the application to be tested. It is used for end-to-end testing of a feature and is generally derived from the use cases.

Test Case Documents: A test case document includes test steps, test data, preconditions, and postconditions that verify requirements.

Functional Testing: The purpose of Functional tests is to test each function of the software application, by providing appropriate input, verifying the output against the Functional requirements.

Regression Testing: Regression Testing is nothing but a full or partial selection of already executed test cases that are re-executed to ensure existing functionalities work fine.

White Box Testing: White Box Testing is a software testing technique in which internal structure, design and coding of software are tested to verify the flow of input-output and to improve design, usability, and security.

Black Box Testing: Black Box Testing mainly focuses on the input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing.

Positive Testing: Positive Testing is a testing type that verifies that the application under test is working for a positive set of inputs.

Negative Testing: Negative testing ensures that your application can gracefully handle invalid input or unexpected user behavior.

GUI Testing: GUI Testing is a software testing type that checks the Graphical User Interface of the Software. The purpose of Graphical User Interface (GUI) Testing is to ensure the functionalities of software applications work as per specifications by checking screens and controls like menus, buttons, icons, etc.

Unit Testing: It is a type of software testing where individual units or components of software are tested. The purpose is to validate that each unit of the software code performs as expected. Unit Testing is done during the development (coding phase) of an application by the developers.

User Acceptance Testing: It is a type of testing performed by the end-user or the client to verify/accept the software system before moving the software application to the production environment. UAT is done in the final phase of testing after functional, integration, and system testing are done.

SDLC METHODOLOGIES:

The software development methodology is a process or series of processes used in software development. It is designed to describe how the life cycle of a
piece of software. It is also codified communication.

Waterfall methodology: The Waterfall methodology—also known as the Waterfall model—is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.

Stages in a Waterfall process:
Using a software development project as an example, the Waterfall process usually includes stages that look like this:

Requirements
The Waterfall methodology depends on the belief that all project requirements can be gathered and understood up front. The project manager does their best to get a detailed understanding of the project sponsor’s requirements. Written requirements, usually contained in a single document, are used to describe each stage of the project, including the costs, assumptions, risks, dependencies, success metrics, and timelines for completion.

Design
Here, software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts, and data models. First, a higher-level or logical design is created that describes the purpose and scope of the project, the general traffic flow of each component, and the integration points. Once this is complete, it is transformed into a physical design using specific hardware and software technologies.

Implementation
Once the design is complete, technical implementation starts. This might be the shortest phase of the Waterfall process because painstaking research and design have already been done. In this phase, programmers code applications based on project requirements and specifications, with some testing and implementation taking place as well. If significant changes are required during this stage, may mean going back to the design phase.

Verification or testing
Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software. The testing team will turn to the design documents, personas, and user case scenarios supplied by the product manager to create their test cases.

Deployment and maintenance
Once the software has been deployed in the market or released to customers, the maintenance phase begins. As defects are found and change requests come in from users, a team will be assigned to take care of updates and release new versions of the software.

Agile methodology:

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

SCRUM FRAMEWORK:

Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely used one. A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes.

Product Manager: A product manager is a person who identifies the customer need and the larger business objectives that a product or feature will fulfill, articulate what success looks like for a product and rallies a team to turn that vision into a reality.

The Scrum Team: The Scrum Team shares different tasks and responsibilities related to the delivery of the product. Each role is closely interrelated. It is recommended for Scrum team members to work together in the same location whenever possible. Let’s take a look at each of these roles in terms of their responsibilities, authority, and characteristics.

Product Owner: The PO is the member of the Agile team who serves as the customer proxy responsible for working with Product Management and other stakeholders—including other POs—to define and prioritize stories in the Team Backlog.

Scrum Master: The scrum master helps to keep the team accountable for their commitments to the business and remove any roadblocks that might impede the team’s productivity. The role of a scrum master includes ensuring the process run smoothly, removing obstacles that impact productivity, and organizing the critical events and meeting.’

Development Team: Development Teams are structured well and empowered by the organization to effectively manage their own work.

User Stories: A user story is an informal, general explanation of a software feature written from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.

EPICS: An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users. Epics are an important practice for agile and DevOps teams.

Product Backlog: The product backlog is a container for work you think you will do in the future to keep your product competitive. It is the output of the product owner in collaboration with stakeholders (customers, the team, analysts).

Sprint Backlog: The sprint backlog is a container for work the team is committed to doing, right now as a part of the sprint (typically a one- to four-week period). It is an output of a sprint planning meeting attended by the team.

Release Backlog: The release backlog is an evolving, prioritized queue of business and technical requirements that need to be developed into a system during the release.

Sprint Planning Meeting: Sprint planning is an event in the scrum that kicks off the sprint. The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved.

Sprint Review Meeting: The sprint review is an informal meeting which the development team, the scrum master, the product owner, and the stakeholders will attend. The team gives a demo of the product and will determine what are finished and what aren’t.

Sprint Retrospective Meeting: The sprint retrospective is a recurring meeting held at the end of a sprint used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint.

Daily Scrum Meeting: The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Agile Estimation: Agile estimation is the process for estimating the effort required to complete a prioritized task in the product backlog.

Story points: Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

Planning poker: It is a group estimation technique often used by agile teams to estimate the
amount of effort or relative size of development goals in software development.

T-shirt sizing: T-shirt Sizing is one of the Story points sizing techniques to estimate user story usually used in agile projects. It’s a relative Estimation Technique. Rather than using several planning pokers, here, Items are classified into t-shirt sizes: XS, S, M,
L, XL.

Velocity: Velocity in Agile is a simple calculation measuring units of work completed in a given timeframe. Units of work can be measured in several ways, including engineer hours, user stories, or story points.

Prioritization: Prioritization in literary terms means the decision of arranging things in order of their importance. Prioritization in agile is the act of deciding in what order the agile team will work on the requirements in a project.

Burndown charts: A burndown chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining.

Hope this Business Analysis quick note was helpful. In case of any questions, please reach us here

error: Content is protected !!