Business Analysis Cheat Sheet by NatalieMoore

The practice of enabling change in an organi­zat­ional context, by defining needs and recomm­ending solutions that deliver value to stakeh­olders.

Business analysts identify and define the solutions that will maximize the value delivered by an organi­zation to its stakeh­olders

Business Analysis is the set of tasks, knowledge, tools and techniques required to identify business needs and determine solutions to business problems [BABOK]

-

Develo­pment of software systems

-

Extensions of existing software

-

Changes to the organi­zation

Supporting implem­ent­ation work in order to ensure developers understand and implement the requir­ements properly

Supporting testing, for example by validating test cases in order to ensure that testing will adequately cover all the requir­ements

Processing new requir­ements (new regula­tions, standards, etc.)

Final or interm­ediate work products that are produced and used during a project

Might be concerned with the process of develo­pment itself, such as project plans, business cases and risk assess­ments

Should be correctly traced to their origin

A Business Goal is a short- or long-term objective of an organi­zation. Business Goals should be charac­terized by the following qualities

-

Optimism

-

Both short- and long-term scope

-

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 allows the organi­zation to understand and maintain a commitment to the business’ main objectives

SMART

-

Specific

-

Attainable

-

Timely

A condition or capability needed by a stakeh­older to solve a problem, or achieve an objective.

A documented repres­ent­ation of a condition or capability

Requir­ements should be placed into one of the following categories

-

User requir­ements

-

Non-fu­nct­ional requir­ements

-

Provide a foundation for assess­ment, planning, execution and monitoring of the project activities

-

Serve as a component of agreem­ents, orders, project plans

-

describe needs and limita­tions of the business processes

-

Marketing

-

Sales and distri­bution

-

Docume­ntation

-

functional and non-fu­nct­ional product requir­ements

Types of requir­ement

-

Solution or system requir­ements

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

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.

Outputs: Structured 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.

Outputs: Priori­tized 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

Outputs: Specified or modeled Requir­ements

Identify stakeh­older requests that are not properly requir­ements but based on assump­tions regarding what the solution team is capable of delivering

Outputs: Assump­tions and Constr­aints

Outputs: Verified requir­ements

