BA Planning & Monitoring

The Business Analysis Planning and Monitoring Knowledge Area defines the tasks associated with the planning and monitoring of business analysis activities, including:
- identifying stakeholders
- defining roles and responsibilities of stakeholders in the business analysis effort
- developing estimates for business analysis tasks
- planning how the business analyst will communicate with stakeholders
- planning how requirements will be approached, traced, and prioritized
- determining the deliverables that the business analyst will produce
- defining and determining business analysis processes
- determining the metrics that will be used for monitoring business analysis work

In addition, this knowledge area describes the work involved in monitoring and reporting on work performed to ensure that the business analysis effort produces the expected outcomes. If these outcomes do
not occur, the business analyst must take corrective action to meet stakeholder expectations.

BA Planning & Monitoring - Task 1 (Plan BA approach)

Elements Techniques Stakeholders

1. Determine timing of BA work 9.8. Decision Analysis Customer
- Tasks to be performed 9.21. Process Modeling Domain SME
- Resources that will perform each task 9.30. Structured Walkthrough End User
2. Decide degree of formality & level of detail for BA Supplier
deliverables Implementation SME
3. Select methods for prioritizing the requirements Project Manager
Determine how requirements will be prioritize Tester
4. Build an appropriate change management Regulator
approach Sponsor
5. Plan & intergrate the execution of BA activities
(integrated into a larger project plan)
 6. Create an approach to stakeholder
communications
- Formal communication methods
- Frequency of communication
7. Identify any requirement analysis or management
tools to be used

8. Consider project complexity

- Number of stakeholders
- Number of business areas affected
- Number of business systems affected
3 spectrum of BA approaches: - Amount & nature of risk
1. Plan Driven - solution is fully defined before its implementation begins. - Uniqueness of requirements
Project sponsor & selected stakeholder has the approval authority e.g. - Number of techinical resoureces required
waterfall
2. Change Driven - many small iterations are defined and developed to
yield final result. Active participant in the team has the approval authority
e.g. Agile
3. Hybrid - combination of both. Will require additional tailoring & scaling of
BA approach to combine them well
BA Planning & Monitoring - Task 2 (Conduct Stakeholder Analysis)

Elements Techniques Stakeholders

1. Identify stakeholders 1. RACI Matrix Domain SME
2. Stakeholder Map Implementation SME
2. Analyze complexity of stakeholder group
- number and variety of direct end users 9.1. Acceptance & Evaluation Criteria Definition Project Manager
- number of interfacing business process & 9.3. Brainstorming Tester
automated systems 9.14. Interviews Regulator
9.19. Organization Modeling Sponsor
9.21. Process Modeling
3. Assess stakeholder attitude & influence 9.23. Requirement Workshops
Attitude towards:
- Business goals, objectives, solution approach 9.24. Risk Analysis
- Business Analysis 9.26. Scenarios and Use Cases
- Collaboration 9.27. Scope Modeling
- Sponsor 9.31. Survey/Questionaire
- Team members
Influence:
- Influence on the project
- Influence in the organization
- Influence needed for the good of the project
- Influence with other stakeholders

4. Define stakeholder authority levels over BA work

- Approve the deliverables
- Inspect & approve the requirements
- Request & approve changes
- Approve requirements process that will be used
- Review & approve tracibility structure
- Veto (to indicate) proposed requirements or
solution
BA Planning & Monitoring - Task 3 (Plan BA Activities)

Elements Techniques Stakeholders

9.10. Estimation Customer
1. Consider geographic distribution of stakeholders
Collocate - locate in same area geographic area 9.12. Functional Decomposition Domain SME
Dispersed - locate in different geographic regions or 9.24. Risk Analysis End User
countries Supplier
Implementation SME
2. Impacts of project type or initiative Operational Support
- Feasibility studies Project Manager
- Process improvement Tester
- Organizational change
Sponsor
- New in-house software development
- New outsourced software development
- Software maintenance or enhancement
- Softward package selection
3. Decide on BA deliverables
- Interivews or facilitated sessions with stakeholder
- Review project documents
- Review organizational process assets

4. Determine BA activities
- Define & decompose the scope of BA work into
smaller pieces using Work breakdown structure
(WBS). Can break a project into iterations, releases,
phases
- Create an Activity List in 3 ways:
1. Take each deliverable, assign activities reqiured
& break each activity into more detailed tasks
2. Divide project into phases, then deliverables, then
activities & tasks
3. Expand on a previous similar projects
Task include the following activities to:
- Determine the activities that must be perform
- Deliverables that must be produced
- Esimate the effort required
- Identify the management tools required to measure the progress of
activities & deliverables
BA Planning & Monitoring - Task 4 (Plan BA Communication)

Elements Techniques Stakeholders

1. Stakeholder geography 1. Communication Techniques Customer
9.30. Structure Walkthrough Supplier
2. Cultural Diversity Domain SME
- Language barriers
End User
- Time / deadline
- Task completion Implementation SME
- Contracts Operational Support
- Formal & informal authority Project Manager
3. Project Type Tester
4. Communication Frequency Regulator
Sponsor

5. Level of formality
- Deliver a large, phase project
- Complex solution domain
- New technology
- Mission-critical solution
- Executive sponsor or key stakeholders who require
formality
- Subject to regulatory review
- Present to suppliers for vendor selection
a. Request for Information (RFI)
b. Request for Quote (RFQ)
c. Request for Proposal (RFP)
BA Planning & Monitoring - Task 5 (Plan Requirements Management Process)

Elements Techniques Stakeholders

1. Build requirements repository 9.8. Decision Analysis Domain SME
2. Decide on requirements traceability 9.20. Problem Tracking End User
9.24. Risk Analysis Implementation SME
3. Select requirements attributes Operational Support
- Absolute reference - Risks
Project Manager
- Author of requirement - Source f the requirement
- Complexity - Stability Tester
- Ownership - Status Sponsor
- Priority - Urgency
4. Define requirments prioritization scheme
- Formality
- Establishing the process and techniques
- Plan the participation

