Cbap Elements Inputs Tecnniques

Front 1

Business Analysis Planning and Monitoring

Back 1

334434

Front 2

Plan business analysis approach
I3

Back 2

This will define the overall process that will be followed for this initiative, how and when tasks will be performed, the techniques used, and the deliverables produced. Will plan KAs including req management, communication, and elicitation.
For this we need business need, expert judgement, and OPAs
And done via decision analysis, process modeling , and st walkthrough (to validate the tailored approach)
DIPSE+COSSTR-OS

Front 3

Stakeholder analysis
I3

Back 3

An activity to identify the impacted, influential and related stakeholders to the business need. We will identify stakeholders, understand their complexity, attitude and influence, and authority for business analysis work.
We will need enterprise architecture, OPAs, and business need.
We will use RACI, stakeholder map along with acceptance and eval criteria(which stakehoder will accept or reject the solution), brainstorming, interviews, org modelling, process modelling, requirements workshops, risk analysis, scenarios & use cases, scope modelling, and surveys.
DIPS+TR

Front 4

Plan business analysis activities
I4

Back 4

Determine the activities required, deliverables produced, estimate the efforts and identify the management tools. This will involve geographic distribution of SH, type of project or initiative, determine deliverables, and activities.
This requires the stakeholder list, business analysis approach, OPAs, and BA performance assessment. Done via estimation, functional decomposition, and risk analysis.

Front 5

Plan business analysis communication
I4

Back 5

It describes the proposed communication structure and schedule. It is to determine how best to receive, distribute, access, update and escalate information from SH and how best to communicate with each.
Consideration includes what and when needs to be communicated, delivery method, appropriate audience. Constraints include their location, communication approach, types of communication, types of requirements elicited and in what detail, how best to communicate conclusions, and time & resource availability constraint. We will look at geography, culture, project type, communicate frequency and formality.
We need OPAs, business analysis plan, approach and SHLRR.
Done structured walkthrough and all techniques of requirements packages, communicate requirements, and communication skills.

Front 6

Plan requirements management process
I3

Back 6