Validate that a requir­ement will satisfy a business need.

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 [

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.

Purpose: Prepare for elicit­ation by ensuring all needed resources are organised and scheduled for conducting the elicit­ation activities

-

Scheduled resources

Assump­tions, constr­aints, risks, issues

Outputs: Stated requir­ements

Purpose: Play back the requir­ements to validate that the stakeh­older’s intentions have been correctly captured and unders­tood.

Interviews

Reviewing existing documents

Brains­torming

Appren­ticing

Requir­ements Elicit­ation should apply to enterprise requir­ements as well as user or customer requir­ements.

Functi­onality

Usability

Mainta­ina­bility

Any person involved in, or with an interest in, a project

Project Managers

Developers and Architects

GUI designers

Testers and Quality Assurance staff

Project sponsors

Instal­lation and Operations personnel

End users who are not a part of the customer’s organi­zation

A lack of unders­tanding of the real operators of the business processes in the organi­zation

Excluding stakeh­olders who are not clearly and directly related to the process

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.

Outputs from the Business Analysis are also inputs to system acceptance testing, which is the final check before the production release.

BA provides info to the following

-

Systems analysis

-

Implem­ent­ation

Common methods of commun­ication include:

-

Presen­tations

Factors to be Considered

-

Commun­ication formality

-

Geogra­phical location

Brains­torming

Data Flow Diagrams

Functional decomp­osition

MoSCoW

MOST (Mission, Object­ives, Strate­gies, Tactics)

Requir­ements Workshops

Scenarios and Use Cases

User stories

1.

Understand the top level critical objectives

3.

Focus on the required system quality, not just its functi­onality

5.

Don’t mix ends and means

7.

Ensure there is “rich specif­ica­tion”; requir­ement specif­ica­tions need much more inform­ation than just the requir­ement itself.

9.

Consider the total lifecycle and apply system­s-t­hin­king, not just a focus on software

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

Measurable and testable criteria allow for the objective and consistent assessment of solutions and designs

Acceptance criteria are typically used when only one possible solution is being evaluated, and are generally expressed as a pass or fail

Attributes that cannot be measured directly are evaluated using expert judgment or various scoring technique

-

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

perfor­mance and respon­siv­eness charac­ter­istics

availa­bility of specific features and capabi­lities

Evaluation criteria provide a way to determine if features provide the value necessary to satisfy stakeh­­older needs.

Acceptance criteria are expressed in a testable form

Acceptance criteria are necessary when the requir­ements express contra­ctual obliga­tions

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

determ­ining solutions to business problems

Business Analyst is not respon­sible for determ­ining the solution implem­ent­ation (creating the product’s design)

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

-

Ambiguous, under-­spe­cified, unclear, imposs­ible, contra­dictory business requir­ements

-

Poor transl­ation of the business needs to requir­ements (incom­plete, incons­istent, or not measurable requir­ements)

-

Commun­ication problems

-

Knowledge barriers

-

Overly formal wording

-

Gold plating (adding unnece­ssary scope)

-

Overlooked user classes

Conseq­uences of low quality BA

-

Planning diffic­ulties

-

Testing problems

-

risk of the project’s failure increases

-

Requir­ements are ambiguous

-

Requir­ements do not fulfill the agreed criteria

-

Business processes and artifacts are not covered by requir­ements or are described incomp­letely

-

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

-

Time pressure

-

Exclusive fixation on costs

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:

-

Detailed requir­ements to design models

-

High level requir­ements to test cases

Allows BA to ensure all business requir­ements have been met.

For the testers and develo­pers, tracea­bility ensures that the requir­ements coverage has been achieved

Purpose: Identify and propose projects that meet strategic needs and goals.

Purpose: Evaluate the internal and external enviro­nment

Define­/refine curren­t/f­uture business archit­ecture

Benchmark analysis

Fully define business proble­m/o­ppo­rtunity

-

Identify potential solutions

-

Recommend viable business solution

Output: Solution Approach

Projects inevitably struggle at some point or the other if the scope is not defined properly

-

Work Breakdown Structure (WBS) - a decomp­osition of the work that is required to complete a project, and accomplish the business objectives

-

System Interface Analysis - a definition of the work required to integrate the new solution into the existing business and technical enviro­nments

Product Breakdown Structure

-

Develop project scope

-

Analyze cost vs. benefit

-

Inputs: Business Archit­ecture, Business Goal(s), Defined Business Proble­m/O­ppo­rtunity Solution Scope

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

Purpose: Assess solutions to ensure that strategic goals are met and requir­ements are satisfied.

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.

Inputs: Solution Design Option(s)

Recommend the releas­e/d­elivery strategy

Inputs: Solution Design, Validated Requir­ements

Determine organi­zat­ional readiness to effect­ively operate the new solution

-

Recommend ways to optimize the organi­zat­ional deployment

Validate the verified and deployed solution meets the business need

Identify defect­s/s­hor­tco­mings (this should be distin­guished from functional testing)

Define corrective actions

When a problem is identified with the deployed solution determine what is the most approp­riate response

-

Assess the value of the solution as deployed to the business (to determine if the original goals are met).

Outputs: Cost/B­enefit Analysis

Invest­igating the business domain

Analyzing the structure of the customer’s organi­zation

Analyzing relati­onships with external organi­zations (suppl­iers, etc.)

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.

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

Provides the reasoning for initiating a project

May be in form of

-

Short argument

Topics may include

-

Qualit­ative and quanti­tative benefits

-

Profit expect­ations

-

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 technology infras­tru­cture

-

Estimated budget

Procedure of Building the Business Case

-

Identify and quantify the costs

-

Define the procedures that will be used to measure the costs and benefits

Follow common standards and guidelines

-

Each requir­ement must be unambi­guous, precise, and unders­tan­dable

-

Templates should be used as an aid

-

Formal graphical notation should be used as a method for presenting complex requir­ements, depend­encies, and relati­onships

-

Introd­uction

-

Regula­tions

-

Stakeh­olders

-

Overall descri­ption

-

Non-fu­nct­ional requir­ements

-

Depend­encies

-

Safety requir­ements

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

Trivia­lities - Lengthy descri­ptions of commonly known issues should not be included

Thinking in solutions - The requir­ements specif­ication should discuss the problem to be solved not the technical design of the solution

Lacking rationale

Modeling is a way of expressing requir­ements by repres­enting parts, or the whole, of the proposed solutions

Easier to read and comprehend than written text

Can skip modeling in the following situations

-

The requir­ements are mostly non-fu­nct­ional and difficult to express in the form of a model

-

The solution is dedicated to use by very few people

-

model repres­ent­ation would be less unders­tan­dable by the key stakeh­olders than written text

-

simplified expression of real processes

-

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.

-

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

Quality criteria for business process models

-

Relevance (no irrelevant details)

-

Clarity (under­sta­ndable by the audience)

-

Systematic design (contains well-d­efined interfaces to other types of models)

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.

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.

Lack of domain knowledge may lead to delays in providing the solution, since the business process and business rules must first be understood

Applying engagement strategies

Generating and organizing data

Mobilizing energy

Recording inform­ation

Flipcharts

Multi-­voting

Brains­torming

Focus group framework

Process Improv­ement supports the introd­uction of change into the current process in order to improve quality, reduce costs and/or accelerate schedules

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

-

Simulate and optimize processes

Business process improv­ement

Capability Maturity Model Integr­ati­on/­Cap­ability Maturity Model (CMMI/CMM)

IT Governance

Lean manufa­cturing

Process management

Six Sigma

1.

Business Analysis Planning and Monitoring (Orange)

3.

Elicit­ation (Light blue)

5.

Solution Assessment and Validation

Collect and document the requir­ements

Assist in the timely completion of the project by providing accurate requir­ements identi­fic­ation and analysis

Signif­icant impact on project management (espec­ially scope and time manage­ment)

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.

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

for the projects that help the organi­zation reach its vision, strategic goals, and business object­ives.

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.

set of activities aimed at producing a specific output for a particular customer or market.

A business process must have the following charac­ter­istics

-

Has specific inputs

-

Uses resources

-

Affects at least one organi­sat­ional unit

Identi­fic­ation of processes allows the Business Analyst to understand the organi­zat­ion’s 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

-

Gathering initial requir­ements for the needed business solution (“to be” analysis)

-

Conducting a feasib­ility study

-

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)