5. Change management
Considerations when plan for handling changes:
- Process for requesting changes
- Who will authorize changes
- Perform impact anlaysis
- Plan the wordings of the request
- Coordinate priorization of change
Components within a change request:
- Cost & time estimates
- Beneift & risk
- Recommended course of action
- Update communication plan & method for
communication to affected stakeholders
- Establish baselines & version control practices on
Define the process that will be used to approve requirements for configuration management & traceability disciplines
implementation & manage changes to the solution or requirements scope
- process for requirement change 6. Tailor requirement management process
- which stakeholders need to approve change Factors to consider:
- who will be consulted or informed of changes, or not involved - Organizational culture
- access the need for requirement traceability - Stakeholder preference
- which requirements attributes will be captured - Project or product complexity
- Organizational maturity
- Resource availability
BA Planning & Monitoring - Task 6 (Manage BA Performance)

Elements Techniques Stakeholders

1. Define performance measures 1. Variance Analysis Domain SME
Used to set expectations regarding what constitutes 9.16. Metrics & Key Performance Indicators End User
effective BA work in the context of a particular 9.14. Interviews Implementation SME
organization or initiative
9.15. Lessons Learned Process Operational Support
Performance measures may be based on:
- Deliverable due dates 9.20. Problem Tracking Tester
- Frequency of requirements change 9.21. Process Modeling Project Manager
- Number of review cycles 9.25. Root Cause Analysis Sponsor
- Qualitative feedback form stakeholders 9.31. Survey/Questionnaire
Appropriate performance measures should enable
the BA to:
- Determine when problems are occurring
- Identify opportunities for improvement

2. Decide performance reporting

3. Take corrective & preventive actions

To manage the performance of business analysis activities to ensure that

they are executed as effectively as possible

Determining which metrics will be used to measure the work performed by

the business analyst, including:
- How to track, assess, and report on the quality of the work, and
- How to correct any problems that may arise

Metrics may feed into the development of future business analysis plans.
The selected metrics are defined and described in the OPA or the
business analysis plans.

Also describes how OPA governing business analysis activities are

managed and updated.
Enterprise Analysis

The Enterprise Analysis Knowledge Area describes the business analysis activities necessary to identify a business need, problem, or opportunity, define the nature of a solution that meets
that need, and justify the investment necessary to deliver that solution. Enterprise analysis outputs provide context to requirements analysis and to solution identification for a given initiative
or for long-term planning. Enterprise analysis is often the starting point for initiating a new project and is continued as changes occur and more information becomes available. It is through
enterprise analysis activities that business requirements are identified and documented.

It describes the business analysis activities that take place for organizations to:
- Analyze the business situation in order to fully understand business problems and opportunities.
- Assess the capabilities of the enterprise in order to understand the change needed to meet business needs and achieve strategic goals.
- Determine the most feasible business solution approach.
- Define the solution scope and develop the business case for a proposed solution.
- Define and document business requirements (including the business need, required capabilities, solution scope, and business case).

Note: the performance of all enterprise analysis activities are governed by the business analysis plans, and business analysis performance metrics should be tracked
Enterprise Analysis - Task 1 (Define Business Need)

Elements Techniques
9.2. Benchmarking
9.25. Root Cause Analysis
1. Align with business goals & objectives - Fishbone Diagram
Goals - longer-term, ongoing & qualitative strategic - Five Whys
statement of a state/condition the company wants 9.3. Brainstorming
to accomplish e.g. increase high revenue client
Objective - state the predetermined results toward 9.4. Business Rules Analysis
which effort is directed. 9.11. Focus Groups
Objective has to be SMART: 9.12. Functional Decomposition
Specific - has an observable outcome
Measureable - tracking & measuring the outcome
Achievable - feasiblity of the effort
Relevant - align with organization's key vision,
mission & goals
Time-bounded - defined timeframe consistent with
business need

2. State the business problem or opportunity

- Adverse impacts
- Expected benefits from potential solution
- How quick the problem can be resolve,
opportunity could be taken, cost of doing nothing
- Underlying source of the problem
3. Descibe the desired outcome - business benefit
that will result from meeting business need & the
end stated desired by stakeholders

Business needs defines the problem that the BA is trying to

find a solution for
New business needs triggered by 4 sources:
1. Top down - achieve a strategic goal
2. Buttom up - address current process function or system
3. Middle management - additional functions or information
to make better decusions or objectives
4. External drivers - customer demands or market
competition
Enterprise Analysis - Task 2 (Assess Capability Gaps)

Elements Techniques
1. Analyze current capabilities 9.9. Document Analysis
9.32. SWOT Analysis
2. Assess new capability requirements
Gap analysis - defining what it will take to
deliminate or minimize the gap between current
capabilities & the desired future state (meeting the
business need)
3. Document your assumptions

To identify new capabilities required to meet business need.

Determine existing capabilities can meet the business need
or if additional capabilities are necessary
Enterprise Analysis - Task 3 (Determine Solution Approach)

Elements Techniques
1. Identify alternative solution options 1, Feasibility Analysis
- doing nothing 9.2. Benchmarking
- alternatives 9.3. Brainstorming
2. Generate assumptions and constraints 9.8. Decision Analysis
3. Rank and select solution approach 9.10. Estimation
9.32. SWOT Analysis

To determine solution approach to meet business need in

enough detail to allow for definition of solution scope &
prepare the business case

Some possible approaches:

- utilize additional capabilities of existing software/hardware
- purchase or lease software/hardward from a supplier
- design & develop custome software
- add business resources
- change business procedure / processes
- partnering or outsourcing
Enterprise Analysis - Task 4 (Define Solution Scope)

Elements Techniques
1. Problem or Vision Statement
1. Define the solution scope 9.12. Functional Decomposition
- describe major features, functions, interations
9.13. Interface Analysis
- state in-scope & out-of-scope components
- describe business units to be involved, business 9.27. Scope Modeling
processes to be improved, process owners and IT 9.33. User Stories
systesm being affected
2. Determine the implementation approach
- how the solution approach will deliver solution
scope e.g. deliver in release
- which process being outsourced
3. Capture solution dependencies

Solution scope - set of capabilities a solution must deliver in

order to meet business need

Defines a recommended solution in enough detail for

stakeholders to understand the new business capabilities
the solution will provide. It includes
- Scope of anlaysis
- Capabilities supported by solution components
- Capabliliies to be supported by individual releases
- Enabling capabilities that are required in order to develop
the capabilities reuiqred to meet business need
Enterprise Analysis - Task 5 (Define Business Case)

