Show Menu

What is Business Analysis?

The practice of enabling change in an organi­zat­ional context, by defining needs and recomm­ending solutions that deliver value to stakeh­olders.
discip­lined approach
Business analysts identify and define the solutions that will maximize the value delivered by an organi­zation to its stakeh­olders
Business analysts work across all levels of an organi­zation and may be involved in everything from defining strategy, to creating the enterprise archit­ecture, to taking a leadership role by defining the goals and requir­ements for programs and projects or supporting continuous improv­ement in its technology and processes.
Business Analysis is the set of tasks, knowledge, tools and techniques required to identify business needs and determine solutions to business problems [BABOK]
BA Solutions may include:
Develo­pment of software systems
Develo­pment of software components
Extensions of existing software
Improv­ements to the business process
Changes to the organi­zation

Role of BA in project phases

Supporting implem­ent­ation work in order to ensure developers understand and implement the requir­ements properly
Business Analyst supports the project from the beginning through the system deployment (and sometimes to the system retire­ment).
Supporting testing, for example by validating test cases in order to ensure that testing will adequately cover all the requir­ements
Analyzing and docume­nting change requests for the requir­ements
Processing new requir­ements (new regula­tions, standards, etc.)
Processing the requests to fulfill new needs requested by the customer or user

What is an artefact?

Final or interm­ediate work products that are produced and used during a project
Might describe the function, archit­ecture, and design of software
Might be concerned with the process of develo­pment itself, such as project plans, business cases and risk assess­ments
Should use version control
Should be correctly traced to their origin

What is a Business Goal?

A Business Goal is a short- or long-term objective of an organi­zation. Business Goals should be charac­terized by the following qualities
Both short- and long-term scope
Setting Business Goals is important because:
The organi­zation needs to have a vision of what it wants to accomp­lish. This is facili­tated by having clearly stated goals, along with establ­ishing time periods in which they need to be achieved
It keeps a clear picture of what the organi­zation is trying to do with the business, and helps focus motivation
It allows the organi­zation to understand and maintain a commitment to the business’ main objectives
It provides a metric against which to measure the organi­zat­ion’s progress
SMART is a system and a tool that is used to establish goals and define their quality object­ives. SMART requires that all goals have the following charac­ter­istics

What is a requir­ement?

A condition or capability needed by a stakeh­older to solve a problem, or achieve an objective.
A condition or capability that must be met or possessed by a system or system component, to satisfy a contract, standard, specif­ica­tion, or other formally imposed documents
A documented repres­ent­ation of a condition or capability
Requir­ements are the foundation of systems, or system compon­ents. They can be obligatory (required functions, constr­aints, etc.), essential for the software to perform its functions, and meet the expect­ations and needs of the intended stakeh­olders
Requir­ements should be placed into one of the following categories
Business requir­ements
User requir­ements
Functional requir­ements
Non-fu­nct­ional requir­ements
Purpose of requir­ements:
Provide a foundation for assess­ment, planning, execution and monitoring of the project activities
Define customer expect­ations (expressed as real requir­ements and stakeh­older’s value of those requir­ements)
Serve as a component of agreem­ents, orders, project plans
Establish system bounda­ries, scope of delivery, and the services classi­fic­ation of the requir­ements
Requir­ement classi­fic­ations
Process requir­ements
describe needs and limita­tions of the business processes
Processing time
Sales and distri­bution
Product requir­ements
functional and non-fu­nct­ional product requir­ements
POV of customer and team
Types of requir­ement
Customer requir­ements
Solution or system requir­ements
Product or component requir­ements

Requir­ement Analysis

Elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeh­olders
Task: Organize Requir­ements
Structure and organize a set of requir­ements into logical sets. The organi­zation may be based on defining multiple “levels” of requir­ements, packaging related functions together, and so forth.
Inputs: Business Case, Solution Scope, Requir­ements
Outputs: Structured requir­ements
Task: Prioritize Requir­ements
Determine the business priority of requir­ements (including voting, ranking, benefit analysis and so forth). Identify logical depend­encies between requir­ements and requir­ements packages.
Inputs: Requir­ements, Business Case
Outputs: Priori­tized requir­ements
Task: Specify and Model Requir­ements
Describes standard practices for writing textual requir­ements and creating models or diagrams. Specific models are addressed as techni­ques. Includes capturing the requir­ements attributes
Inputs: Requir­ements
Outputs: Specified or modeled Requir­ements
Task: Determine Assump­tions and Constr­aints
Identify stakeh­older requests that are not properly requir­ements but based on assump­tions regarding what the solution team is capable of delivering
Capture and assess these requests
Outputs: Assump­tions and Constr­aints
Task: Verify Requir­ements
Outputs: Verified requir­ements
Task: Validate Requir­ements
Validate that a requir­ement will satisfy a business need.
Outputs: Validated requir­ements