-

Managing any requir­ements changes

-

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)

-

Supporting testers in preparing test cases and test scripts at the business level and validating the resulting work products

-

verifying test results

-

Partic­ipating in the prepar­ation of test cases for User Acceptance Testing

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

-

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.

-

RACI matrix (also known as RASCI matrix) plays very important role in this process.

-

estimates related to cost, timings and resources

-

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

-

Each stakeh­older should understand the details of the requir­ements

Monitoring BA work

-

helps in improving future business analysis plans

Plan Business Analysis Activities

-

Determine tasks in the Knowledge Areas:

-

Develop estimates for BA work (time, skill level, complexity of tasks, etc.)

-

Outputs: Business Analysis Plans for each KA

-

Describes how to determine the approp­riate requir­ements process for a particular initiative

-

Which stakeh­olders need to approve

-

includes the approach to requir­ements tracea­bility and determ­ining which requir­ements attributes we will capture

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

Ensure stakeh­olders have access to business analysis work products

Approve requir­ements (according to the approval authority stated in the Requir­ements Management Plan)

Manage requir­ements conflicts and issues

Outputs: Approved Requir­ements, Decision Record

Purpose:

Perform impact analysis when changes are requested and supply this inform­ation to the change control process

Outputs: Traced Requir­ements

Name the respon­sible party who will maintain the requir­ements

Facilitate re-use of requir­ements on related projects to encourage enterprise consis­tency of business models

Outputs: Mainta­ine­d/r­e-used requir­ements

Determine approp­riate format for requir­ements, Create a requir­ements package

Intera­ction with solution team to assure that requir­ements are correctly understood and implem­ented

Identi­fying a potential change

Analyzing the change request

Planning the change

Reviewing and closing the change request

A defect found in the code, docume­ntation or requir­ements

External changes (regul­atory, legal, etc.)

Business process improv­ement initia­tives

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

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.

Impact analysis should be performed

Updating business and system docume­ntation (e.g., specif­ica­tions, archit­ecture design, user manuals)

Implem­enting the change (coding)

Deploying the change to the production enviro­nment

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

Ensure that the model correctly reflects the boundaries for the business problem

-

Goals are business requir­ements

Feature list decomp­osition

-

an abstra­ction of the solution of the problem expressed at a high-level

Functional decomp­osition

-

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.

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

Alloca­table

Feasible

Consistent

Necessary

Testable

Traceable

Does not determine solution

One of the most common techniques for requir­ements’ quality control is the use of checkl­ists.

Statis­tical analysis

Requir­ements analysis

Unders­tanding of engine­ering principles

Unders­tanding of organi­zat­ional behavior

Negoti­ation skills

-

Ability to negotiate with stakeh­olders to implement projects

-

Ability to commun­icate with all levels of management

-

Precision in articu­lating ideas and thoughts

-

Good technical writing skills

-

Public speaking skills

Facili­tation can be defined as a process of enabling groups to work cooper­atively and effect­ively. Facili­tation provides leadership

-

Leading

-

Building team and community

-

Resolving conflicts

-

Evoking wise democracy

Tasks and activities

-

Providing processes to support members of the group to help them use their time effect­ively and to make high-q­uality decisions

-

Supporting members of the group in assessing their current skills and building new skills

-

Managing conflicts using a collab­orative approach

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.

-

Commun­icates well

-

Shows a natural interest

-

Maintains control

-

Handles uncert­ainty

-

Focuses on the business not on personal solutions

-

Unders­tands group dynamics

-

Runs meetings

-

Unders­tands and explains the process