Elements Techniques
1. Quantify the benefits 9.24. Risk Analysis
- Qualitative (nontangible) benefit e.g. morale 9.8. Decision Analysis
- Quantitative (tangible) benefit 9.10. Estimation
9.16. Metrics and Key Performance Indicator
2. Estimate the costs 9.32. SWOT Analysis
- capital expenditures
9.34. Vendor Assessment
- development cost
- implementation cost
- opportunity cost of not investing in other options
- total cost of ownership to support new solution
3. Assess initial risks
- technical risk
- financial risk
- business change & organizational risk
4. Measure expected results

Business cases is used to justify the costs of doing a project

in terms of the value the project adds to the business & the
associated business benefits. It is used to support a go / no
go decision about the project that implements the proposed
solution
ature of a solution that meets
tification for a given initiative
mes available. It is through

acked
Stakeholders
Customer
Supplier
Domain SME
End User
Implementation SME
Regulator
Sponsor
Stakeholders
Customer
Supplier
Domain SME
End User
Implementation SME
Sponsor
Stakeholders
Customer
Domain SME
End User
Supplier
Implementation SME
Sponsor
Stakeholders
Domain SME
Implementation SME
Project Manager
Sponsor
Stakeholders
Sponsor
Domain SME
Implementation SME
Project Manager
Requirements Management & Communication

The Requirements Management and Communication Knowledge Area describes the activities and considerations for managing and expressing requirements to a broad and diverse
audience. These tasks are performed to ensure that all stakeholders have a shared understanding of the nature of a solution and to ensure that those stakeholders with approval
authority are in agreement as to the requirements that the solution shall meet.

Communicating requirements helps to bring the stakeholders to a common understanding of the requirements. Because the stakeholders represent people from different
backgrounds and business domains, this communication is both challenging and critical to the success of any initiative. It involves determining which sets of requirements are
relevant to a particular stakeholder group and presenting those requirements in an appropriate format for that audience.

Management of requirements assists with understanding the effects of change and linking business goals and objectives to the actual solution that is constructed and delivered. Over
the long term, it also ensures that the knowledge and understanding of the organization gained during business analysis is available for future use.

Note: the performance of all requirements management and communication activities are governed by the business analysis plans, and business analysis performance metrics
should be tracked

Requirements Management & Communication - Task 1 (Manage Solution Scope & Requirements)

Elements Techniques Stakeholders

1. Baselining Domain SME
1. Manage solution scope & requirements 2. Sign-off Implementation SME
If they do not fall within the solution scope, BA 9.20. Problem Tracking Project Manager
must act to resolve the conflict by amending
Sponsor
requirements & solution scope or by reaching
agreement. It also focus on getting & maintaining
stakeholder approval & buy-in for those
requirements.
 1. Manage solution scope & requirements
If they do not fall within the solution scope, BA
must act to resolve the conflict by amending
requirements & solution scope or by reaching
agreement. It also focus on getting & maintaining
stakeholder approval & buy-in for those
requirements.
2. Address conflicts & issues
- formal meetings among affected stakeholders
- research into what is actually required
- third party arbitration and resolution
3. Presenting requirements for review
- formal e.g. written spec, structure walkthrough
- informal e.g. email, note, verbally
4. Obtain approval for the requirements
Approval can be obtained for a single requirement
statement, set of related requirements, entire
requirements document

This task involves securing approval of requirements from

stakeholders & managing issues that emerge during
elicitaion and analysis.Any changes after baselining
involves use of a change control process & subsequent
approval
Requirements Management & Communication - Task 2 (Manage Requirements Traceability)

Elements Techniques Stakeholders

1. Coverage Matrix Implementation SME
Project Manager
1. Record dependencies & relationships Tester
Common relationships between requirements:
- Necessity: a reqmt and another related reqmt
must be implemented at the same time. This may
be unidirectional or bi-directional
- Effort: a reqmt is easier to implement if a related
reqmt is implemented at the same time
- Subset: a reqmt is a decomposed outcome of
another reqmt
- Cover: all of the subreqmt must be implemented
in order for this higher level reqmt to be met
- Value: including a particular reqmt increases or
decreases the desirability of implementing a related
reqmt
2. Perform impact anlaysis for change request
3. Use a configuration management system

Create and maintain relationships between business

objectives, requirements, other team deliverables, and
solution components to support BA or other activities (e.g.
test cases)
3 aspects of requirements traceability:
Derivation - backward traceability to its higher level parent
Allocation - forward traceability to its more detailed children
Relationship - dependency & interrelationship to other
proejct requirements
Tracing may be perform at:
- individual requirements - models
- requirements packages - features
Traceibility is used for:
- Impact Analysis - Requirements Coverage
- Requirements Allocation
Requirements Management & Communication - Task 3 (Maintain Requirements for Reuse)

Elements Techniques Stakeholders

n/a Business Analyst
1. Ongoing Requirements Domain SME
- continuous obligation Implementation SME
- quality standard
- business processes
- service level agreement
- business rules
- business processes
2. Satisfied Requirements
Requirements Management & Communication - Task 4 (Prepare a Requirement Package)

Elements Techniques Stakeholders

1. Requirements Documentation Domain SME
1. Producing work products and deliverables
2. Requirements for Vendor Selection Implementation SME
Work product - document, note, diagrams used by
the BA during requirement development Project Manager
Deliverable - specific BA process outputs that the Regulators
team plans to deliver Sponsors
2. Deciding the requirements package format Testers

Requirement package is a set of requirements that are

ready for an important project stakeholder review
It is prepared for a number of reasons:
- Early assessment of quality & planning
- Evaluation of possible alternatives
- Formal reviews and approvals
- Inputs to solution design
- Conformance to contractual & regulatory obligations
- Maintenance for reuse
Possible forms for requirements packages:
- Formal documentation
- Presentation
- Models e.g. process map, whiteboard
Requirements Management & Communication - Task 5 (Communicate Requirements)

Elements Techniques Stakeholders

9.23. Requirement Workshops All
9.30. Structure Walkthrough
1. General Communication
Formal reqmt communication follows the contents
of the BA communication plan. Informal
communication takes place whenever is needed.
Communication focus on 4 knowledge areas:
- Enterprise Analysis: business case, solution
scope
- Elicitation
- Requirement Analysis: refined, modified, clarified,
finalized through effective communication
- Solution Assessment & Validation: assessment of
solution, solution component, organization
readiness, transition requirements
2. Making presentation
Formality of the presentation is driven by the
objective of the communication & audience needs
Elicitation

Eliciting requirements is a key task in business analysis. Because the requirements serve as the foundation for the solution to the business needs it is essential that the requirements be
complete, clear, correct, and consistent