We will look at how the requirements will be managed including their scoping, traceability and re-use. For this we will look at their repository, traceability, attributes(Cara's soups), prioritisation process, change management and tailoring the process.
For this, we will need organisation process assets, business analysis plan, business analysis approach.
This is done via decision analysis, problem tracking, and risk analysis.

Front 7

Manage business analysis performance
I4

Back 7

This will take care of the metrics used to measure performance, , report performance, and take corrective actions. For this we need, OPAs, requirement management plan, business analysis plan, and business analysis performance metrics.
This is done via variance analysis and general tech such as metrics and KPIs, lessons learned process, interviews, problem tracking, process modelling, root cause analysis, surveys.

Front 8

Elicitaion

Back 8

4712

Front 9

Prepare for elicitation
I4

Back 9

Classify the scope, schedule all resources (peole, facilities, equipment) and notify all parties of the plan. For event based techniques, establish ground rules. Agreement on elicitation process as well as mechanism for verifying and signing off elicited results.
We need Business need (what to elicit except when eliciting business need), business case and solution scope (while eliciting SH, solution, and transition requirements), SHLRR.
Brainstorming, DA, FG, Interface Analysis, Interviews,
Participating SH, PM

Front 10

Conduct Elicitation
I7

Back 10

Elicitation events takes place, elicitation is performed or distributed. We will trace requirements, capture requirements attributes, and metrics.
We need business need, Solution scope and business case (what needs to be elicited), supporting materials and resources (required resources), OPAs (templates), requirements management plan (what is to be recorded).
Data Dictionary and glossary, and elicitation event, performance and distribution techniques.
All the participants DIPSE+COSSTR

Front 11

Document elicitation
I1

Back 11

In documenting we will document the results of the elicitation. Now to document, we only need elicitation results. Result from all the techniques that will be used to elicit requirements and help from working documents.
All elicitation event, performance, distribution techniques + Problem Tracking

Front 12

Confirm elicitation
I2

Back 12

In confirming we are making sure the requirements and concerns elicited are true. For this we need the requirements, concerns. This confirmation is the bg confirmation and is done via observation and interviews.
Participants of elicitation techniques

Front 13

Requirements Management and Communication

Back 13

42243

Front 14

Manage solution scope and requirements
I4

Back 14

During this management we will seek review and approval, manage the solution scope, and resolve conflicts and issues on the scope.
To manage solution scope and requirements, we need management plan and requirements. This requires problem tracking, base lining, and sign off. DIPS
Solution Scope and PMs project scope are highly related.

Front 15

Manage requirements traceability
I2

Back 15

We will do this by defining the relationships between requirements, impact analysis how impact on one requirement change others, and to use req mgmt system to trace large no of requirements.
To manage the traceability, we need the requirements and the management plan.
Coverage Matrix
IPT

Front 16

Manage requirements for re use
I2

Back 16

To manage requirements for reuse, they will be bifurcated into ongoing and satisfied requirements.
We need the requirements and OPAs which
DIB

Front 17

Requirements packages
I4

Back 17

Create the requirements pack for the understanding of all the SH. We look at work products & deliverables and format.
For this we need communication plan (whether single or multiple packages, SH groups, and their comm. needs), templates (OPAs), requirements and requirements structure.
This will be via documenting requirements containing product roadmap, req spec, & vision document and documenting requirements for vendor selection.

Front 18

Communicate requirements
I3

Back 18

To bring everybody to a common understanding, we will use conversations, notes, documents, and discussions. All tasks are communicated in general comm , and presentations which can be formal of informal in nature. For this we need the communication plan, packaged and unpackaged requirements and is done via requirements workshop and structured walk through.

Front 19

Enterprise Analysis

Back 19

23234

Front 20

Define business need
I2

Back 20

To perform, we will look at the goals and objectives of the organisation, problem or opportunity that we have to solve, and the desired outcome. We need Business Goals and objectives and stated requirements. We will benchmark, brainstorm, business rules analysis, focus groups, functional decomposition and root cause analysis.
DISE+CSR

Front 21

Assess capability gaps
I3

Back 21

We will look at current capabilities, future capabilities and the assumptions on how solution will meet those needs. We need the enterprise architecture, solution performance assessment and the business need.
For current understanding we will use document analysis and SWOT which will also tell us the opportunities and threats.
DISE+CS

Front 22

Determine solution approaches
I2

Back 22

Determine all viable solution approaches, implementation means, and organisation capabilities. For this we will generate all alternatives including doing nothing and buying time, consider assumptions and constraints, and ranking & selection of all approaches. We need business need (to compare alternatives), OPAs (specific needs and required capabilities that organisation must support)
Done via feasibility analysis and general techniques (benchmarking, brainstorming, decision analysis, estimation, SWOT (to compare approaches))

Front 23

Define solution scope
I3

Back 23

To define which new capabilities the solution must support, we will define the solution scope (and solutions interactions outside the scope), Implementation approach (on how to implement) and dependencies.
We need required capabilities, solution approaches, and assumptions & constraints. Via functional decomposition, interface analysis, scope modelling, user stories, problem or vision statement. DIPS

Front 24

Define business case
I4

Back 24

To justify the investment required to deliver the solution, we will look @ benefits, costs, risk assessment and result measurements.
We need business need, solution scope, SH concerns and assumptions & constraints. This is done via decision analysis( financial decisions), estimating, metrics and KPIs, risk analysis, SWOT(how solution will strengthen and weaknesses), vendor assessment (external solution in consideration)

Front 25

Requirements Analysis

Back 25

532112

Front 26

Prioritize requirements
I5

Back 26

Deciding the order of req on the basis of value, risk, impl difficulty, etc. for this we look at basis for prioritisation & challenges such as non-negotiable demands, unrealistic trade-off. We need business case, business need, requirements, requirements management plan, and SHLRR. Done via decision analysis, risk analysis, MoSCoW, time boxing and voting. DIPS

Front 27

Organize requirements
I3

Back 27

To create a set of views that is comprehensive, complete, consistent, and understand from all SH perspective. We will look at levels of abstraction and modelling of requirements. For this we will need OPAs to describe structure, requirements stated to identify generic needs, and understand solution scope using business rules analysis, data flow, data modelling, functional decomposition, org modelling, process modelling, scenarios and use cases, scope modelling and user stories. DIPSE

Front 28

Specify and model requirements
I2

Back 28

To analyze expressed requirements using text, matrices, diagrams, and formal models. For this, we may specify requirements them as text, matrix documentation, model them as diagrams and formal modeling, capturing attributes and improvement opportunities. We need requirements stated, their structure. 16 general techniques are used.

Front 29

Define assumptions and constraints
I1

Back 29

Factors other than requirements that affect solution are received from SH concerns. Then assumptions and business/technical constraints via problem tracking (which manages the assumptions and constraints) ,risk analysis ( assumption may be invalidated or constraint removed in the future) IP+source of ass/cons~

Front 30

Verify requirements
I1

Back 30

All requirements except stated are verified. Then the quality attributes of the requirements defined CoCoCoCoFeMoUnTe & verification activities are performed via acceptance & eval criteria, problem tracking, structured walkthrough, & checklists.

Front 31

Validate requirements
I2

Back 31

Ensure that all requirements deliver value to business and support SH needs. For this, we need to identify assumptions, define evaluation criteria, determine business value, determine dependencies for benefit realisation and evaluate alignment with business case and opportunity cost. For this, need business case (business objectives and measurements) and verified requirements. Though, validation doesn't need verification to be completed.
Via acceptance & eval criteria, metrics and KPIs, prototyping to gain user support, risk analysis to identify possible scenarios, and confirm via structured walkthrough.

Front 32

Solution Assessment and Validation

Back 32

334424

Front 33

Assess proposed solution
I3

Back 33

We assess single or proposed multiple solutions and we will rank solution options and identify additional potential capabilities. Needs PV requirements, solution scope, and assumptions & constraints. This is done via acceptance and eval criteria, decision analysis, vendor assessment with DIPS + OSS

Front 34

Allocate requirements
I3

Back 34

Allocate requirements among solution considering resources, constraint and req dependencies. For this we will need solution scope, prioritised verified requirements, and designed solution.
This will done via acceptance and evaluation criteria, business rules analysis, decision analysis, functnal decomposition, process modelling, scenarios & uc

Front 35

Assess organisation readiness
I4

Back 35

To assess organisational readiness we will look at cultural , operational/technical, SH assessment. For this we need the enterprise architecture(current state and SH concerns), deployed, designed solution and the solution scope. This is done via acceptance and eval criteria ( solution performance), DFD + process modeling (what is changing), FG+interview+survey (SH concerns), organisation modelling, problem tracking, risk analysis, SWOT (assess strategies to respond to issues), and force field analysis DIPS+OS

Front 36

Define transition requirements
I4

Back 36

To define the transition requirements we will look at people transition, data and ongoing work changes. We need the old and new solution, requirements and organisation readiness assessment.
Techniques used will be business rules analysis, data transition via data modelling, diff in solutions via DFDs, process modelling, organisational modelling. .DIPSE+COSTR

Front 37

Validate Solution
I2

Back 37

Validate that it meets business need and determine most apt response to defects. Assess the defective solution outputs and assess defects to identify the reasons for their causes
For this we need the PV requirement and constructed solution. Done via acceptance and evaluation criteria, problem tracking and RCA. DIPSE + OSTR

Front 38

Evaluate solution performance
I4

Back 38

We will try and understand the value delivered by the solution, solution metrics (expected value delivered) and consider if this solution requires replacement or elimination.
We need deployed solution, requirements, identified defects, and solution performance metrics.
Done via decision analysis, focus groups, observation, survey

Front 39

Elicitation Events

Back 39

Brainstorming, focus groups, interviews, observation, prototyping, requirements workshops

Front 40

Elicitation Performance

Back 40

document analysis, observation

Front 41

Elicitation distributed

Back 41

Surveys/questionnaire