Business Requir­ements Elicit­ation is defined as a set of approa­ches, techni­ques, activi­ties, and tasks used to capture the business requir­ements of a planned solution from the stakeh­olders and other available sources [
Purpose: Explore, identify and document stakeh­older needs. Orienting the requir­ements toward the project vision. Excluding features that the customer does not want and need
Describes how we work with stakeh­olders to find out what their needs are and ensure that we have correctly and completely understood their needs.
Task: Prepare for Elicit­ation
Purpose: Prepare for elicit­ation by ensuring all needed resources are organised and scheduled for conducting the elicit­ation activities
Scheduled resources
Supporting materials
Task: Conduct Elicit­ation
Meet with stakeh­old­er(s) to elicit inform­ation regarding their needs
Elicit­ation activity results
Assump­tions, constr­aints, risks, issues
Docume­ntation based on technique (e.g., interview notes, workshop results, survey responses, etc.)
Task: Document Elicit­ation Results
Purpose: Record stakeh­older info for use in analysis.
Outputs: Stated requir­ements
Task: Confirm Elicit­ation Results
Purpose: Play back the requir­ements to validate that the stakeh­older’s intentions have been correctly captured and unders­tood.
Outputs: Validated stated requir­ements
Reviewing existing documents
Reusing a specif­ication from a previous project
Field observ­ation
Conducting workshops to refine the requir­ements after each iteration
Requir­ements Elicit­ation should apply to enterprise requir­ements as well as user or customer requir­ements.
Requir­ement charac­ter­istics

What is a stakeh­older

Any person involved in, or with an interest in, a project
Stakeh­olders on the vendor side
Project Managers
Business and System Analysts
Developers and Architects
Database designers
GUI designers
Technical writers
Testers and Quality Assurance staff
Instal­lation and Operations personnel
Stakeh­olders on the customer side
Customer repres­ent­atives (i.e., “Busin­ess”)
Project sponsors
End users (from the customer company)
Instal­lation and Operations personnel
External stakeh­olders may be:
End users who are not a part of the customer’s organi­zation
Other organi­zations (e.g., regulatory entities)

Stakeh­older Identi­fic­ation Problems

A lack of unders­tanding of the real operators of the business processes in the organi­zation
Unclear definition of respon­sib­ilities within the customer’s organi­zation
Excluding stakeh­olders who are not clearly and directly related to the process
Incomplete analysis resulting in missing processes and activi­ties, and the related stakeh­olders

Business Analysis Commun­ication Planning

The main purpose of planning the Business Analysis commun­ication is to define how to receive, distri­bute, access, update and escalate inform­ation to and from the project stakeh­olders, as well as how to organize the schedule and structure of the commun­ication within a project.
Business Analysis is the starting point for designing and implem­enting a software solution. Its delive­rables are inputs to many other project phases and processes, such as establ­ishing the system archit­ecture that will allow meeting the business goals, creating detailed functional and non-fu­nct­ional system specif­ica­tions, and planning and executing QA activi­ties.
Outputs from the Business Analysis are also inputs to system acceptance testing, which is the final check before the production release.
System acceptance testing is conducted to verify that the software is working as expected, and is needed in order to realize its goals (i.e., improving efficiency of performing the business process
BA provides info to the following
Project management (scope planning, schedu­ling, and estimating develo­pment and testing)
Systems analysis
Design (system specif­ication and archit­ecture)
Common methods of commun­ication include:
Factors to be Considered
Type of project
Commun­ication formality
Commun­ication frequency
Geogra­phical location

Common BA techniques

CATWOE (Clients, Actors, Transf­orm­ation, Worldview, Owner, Enviro­nmental constr­aints)
Data Flow Diagrams
Five Why’s
Functional decomp­osition
PESTLE (P for Political, E for Economic, S for Social, T for Techno­log­ical, L for Legal and E for Enviro­nme­ntal)
MOST (Mission, Object­ives, Strate­gies, Tactics)
Requir­ements Workshops
Risk Analysis
Scenarios and Use Cases
User stories

Principles for Successful Requir­ements

Understand the top level critical objectives
Think stakeh­olders, not just users and customers
Focus on the required system quality, not just its functi­onality
Quantify quality requir­ements as a basis for software engine­ering.
Don’t mix ends and means
Capture explicit inform­ation about value.
Ensure there is “rich specif­ica­tion”; requir­ement specif­ica­tions need much more inform­ation than just the requir­ement itself.
Carry out specif­ication quality control (SQC).
Consider the total lifecycle and apply system­s-t­hin­king, not just a focus on software
Recognize that requir­ements change; use feedback and update requir­ements as necessary.

Acceptance and Evaluation Criteria

Acceptance criteria are used to define the requir­ements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeh­olders. Evaluation criteria are the measures used to assess a set of requir­ements in order to choose between multiple solutions
Define measures of value attributes to be used for assessing and comparing solutions and altern­ative designs
Measurable and testable criteria allow for the objective and consistent assessment of solutions and designs
Acceptance criteria describe the minimum set of requir­ements that must be met in order for a particular solution to be worth implem­enting. They may be used to determine if a solution or solution component can meet a requir­ement.
Acceptance criteria are typically used when only one possible solution is being evaluated, and are generally expressed as a pass or fail
Valuation criteria define a set of measur­ements which allow for ranking of solutions and altern­ative designs according to their value for stakeh­olders.
Attributes that cannot be measured directly are evaluated using expert judgment or various scoring technique
~ Value attributes ~
are the charac­ter­istics of a solution that determine or substa­ntially influence its value for stakeh­olders
represent a meaningful and agreed­-upon decomp­osition of the value propos­ition into its consti­tuent parts, which can be described as qualities that the solution should either possess or avoid
ability to provide specific inform­ation
ability to perform or support specific operations
perfor­mance and respon­siv­eness charac­ter­istics
applic­ability of the solution in specific situations and contexts
availa­bility of specific features and capabi­lities
usability, security, scalab­ility, and reliab­ility
~ Assessment ~
In order to assess a solution against acceptance or evaluation criteria, it must be constr­ucted in a measurable format
Evaluation criteria provide a way to determine if features provide the value necessary to satisfy stakeh­­older needs.
The criteria are presented as parameters that can be measured against a continuous or discrete scale.
Acceptance criteria are expressed in a testable form
Acceptance criteria are presented in the form of statements which can be verified as true or false. This is often achieved through user acceptance testing (UAT)
Usage Consid­era­tions
Agile method­ologies may require that all requir­ements be expressed in the form of testable acceptance criteria
Acceptance criteria are necessary when the requir­ements express contra­ctual obliga­tions
Acceptance criteria provide the ability to assess requir­ements based on agreed­-upon criteria
Evaluation criteria provide the ability to assess diverse needs based on agreed­-upon criteria, such as features, common indica­tors, local or global benchm­arks, and agreed ratios
Evaluation criteria assist in the delivery of expected return on investment (ROI) or otherwise specified potential value
Evaluation criteria helps in defining priorities
Acceptance criteria may express contra­ctual obliga­tions and as such may be difficult to change for legal or political reasons
Achieving agreement on evaluation criteria for different needs among diverse stakeh­olders can be challe­nging.

What is a business analyst?

A person respon­sible for:
identi­fying the business needs of the customer (external or internal) and other stakeh­olders
determ­ining solutions to business problems
BA activities include identi­fying, analyzing, developing and managing the requir­ements.
Business Analyst is not respon­sible for determ­ining the solution implem­ent­ation (creating the product’s design)
The Business Analyst acts as a bridge between the customer and other stakeh­olders (e.g., the project team), identi­fying, negoti­ating and achieving a consensus between the needs of the various repres­ent­ative indivi­duals and groups.

Why is Business Analysis Necessary?

Problems with requir­ements can cause projects to fail. In most cases those problems are caused by poor or incorr­ectly conducted Business Analysis (espec­ially Requir­ements Engine­ering, a part of the Business Analysis knowledge area).
Common problems
Ambiguous, under-­spe­cified, unclear, imposs­ible, contra­dictory business requir­ements
Instab­ility of the requir­ements (frequent and uncont­rolled changes in requir­ements)
Poor transl­ation of the business needs to requir­ements (incom­plete, incons­istent, or not measurable requir­ements)
Unclear objectives of the initiative
Commun­ication problems
Language barriers
Knowledge barriers
Vague wording
Overly formal wording
Gold plating (adding unnece­ssary scope)
Insuff­icient user involv­ement
Overlooked user classes
Minimal specif­ication
Conseq­uences of low quality BA
Problems during during scope definition
Planning diffic­ulties
Implem­ent­ation problems
Testing problems
Unclear requir­ements, or low quality business design of the solution, can lead to confusion and questions regarding the intended software product or process solution
risk of the project’s failure increases
Requir­ements are imprecise
Requir­ements are ambiguous
Requir­ements are contra­dictory
Requir­ements do not fulfill the agreed criteria
Requir­ements are missing
Business processes and artifacts are not covered by requir­ements or are described incomp­letely
All stakeh­olders are not identified
Business goals or needs are not identified causing the designed solution to fail to meet the organi­zat­ion’s needs and not achieve the business goals
Common reasons for neglecting BA
Time pressure
Exclusive focus on fast results
Exclusive fixation on costs
Perceiving docume­ntation or the analysis and unders­tanding of the business processes within an organi­zation as a cost, not an added value

Requir­ements Elicit­ation

Requir­ements Elicit­ation is the collection of activi­ties, approa­ches, tools and techniques for capturing the requir­ements for a planned software system (or other business solution) from the stakeh­olders\


Tracea­bility is an associ­ation that exists between different types of requir­ements and the following items:
Requir­ements (mapping the higher level requir­ements that defined the needs and features to the more detailed requir­ements)
Detailed requir­ements to design models
Detailed requir­ements to test cases
High level requir­ements to test cases
Requir­ements to releas­e/code branch­/ve­rsion
Allows BA to ensure all business requir­ements have been met.
Important from the change management perspe­ctive, to determine the impact of a change on the system or process
For the testers and develo­pers, tracea­bility ensures that the requir­ements coverage has been achieved

What is Enterprise Analysis?

Purpose: Identify and propose projects that meet strategic needs and goals.
Task: Identi­fying business processes performed in the organi­zation
Purpose: Evaluate the internal and external enviro­nment
Conducting feasib­ility studies to determine the optimum business solution
Define­/refine curren­t/f­uture business archit­ecture
Assess the current state of technology (infra­str­ucture and applic­ations)
Benchmark analysis
Compet­itive studies
Fully define business proble­m/o­ppo­rtunity
Output: Defined Proble­m/O­ppo­rtunity
Task: Determine Solution Approach
Identify potential solutions
Analyze feasib­ility of options
Recommend viable business solution
Validate with decision makers
Output: Solution Approach
Task: Define Solution Scope
Projects inevitably struggle at some point or the other if the scope is not defined properly
Solution scope may be determined using the following techniques
Work Breakdown Structure (WBS) - a decomp­osition of the work that is required to complete a project, and accomplish the business objectives
Product Breakdown Structure (PBS) - a decomp­osition of the components of the product
System Interface Analysis - a definition of the work required to integrate the new solution into the existing business and technical enviro­nments
Context diagram
Product Breakdown Structure
Output: Solution Scope
Task: Develop the Business Case
Define project objectives and expected business benefits
Develop project scope
Estimate time, cost, resources
Analyze cost vs. benefit
Evaluate risk
Inputs: Business Archit­ecture, Business Goal(s), Defined Business Proble­m/O­ppo­rtunity Solution Scope
Outputs: Business Case

Solution Assessment and Validation

How to assess proposed solutions to determine which solution best fits the business need, identify gaps and shortc­omings in solutions, and determine necessary workar­ounds or changes to the solution
How we assess deployed solutions to see how well they met the original need in order to enable businesses to assess the perfor­mance and effect­iveness of projects.
Purpose: Assess solutions to ensure that strategic goals are met and requir­ements are satisfied.
Task: Assess Requir­ements Coverage
Purpose: Determine how well possible options for solution designs will meet the requir­ements. The assessment may include a recomm­end­ation of a particular solution, rejection of all solutions, or an assessment of possible trade-­offs.
Examples: RFI/RFP responses, Internal designs, Manual procedures
Inputs: Solution Design Option(s)
Outputs: Solution Design Assessment
Task: Allocate Requir­ements
Purpose: Allocate requir­ements among releases and/or solutions compon­ents. Ensures that the possible release options are designed in a way to maximize the possible business value given the options and altern­atives generated by the design team.
Allocate requir­ements to hardware, software, manual proced­ures, etc.
Recommend the releas­e/d­elivery strategy
Understand trade-offs between different implem­ent­ation approaches
Inputs: Solution Design, Validated Requir­ements
Outputs: Allocated Requir­ements
Task: Determine Organi­zat­ional Readiness
Determine organi­zat­ional readiness to effect­ively operate the new solution
Conduct organi­zat­ional readiness assessment
Recommend ways to optimize the organi­zat­ional deployment
Outputs: Organi­zat­ional Readiness Assess­ment, Organi­zat­ional Change Recomm­end­ations
Task: Validate Solution
Validate the verified and deployed solution meets the business need
Define acceptance criteria (including what level of confor­mance to requir­ements is accept­able)
Identify defect­s/s­hor­tco­mings (this should be distin­guished from functional testing)
Analyze impact
Define corrective actions
Validate corrective actions
When a problem is identified with the deployed solution determine what is the most approp­riate response
Outputs: Validated Solution, Defect Impact Analysis, Validated Correc­tive, Actions
Task: Evaluate Solution
Assess the value of the solution as deployed to the business (to determine if the original goals are met).
Compare actual vs. expected costs and benefits.
Outputs: Cost/B­enefit Analysis

Stakeh­older Identi­fic­ation Techniques

Invest­igating the business domain
Identi­fying owners of the business processes
Analyzing the structure of the customer’s organi­zation
Exploring the target market of the customer’s organi­zation
Analyzing relati­onships with external organi­zations (suppl­iers, etc.)

Stakeh­older Needs and Expect­ations

Different stakeh­olders may have different needs and expect­ations regarding the planned solution. It is very important to identify all the stakeh­olders and their needs, and to find a common unders­tanding of the purpose of a solution, in order to avoid the situation where the final product may meet the requir­ements of only a selected group of stakeh­olders.
Ensure that the features to be implem­ented will not conflict with the requir­ement of other stakeh­olders
One of the respon­sib­ilities of a Business Analyst is to identify all the stakeh­olders and define their requir­ements and expect­ations
Determines the initial scope and requir­ements of the system

Business Case Definition

Provides the reasoning for initiating a project
Describes a justif­ication for the project in terms of the value added to the business as a result of the project outcomes, in comparison to the cost of developing the new solution
May be in form of
Structured document
Short argument
Topics may include
Inform­ation about the opport­unity (market trends, compet­itors)
Qualit­ative and quanti­tative benefits
Estimates of cost and time to breakeven
Profit expect­ations
Follow-on opport­unities
Cash flow conseq­uences of the action, over time, and the methods used for quanti­fying benefits and costs
The impact of the proposed project on the business operations or business process
The impact of the proposed project on the technology infras­tru­cture
Constr­aints associated with the proposed project
Estimated budget
Alignment with priorities establ­ished by the business
Procedure of Building the Business Case
Identify and quantify the benefits
Identify and quantify the costs
Prepare the Business Case
Define the procedures that will be used to measure the costs and benefits

Requir­ements Docume­ntation

Follow common standards and guidelines
Important guidelines
Each requir­ement must be unambi­guous, precise, and unders­tan­dable
Superf­luous inform­ation should be avoided
Templates should be used as an aid
Models and diagrams should be used to make the specif­ication document clear and more unders­tan­dable for readers.
Formal graphical notation should be used as a method for presenting complex requir­ements, depend­encies, and relati­onships
A requir­ements document may include
Secrecy clause
Purpose of the product
Overall descri­ption
Functional requir­ements
Non-fu­nct­ional requir­ements
Limita­tions and assump­tions
Safety requir­ements
Document acceptance
When creating a requir­ements document, the Business Analyst should remember that requir­ements specif­ica­tions must be complete, consis­tent, modifi­able, and traceable [Wiegers].
Common Mistakes
Trivia­lities - Lengthy descri­ptions of commonly known issues should not be included
Inform­ation out of scope
Thinking in solutions - The requir­ements specif­ication should discuss the problem to be solved not the technical design of the solution
Redundant details
Lacking rationale


Modeling is a way of expressing requir­ements by repres­enting parts, or the whole, of the proposed solutions
Way of presenting complex requir­ements and relati­onships in the form of a model, especially some graphical form such as diagrams, helps ensure the solution is understood by other stakeh­olders
Easier to read and comprehend than written text
Not mandatory but very helpful in big projects
Can skip modeling in the following situations
The solution is fully understood by the stakeh­olders and is easy to implement.
The requir­ements are mostly non-fu­nct­ional and difficult to express in the form of a model
The problem domain is well known
The solution is dedicated to use by very few people
The scope is declared as constant and there is a low probab­ility of changes in the scope resulting from future requir­ements or needs.
model repres­ent­ation would be less unders­tan­dable by the key stakeh­olders than written text
Benefits of modeling
simplified expression of real processes
describe a complex system in the most clear and unambi­guous way.
Models present the whole system and its context in a single diagram and therefore help to look at the problem from the overall perspe­ctive.
Common techniques
UML notation to express requir­ements as use case diagrams, activity diagrams, component diagrams, state machine diagrams, etc.
Using protot­yping as a technique of GUI modeling
Using SysML notation to develop specif­ica­tions, analysis, design, verifi­cation and validation docume­ntation for systems and system­s-o­f-s­ystems. The specif­ica­tions may include hardware, software, inform­ation, processes, personnel and facili­ties.
Quality criteria for business process models
Correc­tness (syntactic and semantic correc­tness)
Relevance (no irrelevant details)
Economic efficiency (designed for a particular purpose)
Clarity (under­sta­ndable by the audience)
Compar­ability (based on the same modeling conven­tions within and between models)
Systematic design (contains well-d­efined interfaces to other types of models)

Domain Knowledge

The goal of a Business Analyst is to provide business solutions to business issues by assessing business problems, and identi­fying and analyzing root causes.
The success of Business Analysis is determined by the benefit that the solution provides to the business either in terms of savings in costs, improv­ement in produc­tivity, and/or increase in customer satisf­action.
To be able to provide a business solution that provides a measurable benefit to the organi­zation, the Business Analyst must have knowledge of the business domain.
Domain knowledge makes it easier for the Business Analyst to connect and commun­icate with Business Users.
Domain knowledge makes unders­tanding and analyzing business issues easier
Lack of domain knowledge may lead to delays in providing the solution, since the business process and business rules must first be understood

Tools and Techniques of Facili­tation

Applying engagement strategies
Creating partic­ipation
Generating and organizing data
Initiating reflection
Mobilizing energy
Igniting action
Recording inform­ation
Applying SWOT analysis
Gap analysis
Root cause analysis
Managing conflicts tips sheet
Focus group framework

Process Improv­ement

Process Improv­ement supports the introd­uction of change into the current process in order to improve quality, reduce costs and/or accelerate schedules
Supporting Process Improv­ement is one of the tasks of a Business Analyst.
The Business Analyst models and analyzes business processes used within an organi­zation in order to discover any ineffe­ctive elements.
Manually re-design processes on the basis of experience and domain knowledge with the goal of elimin­ating bottle­necks and making the execution times shorter and more efficient
Introduce tools, including software, to optimize the business processes in the organi­zation (e.g., SAP, ERP, CRM software)
Simulate and optimize processes
Adopt a selected method­ology or strategy
Business process improv­ement
Business process reengi­neering
Capability Maturity Model Integr­ati­on/­Cap­ability Maturity Model (CMMI/CMM)
ISO 9000
IT Governance
Just In Time manufa­cturing
Lean manufa­cturing
Perfor­mance improv­ement
Process management
Process Improv­ement and Management (PI&M)
Six Sigma
Total Quality Management (TQM)

BA Knowledge Areas

Business Analysis Planning and Monitoring (Orange)
Enterprise Analysis (Dark Green)
Elicit­ation (Light blue)
Requir­ement Analysis (light pink)
Solution Assessment and Validation
Requir­ements Management and Commun­ication

Common Objectives of Business Analysis

Collect and document the requir­ements
Design business solutions to resolve the business problems
Assist in the timely completion of the project by providing accurate requir­ements identi­fic­ation and analysis
Improve efficiency by increasing the quality of requir­ements identi­fic­ation and analysis and therefore reducing the need for rework and fixes in the later stages of the project

Business Analysis influences other project areas

Signif­icant impact on project management (espec­ially scope and time manage­ment)
Design – Business Analysis determines the required business archit­ecture and scope of the solution
Develo­pment – The Systems Analyst (who determines detailed requir­ement specif­ica­tions) uses the Business Analysis to determine what has to be implem­ented.
Testing and other Quality Assurance activities – Products of Business and Systems Analysis are a basis for testing

Business needs

A Business Need describes the business problem or opport­unity which the Business Analyst must understand and analyze in order to recommend approp­riate solutions
before a project starts, the Business Need (under­stood as a problem or an opport­unity) and Business Case (under­stood as costs vs. benefits) are defined, either formally or inform­ally.
for the projects that help the organi­zation reach its vision, strategic goals, and business object­ives.
Business Analysts are often supported by Project Managers and Product Managers in defining Business Needs
One of the respon­sib­ilities of a Business Analyst is to cooperate with the person or group requesting the project, including users or proxy users, and to help them articulate the real need.

What is a business process?

set of activities aimed at producing a specific output for a particular customer or market.
focuses on how the work is done within an organi­zation, the way of organizing work, activi­ties, relati­onships and the depend­encies between them. A process can be considered as the ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs [
A business process must have the following charac­ter­istics
Has a goal
Has specific inputs
Has specific outputs
Uses resources
Has a number of activities that are performed in some order
Affects at least one organi­sat­ional unit
Creates value for the customer (both internal and external)
Identi­fic­ation of processes allows the Business Analyst to understand the organi­zat­ion’s goals,
Helps determine the activities and the flow required to achieve future planned business and strategic goals
Identi­fic­ation of business processes helps find possible gaps and ineffe­ctive parts of the process, which may then be improved via process optimi­sation
If business processes are not establ­ished and unders­tood, then the organi­zation may have a low maturity level, which makes measuring and contro­lling processes very difficult. In addition, there are likely to be signif­icant problems with the definition of the business goals and needs.

BA in Phases of the Software Life Cycle

Analysis phase
Identi­fying and evaluating the current business processes in an organi­zation (“as is” analysis)
Gathering initial requir­ements for the needed business solution (“to be” analysis)
Creating and analyzing the business case
Conducting a feasib­ility study
Preparing ideas for the business solution
Specif­ication phase
Identi­fying and docume­nting business requir­ements on a more detailed level
Supporting the Systems Analyst in preparing the detailed system specif­ica­tions (e.g., covering such items as data, mapping, integr­ation issues, user interf­aces)
Validating the proposed software design with the customer and other stakeh­olders
Managing any requir­ements changes
Develo­pment phase
Supporting the develo­pment team during implem­ent­ation (e.g., clarifying issues related to the requir­ements, validating business rules to be applied in the code)
Validating the evolving solution according to the intended requir­ements and needs (when possible)
Supporting testers in preparing test cases and test scripts at the business level and validating the resulting work products
Managing any required changes to the requir­ements (resulting from detected defects, regulatory or legal changes, needs for new or extended functi­ona­lity, etc.)
Testing phase
BA role varies
verifying test results
resolving issues related to defects or gaps in the requir­ements
Partic­ipating in the prepar­ation of test cases for User Acceptance Testing
Supporting the acceptance testers by answering questions during test execution

BA Planning and Monitoring

The parameters which are defined and set during the planning phase should retain their validity throughout the project phases and it becomes the respon­sib­ility of the business analyst to perform the activities classified under this knowledge area precisely.
Identify the stakeh­olders
Identify stakeh­olders who may be impacted by a proposed initiative or who share a common business need.
determ­ining approp­riate stakeh­olders for the project or project phase, and analyzing stakeh­older influence, authority (approve, sign off, veto), and project attitude.
Outputs: Stakeh­older list, Stakeh­older roles and respon­sib­ility design­ation
RACI matrix (also known as RASCI matrix) plays very important role in this process.
Scope of the tasks and the dependency can be defined easily
estimates related to cost, timings and resources
Commun­ication Planning
Determine what inform­ation the various stakeh­olders need to be provided about the results of business analysis and the forms it should take (verbal, written, etc). It includes consid­era­tions for, as well as constr­aints, impacts, durability and trade-offs of different commun­ica­tions media
Commun­ication plays very important role in any stage of project life-cycle and in order to avoid ambiguity or conflicts in the requir­ements and end results, the commun­ication should be precise and contro­lled.
Each stakeh­older should understand the details of the requir­ements
WHAT, WHO and WHEN are the important questions related to commun­ication
Monitoring BA work
metrics that can be used for monitoring business analysis work are determ­ined.
helps in improving future business analysis plans
perfor­mance measures, reporting and corrective actions
Plan Business Analysis Activities
Determine which activities are required to define the solution to a business problem, how those activities will be carried out, the work effort involved, and an estimate of how long the activities will take.
Determine tasks in the Knowledge Areas:
Identifies task depend­encies
Develop estimates for BA work (time, skill level, complexity of tasks, etc.)
Inputs: Stakeh­older list, Stakeh­older roles and respon­sib­ility design­ation, Organi­zat­ional Standards
Outputs: Business Analysis Plans for each KA
Plan Requir­ements Management Process
Describes how to determine the approp­riate requir­ements process for a particular initiative
Consider whether and how requir­ements are changed
Which stakeh­olders need to approve
Who will be consulted on, or informed of changes,
includes the approach to requir­ements tracea­bility and determ­ining which requir­ements attributes we will capture
Output: Requir­ements Management Plan
RASCI: R- Respon­sible (does the work), A- Accoun­table (decision maker, only one), S- Support (provides support during any phase of lifecy­cle), C- Consulted (consulted prior to the work and provides input), I- Informed (informed about the work progress).

Requir­ements Management and Commun­ication

How we manage conflicts, issues and changes and ensure that stakeh­olders and the project team remain in agreement on the solution scope
Recognise that commun­ication takes places throughout all knowledge areas and is important for managing requir­ements
Manage the approved solution and requir­ements scope
Ensure stakeh­olders have access to business analysis work products
Prepare and commun­icate requir­ements to stakeh­olders
Task: Manage Solution and Requir­ements Scope
Baseline and manage changes to business case, solution and requir­ements
Approve requir­ements (according to the approval authority stated in the Requir­ements Management Plan)
Control multiple versions of requir­ements work products
Manage requir­ements conflicts and issues
Inputs: Stakeh­older roles and respon­sib­ility design­ation, Requir­ements, Requir­ements management plan
Outputs: Approved Requir­ements, Decision Record
Task: Manage Requir­ements Tracea­bility
Trace requir­ements (update and mainta­ining relati­onships between requir­ements compon­ents)
Perform impact analysis when changes are requested and supply this inform­ation to the change control process
Support the allocation of requir­ements to the solution in Solution Assessment and Valida­tion.
Outputs: Traced Requir­ements
Tasks: Maintain Requir­ements for re-use
Select which implem­ented requir­ements will be maintained after solution implem­ent­ation
Name the respon­sible party who will maintain the requir­ements
Facilitate ongoing use of requir­ements for impact analysis and solution mainte­nance
Facilitate re-use of requir­ements on related projects to encourage enterprise consis­tency of business models
Inputs: Implem­ented requir­ements
Outputs: Mainta­ine­d/r­e-used requir­ements
Task: Prepare Requir­ements Package
Determine approp­riate format for requir­ements, Create a requir­ements package
Outputs: Requir­ements package (e.g., executive summary, formal docume­nta­tion, RFI, RFP, etc.)
Task: Commun­icate requir­ements
Intera­ction with all stakeh­olders before, during and after projects.
Intera­ction with solution team to assure that requir­ements are correctly understood and implem­ented

Change Management process

Identi­fying a potential change
Requesting new functi­onality
Analyzing the change request
Evaluating the change
Planning the change
Implem­enting the change
Reviewing and closing the change request
Potential changes might be a result of:
A defect found in the code, docume­ntation or requir­ements
System improv­ement efforts
External changes (regul­atory, legal, etc.)
New or changing requir­ements (resulting from new regula­tions, changes within the business domain, new features requested by the users, etc.)
Business process improv­ement initia­tives
Change Request
When the need for a change appears, there should be a Change Request raised by a stakeh­older requesting new or modified functi­ona­lity. Important elements of a change request are a unique identi­fier, the author, the deadline (if applic­able), an indication whether the change is required or optional, the change type, and an abstract, or descri­ption, of the proposed change
All changes should be tracked in a Change Log or Change List
Changes should be managed by the Change Control Board (CCB). The CCB is not allowed to submit, approve, reject, or implement changes without discussion with the other stakeh­olders.
may have signif­icant impact on other elements of the system, such as compon­ents, interf­aces, functi­ona­lity, etc.
Impact analysis should be performed
Impact analysis includes analysis of the changes needed in the project schedule or budget that would be necess­itated if the change were to be implem­ented
The planning of change implem­ent­ation includes:
Updating plans as needed depending on the phase of the project (e.g., Project Plan, Develo­pment Plan, and Test Plan)
Updating business and system docume­ntation (e.g., specif­ica­tions, archit­ecture design, user manuals)
Updating test cases and test scripts
Implem­enting the change (coding)
Testing by vendor or/and customer test team
Deploying the change to the production enviro­nment

Requir­ements Organi­zation

Requir­ements can be organized (struc­tured) into packages. This packaging conforms to the boundaries (limit­ations) and solution scope establ­ished during Enterprise Analysis and helps to further define those boundaries
BA decomposes the problem model to make each requir­ement more detailed
Ensure that the model correctly reflects the boundaries for the business problem
Ensure proper level of detail is achieved
Types of decomp­osition
Goal decomp­osition
Goals are business requir­ements
Goal decomp­osition helps to ensure the solution will satisfy stakeh­older’s needs
Feature list decomp­osition
A feature is a service that the solution provides to fulfill one or more stakeh­older need
an abstra­ction of the solution of the problem expressed at a high-level
A feature is developed into completely described functional and supple­mental requir­ements
Functional decomp­osition
breakdown of a list of items into classi­fic­ations or groups based on the function each item performs or the use it provides
identifies the high-level functions of the proposed solution, or the organi­zation itself, and then breaks them down into sub-pr­ocesses and activi­ties.
usually performed by a Systems Analyst

Quality Assurance

Quality Assurance is a process of systematic monitoring and evaluation of the various aspects of a project or solution. The goal is to maximize the probab­ility that the solution has achieved a desired standard of quality
Quality Criteria for Requir­ements
Does not determine solution
One of the most common techniques for requir­ements’ quality control is the use of checkl­ists.

Acceptance and Evaluation Criteria

BA necessary skills

Analytical skills
Financial analysis
Statis­tical analysis
Operations research
Requir­ements analysis
Systems analysis
Technical skills
Working knowledge of technology
Unders­tanding of engine­ering principles
Ability to apply financial principles to feasib­ility studies
Managerial skills
Project management capabi­lities
Unders­tanding of organi­zat­ional behavior
Soft skills
Negoti­ation skills
Ability to negotiate to obtain data
Ability to negotiate with stakeh­olders to implement projects
Commun­ication and writing skills
Ability to commun­icate with all levels of management
Ability to commun­icate with stakeh­olders of various knowledge levels
Precision in articu­lating ideas and thoughts
Ability to relate with line workers
Good technical writing skills
Strong commun­ication skills in all forms (verbal, non-ve­rbal, written, etc.)
Public speaking skills
Facili­tation skills
Facili­tation can be defined as a process of enabling groups to work cooper­atively and effect­ively. Facili­tation provides leadership
Facili­tation serves to improve the following skills
Solving issues
Building team and community
Resolving conflicts
Evoking wise democracy
Building personal effect­iveness
facili­tator is a person who contri­butes structure and process to intera­ctions so that groups are able to function effect­ively and make high-q­uality decisions. The facili­tator’s goal is to support others and enable them to achieve high perfor­mance
Tasks and activities
Helping the group to define its goals and objectives
Providing processes to support members of the group to help them use their time effect­ively and to make high-q­uality decisions
Guiding group discus­sions to ensure objectives are met, and noting any ideas and concepts raised by members during the discussion
Supporting members of the group in assessing their current skills and building new skills
Using consensus to enable the group to make decisions
Managing conflicts using a collab­orative approach
Helping the group to commun­icate effect­ively and to access resources needed to make decisions
The facili­tator must always stay neutral, listen actively and ask questions that allow the group to identify and collect ideas and concepts. One of the facili­tator’s tasks is to note and summarize all ideas raised by the members of the group.
Facili­tator compet­ancies
Commun­icates well
Processes ideas from people
Shows a natural interest
Listens well
Maintains control
Empowers the group
Handles uncert­ainty
Connects with the group quickly
Focuses on the business not on personal solutions
Negotiates between parties
Unders­tands group dynamics
Helps the group to listen and draw logical conclu­sions
Runs meetings
Manages people’s expect­ations
Unders­tands and explains the process


thanks, very useful cheat sheet

I cannot seem to download the PDF version of this cheat sheet. Please advise.

The cheat sheet looks really good.

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          System Design Cheat Sheet

          More Cheat Sheets by NatalieMoore