The definition of elicitation is:

- to draw forth or bring out (something latent or potential)
- to call forth or draw out (as information or a response)

This chapter includes details for eliciting business, stakeholder, solution, or transition requirements. The business analyst should understand the commonly used techniques to elicit
requirements, should be able to select appropriate technique(s) for a given situation, and be knowledgeable of the tasks needed to prepare, execute and complete each technique.
Eliciting requirements is not an isolated or compartmentalized activity. Typically, requirements are identified throughout the elicitation, analysis, verification and validation activities. For example,
requirements may be elicited in interviews or requirements workshops. Later, when those requirements are used to build and verify model(s), gaps in the requirements may be discovered. This
will then require eliciting details of those newly identified requirements.

It is expected that at some point while performing elicitation that sufficient material will have been elicited from the business experts to allow analysis activities to begin. The combined results of
all the elicitation techniques used will serve as input to building the selected analytical models. Missing, incomplete or incorrect requirements will ideally be exposed during the analysis activities,
thus requiring additional elicitation

Note: the performance of all elicitation activities are governed by the business analysis plans, and business analysis performance metrics should be tracked
Elicitation - Task 1 (Prepare for Elicitation)

Elements Techniques
1. Clarify the scope of the selected elicitation 9.3. Brainstorming
technique & gather any necessary supportin 9.9. Document Analysis
material 9.11. Focus Groups
2. Schedule all resources e.g. people, facilities, 9.13. Interface Analysis
equipment 9.14. Interviews
3. Notify appropriate parties of the elicitation plan 9.18. Observation
9.22. Prototyping
9.23. Requirement Workshops
For event-based elicitation (brainstorming, gocus 9.31. Survey/Questionnaire
group, interview, observation, prototyping,
requirements workshop), ground rules must be
established. Agreement has to be reached with the
stakeholders on the followings:
- the form & frequency of feedback during the
elicitation process
- mechanism for verifying the elicitated results
- signing off on the elicitated results

Ensure all needed resources are organized & scheduled for conducting the
eliciation activities.
Preparation work should include:
- build a detailed schedule for a particular eliciation activity
- defining the more detailed task that need to be done
- scheduling those detailed task
Elicitation - Task 2 (Conduct Elicitation Activity)

Elements Techniques
1. Tracing requirements 9.5. Data Dictionary and Glossory
2. Capturing requirements attributes
- source
- value
- priority General elicitation techniques:
1. Events
3. Collecting elicitation metrics - 9.3. Brainstorming
Tracking the eliciation participants & the actual time - 9.11. Focus Groups
spent eliciting the requirements provides a basis for - 9.14. Interviews
future planning - 9.18. Observation
- 9.22. Prototyping
- 9.23. Requirements Workshop
2. Performed work
- 9.9. Document analysis
- 9.13. Interface analysis
3. Collected work
- 9.31. Survey/Questionnaire

Meet with stakeholders to elicit information regarding their needs.

The elicitation event takes place or eliciation is performed or distributed
Elicitation - Task 3 (Document Elicitation Results)

Elements Techniques
9.3. Brainstorming
Documentation can take a number of forms: 9.9. Document analysis
- written documents describing the outcomes e.g.
9.11. Focus Groups
meeting minutes
- visual or audio recording 9.13. Interface analysis
- whiteboards where notes are retained until thye 9.14. Interviews
are transferred to another medium 9.18. Observation
9.20. Problem Tracking
9.22. Prototyping
9.23. Requirements Workshop
9.31. Survey/Questionnaire

Record the information provided by stakeholders for use in analysis

For an elicitation event, a summary of the output from the event, including
issues is produced
Elicitation - Task 4 (Confirm Elicitation Results)

Elements Techniques
n/a 9.14. Interviews
9.18. Observation

Validate that the stated requirements match the stakeholder's

understanding of the problem and needs. This important step ensures that
you clearly understand stakeholder intentions and any related issues that
might impact your requirements and your project
t the requirements be

chniques to elicit
each technique.
dation activities. For example,
nts may be discovered. This

gin. The combined results of

d during the analysis activities,
Stakeholders
All stakeholders
Project Manager
Stakeholders
Customer
Domain SME
End User
Supplier
Sponsor
Implementation SME
Operational Support
Project Manager
Supplier
Tester
Stakeholders
Business Analyst
Stakeholders
Business Analyst
Any stakeholders
Requirements Analysis

The tasks found in the Requirements Analysis knowledge area focus on analyzing the stated requirements from your elicitation efforts and building the real stakeholder or solution requirements for your
project. The stated requirements were provided to you by your project stakeholders during requirements elicitation. The real requirements define the derived needs of your stakeholders after your
structured and collaborative requirements analysis efforts are complete.

The Requirements Analysis knowledge area focuses on analyzing what your stakeholders have told you and defining which capabilities need to be part of the resulting solution. Requirements Analysis
knowledge area is where you develop your stakeholder and solution requirements for your project.
- Stakeholder requirements describe the capabilities of the solution that will meet the stakeholder needs
- Solution requirements are more detailed requirements, describing the behavior of the solution components so that those components can actually be created later in the project life cycle
- Business requirements are developed by tasks in the Enterprise Analysis knowledge area.
- Transition requirements are built by the Solution Assessment and Validation tasks.

The tasks in the Requirements Analysis knowledge area begin by developing the project's stakeholder requirements and continue until the more detailed solution requirements are completed. Typically,
defining the stakeholder and solution requirements on your projects takes place in the controlled middle of the project life cycle as part of the project's requirements development or definition phase.

Note: The performance of all requirements analysis activities are governed by the business analysis plans and business analysis performance metrics should be tracked
Requirements Analysis - Task 1 (Prioritizing Requirements)
Prioritization of requirements ensures that analysis and implementation
efforts focus on the most critical requirements.
Requirement prioritization is a decision process used to determine the
relative importance of requirements. The importance of requirements may
be based on their relative value, risk, difficulty of implementation, or on
other criteria.
Elements Techniques
1. MoSCoW Analyais
2. Timeboxing / Budgeting
3. Voting
1. Basis for requirement prioritization 9.8. Decision Analysis
- Business Value: The most valuable reqmt will be 9.24. Risk Analysis
development first. Used when enhancing an existing
solution
- Business or Technical Risk: The highest risk to the
project failure will implement first
- Implementation Difficulty: The easiest reqmt first.
This is used during a pilot of new process or tools or
when rolling out a packaged solution
- Likelihood of Success: The reqmt that are likely to
produce quick and relatively certain successes.
Used when a project is controversial and early signs
of progress are needed to gain support
- Regulatory or Policy Compliance: Prioritizes reqmt
to meet regulatory or policy demands
- Relationship to Other Requirements: A reqmt may
not be high value in itself, but may support other
high-priority reqmt
- Stakeholder Agreement: Requires stakeholders to
reach a consensus on which reqmts are most useful
or valuable
- Urgency: Prioritizes requirements based on time
sensitivity
2. Considering prioritizing challenges
The facilitator must recognize and focus on the
need for trade-off decision making
- Non-negotiable Demands: Stakeholders attempt to
avoid difficult choices, fail to recognize the necessity
for making tradeoffs, or desire to rank all
requirements as high priority
- Unrealistic Tradeoffs: The solution development
team may try to influence the prioritizing the result
by overestimating the difficulty or complexity of
implementing certain requirements
Requirements Analysis - Task 2 (Organizing Requirements)
To create a set of views of the requirements for the new business solution
that are comprehensive, complete, consistent, and understood from all
stakeholder perspectives
Two key objectives:
- Understand which models are appropriate for the business domain and
solution scope
- Identify model interrelationships and dependencies
Elements Techniques
9.12. Functional Decomposition
1. Define level of abstraction or detail 9.19. Organization Modeling
It is important for you to understand the
9.4. Business Rules Analysis
levels of abstraction in your project requirements
and factor them into your requirements 9.6. Data Flow Diagrams
elicitation and analysis activities across the project 9.7. Data Modeling
life cycle 9.21. Process Modeling
9.26. Scenarios and Use Cases
9.27. Scope Modeling
9.33. User Stories
2. Selecting requirements modeling techniques
Model is used to describe the solution scope and
meet the informational needs of stakeholders
5 general modling concepts:
- User Classes, Profiles, or Roles: These models
categorize and describe the people who directly
interact with the solution, grouping them by their
needs, expectations, and goals for that solution. It is
used in organization models, process models, use
cases
- Concepts and Relationships: Concepts usually
correspond to something in the real world; a place,
a person, a thing, an organization. They define the
objects, entities or facts that are relevant to the
business domain and what relationships they have
with other concepts
- Events: A request to a business system or
organization to do something e.g. a customer
placing an order. An event can be internal or
external, occur randomly or regularly. It is used in
scope models, process models, state diagrams, use
cases
- Processes: A sequence of repeatable activities
executed within an organization involving people
and system. It is used in organization models, state
diagrams, use cases
- Rules: Guide how people make decisions and
define the range of valid values for change. Used in
process models, state diagrams, use cases
Requirements Analysis - Task 3 (Specifying and Modeling Requirements)

Elements Techniques
1. Writing text requirements 9.4. Business Rules Analysis
9.6. Data Flow Diagram
2. Using matrix documentation
Used when a set of requirements have a complex 9.7. Data Modeling
but uniform structure which can be broken down into 9.17. Nonfunctional Requirement Analysis
elements that apply to every entry in the table 9.21. Process Modeling
9.26. Scenarios and Use Cases
3. Building textual or graphical models 9.28. Sequence Diagrams
6 reasons to use a model: 9.29. State Diagrams
- Describe a situation or define a problem 9.33. User Stories
- Define business domain boundaries
9.5. Data Dictionary and Glossory
- Describe processes and the fl ow of action
- Categorize and create hierarchies of items 9.12. Functional Decomposition
- Show components and their relationships 9.13. Interface Analysis
- Show business logic 9.14. Metrics and KPIs
9.19. Organiziation Modeling
4. Capture requirements attributes
Capture the reqmt attributes defined in the 9.22. Prototyping
Requirements Management Plan (BA Planning and
Monitoring)

5. Seek opportunities for improvement

Opportunities likely to identify:
- Automate or simplify the work people do
To analyze expressed stakeholder desires and/or the current state of the - Improve information access across organization
organization using a combination of textual statements, matrices, diagrams - Reduce complexity of interfaces between systems
and formal models. and people
- Increase consistency in how people behave
- Eliminate redundancy across stakeholders
Requirements Analysis - Task 4 (Defining Assumptions and Constraints)

Elements Techniques
9.20. Problem Tracking
1. Assumptions 9.24. Risk Analysis
Factors that believed to be true, although these
factors have not been confirmed. Assumptions can
relate to something in the present or in the future. If
an assumption is found to be false it will usually
impact the project
2. Business Constraints
Restrictions or limits on the solution or the current
organizational state e.g. Available time, money,
resources

3. Solution Contraints
Decisions that limit the solution design. They tend to
be inflexible and unchanging, and can impact
solution implementation e.g. development
languages, hardware, software

Identify factors other than requirements that may affect solutions

Requirements Analysis - Task 5 (Verifying Requirements)
A quality check of the analyzed requirements. This task involves making
sure your requirements are correct and complete, and that they meet the
quality standards defined for them
Elements Techniques
1. Checklist
9.30. Structured Walkthrough
9.1. Acceptance and Evaluation Criteria
1. Characteristics of requirements quality Definition
- Cohesive: A set of requirements relating to one 9.20. Problem Tracking
particular thing e.g. a business process, business
rule, organizational unit. All requirements in a set or
model should support its overall purpose and scope
- Complete: The entire set of requirements should
represent all relevant reqmts. Specify everything
that is needed at the appropriate level of detail
- Consistent: Individual requirements do not
contradict each other and level of details should be
the same at a specific numbering level
- Correct: Defects in requirements will lead to
defects in the resulting solution
- Feasible: The existing budget, timeline, resources,
infrastructure should be adequate to implement your
requirements as defined
- Modifiable: Related requirements must be grouped
together in order for requirements to be modifiable
- Unambiguous: Individual requirements must never
be unclear
- Testable: All requirements must be measurable
and provable. Testing proves that what is needed is
indeed present in the solution
2. Requirements verification activities
Performed iteratively throughout the requirements
analysis process
Requirements Analysis - Task 6 (Validating Requirements)

Elements Techniques
1. Identify assumptions 9.1. Acceptance and Evaluation Criteria
2. Define measurable evaluation criteria Definition
9.16. Metrics and KPI
3. Determine business value 9.22. Prototyping
The business case defines the value delivered by a
9.24. Risk Analysis
solution that meets the solution scope, but it is also
possible to assess individual requirements or 9.30. Structured Walkthrough
features to determine if they also deliver business
value
4. Determine requirements dependencies
5. Evaluate Alignment with Business Case and
Opportunity Cost

To ensure that all requirements support the delivery of value to the

business, fulfill its goals and objectives, and meet a stakeholder need. It is
an ongoing process to ensure that stakeholder, solution, and transition
requirements align to the business requirements
solution requirements for your
stakeholders after your

ution. Requirements Analysis

project life cycle

ents are completed. Typically,

pment or definition phase.
Stakeholders
Domian SME
Implementation SME
Project Manager
Sponsor
Stakeholders
Domain SME
End User
Implementation SME
Sponsor
Project Manager
Stakeholders
Any stakeholder
Stakeholders
Implementation SME
Project Manager
All stakeholders
Stakeholders
All
Stakeholders
All
Solution Assessment & Validation

The Solution Assessment and Validation Knowledge Area describes the tasks that are performed in order to ensure that solutions meet the business need and to facilitate their successful
implementation. These activities may be performed to assess and validate business processes, organizational structures, outsourcing agreements, software applications, and any other component of
the solution.

Business analysis ensures that the process of reviewing, selecting, and designing the solution is done in a way that maximizes value delivered to stakeholders. The business analyst knows the business
environment and can assess how each proposed solution would affect that environment. The business analyst is responsible for ensuring that stakeholders fully understand the solution requirements
and that implementation decisions are aligned with the relevant requirements.

Four different assessments are created by and used:

1. Solution Performance Assessment describes how the operational solution is performing relative to business goals and objectives.
2. Solution Validation Assessment assesses the solution’s ability to meet the business need at an acceptable level of quality.
3. Organizational Readiness Assessment describes stakeholder readiness to accept the change associated with a solution and their ability to use the solution effectively.
4. Assessment of Proposed Solution or Solutions assesses the value delivered by each proposed solution and recommends the best solution.

Note: the performance of all solution assessment and validation activities are governed by the business analysis plans, and business analysis performance metrics should be tracked
Solution Assessment & Validation - Task 1 (Assess Proposed Solution)

Elements Techniques
2 elements to prioritize the stakeholder or solution 9.1. Acceptance and Evaluation Criteria
requirements 9.8. Decision Analysis
9.34. Vendor Assessment
1. Ranking solution options
Use a set of evaluation criteria to access solution
options. For more complex decision problems, a
scoring system may be used, with sets of related
requirements assigned a weighting to reflect their
relative importance to the organization. Each
solution is scored and the top-rated solution or
solutions are then investigated in greater detail

2. Identification of additional potential capabilities

Solution options might provide capabilities beyond
the requirements. Decide if these additional solution
capabilities provide value to the organization, either
now or in the future

To assess proposed solutions in order to determine how closely they meet

stakeholder and solution requirements. Solution assessment may be
performed on a single solution or to compare multiple proposed solutions.

When assessing a single solution, the BA determines whether the solution

delivers enough business value to justify its implementation. This will most
often be the case when a custom solution has been created to meet a
particular business need.

When assessing multiple alternative solutions, the BA has the additional

goal of attempting to determine which solution delivers the greatest
business value. This requires understanding the advantages and
disadvantages of each alternative.
Solution Assessment & Validation - Task 2 (Allocate Requirements)

Elements Techniques
9.1. Acceptance and Evaluation Criteria
Definition
9.4. Business Rules Analysis
9.8. Decision Analysis
1. Allocating requirements to solution components
9.12. Functional Decomposition
The majority of business solutions will be composed
of multiple components. Each component 9.21. Process Modeling
implements a subset of the requirements. The 9.26. Scenarios and Use Cases
allocation of requirements to solution components
will be a primary driver of the cost to implement the
solution and the benefits delivered by it.
You will most likely allocate your requirements
several times before achieving a cost-effective
implementation of the solution scope. Requirements
allocation will involve assessing available resources,
solution constraints, and your requirements
dependencies
Solution components:
business process, policies, rules, people with job
functions & responsibilities, software applications &
application components, organization structure & its
internal/external interactions

2. Perform release planning

You also have to decide which requirements will be
Allocate stakeholder and solution requirements to solution components included in each project release. Deploying
and releases in order to maximize the possible business value given the solutions with a phased approach reduces the initial
options and alternatives generated by the design team cost of implementation and offers you the ability to
phase in solution functionality over time
Allocating requirements begins early in a project, typically right after the
solution approach is determined as part of the Enterprise Analysis
knowledge area work. Requirements allocation is ongoing and incremental,
continuing until all of the solution requirements for your project have been
allocated
Solution Assessment & Validation - Task 3 (Assess Organizational readiness)

Elements
1. Culture assessment
Determine whether stakeholders understand the
reasons to implement new solution, whether they
view the solution is beneficial. Assess the beliefs,
attitudes and feelings common to key stakeholder
groups and the willingness of accept a change
2. Operational or technical assessment
Determine whether the organization is able to
benefit from the new solution, and whether
stakeholders are prepared for it. Determine if
training is required, whether need to create new
policies & procedures to facilitate the use of new
solution, whether system support & maintenance is
required prior to solution implementation
Techniques
1. Force Field Analyasis
A graphical method to:
- identify the forces that support and
oppose a change
- depict them on opposite sides of a line
- estimate the strength of each force in
order to assess which set of forces are
stronger
Once this analysis is complete, look for
ways to strengthen the forces that support
the desired outcome or generate new
forces

3. Stakeholder impact analysis

Understand how change will affect the stakeholders
in the following areas:
- Functional: any new or modified process,
applications being impacted?
- Location: Are the stakeholders located in a single 9.1. Acceptance and Evaluation Criteria
Assess whether the organization is ready to make effective use of a new place or in a distributed team? Will the change Definition
solution. It identify the effect a new solution will have on an organization affect their communications? 9.6.. Data Flow Diagram
and whether the organization is prepared for the organizational change - Tasks: Will the change alter how tasks are 9.11. Focus Groups
that the solution implementation will cause. performed, or affect the skill levels required to
Effective communication of solution impacts assists in enabling necessary 9.14. Interviews
perform them? Will stakeholders have more or less
organizational change management practices and identifying training flexibility in performing their tasks? 9.19. Organization Modeling
requirements for solution implementation - Concerns: solution usability, work demands, 9.20. Problem Tracking
potential job loss, or changes in work satisfaction 9.21. Process Models
9.24. Risk Analysis
9.31. Survey/Questionnaire
9.32. SWOT Analysis
Solution Assessment & Validation - Task 4 (Define Transition Requirement)

Elements Techniques
9.4. Business Rules Analysis
1. Data 9.6. Data Flow Diagram
Need to review the data used by existing solution to
9.7. Data Modeling
see if there is a need to archieve or migrate to new
solution. Rules for conversion, business rules may 9.19. Organization Modeling
need to be defined to ensure that the new solution 9.21. Process Modeling
interprets the converted data correctly

2. Ongoing work
Options for managing ongoing work:
- finishing existing work using the current solution
and starting new work in the new solution
- holding the processing of new work for a period of
time
- converting all work at the time of implementation

3. Organizational change
Develop recommendations for changes to the
organizational structure or personnel, as job
functions may change significantly as the result of
work being automated. New information may be
made available to stakeholders, and new skills may
be required to operate the solution

To define requirements for capabilities needed to transition from an

existing solution to a new solution.
Transition requirements are elicited, analyzed, managed & communicated
just like the other requirements. However they cannot be defined until after
that solution has been designed. They are no longer needed after the new
solution is operational
A successful transition period may include:
- Operating the old and new solutions in parallel
- Migrating information between the old and new solution
- Conducting stakeholder training on the new solution
- Developing new capabilities to support the transition period
Solution Assessment & Validation - Task 5 (Validate Solution)

Elements Techniques
1. Investigate defective solution outputs 9.1. Acceptance and Evaluation Criteria
Occurs when outputs from the solution are below an Definition
acceptable level of quality. It requires investigation 9.20. Problem Tracking
and resolution as part of solution validation activities 9.25. Root Cause Analysis

2. Assess defects and issues

Defects are reviewed to assess the effect on the
operations - severity, probability of occurrence,
business impact, capacity of absorbing the impact.
Identify which defects must be resolved, which can
be mitigated through workarounds, and which can
be accepted until resources exist to address them
Ways to mitigate the impact through workaround:
- Add quality control checks
- Introduce new manual processes
- Remove support for exceptions and errors

To ensure that a delivered solution meets the business needs on an

ongoing basis. Problems that are identified through solution validation will
be reported and prioritized for resolution. BA will help to determine the
most appropriate action.
Solution Assessment & Validation - Task 6 (Evaluate Solution Performance)
Investigating how a solution is actually used after it is deployed, and
assessing the positive and negative impact. It may also referred to post-
implementation assessment performed immediately after project
completion
If user create new ways of using the solution (e.g. manual workaround,
recording additional info, adopting informal procedures), need to
understand when, where and why this has occurred and assess the benefit
that these changes have brought to the organization
Elements Techniques
9.8. Decision Analysis
1. Understand the value delivered by the solution 9.11. Focus Groups
Gather the actual metrics that describe the solution 9.18. Observation
performance. 9.31. Survey/Questionnaire
Solution could be under-performance & addressing
it might becomes a business need. Significant over-
performance may indicate that resources can be
used elsewhere, or the value of the solution to the
business was underestimated
2. Validate the solution metrics
If the metric show excellent result but it doesn't align
with the business goals & objective, there might be
a flaw in the metric. It should be validate & define
more appropriately
3. Consider solution replacement or elimination
Solution might need to replace due to:
- outdated technology
- change in business goals & objectives
- services being insourced or outsourced
4 issues that may influence the decision:
- Ongoing cost vs initial investment
- Opportunity cost: potential value that could have
gain by adopting new solution
- Necessity: most solution have a limited lifespan
due to obsolate, change in market condition
- Sunk cost: money & effort already spent in the
current solution
 their successful
and any other component of

ss analyst knows the business

d the solution requirements

be tracked
Stakeholders
Domain SME
Implementation SME
Operational Support
Project Manager
Supplier
Sponsor
Stakeholders
Customers
Suppliers
Domain SME
End User
Implementation SME
Operational Support
Project Manager
Tester
Sponsor
Stakeholders
Domain SME
Implementation SME
- Org Chg Mgmt SME
- Usability SME
- Training SME
Operational Support
Project Manager
Sponsor
Stakeholders
Customer
Domain SME
End User
Implementation SME
Operational Support
Project Manager
Regulator
Tester
Sponsor
Stakeholders
Domain SME
End User
Implementation SME
Operational Support
Project Manager
Tester
Regulator
Sponsor
Stakeholders
Customer
Domain SME
Supplier
End User
Operational Support
Regulator
Sponsor
Areas Underlying Competencies
Creative Thinking
Decision Making
Analytical Thinking and
Learning
Problem Solving
Problem Solving
Systems Thinking
Ethics
Behavioral Characteristics Personal Organization
Trustworthiness
Business Principles and Practices
Industry Knowledge
Business Knowledge
Organization Knowledge
Solution Knowledge
Oral Communications
Communication Skills Teaching
Written Communications
Facilitation and Negotiation
Interaction Skills Leadership and Influencing
Teamwork
General-Purpose Application
Software Application
Specialized Application
Technique Purpose
9.1 Acceptance and To define the requirements that
Evaluation Criteria must be met in order for a solution
Definition to be considered acceptable to key
stakeholders.

9.2 Benchmarking To compare the strength &

weaknesses of an organization
against its peers & competitors

9.3 Brainstorming Creative thinking about a problem,

produce new ideas for further
analysis

MoSCoW Analyais
 Timeboxing /
Budgeting

9.12 Functional
Decomposition
9.19 Organization
Modeling

Baselining

Sign-off
9.20

Problem Tracking

Coverage Matrix

Requirements
Documentation

Requirements for
Vendor Selection
9.23
Requirement
Workshops
9.30 Structure
Walkthrough
9.25 Root Cause Analysis

9.9 Document Analysis

9.32 SWOT Analysis

Problem or Vision
Statement

9.24 Risk Analysis

RACI Matrix

Stakeholder Map
9.10 Estimation

Variance Analysis

9.16 Metrics & Key

Performance
Indicators

Checklist
Description Elements
Acceptance criteria - minimal set of requirements that 1. Testability
must be met in order for a solution to be considered Must be expressed in a testable form e.g. test cases
acceptable by stakeholders. It is typically used when written to verify the solution against the criteria
only one possible solution is being evaluated and are 2. Determine Ranking & Scoring
generally expressed as a pass or fail Ranking - determine the order of importance of all
requirements
Evaluation criteria - set of requirements that will be Scoring - determine how well a solution meet a
used to choose between multiple solutions. It is used requirement
to compare multiple solutions and allow for a range of Stakeholders must agree on the criteria & how the
possible scores solution be rated

To determine how companies achieve their 1. Identify the area to be study

performance levels and use that info to design
projects to improve operations of the enterprise. It is
usually focus on stragegies, operations & processes
2. Identify the org leader in the sector
3. Conduct survey of selected org to understand their
practices
4. Arrange for visits to selected org
5. Develop project proposal to implement best
practices

It focus on a topic or problem, then come up with 1. Preparation

many possible solutions, and best apply to a group
It helps to answer specific questions:
- what options available to resolve the issue
- what factors preventing the group from moving
ahead with an approach or options?
- what could be causing a delay in activity
- what can the group to solve the problem
- develop a clear & concise definition of interest area
- develop a time limit for the group discussion
- identify facilitator & participants, aim for participants
from a range of backgroup & experience with the topic
- set expectation & get their buy in to the process
- establish criteria for evaluating & rating the ideas
2. Session
- share new idea without
3. Wrap-up

Works best as a group technique
- Must: Very high priority item that Must be satisfied in
order to be considered a success
- Should: Very high priority item that Should be
included if possible. Might have workarounds or may
not be as time critical
- Could: Desirable but not necessary. Will be included if
time and resources available
- Won’t: Will not be implemented in a given release, but
may be considered for the future
Timeboxing - prioritizes requirements based on the
amount of work that the project team is capable of
delivering in a set period of time
Budgeting - when the project team has been allocated
a fixed amount of money
3 approaches:
- All In: Include all eligible requirements first, then
remove them one by one in order to meet the calendar
dates or budget limit
- All Out: Add eligible requirements one by one until the
calendar dates are met or budget limit is reached
- Selective: Add high priority requirements and then
add / remove them until date & budget is reached

Breaks down the solution scope into component parts - Task-focused using a WBS
base on a group of related funcationalities - Product-focused using a solution breakdown
Describes the various organizational units,
stakeholders, and their relationships e.g. Organization
Chart
- reviewed & agreed-upon requirements at a specific
point in time
- any changes to the baselined requirments must go
through a formal change control process and is being
recorded & tracked

Formal agreement from stakeholders that the content

& presentation of the requirements was accurate and
complete
Allow BA to manage any issues identified with
requirements by stakeholders & ensure that those
issues are resolved
3 key pieces to this technique:
- create problem tracking system containing the
problem records
- decide on problem metrics & KPI to measure & report
- manage the recorded problems until they are fixed

A table or spreadsheet used to manage & facilitate

tracing of requirements. It is specific to the Manage
Requirements Traceability task
Several common types of RD:
- Business requirements document
- Product roadmap
- Software or system reqmt spec
- Supplementary reqmt spec
- Vision document

Document in 3 ways:
- Request for Information (RFI): short documents
asking specific questions about the services provide.
Used when organization is open to alternative solution
& is seeking information to evaluate possible options
- Request for Quote (RFQ): A request for solution
pricing. It allows vendor to provide a solution cost & is
used to get an idea of the cost
- Request for Proposal (RFP): Provide potential
vendor with detailed information. Vendor answer
specific, solution-focused questions about how their
solution will meet organization's needs & goals. It is
used when you know what you want & are making
detailed vendor selection
structured meetings where selected group of
stakeholders work together to define a set of proejct
requirements
team review of project deliverables. Attendees are
looking for errors or omissions in the requirements
- Fishbone Diagram
- Five Whys
To elicit, confirm, corss-check information by studying
existing documents.
It involves 3 stages:
- Preparation
- Actual document review
- Wrap-up

sing a matrix or grid 2 dimension:

- internal strength and weaknesses of the organization
- external opportunities & negative threats

- states the business need

- identifies key stakeholders
- briefly describes the positive impact on stakeholders

Risk response strategies:

Positive or negative:
Accept - do nothing
Positive:
Share - work with third party to increase the probability
& share the benefit
Enhance - increase the probability
Exploit - ensure the risk does occur
Negative:
Transfer - transfer to a third party
Avoid - take measure to ensure risk does not occur
Mitigate - reduce the probability or the impact of
occuring

- Responsible does the work

- Accountable is the decision maker (only 1)
- Consulted must be consulted prior to the work &
gives input
- Informed means they must be notified of the
outcome

- Stakeholder Matrix: influence vs interest

- Stakeholder Onion Diagram
1. Analogous estimation - uses similar projects as the
basis for top-down estimates
2. Parametric estimation - uses parameters &
historicial data
3. Bottom-up estimation - estimates smaller items first
& aggregates upward
4. Rolloing wave - refines detail estimates for
increments of work over time
5. Three-point estimateion - estimates optimistic,
pessimistic, & most likely cases
6. Historic analysis - uses history as basis for bottom-
up & top-down estimates
7. Expert judement - relies on those who performed
similar work in the past
8. Delphi estimateion - combines expert judgment &
history

- Compare planned vs actual performance,

determinate magnitude of those discrepancies &
recommend corrective & preventive actions
- Measure project variables on estimates, costs,
scope, product

KPIs - indicators to measure performance or progress Good indicators:

of solution toward strategic goals or objectives - Clear
Metrics - basic monitoring & evaluation of BA work - Economical
activities & deliverables to meet overall solution goals - Quantifiable
Indicators - identify numeric measurements indicating - Relevant
progess towards deliverable - Adequate

Checklists are useful as a quality control technique for Checklists ensure that important items are included in
requirements documentation the fi nal requirements deliverables for your project. It
may also contain process steps to guide you through
the requirements verification activities that should be
done on your project
Usage considerations
1. Advantages
- Agile method require reqmt to be expressed
in the form of testable acceptance criteria
- acceptance criteria require when express
contrctual obligation

2. Disadvantages
- may express contractual obligations

1. Advantages
- provides info about new & different methods,
ideas, tools to improve org performance

2. Disadvantages
- time consuming, may not have expertise to
conduct the analysis, acquire or interpret
useful competitive info. It cannot produce
innovative solutions or produce sustainable
competitive advantages