business analysis introduction: defining successful...

Business Analysis Introduction: Defining Successful Projects

Course 211

211/CN/H.2/407/H.1

© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent.

© LEARNING TREE INTERNATIONAL, INC.All rights reserved.

All trademarked product and company names are the property of their respective trademark holders.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, or translated into any language, without the prior written

permission of the publisher.

Copying software used in this course is prohibited without the express permission of Learning Tree International, Inc. Making unauthorized copies of

such software violates federal copyright law, which includes both civil and criminal penalties.


The author would like to acknowledge the following for their contributionsto this course:

Steve Johann

All 211 instructors

Kevin Rock

Learning Tree Publications Department

Stephen O’Connell

Acknowledgments

Introduction and Overview


In this course, you will learn how to

Perform the key functions of the Business Analyst (BA) by applying the International Institute of Business Analysis (IIBA) business analysis framework

Apply the techniques to elicit requirements in your organization

Create the business analysis plan

Evaluate and prioritize the feasibility of various business initiatives and present the business case

Understand the BA’s role in solution evaluation and performance assessment

Develop key business analysis competencies

Course Objectives

20-


Introduction and Overview

Chapter 1 The Role of the Business Analyst, Definitions, and Introducing the IIBA BABOK®

Chapter 2 Business Analysis Planning and Monitoring

Chapter 3 Enterprise Analysis

Chapter 4 Elicitation

Chapter 5 Requirement Analysis

Chapter 6 Requirements Management and Communication

Chapter 7 Solution Assessment and Validation

Chapter 8 Business Analysis Competencies and Capstone Exercise

Chapter 9 Course Summary

Course Evaluation

Appendix A Optional Workshops

Course Contents

30-


Course Materials

40-

Course Notes• Copies of all slides and supplemental

presentation material

Handouts

Reference Manual

Visit your My Learning Tree account for additional information and resources related to this course


Independent, nonprofit professional association serving the field of business analysis

Committed to developing and advancing standards for the practice of business analysis and for the certification of practitioners• Certified Business Analysis Professional™ (CBAP®)• Certification of Competency in Business Analysis™ (CCBA™)

Custodians of the Business Analysis Body Of Knowledge® (BABOK®)

Founded in 2003 and headquartered in Toronto, Canada

More than 25,000 members with chapters in more than 100 countries

Learning Tree International is an IIBA Endorsed Education Provider (EEP™)

For more information, see www.iiba.org

International Institute of Business Analysis (IIBA®)

IIBA®, the IIBA® logo, BABOK®, and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP ® is a registered certification mark owned by International Institute of Business Analysis. CCBA™ is a trademark owned by International Institute of Business Analysis. These trademarks and certification marks are used with the express permission of International Institute of Business Analysis.

50-


The Project Management Institute (PMI)® is a nonprofit professional project management association• PMI grants multiple certifications, including the Project Management

Professional® (PMP)® certification, an industry standard for project management

Learning Tree International is a PMI Global Registered Education Provider• This course can be applied toward the Professional Development Units

(PDUs) required to– Maintain an existing PMP certification– Satisfy the educational requirement for PMP candidates

For more information about PMI-aligned Learning Tree courses• Refer to the PMI Q&A available at www.LearningTree.com/pmi

Project Management Institute (PMI)

PMI, Project Management Professional, and PMP are registered marks of the Project Management Institute, Inc.

60-


Business analysts participate in different tasks depending on various factors, including• Individual skill level, etc.• Organizational design, role/responsibility descriptions• Company size• Project complexity/needs

This course provides an overview of the tasks and techniques often conducted by business analysts• Business analysts may not conduct all tasks on all projects

Broad Overview Approach

70-


To promote a positive course experience over the next three days, we have some ground rules:• This is an introductory course

– Recognize that topics will be introduced but not always covered in great detail

• It is all right not to complete the workshops in their entirety– The workshops are introduced to help you understand concepts and

processes• Your instructor will be happy to answer all questions, provided that you allow

the following responses:– “We’ll be discussing that later”– “I don’t know!”

• Be open to new ideas• Participate• Be considerate of your classmates

– Turn off the ringer on mobile phones and pagers• Have fun!

Ground Rules

80-


Work as a team

Use your AnyWare connection to click on the link to your digital whiteboard

We have set up an introductory page for you to try out

Activity 0.1: Part 1: Introduction to the Digital Whiteboard

90-


The Business Process Manager will interview their team, using the digital whiteboard to document each member’s:• Background• Aims for this course • Interests outside this course

Be prepared to introduce your team to the rest of the class

Activity 0.1: Part 2: Introduce Your Team

Be ready to present by:

100-

The Role of the Business Analyst, Definitions, and Introducing the IIBA BABOK®

Chapter 1

2© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1-

In this chapter, we will

Define business analysis

Explore the role of the business analyst and the relationships with other roles in an organization

Investigate the scope of the business analyst’s work

Introduce the IIBA Business Analysis Body of Knowledge®

Position business analysis within the project life cycle

Chapter Objectives


Chapter Contents

Workshop 1.1 Defining the Business Analysis Role

Workshop 1.2

Workshop 1.3

In Scope/Out of Scope

Introducing the IIBA and the BA Knowledge Areas

Project Life Cycle Review

Workshop 1.4


You will be asked to take a turn playing the role of the business analyst for each workshop during this class

As the business analyst facilitating the workshop, you will demonstrate and practice some of the BA’s underlying competencies from the IIBA Business Analysis Body of Knowledge®

While facilitating, keep some of the following guidelines in mind:• Make sure that everyone has an opportunity to participate• Think about how you gain consensus during these workshops• What benchmarks/measurements will you use?• Control the conversation and ensure that you stay on track

Your duties as BA will include• Documenting the results of your workshop on the flipchart• Presenting your findings to the rest of the class

Role of the Business Analyst During a Workshop


Work individually

On sticky notes, write at least five comments extending the following statement

“Business analysis would work better in my organization if:”• Include a verb• Use eight words or fewer per comment

Workshop 1.1a: Your Business Analysis Process

Sample acceptable comments:• We had more frequent communications

from upper management • Employees had more training

opportunities

Sample unacceptable comments:• Judy learned how to do her job

and stopped asking me to do it• Communications


Pick a new business analyst for this workshop• The business analyst will facilitate your ideas using the digital whiteboard

Work as a team

1. Go to Workshop 1.1b on your digital whiteboard

2. Discuss your notes and group them into categories

3. Agree on a title for each category• Your output should look like the table on this slide

If you have time left over, prioritize your categories!

This is a brainstorming elicitation technique called affinity diagramming

Workshop 1.1b: Your Business Analysis Process


Chapter Contents

Workshop 1.1

Defining the Business Analysis Role

Workshop 1.2

Workshop 1.3




Workshop 1.4


What Is Business Analysis?

*A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business Analysis, 2009.

“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals”

—BABOK Guide*

Business analysis is a discipline, not a job title

Business analysis is not defined by your job title as a business analyst, but rather by what you do in your workplace


Exact roles and responsibility distinctions between project managers and business analysts can vary by organization or project

Business analysts may be involved during the earliest phases of project definition

Business analysts primarily focus on the product or service, while project managers focus on the overall project

The BA is responsible for ensuring that the product is built according to requirements

Business Analysis vs. Project Management


System design analyst• Analyzes solution requirements and translates them into system requirements

and design

Quality Assurance (QA) tester• QA is responsible for ensuring that business requirements are tested

Trainer• The BA is in a supporting role; often first time that the end user experiences

the new system or process

Support of system• Opportunity to start “new”

• Can you name other roles within your organization that use business analysis skills?

Business Analysis vs. Other Roles in Your Organization


Chapter Contents

Workshop 1.1


Workshop 1.2 Workshop 1.3




Workshop 1.4


Case Study Introduction

Dept. 1

Dept. 8

Dept. 2

Dept. 3 Dept. 4

Dept. 7

Dept. 6Dept. 5

Creative services

Finished products• Finished TV shows• Finished films• Production schedules• Movie posters• Movie trailers• Photographs

Request content

Provide contentCurrent content acquisition process


Work individually

1. Read the case study Handouts 1 and 2

2. Identify the following information:• What problems does Franklin Films have?• What are the potential opportunities?• What risks and constraints are listed in the case

study?• Who are some of the key players?

If you finish before the time is up:

3. Think about some next steps to address the potential challenges• Focus on the additional information you will need

and how you can get this information

Workshop 1.2: Introducing the Case Study


After reviewing the material, the instructor will conduct a digital archive demonstration with www.artbeats.com

• Have you seen other examples of digital archiving solutions?

Case Study Introduction


Chapter Contents

Workshop 1.1


Workshop 1.2

Workshop 1.3 In Scope/Out of Scope



Workshop 1.4


1. Identify a new business analyst to lead this workshop

2. Work as a team• Consider what questions the BA and other roles might ask at the beginning

stage of the Franklin Films project

Go to the digital whiteboard for this workshop and record your questions

Does the same person ever play these various roles?

Workshop 1.3: Business Analysis vs. Project Management

BA primaryquestions

Other project roles’*primary questions

PM primary questions

*Consider trainer, tester, and implementer.


Chapter Contents

Workshop 1.1


Workshop 1.2

Workshop 1.3

In Scope/Out of Scope Introducing the IIBA and the BA

Knowledge Areas


Workshop 1.4


Identify problems and opportunities Business needs

Clarify and prioritize business needs

Recommend potential projects to address these needs Sell

Gather, analyze, and document requirements

Communicate Interface/facilitate/translate

What Is Typically in Scope for a Business Analyst?


Facilitating communications between business and IT communities

Using basic skills (in strategic and functional disciplines)

What Is Typically in Scope for a Business Analyst?

Business analyst

Human resources

Quality assurance

Finance

Information technology

Marketing

Project management


Representing his or her own “agenda”

Authorizing projects or providing funding

Implementing solutions

Living exclusively in the worlds of business or IT

Providing deep expertise in either strategic or functional discipline areas

What Is Typically Out of Scope for a Business Analyst?


BA Often Acts as Intermediary Between Business and IT

Keys to success:

• Ideally having a background in both business and technology

• Focusing on the requirements (the “what”) before considering potential solutions

• Using a work style that balances both tasks and relationship focus

• Building strong relationships

• Using objective prioritization and consensus-building techniques

Common challenges:

• Interpreting different “languages”

• Avoiding the temptation to jump to solution development

• Focusing on task while maintaining positive relationships

• Mediating differences

• Balancing priorities


Chapter Contents

Workshop 1.1


Workshop 1.2

Workshop 1.3




Workshop 1.4


The BABOK® Knowledge Areas

EnterpriseAnalysis

SolutionAssessment and

Validation

RequirementsAnalysis

UnderlyingCompetencies

RequirementsManagement andCommunication

Elicitation

The BABOK does not stipulate a particular process or an order in which tasks are performed.Graphic: A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business Analysis, 2009.

Business AnalysisPlanning and

Monitoring


The model is composed of six key knowledge areas

Knowledge areas are broken down into tasks that describe the work that the business analyst will perform on projects• Tasks are not necessarily sequential but rather iterative• The techniques detail how the business analyst will produce the tasks

– For example, BAs conduct stakeholder analysis by producing a RACI matrix

• This course will focus on the knowledge areas– Highlights the essential tasks that the business analyst most often performs

inside of each knowledge area and points to the techniques that help BAs perform these tasks


RACI = responsible, accountable, consulted, informed


Business analysis planning and monitoring• Governs performance of all other business analysis tasks• Select business analysis tasks and techniques to manage requirements and

assess progress of work• Identify and analyze your stakeholders• Understand exactly what your deliverables will be • Do this step at the beginning and clarify and validate as you go

Enterprise analysis• The tasks that are performed to identify the business need• Not only define and clarify the definitions of your business objectives, but also

understand the root cause and quantify the feasibility of moving forward• Culminates in the business case



Elicitation• Understand the needs of the stakeholders and their environment• Elicitation is not a one-time event• Deals with the “how to” of gathering requirements from the stakeholders• End goal is for requirements to be complete, clear, correct, and consistent

Requirements analysis• Prioritize and elaborate requirements so that you can effectively implement a

solution to meet your sponsor’s needs• Analyze the needs of your stakeholders• Assess current state

– Identify gaps and areas for improvement– Recommend improvements

• Verification and validation of requirements



Requirements management and communication• Manage conflict, risks, issues, and changes to your requirements• Ensure that agreement on solution scope is maintained• Communicate requirements to stakeholders• Maintain the information you have gathered for future use

Solution assessment and validation• Determine that the proposed solution(s) meets the specified business needs • Identify any gaps or shortcomings of solutions• Assess that the deployed solutions meet the stated benefits

Underlying competencies• Behaviors, knowledge, and other key characteristics that support the

effective/successful performance of the business analyst



Chapter Contents

Workshop 1.1


Workshop 1.2

Workshop 1.3



Project Life Cycle Review Workshop 1.4


Let’s review a generic project life cycle


Enterprise/problem analysis

Analyze the high-level needs/issues of the enterprise

Evaluate potential business initiatives

Envision potential future state

1 Design, develop, and test

Translate requirements into solution components

Design solution Validate requirements*

3

Implementation

Implement solution

4

Close project Provide ongoing

solution support Warranty Knowledge transfer

Maintenance/support

5

*Validation may be conducted at various points in the process.

Detailed requirements development

Elicit specific stakeholder wants and needs

Document and prioritize stakeholder requirements

2


Chapter Contents

Workshop 1.1


Workshop 1.2

Workshop 1.3




Workshop 1.4


1. Work as a team, and select a new business analyst to facilitate this workshop

2. Use the digital whiteboard for this workshop

3. Consider the five stages of the generic project life cycle:a. Enterprise/problem analysisb. Detailed requirements developmentc. Design, develop, and testd. Implementatione. Maintenance/support

4. Think about the business analyst’s level of involvement at each stage of the project life cycle in your organization, and rank each stage to indicate the typical involvement during that stage• High = heavy involvement• Medium = moderate involvement• Low = little or no involvement

5. Determine which BABOK® areas fit into each stage of the project life cycle

Workshop 1.4: The BA’s Role in the Project Life Cycle?


Workshop 1.4: What Is the BA’s Role in the Project Life Cycle?

Project life cycle stageLevel of BA involvement:H, M, L

BABOK® areas that apply during stage of project

1. Enterprise/problem analysis

2. Detailed requirementsdevelopment

3. Design, develop, and test

4. Implementation

5. Maintenance/support


In this chapter, we have

Defined business analysis

Explored the role of the business analyst and the relationships with other roles in an organization

Investigated the scope of the business analyst’s work

Introduced the IIBA Business Analysis Body of Knowledge®

Positioned business analysis within the project life cycle

Chapter Summary


Chapter Review

Role of the Business Analyst,

Definitions, and IIBA BABOK®

What are the six knowledge areas identified in the BABOK®?1.2.3.4.5.6.

True or false? The BA usually focuses on the project, while the PM usually focuses on the product.

True or false? The BA usually provides project authorization.

_____________ are the behaviors, knowledge, and other key characteristics that support the effective and successful performance of the business analyst.

Which knowledge area determines that the proposed solution(s) meets the specified business needs

Business Analysis Planning and Monitoring

Chapter 2



Introduce the key tasks of business analysis planning and monitoring

Plan the business analysis approach: plan-driven vs. change-driven

Identify and assess stakeholder roles and responsibilities

Identify key elements of the requirements management process

Encourage development of a change management process

Understand the importance of managing the business analyst’s performance

Chapter Objectives



A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business Analysis, 2009.

EnterpriseAnalysis


Validation




Elicitation


Monitoring


This is where you plan out your key tasks, what you will deliver, and who you will deliver to• As a business analyst, your plan is key to the overall project plan• Result is the detailed business analysis plan


Key inputs:• Business analysis

performance metrics• Business need• Enterprise

architecture• Expert judgment• Organizational

process assets

Key tasks:• Plan business

analysis approach• Conduct stakeholder

analysis• Plan business

analysis activities• Plan business

analysis communication

• Plan requirements management process

• Manage business analysis performance

Key outputs:• Business analysis

approach• Stakeholder list, roles,

and responsibilities• Business analysis plan• Business analysis

communication plan• Requirements

management plan• Business analysis

performance assessment

• Business analysis process assets


Chapter Contents

Key Tasks of the Business Analysis Plan Planning the Business Analysis Approach

Workshop 2.1

Documenting Key Assumptions

Conducting Stakeholder Analysis

Workshop 2.2

Planning Business Analysis Activities

Planning Business Analysis Communication

Planning the Requirements Management Process

Managing Business Analysis Performance


The Business Analysis Plan: Preplanning Checklist

Does your organization currently conduct sufficient requirements planning?

Which planning steps are conducted consistently?

Which planning steps need to be implemented?

Does the organization have a documented strategy for analysis?

Are there projects and metrics in place to deliver a strategy?

Will you be expected to conduct enterprise-level analysis?

Does the business know its business needs?

Do business requirements exist?

Which tools and techniques are available to help elicit the information you need to conduct appropriate analysis?

If you don’t specifically work in the area of requirements development, consider each of these questions in the context of general project planning!


Level of Analysis

Tactical

System

Strategic

Lower degree of change—less complex—costs and benefits

short term

Medium impact—less complex—costs and benefits

medium term

Higher impact—more complex—costs and benefits

long term


Steps are iterative in nature and will continue to be “fleshed out” as more information becomes available

Key Tasks of Business Analysis Planning and Monitoring

Plan business analysis approach

Conduct/reviewstakeholder analysis

Plan business analysis activities

Plan business analysis communications

Plan requirements management process

Manage business analysis performance

1 2 3

54 6


Chapter Contents

Key Tasks of the Business Analysis Plan

Planning the Business Analysis Approach Workshop 2.1



Workshop 2.2






These are some of the elements to consider when planning your business analysis approachTiming of business analysis workFormality and level of detail of business analysis

deliverablesRequirements prioritizationChange managementBusiness analysis planning processCommunications with stakeholdersRequirements analysis and management toolsProject complexity

Your chosen methodology should reflect these elements

Most methodologies are either • Plan-driven• Change-driven

Elements of the Business Analysis Approach

1



BA’s work starts at the beginning of a project or during a specific phase of a project

Requirements become clear and fixed and are carefully managed

Change management process is documented and controlled

Requirements are captured in formal documents

Communication is pre-planned

Generally, this approach is used during waterfall-type methodologies

Plan-Driven Approach

1


Requirements

Design

Development

QA/Testing/ Verification

Implementation

Maintenance

Example waterfall methodology


Initial list of high-level requirements (product backlog)

This list is updated as new requirements surface• Changes to existing capabilities are prioritized

This process takes into account business changes that can occur throughout a project life cycle

Formal documentation is limited and produced after implementation to facilitate knowledge transfer

Emphasis on frequency of communication

This approach aligns with rapid delivery—also known as the Agile method

Change-Driven Approach

1


30-Day Sprint

24-hourScrum

Assigned to

Product Backlog (Requirements)

Product Backlog

(Requirements)

Product Backlog

(Requirements)

SprintBacklog

Usable Product

15 min. daily scrum meetingTeam members describe:• What they’ve done since last

meeting• What they will do before next

meeting• Issues they need help to

resolve

Delivers

Example Agile methodology (Scrum)


Recognize the teams of people that you will be working with and how you plan on interacting with them

Conduct workshops to determine the BA effort and activities that will support project objectives

How are the requirements development efforts typically managed in your organization?

Project Execution Approaches

1


Core team Extended teamInternal resources

BA or PM alone (or small team)

BA/PM team, including additional support

External resources

Outsourced management team

Outsourced extended team


Chapter Contents


Planning the Business Analysis Approach

Workshop 2.1 Documenting Key Assumptions


Workshop 2.2






1. Select a team member to perform the role of BA for this workshop task

2. We have just seen two methods of approaching potential initiatives along with different levels of analysisa. Types of approaches: plan- and change-drivenb. Types of analysis: strategic, system, tactical

3. Your instructor will assign you one of the types of analysis and/or approach

4. Read Handout 4, which gives you a list of the potential initiatives that Franklin Films is considering

5. Identify where each initiative fits. Can it fit into the type of analysis and or approach your instructor has assigned you?

6. Identify the benefits of following one type of analysis or approach

7. If you still have time, consider where applying the method of categorization you were not assigned would place your initiatives

Workshop 2.1: Recognizing Approaches and Analysis Types


Chapter Contents



Workshop 2.1

Documenting Key Assumptions Conducting Stakeholder Analysis

Workshop 2.2






Key elements to confirm before project initiation:• Relevant assumptions• Team ground rules• Templates to be used

Sample assumptions:• All users will be on a XXX platform• Users will be made available for interviews during June and July• Contractors will not be allowed to bill more than 40 hours per week

What happens if we don’t define and validate assumptions?

It is important for the team to agree on ground rules

Sample ground rules:• No meetings before 10 a.m.• Meetings must start and end on time• Scribe responsibilities will be rotated• …

Documenting Key Assumptions & Setting Ground Rules

1Plan business analysis approach


Chapter Contents



Workshop 2.1


Conducting Stakeholder Analysis Workshop 2.2






The PMBOK® Guide definition of a stakeholder:• “Person or organization (e.g., customer,

sponsor, performing organization, or the public) that is actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.”*

• In other words, anyone with a stake in the project

A variety of stakeholders potentially exercise influence over the project and its results

Who Is a Stakeholder?

*Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK®

Guide)—Fourth Edition, Glossary. Project Management Institute, Inc., 2008. Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.PMBOK is a registered mark of the Project Management Institute, Inc.PMBOK = Project Management Body of Knowledge


Stakeholder analysis is not a one-hit process• Depending on the stage of the project, we may take a

different perspective on certain groups of stakeholders

The players, and their interest and impact, may change

Have you been involved in a project where stakeholder dynamics changed?• What were the consequences and how

were they managed?

You need to • Deliver a list of stakeholders• Identify their roles and responsibilities• Recognize their impact on the initiative

A RACI matrix can help with this• Tracking who is Responsible, Accountable

Consulted, and Informed

Discussion: Conducting Stakeholder Analysis

Activity 1

Activity 3

Activity 4

Activity 5

Activity 2

A R

C

I


Questions to consider when you are identifying who yourstakeholders are:

Who is responsible for conducting detailed requirements development?

Who is most interested (or least interested) in the requirements process?

Who will be most impacted (or least impacted) by your project?

Who can most impact the success of your plan?

Who are the critical decision makers?

Are there any stakeholders who might be adversely impacted by the outcome of your plan or intentionally “working against” the process?

Checklist: Useful Stakeholder Planning Questions

Conduct stakeholder analysis

2


Business Analysis Generic Stakeholders

Generic stakeholder Examples and alternate rolesBusiness analyst Business systems analyst, systems analyst, process analyst,

consultant, product owner, etc.

Customer Segmented by market, geography, industry, etc.

Domain Subject-MatterExpert (SME)

Broken out by organizational unit, job role, etc.

End user Broken out by organizational unit, job role, etc.

Implementation SME Project librarian, change manager, configuration manager, solution architect, developer, DBA, information architect, usability analyst, trainer, organizational change consultant, etc.

Operational support Help desk, network technician, release manager

Product manager Scrum master, team leader

Supplier Provider, consultant, etc.

Tester Quality assurance analyst

Regulator Government, regulatory body, auditor

Sponsor Manager, executive, product manager, process owner


Common challenges: • Competing interests among different business units• Poor knowledge of system and processes currently in place• Difficult to solicit balanced input

– From aggressive personalities to noncontributors• Groups often can’t reach agreement on priorities• Groupthink* may suppress breadth of feedback• Feedback sessions are often difficult to manage• Fear of change

Stakeholder Challenges

*Groupthink: Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternate ideas or points of view


Brainstorm possible stakeholders

Identify two stakeholder evaluation criteria (representing the x and y axes)• Power and influence within the organization• Level of impact the project will likely have on the stakeholder• Immediacy of need for product or service• Availability for information gathering• Level of receptivity (positive or negative disposition towards the project)

List relevant stakeholder organizations on sticky notes

Rate each stakeholder group using evaluation criteria• Place the sticky note at the appropriate point on the grid

Multiply axis ratings to yield overall prioritization• (Impact rating) * (Influence rating) = Overall prioritization

Stakeholder Analysis Process



Influ

ence

in

orga

niza

tion

Amount impacted by project

Stakeholder assessment grid

High(5)

Low(1)

Marketing(1)

Medium(3)

Hig

h(5

)Lo

w(1

)M

ediu

m(3

)

Sales(15)

Finance(3)

CIO(25)

Users(10)

IT(12)



Influ

ence

in

orga

niza

tion



High(5)

Low(1)

Medium(3)

Hig

h(5

)Lo

w(1

)M

ediu

m(3

)

Needs must be met

Less important

Key players

Show consideration


Chapter Contents



Workshop 2.1



Workshop 2.2 Planning Business Analysis Activities





1. Select a team member to perform the role of BA for this workshop task

2. Review Handout 3 for information on all characters involved

3. In your groups, generate a stakeholder analysis grid for the case study situation• Identify potential stakeholders (using the case study information provided

and your general opinions and background knowledge)• List all potential stakeholders on sticky notes• Select the appropriate evaluation criteria and label the axes

4. Debrief the following:• What value do you see in this activity?• What are the risks of not conducting some sort of

stakeholder analysis?

Workshop 2.2: Case Study Stakeholder Analysis


Chapter Contents



Workshop 2.1



Workshop 2.2

Planning Business Analysis Activities Planning Business Analysis Communication




Plan Business Analysis Activities

You should define• The scope of your work

– Identify all of the activities you will need to perform

• The amount of time– Estimate

– How long these activities will take

– What resources you will need to help you

Design templates

Decide how to capture, manage, and document requirements information• Requirements-gathering

template(s)• Interview guide(s)• Business case template• Project-planning templates• Action item template• Change management template• Requirements document template• Test record template (if applicable)


3 In this step, you identify your deliverables• Your key deliverable is a clear, concise set of requirements

that will support solution development


Document tasks on a high-level schedule

Is this plan based on a plan-driven approach or a change-driven approach?

Be sure to include deliverables for each major task area in the final plan

Construct a Requirements Schedule3


No. Task Duration Resource(s) Deliverable(s)

1.0 Project initiation 5d BA Approved BA project plan

2.0 Requirements elicitation 10d BA, JM Completed interview guides, surveys

3.0 Requirements analysis 5d BA, JM, JK Revised analysis templates, graphical models

4.0 Requirements specification 15d BA, JM, JK Solution and stakeholder Requirements

5.0 Prepare the requirements Package

3d Extended team Requirements Package

6.0 Project closeout 2d BA Closed action item database, project debrief documentation


Chapter Contents



Workshop 2.1



Workshop 2.2


Planning Business Analysis Communication Planning the Requirements Management Process



Communication does not happen by accident• You must plan it

Consider your audience in your communication plan:• Who are your stakeholders? • How often should you provide information?• Select the appropriate media to deliver the message• Consider the geographical location of your extended

project team• What is the message or information you are delivering?

What other elements should you consider in your communication plan?

Plan Business Analysis Communications

Plan business analysis communications

4


Another Use for the Stakeholder Assessment Grid

Influ

ence

in

orga

niza

tion



High(5)

Low(1)

Medium(3)

Hig

h(5

)Lo

w(1

)M

ediu

m(3

)

1st tier communication

2nd tier communication

3rd tier communication

2nd tier communication


Chapter Contents



Workshop 2.1



Workshop 2.2






Elements to consider and document:• Who has the authority to provide sign-off?• Where do you plan to store your requirements?• What level of traceability will you have?• What attributes will be relevant for to you track?Numeric referencesSource informationOwner (who needs the requirement)PriorityRisk UrgencyStatus

Change management fits into this area• You need to manage the process for

– Requirements approval – Changes to requirements once they are approved

Requirements Management Process


5


At what point is the requirements document baselined?

When is the change management process initiated?

How frequently do we anticipate the requirements changing?• How are those changes to be submitted?• To whom are changes submitted? • In what format?

Who makes approval decisions on requested changes?

Do all changes need to go through the change management process?• If not, which ones do not?

How quickly are decisions made on requested changes?

How will traceability information (relationships between requirements) be maintained to facilitate efficient change management?• We will cover traceability in Chapter 6

Checklist: Change Management Process


5


Chapter Contents Key Tasks of the Business Analysis Plan


Workshop 2.1



Workshop 2.2






The business analyst should have clear set of success criteria• How you follow your plan is a measure of your success

– Your planned performance vs. your actual performance• Have clearly defined deliverables

– Understand the metrics that will measure your success• What happens if your deliverables change?

– Allowing for change in activities will add to the plan• Have a clear escalation path

– You need an executive decision maker to cut through potential bottlenecks

• If performance is unsatisfactory, what caused it?– This can help with recommendations for better results

Plan for success based on what you know and have documented, not what has been assumed!

Manage Business Analysis Performance

Manage business analysis performance

6


Once you have documented your plan• Ensure support of project manager and sponsor• Verify

– Common understanding of deliverables– All assumptions

• Confirm if anything has changed since project initiation• Monitor your plan to ensure that you are on track• Follow your communication plan

Validate Your Plan



Introduced the key tasks of business analysis planning and monitoring

Planned the business analysis approach: plan-driven vs. change-driven

Identified and assessed stakeholder roles and responsibilities

Identified key elements of the requirements management process

Encouraged development of a change management process

Understood the importance of managing the business analyst’s performance

Chapter Summary


Chapter Review

Business Analysis Planning

and Monitoring

In which task does the business analyst identify the deliverable that will be produced?

True or false? Stakeholder analysis should only be completed at the start of the project.

Name six key tasks in business analysis planning and monitoring:1.2.3.4.5.6.

Which BA approach aligns itself with the rapid delivery methodology also known as Agile?

Name three attributes that you might consider tracking during the requirements management process?

Enterprise Analysis

Chapter 3


In this chapter, we will Identify the business need

Reveal the root cause to identify the real problem Develop problem statements to clearly state problem and capabilities of

business need

Assess business capabilities and gaps Determine the solution approach

Identify elements of the initial solution scope Present analysis methods used to assess the feasibility of the solution

approach

Develop project objectives Review key components of a business case, including benefits and costs

Chapter Objectives


Enterprise Analysis


EnterpriseAnalysis


Validation




Elicitation


Monitoring


This is the set of activities where the business analyst identifies the business needs across the enterprise and turns them into potential initiatives• All elements of the business case are discovered and documented

Enterprise Analysis

Key inputs:• Assumptions and

constraints• Business goals and

objectives• Enterprise architecture• Organizational process

assets• Requirements (stated)• Solution performance

assessment• Stakeholder concerns

Key tasks:• Define business need• Assess capability gaps• Determine solution

approach• Define solution scope• Define business case

Key outputs:• Business case• Business need• Required capabilities• Solution approach• Solution scope


Chapter Contents

Defining Business Needs Exposing the Root Cause

Workshop 3.1 The Problem Statement

Workshop 3.2 Solution Capability Gaps, Approach, and Scope

Defining the Solution Feasibility Analysis Tools

Workshop 3.3 SMART Objectives

Workshop 3.4 Defining the Business Case


The BA First Seeks to Identify the Top Issues/Opportunities

Initiatives evaluated and top one selected

Business case drafted tosell recommended initiative to management

Business caseapproved

Project begins

Business casenot approved

Back to identify additional initiatives or reevaluate previous initiatives

Identify the topissues

Assess solution capabilities, gaps and approach, then define solution scope• Specific action-

oriented initiatives • Identify benefits and

costs• Ranking of best

approach

Identify business need• Root-cause analysis• Problem statements


Understand your business—know where to begin

1. Strategic goals—what is your business direction, vision, mission statement? Has this changed?

2. Is there an event that has created a new business need?• Regulatory, contractual

3. Has the business changed?• Missing processes, systems, or tools

4. Is your business losing money or market share?

5. What is your desired outcome?

6. Perform elicitation to allow stakeholders to state their perceived needs

Identifying the Business Need


New business needs can be generated in several different ways:

From the top down• The need to achieve a strategic goal

From the bottom up• A problem with the current state of a process, function, or system

From middle management• A manager needs additional information to make sound decisions or must

perform additional functions to meet business objectives

From external drivers• Driven by customer demand or business competition in the marketplace

Identifying the Business Need


Chapter Contents

Defining Business Needs

Exposing the Root Cause Workshop 3.1 The Problem Statement






As we prepare to define the project, we must ensure that we focus on the real problem and not the symptom

Identifying the Root Cause

Symptom

Root-cause problem


Helps to identify the root cause of a problem

Benefits of the five whys• By repeatedly asking why, you peel away the layers of symptoms

Evaluate the surface problem—symptom—by asking why to uncover the true root cause

How to complete the five whys• Write down the specific problem • Ask why the problem happens and write the answer down below the problem• Ask why the second problem happens and write that answer down• The general rule is that asking the question five times can get you to the root

cause

Effective when the problem involves human interactions

Root-Cause Analysis Methods: Five Whys


Root-Cause Analysis Methods: Cause-and-Effect Diagram

Also called fishbone or Ishikawa diagram

Focuses on the cause of the problem

Organize your ideas before you do further analysis

Problem

Category 2Category 1

Category 3 Category 4

Tertiary

Secondary

Potential cause

Potential cause

These are potential causes that you must validate with additional analysis and data


Chapter Contents








Workshop 3.1: Root-Cause Analysis

1. Refer to the Franklin Films Case Study (Handout 1)

2. On the whiteboard for this activity is a template cause-and-effect diagram

3. One of the problems identified in the case study was that the company lost money in the past year; using this problem and the categories you created during the affinity diagram session, identify the potential root cause using the cause-and-effect diagram methoda. Brainstorm potential categoriesb. Brainstorm potential causes of those categoriesc. Document all assumptionsd. Make a list of what information you will validate after the session

4. Document your cause-and-effect diagram on the whiteboard


Chapter Contents


Workshop 3.1

The Problem Statement Workshop 3.2 Solution Capability Gaps, Approach, and Scope





The problem statement is a brief description of what the problem is

Some guidelines to consider:• Address one problem at a time• Each problem statement should be only one or two sentences in length• Do not suggest the solution

Example problem statements:• 35 percent of the high school students in the region of Caledonia are off task

50 percent of the time during direct instruction• 15 percent of the system updates that we applied last month had to be

backed out; this has caused a 20 percent increase in the number of calls to the service desk

Creating the Problem Statement

“A problem well stated is a problem half solved.”

—Charles F. Kettering


How to write an effective problem statement:

1. Write down the current state problem

2. Expand by using the 5 Ws• Who does or does it not affect?• What does it or does it not affect?• When is it a problem?• Where does the problem occur or not occur?• Why should we fix the problem or not fix the problem?

3. Think about the desired future state

4. Write the new problem statement(s)

Creating the Problem Statement


Chapter Contents








1. Assign a business analyst to lead this activity

2. Using the guidelines from the previous slide on how to create a problem statement, write one or two problem statements for Franklin Films

3. Document your problem statements on the flipchart

Workshop 3.2: The Problem Statement


Chapter Contents

Defining Business Needs Exposing the Root Cause Workshop 3.1 The Problem Statement Workshop 3.2

Solution Capability Gaps,Approach, and Scope

Defining the Solution Feasibility Analysis Tools Workshop 3.3 SMART Objectives Workshop 3.4 Defining the Business Case


The BA Assesses Solution Capabilities, Gaps, and Approach




Project begins







approach



Capability: the quality of being capable, having ability

Consider if the organization has the ability to handle/meet the identified business need• Are business processes in place?• Do the users have the right skills?

– What tasks must be performed by end users—is there training involved?• Is the proposed solution sustainable within your current organization?• Are the right tools in place?• Proposed goals must be able to be met or accomplished

What do you do if the capabilities are not in place?• Develop new capability or enhance existing capability

Assess Capability Gaps


Identify options to meet the business need and address the capability gaps

You are not creating the solution but considering options to address your business need• Designing and developing of new hardware and software• Enhancing systems that already exist within the organization• Changing business processes and procedures• Outsourcing to a third-party vendor

What is the cost of doing “nothing”?

Is there a minimum option?

Solution Approach


Chapter Contents








Define Solution Scope

“Solution Scope: Defines what must be delivered in order to meet the business need, and the effect of the proposed change initiative on the business and technology operations and infrastructure.”

—BABOK® Guide*


Identify the new business capability that the solution will deliver• Include in-scope and out-of-scope items

Include the existing capabilities that will be supported by the solution scope

Once the initiative is selected, the business analyst should ensure that there is a general understanding of the desired future state• The goal at this point is not the detailed solution design; it is, however,

important to begin to envision potential solutions and the future state


Chapter Contents




Defining the Solution

Feasibility Analysis Tools Workshop 3.3 SMART Objectives



What is a feasibility study?• Determines the viability of an idea and whether or not the proposed options

will provide some benefit to the organization in order the meet the business needs

• Rank and select the best solution approach

Educates the business process owners on alternatives, risks, implications, and benefits of potential initiatives• Conducted to determine the viability of an idea

for a new business opportunity

May result in the decision not to recommend a potential solution

Feasibility Analysis Tools


Types of studies may include• Quantitative analysis• Competitive analysis• Benchmarking studies• Environmental assessments• Stakeholder analysis• Technical feasibility assessment• Vendor analysis

Many potential feasibility analysis techniques exist• We’ll review two methods:

– 2 x 2 analysis– Prioritization matrix

Conducting Feasibility Studies


The 2 x 2 analysis technique can be a powerful tool to help guide a group toward a logical, well-supported decision

2 x 2 AnalysisEa

se o

f Im

plem

enta

tion

Anticipated revenue

Redefine

Dogs High potential

Quick wins

A

CD

E

B

Sample 2 x 2 analysis

HighLow

5.0

4.0

3.0

2.0

1.01.0 2.0 3.0 4.0

F

5.0

Easy

Hard

G

H

I


Used to rank proposed alternatives and business initiatives

2 x 2 matrix development steps• Identify two relevant criteria elements (axes labels)• Rate each initiative against each criteria element• Plot the initiative on the grid corresponding with the x and y ratings

The quadrants indicate recommended action• Dogs (don’t do: low revenue, difficult to implement)• Quick wins (do now: high revenue, easy to implement)• High potential (do later: high revenue, difficult to implement)• Redefine (consider further: low revenue, easy to implement)

2 x 2 Analysis


2 x 2 Analysis

Pros Cons• Powerful visual representation • Well received by management• Easy to understand• Facilitates criteria discussion

• Limited to two criteria elements• Sometimes requires consensus

on ratings• Potential for all options to be

positioned in same quadrant

Possible decision criteria (axes labels):• Ease of implementation• Revenue, profit, business value, market share• Cost• Benefit to the organization• Risk• Goodwill, brand equity• Customer satisfaction• Resource requirements• Stakeholder demand


Prioritization Matrices

Identify key decision-making criteria

Determine thepriority of each criterion

Rate each option based on thecriteria

Multiply priority by rating for each option to identify best alternative

1

2

3

4


Example: Identify the best location for the annual team celebration


Cost Proximity to NY Family-friendlyTotal

Priority Rating Priority Rating Priority RatingLas Vegas 2 3 6 1 2 2 3 1 3 11

Orlando 2 4 8 1 4 4 3 4 12 24

CO Skiing 2 2 4 1 2 2 3 2 6 12

Paris 2 1 2 1 1 1 3 2 6 9

1 = Low 2 = Medium 3 = High

Shaded columns are calculated by multiplying the previous two column results together.Total column is the sum of each of the shaded column values.


2 x 2 analysis alternative decision criteria may be used here as well


Pros Cons• Facilitates criteria discussion• Enables weighting of different

criteria• Can handle more than two

criteria • Facilitates methodical decision-

making process

• Method is more time-consuming than the 2 x 2

• Requires consensus on ranking of priorities

• Potential for ties


Comparison of Evaluation Techniques

Technique When to use2 x 2 analysis • Have time constraints

• Need an “executive summary” type of analysis• Multiple criteria are not important• Need to compare many options

Prioritization matrices • Need more detailed analysis• Audience responds better to quantitative analysis• Multiple criteria are important• Criteria have different priorities• Need to compare many options


Chapter Contents








1. In your groups, select a new business analyst volunteer to lead the workshop

2. Using the list of potential initiatives outlined in Handout 4, evaluate the alternatives using either of these techniques:• 2 x 2 analysis

– Evaluate all eight initiatives– Avoid selecting decision criteria where one is a direct function of the other

(e.g., profit vs. cost)– Make sure axes are labeled correctly (which end of the axis is “good ”

and which is “bad ”) and provide appropriate labels for axis extremes• Prioritization matrix

– Evaluate four initiatives– Select three decision criteria

Workshop 3.3: Initiative Evaluation


Chapter Contents





Workshop 3.3

SMART Objectives Workshop 3.4 Defining the Business Case


Clear objectives are an important element of future project success• Concrete set of statements that describe what the project will try to achieve

SMART Objectives

Project objectives• Project definition• Project scoping• Project planning• Project execution

• Enterprise-wide information gathering

• Root-cause analysis• Problem statements• Solution capabilities


Effective objectives meet the SMART criteria• Specific• Measurable• Achievable• Relevant• Timebound

An example of a SMART objective for a new HR initiative: • Administer a three-day brand marketing training program for all new Marketing

employees (hired within past six months) before December 31, 2014– Is it specific?– How can we measure achievement at the end of the project?– Does it seem achievable?– Does it seem relevant?– Is it timebound?

SMART Objectives


Chapter Contents








1. Select a new business analyst to lead this workshop

2. Write your team’s selected initiative from the previous workshop at the top of a new sheet of flipchart paper

3. Work with your group to draft objectives based on the handout• Identify one or two high-level initiative objectives• List them on the whiteboard page for this workshop

4. Apply the SMART criteria to each objective

Workshop 3.4: Drafting SMART Objectives


Chapter Contents





Workshop 3.3 Project Objectives

Workshop 3.4

Defining the Business Case


The BA Defines the Business Case




Project begins







approach



The business case captures the rationalization for initiating a project and describes the value the project will add to the organization once the solution has been deployed• The value takes into account the cost to develop and operate the deployed

solution

It is submitted to management to determine whether future investment is warranted

Serves as the “go or no-go” decision point

Authorizes funding for future activities, including• Project initiation • Requirements planning and elicitation • Detailed requirements analysis and documentation

May outline qualitative and quantitative project benefits and costs

Often provides financial assessment of anticipated returns

May vary in terms of structure and components

Defining the Business Case


Assessing Benefits and Costs

Quantitative assessmentQualitative assessment

Common indicators:• Benefit/cost ratio• Present Value (PV), Net Present

Value (NPV), Net Future Value (NFV)

• Return On Investment (ROI)• Payback period• Breakeven analysis• Anticipated revenue/profit• Market share

Common indicators:• Risk analysis• Brand equity and goodwill• SWOT analysis• Competitive analysis• Benchmarking analysis• Organizational analysis

SWOT = strengths, weaknesses, opportunities, and threats

Which measurement indicator is most relevant to your organization?


One of the biggest challenges in business case development is quantifying the “nonquantifiable”

Example: quantifying “increased customer satisfaction” at the pizza restaurant

How could we quantify “increased customer satisfaction” as a benefit?

Quantifying Qualitative Elements

“Increased customersatisfaction”

Can be quantified by…

Potential measurements:••••••


Sample Business Case Components1. Title Page

2. Executive summary

3. Introduction and Summary• Project rationale for preferred option• Current business process• Description of the problem• Opportunity• Project objectives• Project scope and boundaries• Business benefits• Project costs• Assumptions & Constraints• Potential business and staff impact analysis• Potential technology impact analysis• Other issues• Implementation plan

3. Approach• Financial metrics• Privacy impact assessment• Alternative evaluation criterion

4. Key selection criterion• Weighting• Constraints and limitations

5. Preferred alternative (insert title)• Business benefits• Alternative costs• Assumptions• Potential business and staff impact

analysis• Other issues

6. Risk management plan• Risk assessment• Risk response• Benefit realization

7. Conclusion and recommendations



Identified the business need

Revealed the root cause to identify the real problem

Developed problem statements to clearly state problem and capabilities of business need

Assessed business capabilities and gaps

Determined the solution approach

Identified elements of the initial solution scope

Presented analysis methods used to assess solution approach

Developed project objectives

Reviewed key components of a business case, including benefits and costs

Chapter Summary


Chapter Review

Enterprise AnalysisDetermining the viability of an

idea and whether or not the proposed options will provide some benefit to the organization in order to meet the business needs is ______________.

__________ defines what must be delivered in order to meet the business need.

True or false? The project objective is a brief description of what the problem is and what a successful solution might look like.

Deeply studying issues that go beyond symptoms is called _________ analysis.

The concrete set of statements that describe what a project is trying to achieve are called _________________________.

Elicitation

Chapter 4



Identify steps to prepare for elicitation

Introduce some techniques to elicit information from stakeholders

Examine methods to record elicitation results

Understand the importance of confirming elicitation results

Chapter Objectives


Elicitation

EnterpriseAnalysis


Validation




Elicitation


Monitoring



Work with stakeholders to elicit their requirements • Elicitation can take place at more than one stage of an initiative or project• Elicitation is used to gather business, stakeholder, solution, and transition

requirements

Elicitation

Key tasks:• Prepare for elicitation• Conduct elicitation

activity• Document elicitation

results• Confirm elicitation

results

Key outputs:• Elicitation results• Scheduled

resources• Stakeholder

concerns• Supporting material

Key inputs:• Business case• Business need• Organizational

process assets• Requirements

management plan• Solution scope


Chapter Contents

Preparing for Elicitation Workshop 4.1

Elicitation Techniques

Gaining Consensus

Workshop 4.2

Workshop 4.3

Documenting & Confirming Elicitation Results


Regardless of the technique that you use, consider the following:• Do your homework!• Consider your objective• Be prepared to answer the “What’s in it for me?” question• Schedule the appropriate amount of time• Set the ground rules• Ensure that everyone has clear understanding of the method you have

decided to use• Document according to your plan• Request help if required• You may only have one opportunity with your selected audience

Preparing for Elicitation


Elements of preparation: • Business need—why

– Understand work environment– Clear objective of information you wish to get

• Stakeholders—who– Availability– Receptivity– Role in the organization, level of authority, knowledge

• Time—when– Project schedule

• Deliverables—what– Artifacts, templates– Decides what your output needs to look like

• Information-gathering techniques you will use—how



Schedule your elicitation activity around the availability of your stakeholders• Enlist the assistance of your project manager to ensure that stakeholders

participate in the sessions



What Are We Eliciting? Requirement ClassificationsBroader

More detailed

Solution require-ments

What is required from the business’s perspective

Behavior and information that the solution will manage

An airline ticketing example:Decrease customer wait times by providing self-service check-in capability

The self-service kiosk must read customer information from airline’s loyalty card

The kiosk shall run on XYZ software

Environmental conditions required for the solution to remain effective

Nonfunctional requirements

Functional requirements

What is required from each stakeholder’s perspective

Characteristics that meet both business and stakeholder requirements

What is required to transition from current to future state

The user must be able to print a boarding pass using the self-service kiosk

Kiosks will be manned by service personnel during the first two years of operation

Stakeholder requirements

Businessrequirements

Transitionrequirements


“Fortune 500 companies with poor requirements, on average, will spend $2.24 million more per project than those that employ best requirements practices.” • IAG Survey*

“... projects suffer most when changes in requirements touch off a cascade of delays, revisions, and rework. This happens all too often, as existing processes for establishing requirements are ad-hoc and inefficient, making it difficult for business people to communicate their needs to technology teams. This leads to miscommunications and insufficiently defined requirements that drive up development costs and delay projects.• MicroFocus White Paper 2009**

Industry Insight: Cost of Poor Requirements

*Quote from http://phoenix.theiiba.org/download/vpprograms/presentations/2010/2010-01-the-ten-myths-of-successful-it-and-business-comm.pdfDownload at www.iag.biz/resources/library/download-business-analysis-benchmark-2009.html**Download at www.microfocus.com/downloads/successful-projects-start-with-200400.aspx


Examples: Functional Requirements

For a car• Starting the car• Steering the car• Braking

For a store guide in a shopping mall• Locating a store• Finding the bathroom facilities• Finding first aiders

Why are these functional? • Because they specify something that

the user wants to be able to do – They represent a user goal


What Types of Requirements Are There?

Functional requirements• Capabilities

– Describe functionality—high-level statements of what the product should do

– Depend on product expectations, users, and the environment in which the product is used

A functional requirement represents an activity that a user, system, or process can do• A user goal

Non-functional requirements• Conditions

– Qualities that the product should possess

• Constraints– Constraints on the services,

functions, or conditions of the product

A non-functional requirement represents a quality that a product, system, or process should possess or a limitationon that product, system, or process


1. The car driver shall be able to start the car within 60 seconds of entering the vehicle

2. The customer shall be able to use the store guide to locate the appropriate section of the store within 60 seconds of arriving at the store

Why are these functional? • Because they specify a task that

that the user wants to be able to perform

Example: Functional Requirements


For a car• The color of the car• How long it takes the car to

go from 0 to 60 mph• Using a key to start the car

For a store guide in a shopping mall• Where the store guides are placed

– By both down and up escalators– Inside the lifts

• The store guides shall be laminated

Why are these non-functional?• Because they represent a quality of the

product, process, or service being specified

Examples: Non-Functional Requirements


The car driver shall start the car by using a key

The store guides shall be placed • 2.1 At the store entrances• 2.2 By both down and up

escalators• 2.3 Inside the lifts

The store guides shall be laminated

Why are these non-functional?• Because they represent a property of or

a constraint on the product, process, or service being specified

Example: Non-Functional Requirements


Chapter Contents


Workshop 4.1 Elicitation Techniques

Gaining Consensus

Workshop 4.2

Workshop 4.3



Workshop 4.1: Identifying Requirements Types Work individually

1. Identify as many requirements as you can for the item your instructor has assigned your group

2. Write the requirements on sticky notes on your digital whiteboard

Work as a team1. The whiteboard for this workshop

has been divided into Functional and Non-Functional category areas

2. Place the sticky notes in the appropriate area


Chapter Contents


Workshop 4.1

Elicitation Techniques Gaining Consensus

Workshop 4.2

Workshop 4.3



Three Types of Elicitation Techniques

Event-based• Gathering of people

– Establish ground rules– Agree on how feedback will be

given and taken– Understand the willingness of

the stakeholder to participate– Agree on how you will establish

consensus if required– Ensure participation of all

stakeholders

Performance-based• Analysis from existing

documentation

Distributed• Distribution of material

– Clarity on how to provide feedback and deadline on response time frame


Select the appropriate technique

Once you gather sufficient information, begin to analyze • Ideally, missing incomplete or incorrect requirement will be exposed through

the analysis process

Elicitation for that material then begins again, potentially using another technique

The Elicitation Process

Elicit Analyze


The Elicitation Process

During elicitation, record all information based on your requirements management plan• This includes the attributes that

you decided were important to record

• Trace all requirements back to business need and objectives

Tools• Do you have a whiteboard,

flipchart, working markers, suitable software, or someone to help you record results?

Common challenges during elicitation activities:• Scope creep/wish list• Stakeholders’ willingness to

participate• Full participation of stakeholders• Gaining consensus• Digression—maintaining focus• Information you are looking for

may be beyond the depth of individuals in the room

• Participants do not always understand the process that you are using


Consider using a variety of different techniques to gather information from your stakeholders:• Brainstorming• Document analysis of existing metrics/data• Focus groups• Interface analysis• Interviews: individual and group

– Face-to-face – Teleconferences, video conferencing, and Web seminars (Webinars)

• Observation sessions/time and motion studies• Prototypes• Requirements workshops• Questionnaires/surveys

What are some pros and cons of using these different techniques? Which techniques have you used?

Information-Gathering Techniques


As facilitator, you plan, manage, and guide groups of people through the elicitation techniques

Some points to remember:• Maintain a neutral stance• Keep people on track• Create a safe environment for participants to contribute• Keep the objective of the event in mind and be clear about desired outcomes

What characteristics do you think make a strong facilitator?

Facilitation


Chapter Contents


Workshop 4.1


Gaining Consensus Workshop 4.2

Workshop 4.3



1. Identify methods you’ve seen for gaining consensus among a group of diverse individuals, and list them

2. Then list the pros and cons of each recommendation

Class Discussion: Gaining Consensus

Recommendations Pros and cons


Description:• Idea-generation technique

– Process for gathering a broad set of ideas• Focusing on one topic and coming up with many possible solutions• Derive themes for further analysis

Steps:• Develop clear definition of topic• Select participants who have appropriate experience with topic• Establish criteria for evaluating and rating ideas• Allow group to create ideas and group according to criteria for further analysis

Results/output:• Final list of rated ideas shared with appropriate parties

Elicitation Techniques: Brainstorming


Elicitation Techniques: Document Analysis

Description:• Analysis of existing metrics, reporting, and documentation

– Reference material to use during elicitation can include artifacts from other projects, existing methods and procedures, marketplace studies

Steps:• Analyze what exists and what is relevant and up to date• Study selected material and note relevant details• Review these details with your SMEs

Results/output:• Existing information analyzed and packaged into requirements format


Elicitation Techniques: Focus Group

Description:• Gather information about specific product, service, or opportunity

Steps:• Select prequalified individuals• Create discussion guide with clear goals and objectives

– Include questions you will ask and how the information will be recorded• Assign moderator and recorder

Results/output:• Report analyzing participants’ ideas and perceptions


Elicitation Techniques: Focus Group

Recruit participants• Six to 12 people• Homogeneous: similar characteristics• Heterogeneous: diverse background

Assign an experienced moderator

Discussion guide• Goals and objectives of the session• Five or six open-ended questions

Results/output• Report that documents ideas and themes


Chapter Contents


Workshop 4.1


Gaining Consensus




You have been asked to lead the focus group to determine what the demand would be if Franklin Films were to make their digitized content available in the marketplace. Franklin Films would also like to have an indication of which demographic group they will be most successful with and how much people would be willing to pay to purchase this content

1. Select a business analyst to lead this activity

2. Create a discussion guide for your focus group session; include the following:• Goal/objectives• Six open-ended questions• Who should be recruited to participate in your focus group• How you will record the information

3. You would like to select the right person to moderate this focus group; list the type of skills you think a moderator should have

4. Record the results on your digital whiteboard

Workshop 4.2: Focus Groups


Description:• Define and understand the interaction between stakeholders and various

systems – Common interface types include user interfaces and interfaces to and from

external applications and devices

Steps:• Identify all interfaces• Capture information: purpose, type, and details of interface including content

and names, inputs, outputs, and events

Results/output:• Identification of interfaces and understanding of relationships and

interoperability– People and system integration impacts and dependencies clearly defined

Elicitation Techniques: Interface Analysis


Description:• Systematic approach to elicit information from people

Steps:• Identify interviewees• Design the interview with appropriate questions and structure• Conduct the interview• Record results

Results/output:• Documented questions and answers

Elicitation Techniques: Interview


The interviewer directs questions to a stakeholder to elicit a response

Successful interview depends on both interviewer and interviewee

Maintain focus, address interviewee concerns, and practice active listening

Elicitation Techniques: Interview

Type Format

Structured Pre-set questions with limited set of responses

Semi-structured Base questions designed to probeOpportunity to delve into other areas

Unstructured Questions typically open-ended


Description:• Shadowing people while they perform their tasks

Steps:• Prepare by introducing yourself and letting individual know that observation

has nothing to do with job performance• Take detailed notes

Results/output:• Summary of tasks performed during observation, including commonalities and

differences between performers

Elicitation Techniques: Observation


Description:• Building an early sample or model of a system

Steps:• Determine type of prototype• Identify functionality to be modeled• Steps are iterative• Storyboard—shows paths across interface components, includes visual of

screens along with arrows that show navigational flow• Verify that interface elements map to requests

Results/output:• A picture of the “future system interfaces”

Elicitation Techniques: Prototyping


Description:• Structured event attended by key stakeholders and SMEs, used to identify or

review requirements

Steps:• Identify key stakeholders• Define the workshop agenda• Send preparation materials before the workshop• Conduct pre-meeting interviews with attendees• Elicit, analyze, and document requirements

Results/output:• Requirements documented and formatted in the predetermined format

Elicitation Techniques: Requirements Workshop


What do you think a good requirements workshop looks like?

Consider• People• Time• Place• Techniques• Handling conflict• Ground rules

Elicitation Techniques: Requirements Workshop


Description:• Questionnaire that collects information from many people at once, sometimes

anonymously

Steps:• Define purpose of survey and target group• Choose the survey type and sample group• Write the survey questions• Test survey and fine-tune• Send the survey to the target group

Results/output:• Collated responses identifying common themes

Elicitation Techniques: Survey


Chapter Contents


Workshop 4.1


Gaining Consensus

Workshop 4.2

Workshop 4.3 Documenting & Confirming

Elicitation Results


1. Select a business analyst to lead this activity

2. You have been asked to gather requirements for Franklin Films

3. Use the material already provided to you in previous chapters

4. Select the elicitation technique(s) that you think is most appropriate• Be prepared to explain why you selected this technique

5. Create a plan to execute the technique that you have selected, including• Session Objective• Agenda • Who you plan to invite• What questions you will ask• How you plan to present your results

6. Record the results on the digital whiteboard for this activity

Workshop 4.3: Select an Elicitation Technique and Plan Activities


Chapter Contents


Workshop 4.2


Gaining Consensus

Workshop 4.3



More than just recording your gathered information

Organizing and structuring the information based on the templates you selected during your planning stage• Produce reports from result of interviews, observation sessions,

questionnaires, etc.

What to document:• Meeting minutes

– Attendees– Action items– Decisions

• Assumptions and constraints• Risks and issues identified during sessions

Documenting Results


Reviewing documented results• Confirm with your stakeholders that you captured and correctly understood

their stated requirements• Allow the stakeholder sufficient time to review your document and provide

input• This allows the participant to point out items that may have been missed,

incorrectly documented, or misunderstood

This step does not confirm that results are valid, only that the information was gathered and correctly understood and recorded by you

Your output is stated and confirmed requirements, not validated or analyzed requirements

Confirm Elicitation Results



Identified steps to prepare for elicitation

Introduced some techniques to elicit information from stakeholders

Examined methods to record elicitation results

Understood the importance of confirming elicitation results

Chapter Summary


Chapter Review

Elicitation What are the four key tasks for elicitation?1.2.3. 4.

A structured event attended by key stakeholders and SMEs and used to identify or review requirements is called ________________.

is a process for gathering a broad set of ideas.

What are nine information-gathering techniques?1.2.3.4.5.6.7.8.9.

True or false? The output of the “confirm elicitation results” task is stated and validated requirements.

Requirements Analysis

Chapter 5



Learn how to effectively prioritize and organize your requirements

Review existing requirements standards and best practices

Emphasize the importance of managing assumptions, constraints, and risks

Review steps to verify and validate your requirements

Chapter Objectives



EnterpriseAnalysis


Validation




Elicitation


Monitoring



The business analyst must analyze the stated requirements• This solution and stakeholder requirements are analyzed to effectively

implement the solution to meet the needs of the sponsor


Key inputs:• Business case• Business need• Requirements• Organization process

assets• Requirements

management plan• Stakeholder concerns• Stakeholder list, roles,

and responsibilities• Solution scope

Key tasks:• Prioritize

requirements• Organize

requirements• Specify and model

requirements• Define assumptions

and constraints• Verify requirements• Validate

requirements

Key outputs:• Assumptions and

constraints• Requirements

structure• Requirements

– Prioritized– Validated– Verified

• Stakeholder or solution requirements


Requirements AnalysisRequirements

collected

Elicitation Prioritize and organize

Specify and Model

Verify and Validate

Start

Requirementsdocumented in draft

Requirements baselined

Requirements understood

Requirements controlled

Management• Solution scope• Traceability• Re-Usable• Communication

Decision point:Accept documentor reenter spiral

®

315Developing User

Requirements: The Key to Project Success


Requirements Defined

“Stakeholder requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements.

Solution requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirement analysis. They are frequently divided into sub-categories, particularly when the requirements describe a software solution:

• Functional requirements describe the behavior and information that the solution will manage. They describe capability the system will be able to perform in terms of behavior or operations....

• Nonfunctional requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have.”

—BABOK® Guide*

*A Guide to the Business Analysis Body of Knowledge. Release 2.0. International Institute of Business Analysis, 2009. pp. 5–6.


Chapter Contents

Prioritizing and Organizing Requirements

Specifying and Modeling Requirements

Workshop 5.1

Assumptions, Constraints, and Risks

Verifying and Validating Requirements


Brainstorm the elements that you should consider when prioritizing requirements

Requirements Analysis—Prioritization


Elements to consider during prioritization of requirements:• Value to the business• Contractual obligations• Regulatory obligations• Legal and political• Time-sensitive• Dependencies—relationships to other requirements• Industry recommendations and best practices• Business or technical risks• Limited budget• Low-hanging fruit

Challenges:• Challenges are usually mostly related to your stakeholders• Groups of stakeholders do not always agree on prioritization points• It is not uncommon to rate everything as high

Prioritization of Business Requirements


MoSCoW analysis• All requirements are important; however, from a stakeholder’s perspective,

there are some that are more important than others

Must• Important to success of the project; if we don’t have these, the project will fail

Should• These are very important; however, there are acceptable workarounds

Could • These are nice to have but not necessarily foundational to the project

Won’t • These will not be considered for this current project• You have these on your list in case something changes; you may reprioritize

them or consider them for a future release

What do you do if everything is a Must?

Prioritization Technique


The end view is to have clearly organized requirements with clearly documented relationships

Requirements should be understood by all stakeholders equally

Consider the following:• Organization standards • Document dependencies and relationships between requirements• Use simple, consistent language• Use appropriate business language

Organize Business Requirements


Chapter Contents



Workshop 5.1




Specify one requirement at a time

Use terminology in a consistent way

Use a limited vocabulary

Use simple, direct sentences

Use the active voice

Requirement should have a verb

Do not assume reader knowledge

Don’t ramble

Specify Your Requirements


Standards are • Industry recommendations and best practices• Potential guidelines and procedures • Often a helpful starting point

The great thing about standards is that there are so many to choose from!• Potential standards bodies relevant to business analysis and requirements

and project management include– IEEE – ISO 9000– SEI CMMI– PMI PMBOK

Requirements Standards

IEEE = Institute of Electrical and Electronics EngineersISO = International Organization for StandardizationITIL = Information Technology Infrastructure Library PMBOK = Project Management Body of KnowledgePRINCE = Projects in Controlled EnvironmentsSEI CMMI = Software Engineering Institute Capability Maturity Model IntegrationSWEBOK = Software Engineering Body of Knowledge

– SWEBOK– PRINCE2– ITIL– IIBA


Requirements can be documented into matrices• Table or spreadsheet

Documenting requirements in this way clearly displays relationships • Traceability• Applicable business rules• Attributes• Relevant data elements• Project objects• Test cases• Training information

Specify Requirements


Identify improvement opportunities• Improving access to information• Candidates for automation• Reducing complexities• Increasing consistency of behaviors• Eliminating redundancies

Capture requirement attributes of each requirement• Use your requirements management plan and document the attributes that

you identified as important• Every requirement should have these attributes assigned to it

What are some examples of the attributes you should consider?



Identify requirements for acceptance and evaluation criteria

This is a technique that helps the business analyst during solution assessment and validation• Acceptance

– Minimal set of requirements that must be met for a solution to be worth implementing

• Evaluation criteria– Requirements used to choose between multiple solutions

• Ranking– Order of importance for requirement (prioritization)– Scoring—can be established to rate how well a solution meets the

requirement

Helps for stakeholder to buy in to solution



Modeling requirements allows you to represent different views of the business and group requirements according to the impacted business domain

Model Your Requirements


The business analyst should ensure that there is a general understanding of the current state and the desired future state

Although the goal is not a detailed solution design, it’s important to begin to envision potential solutions and the future state

Modeling the Present and Future

What does the future look like?


Modeling helps to answer the following common questions:

What does the current process look like?

What should the future process look like?

What will future user scenarios look like?

How will various data elements, processes, or organizations interact?

Have we considered all elements of the system or process?

Have we omitted any relevant business needs or requirements?

Have we considered all relevant constraints and conditions?

Are we all on the same page?

Benefits of Modeling


Key modeling concepts:• User class/profile/role

– People who interact with the solutions• Concepts and relationships

– A place, person, or thing (organization) and the relationships between them• Events

– A request that triggers or affects a business process• Process

– Sequence of repeatable activities; a response to the event• Rules

– Specific directives used by the enterprise; e.g., business rules

Model Your Requirements


Swimlane/Line of visibility modeling template:

Basic Workflow Modeling

LOV

Customer process

Service encounters

Contact process

Your business

Customer process

Business area/function/job/role

Contact process

Tools/support systems System

Support process

Sequenced workflow activities

InterdependenciesTeam players

Invisible

Visible

LOV = line of visibility


Swimlane example:

Workflow Modeling Example

Customer

Takeorder

Makepizza

Bakepizza

Boxpizza

Deliverpizza

Placeorder

Receivepizza

Order Taker

Maker

Baker

Boxer

Deliverer

Tools Order pad and Pencil

Pizza oven

Map system

Pizza box


Chapter Contents



Workshop 5.1 Assumptions, Constraints, and Risks



1. In your groups, select a new business analyst volunteer to facilitate the workshop

2. Review the case study handout information provided

3. Develop a swimlane workflow diagram depicting the process assigned to your group by your instructor• Use sticky notes to document workflow activities• Identify major swimlane categories (e.g., each department, external

suppliers, internal/external customer, tools)• Post workflow on the wall or flipchart

4. Debrief topics:• What did you like and dislike about the process?• What value do you see in the process?

Workshop 5.1: Modeling the Future Vision


Chapter Contents



Workshop 5.1




Identify and document assumptions, constraints, and risks as they relate to each requirement

Assumption• The act of taking something for granted• You must confirm the accuracy of your assumption• If your assumption is not confirmed, it is a risk to your project

Constraint• A limitation• Types of constraints can be based on dates, budget, current state that cannot

be changed

Risk• “An uncertain event or condition that, if it occurs, has a positive or negative

effect on a project’s objectives”—PMBOK Guide*

These should be reviewed and refined on a regular basis

Define Assumptions and Constraints

*PMI® PMBOK® Guide—Fourth Edition, Glossary


Chapter Contents



Workshop 5.1




Confirm that your requirement is of sufficient quality to continue• Use a checklist

– Are there loose ends?– Do you have all of the relevant information?– Is it well organized?– Is all information correctly labeled and matching?

• Conduct peer reviews and document walkthroughs to help verify your requirements

Verify


Validate• Validation is an ongoing process• Each requirement must be aligned to your business case and have some

business value• If you have requirements that do not fall into this category, you may want to

add a change to your project, or park them for future releases

Ultimately, each requirement must be traceable to a stated business objective

Validate



Learned how to effectively prioritize and organize your requirements

Reviewed existing requirements standards and best practices

Emphasized the importance of managing assumptions, constraints, and risks

Reviewed steps to verify and validate your requirements

Chapter Summary


Chapter Review


In a workflow diagram, functional areas are designated by ___________.

True or false? If an assumption is not validated, it becomes a risk to your project.

___________ describe the behavior and information that the solution will manage. They describe capability the system will be able to perform in terms of behavior or operations.

True or false? Requirements should be written in a creative fashion using a variety of complex vocabulary.

Name three elements to consider during requirements prioritization.

Requirements Management and Communication

Chapter 6


Chapter Objectives


Identify key elements to manage solution scope and requirements

Learn how to manage requirements traceability

Identify common communications pitfalls

Identify techniques for selling the message for optimal acceptance

Recommend steps for conducting the requirements review

Review the importance of maintaining requirements for reuse




EnterpriseAnalysis


Validation




Elicitation


Monitoring


The business analyst manages and shares the requirements with a diverse audience• Stakeholders should have a common understanding of the requirements and

the solution


Key inputs:• Business analysis

communication plan• Organizational

process assets• Requirements• Requirements

management plan• Solution scope• Stakeholder list, roles,

and responsibilities

Key tasks:• Manage solution

scope and requirements

• Manage requirements traceability

• Maintain requirements for reuse

• Prepare requirements package

• Communicate requirements

Key outputs:• Requirements

– Approved– Communicated– Maintained and

reusable– Traced

• Requirements package


Requirements Management and CommunicationRequirements

collected

Elicitation Prioritize and organize

Specify and model

Verify and validate

Start

Requirementsdocumented in draft

Requirements baselined

Requirements understood

Requirements controlled

Management• Solution scope• Traceability• Re-usable• Communication

Decision point:Accept documentor reenter spiral

®

315Developing User

Requirements: The Key to Project Success

RequirementsManaged


Chapter Contents

Managing Solution Scope and Requirements

Managing Requirements Traceability

Common Communications Challenges

Active Listening

Workshop 6.1

Conducting Requirements Review

Maintaining Requirements for Reuse


Solution scope and supporting requirements should be clearly documented• Refer to your plans

– Communication plan– Stakeholder analysis– Requirements management plan

Managing solution scope and requirements may happen at various points during the business analysis process



Solution scope management• Assess that all requirements fall within the boundaries of your solution scope

Conflict and issue management• Be prepared to facilitate conflicts that may arise between your stakeholders• Manage and track all identified issues

Presenting requirements for review• Decide how to present requirements for review and approval

Approval• Review your stakeholder analysis and confirm those who are authorized to

review, agree, and sign off on the solution scope and requirements package



Chapter Contents




Active Listening

Workshop 6.1




Confirms that every business objective has been analyzed and included in the solution

A requirement must be capable of being traced frontwards and backwards• Derivation—backward traceability• Allocation—forward traceability

Identify the relationships between your business requirements and business objectives, along with all other deliverables, such as system requirements, test cases, other dependent or related requirements• This is about relationships between requirements and other artifacts• If you trace these relationships then when something changes, you can more

easily track and assess all of the impacts

Traceability


Chapter Contents




Active Listening

Workshop 6.1




Communication skills are an absolutely critical part of the overall process!• Managing communications throughout the entire business analysis and project

management life cycles• Selling the requirements package once it is completed

What communications problems have you encountered either during the “selling phase” or throughout the entire process?

Importance of Effective Communication Throughout the Process


What percentage of our message is communicated by words alone?



Research shows that approximately 93 percent of our message is derived from nonverbal signals

Nonverbal communication• Tone of voice• Voice inflection• Facial expressions• Hand gestures

What is really being said here?• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday• Please e-mail me the sales report before Monday



Chapter Contents




Active Listening Workshop 6.1




Remember, listening wins respect!

Once you have won respect, you will get more,and better, information much more freely

It’s easy not to listen: cycle time• The average person can hear 480 words per

minute• But the average person speaks at only 120 words per minute

Improve your listening by• Wanting to listen; make a conscious effort, a decision to listen• Shutting up!

Don’t prepare your next question, rebuttal, etc., while the other person is still speaking• Don’t switch to “send mode”

Listen and Learn

Listen


Quotes

“Conversation in the United States is a competitive exercise in which the first person to draw a breath is declared the listener.”

—Nathan Miller

“I have a task, and that is talking to you. You have a task and that is listening to me. I hope you do not finish before I do.”

—Author Unknown


Stop talking

Put talker at ease

Look and be interested• Eye contact

Try to see the other person’spoint of view; empathize

Ask questions

These may seem common sense, but how many people follow them all?

Some Guidelines for Active Listening

Be patient; don’t interrupt

Hold your temper

Avoid criticism; do not argue

Feedback to verify your understanding


Chapter Contents




Active Listening

Workshop 6.1 Conducting Requirements Review



1. In your groups, select a business analyst to lead this activity

2. Have one individual begin a story. While in the middle of the story, the business analyst stops the student and asks the next person to continue

3. The next person must repeat the last sentence and then add to the story

4. The facilitator should alternate randomly and out of sequence between the online students and the in-class students

Workshop 6.1: The Active Listener


Active Listening

“When you really listen, with your full attention, you begin to hear not only what people are saying but what they are trying to say.”

—Nathan Miller

“The most prevalent mistake that people make about listening is to regard it as passively receiving rather than as actively participating.”

—Mortimer Adler

Active listening involves your whole body• Ears, eyes, heart, full attention


Chapter Contents




Active Listening

Workshop 6.1




When you are ready to present the requirements for review, the business analyst must “sell” the package to key decision makers

Presenting Requirements for Review

Identify thebest messenger and correctaudience

Document sessionobjectives andagenda

Lobby key stakeholdersand review details prior to formal session

Selectdocument content and structure

Conduct formal review and obtain acceptance and sign-offs

Baselined requirements


Requirements are documented in various templates, depending on their purpose• Business Requirements Document (BRD)• Product road map• Software/system requirements specification document• Vision document• Required for vendor selection

– Request For Information (RFI)– Request For Quotation (RFQ)– Request For Proposal (RFP)

Recommended Presentation


Interaction with stakeholders has occurred throughout the process of gathering information

When you request acceptance and sign-off, there should be no surprises

Acceptance and sign-off comes from various stakeholders• Project sponsor• Other business stakeholders impacted by your requirements• Delivery teams• Testing team

Presenting Requirements for Review


Brannock proposes the following structure for management briefing presentations• Overall recommendation is provided early• Tells a logical “story”

Recommended Presentation Outline

1. Title2. Recommendation3. Problem statement4. Assumptions5. Study approach6. Define problem7. Develop alternatives

8. Evaluate alternatives9. High-level requirements10. Costs11. Benefits12. Assessment of risk13. Summary and conclusions14. Proposed implementation plan

Source: Brannock, James W. BCA: Business Case Analysis. STS Publications, 2004. pp. 368–379.


Chapter Contents




Active Listening

Workshop 6.1




You have spent considerable effort to gather, analyze, and properly document requirements

Some requirements can be reused• System requirements• Operational requirements• Requirements related to security standards• Technology standards• Contractual or regulatory standards

Identify the requirements that should be reused

Ensure that they are clearly named, clearly defined, and easily available

Store them in your organization’s document repository




Identified key elements to manage solution scope and requirements

Learned how to manage requirements traceability

Identified common communications pitfalls

Identified techniques for selling the message for optimal acceptance

Recommended steps for conducting the requirements review

Reviewed the importance of maintaining requirements for reuse

Chapter Summary


Chapter Review

Requirements Management

and Communication

Name the key inputs for the requirements management tasks:1.2.3.4.5.6.

What percentage of communication is transmitted by nonverbal signals?____%

True or false? Identifying the correct messenger is critical to selling the requirements package.

_____________confirms that every business objective has been analyzed and included in the solution.

What are five types of requirements that can be reused?1.2.3.4.5.

Solution Assessment and Validation

Chapter 7



Review how to assess the proposed solution

Introduce the key considerations in allocating requirements

Discuss factors in assessing organizational readiness

Define transition requirements

Describe your role in solution validation and evaluation of solution performance

Chapter Objectives



EnterpriseAnalysis


Validation




Elicitation


Monitoring



The business analyst supports activities downstream in the project life cycle• Making sure that solution meets business need and facilitating successful

implementation


Key inputs:• Assumptions and

constraints• Enterprise architecture• Requirements• Solution (constructed,

deployed, or designed)• Solution options• Solution performance

metrics• Solution scope• Stakeholder concerns

Key tasks:• Assess proposed

solution• Allocate

requirements• Assess organization

readiness• Define transition

requirements• Validate solution• Evaluate solution

performance

Key outputs:• Assessment of

proposed solution• Identified defects• Mitigating actions• Organizational

readiness assessment• Requirements

(allocated)• Transition requirements• Solution performance

assessment• Solution validation

assessment


The business analyst maintains linkage to downstream development activities

Partnering With Downstream Development

Enterprise/problem analysis

Detailedrequirementsdevelopment

Solution development

Business analyst plays primary role

Business analyst provides necessary support• Assess proposed solutions• Ensures that requirements aren’t dropped or added• Clarifies requirements as needed• Reengages when major changes occur

Hand off to development

Changemanagement

process


Business Analyst’s Role in the Project Life Cycle

Detailed solutiondesign

Implementation Maintenance/support

Key

act

iviti

esPr

imar

y B

A ro

le

• Translate requirements into solution components

• Design solution• Test requirements

• Design/analysis assistance (as needed)

• Clarify requirements• Assess solution and allocate

requirements• Check for dropped or added

requirements• Validate acceptance criteria

• Implement solution• Conduct acceptance

testing

• Requirements SME• Provide training to support

rollout (if needed)• Communicate change impacts

to stakeholders• Solution validation—QA

• Provide ongoing system support

• Generate new business needs

• Evaluate solution performance

• Refine processes• Suggest changes


Chapter Contents

Assessing the Proposed Solution Allocating Requirements

Assessing Organizational Readiness

Transition Requirements

Workshop 7.1

Your Role in Solution Evaluation and Solution Performance


Solution Assessment Does the proposed solution(s)

add value to the business?

Consider the acceptance and evaluation criteria that you produced in requirements analysis• The minimal set of requirements

that must be met for a solution to be worth implementing

Are your requirements ranked correctly?• Rank solution options according to

your various analyses• Prioritization matrices let you rank

solutions using multiple criteria

Consider • Risk• Scalability• The potential for future value

Solutions should be measured based on direct comparability• These comparisons can be

qualitative or quantitative– Qualitative: the distinction of

qualities; deals with the how and why

– Quantitative: deals with measurements; generally expressed in numerical form

Result Recommended solution


Chapter Contents

Assessing the Proposed Solution

Allocating Requirements Assessing Organizational Readiness


Workshop 7.1



Stakeholder and solution requirements are allocated to the solution components and/or releases

Purpose of this step is optimization of business value• Business value may change depending on

– How requirements are implemented – When they are implemented

• Allocation may change during solution design as you understand more about the value and cost of a solution

When allocating requirements, consider• Availability of resources• Dependencies between requirements• Constraints on solution

Allocation starts when you determine the solution approach, and continues until all requirements are allocated

Allocation of Requirements


Why can’t you do everything at once• Overall project budget• Resource constraints• Urgency of need for parts of a solution• Ability of business to absorb change• Freeze periods

The business analyst assists in planning the timing of implementation based on minimal disruption and the value to the business

Allocation of Requirements


Chapter Contents


Allocating Requirements



Workshop 7.1



Rewrite the following statement on the lines below:• “It’s often hard to change the way we think and act”

Activity


Organizational Readiness Is the organization ready for the

change?

Identify the impacts on your organization as a result of the change• Cultural

– Do stakeholders want change to succeed?

– Are they ready to take advantage of new capabilities?

– Do they understand why the solution is being implemented, the benefits to the business?

• Technical or operational– Are IT systems in place to

support the solution?

– Is the solution capable of performing at the required level?

– Are processes or policies in place to support the new solution?

– Has training been completed?• Stakeholder impact

– What concerns will stakeholders have?

– How does change impact stakeholder groups?

– Is job loss or relocation involved?

– Will tasks that the stakeholder performs change?

– How does change impact communication?

Refer to your organizational models and stakeholder analysis


Chapter Contents




Transition Requirements Workshop 7.1



These are defined after the solution is defined

They are temporary in nature—lifespan is during the transition period

Examples of transition requirements are• Data that needs to be transferred, archived, or converted• Parallel work that takes place if the new system is operating at the same time

as the old system• Does an organization need to change in order to manage or implement the

new solution?– Are new skills or functions required as a result of the new solution?


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

—BABOK® Guide*



Chapter Contents





Workshop 7.1 Your Role in Solution Evaluation

and Solution Performance


Work as a team

1. Identify the transition requirements needed to take Franklin Films from their current situation to their desired situation, using • The initiative you identified for Franklin Films• All of the information so far in the course• The digital whiteboard for this workshop

2. If you are not certain what would happen, detail what you think is most likely to happen

Workshop 7.1: Defining Transition Requirements

Transition just ahead!


Chapter Contents





Workshop 7.1



Validating the solution is about testing that the solution meets the specified business needs• The business analyst

– Is in a support role during the quality assurance phase of a project– Assists in clarifying requirements and investigating issues that come up

during testing– Assists the business in determining potential alternatives based on defects

that cannot be resolved in a reasonable period of time– Has a key role in determining the severity of a defect based on the

prioritization and acceptance criteria identified for the solution

Ultimately, the project sponsor accepts the solution

Solution Validation


This occurs after the solution is deployed• The BA gathers metrics that describe performance• Metrics can be qualitative and/or quantitative

Underperformance—what is the root cause?

Overperformance—consider redeploying your resources

What is the difference between the performance metrics and the business goals and objectives?• If there is a difference, further investigation is required

Solution Evaluation of Performance



Reviewed how to assess the proposed solution

Introduced the key considerations in allocating requirements

Discussed factors in assessing organizational readiness

Defined transition requirements

Described your role in solution validation and evaluation of solution performance

Chapter Summary


Chapter Review

Solution Assessment

and Validation

The minimal set of requirements that must be met for a solution to be implemented is ___________.

True or false? Allocation may change during solution design as more is understood about the value and cost of potential solution.

Name three types of impacts to your organization as a result of new solution implementation:1.2.3.

___________ describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete. True or false? The business analyst

assists in planning the timing of implementation based on minimal disruption and the value to the business.

Business Analysis Competencies and Capstone Exercise

Chapter 8



Review the business analysis competency framework

Find solutions to the issues we identified in Chapter 1

Chapter Objectives


Underlying Competencies

EnterpriseAnalysis


Validation




Elicitation


Monitoring



Chapter Contents



The IIBA is actively seeking to help business analysts develop professional-level competency

It has produced a business analysis competency framework for BAs to assess themselves against

The model is behaviorally based and enables individuals to assess themselves

The IIBA and Competency Development

Level Description1: Novice Textbook understanding, no experience2: Advanced Beginner Limited experience and abilities; may need guidance

from others3: Competent Consistently produce acceptable results4: Proficient In-depth knowledge and experience5: Expert Consistent high-quality results and deep expertise;

recognized as an expert outside of the immediate team


It cannot be reproduced here, but there are some aspects you can assess yourself against• Performance competencies

– How do you rate yourself in terms of your ability to perform the IIBA knowledge areas?

• Underlying competencies– How do you rate yourself in terms of the following?


Analytical thinking and problem solving:• Creative thinking—Generate new ideas• Decision making—Understand effective criteria for decision making• Learning—Know how to translate learning into benefits• Problem solving—Define and solve problems• Systems thinking—How do people, processes, and technology fit together?

Behavioral characteristics:• Ethics and trustworthiness—Earn trust and respect through actions• Personal organization—Effectively manage tasks and information


Business knowledge:• Business principles and practices—Understand fundamental best practices and standards;

these can be regulatory, cultural, political, or institutional• Industry knowledge—Knowledge of the industry you are working within• Organizational knowledge—Understanding of the organization you are analyzing• Solution knowledge—Understanding of existing solutions to effectively recommend changes

Communication skills:• Oral communications—Effectively express ideas while considering your audience• Teaching—Ability to ensure that communicated information is retained and understood• Written communications—Ability to document all necessary documents

Interaction skills:• Facilitation and negotiation—Moderate discussions and effective negotiate to resolve

differences• Leadership and influencing—Develop vision of future state and motivate team to work together

towards common goal• Teamwork—Work to manage team dynamics and resolve conflicts

Software applications:• Use of general-purpose applications—Effective use of tools; i.e., word processing,

spreadsheets ,and presentation software tools • Use of specialized applications—Effective use of modelling tools, requirements management

tools, and other productivity tools



Using the description outline on the previous two slides, rate yourself in the underlying competencies as they relate to business analysis and the knowledge areas we have described in the past three days

Determine some next steps that you will take to increase your levels of competency in each area

Workshop 8.1: Underlying Competencies

Underlying competency Level Next steps for improvement

Analytical thinking and problem solving

Behavioral characteristics

Business knowledge

Communication skills

Interaction skills

Software applications


Chapter Contents

Workshop 8.1

Workshop 8.2


In Chapter 1, each team identified a range of issues with the practice of business analysis in your organizations• It is time to fix these issues

1. Work as a team and choose a new business analyst to facilitate this workshop

2. Work through one or two problems you identified in your first exercise, identifying and documenting what you would do to address them

3. Each team will pick a presenter to talk their way through the initial problems, and the solutions you identify

Workshop 8.2: Capstone Exercise



Reviewed the business analysis competency framework

Found solutions to the issues we identified in Chapter 1

Chapter Summary


Chapter Review

Developing Business Analysis

Competencies

True or false? Decision making is an IIBA competency within “analytical thinking and problem solving.”

What are the levels of assessment in the IIBA competency model?1.2.3.4.5.

_____________ are how you rate yourself in your ability to perform in the IIBA knowledge areas.

True or false? Ethics and Trustworthiness is an IIBA competency within “Software Applications.”

True or false? Underlying competencies are unique to business analysts.

Course Summary

Chapter 9


In this course, you have learned how to

Perform the key functions of the business analyst by applying the IIBA business analysis framework

Apply the techniques to elicit requirements in your organization

Create the business analysis plan

Evaluate and prioritize the feasibility of various business initiatives and present the business case

Understand the BA’s role in solution evaluation and performance assessment

Develop key business analysis competencies

Course Summary


1. Review all course material

2. Develop three questions in any format (true/false, multiple choice, etc.)

3. Write each question on a separate index card (list the answer on the back of the index card)

4. Hand the cards to the instructor

5. The instructor will quiz the class from the student-generated question cards

Final Workshop: Course Review

Optional Workshops

Appendix A

2© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. A-

This appendix includes additional optional tools and workshops that your instructor may wish to use during the course

Overview


You will work individually in this workshop

Using the sticky notes on your desk and one of the black markers, complete the following sentence:• “I would be a better business analyst if I…”

Brainstorm as many ways of completing that sentence as your instructor indicates

Tip: Try not to overanalyze your thoughts too much—go with what comes to mind

When you’ve done what you can, please hand your answers to your instructor

Workshop: What Makes a Good Business Analyst?

Apply


Before any workshop, it is important that the ground rules are agreed on by all participants• This workshop is no different

Establishing some ground rules will help us all build a positive learning experience

Here are some to get you started:• Be an active participant • Embrace a “discovery approach” to learning• Respect the opinions of others• Accept that many topics will be introduced but not all can be covered in detail• Focus on grasping the process rather than obsessing on the right answer• Recognize business analysis as an emerging discipline, which implies that

many concepts aren’t set in stone• Have fun!

Workshop: Defining Ground Rules


Agreeing on ground rules helps to• Maintain a positive workshop experience• Increase the likelihood that desired workshop outcomes will be achieved

People tend to stick to ground rules that they have had a role in creating, so you will have an opportunity now to create your own ground rules for the course

Use the following to help you:• Starter ground rules provided by your instructor• “Ways to Elicit Workshop Ground Rules” in your Reference Manual

– See the section titled “During the Workshop”

Workshop: Defining Ground Rules

Apply


This is an exercise that can be performed to emphasize how important ground rules are

In your groups, brainstorm and then select the top three positive ground rules (these are usually explicit) and the top three negative ground rules (usually implicit; e.g., never disagree with the boss)

Then have a five-minute discussion with only negative ground rules, and a five-minute discussion with only positive ground rules

Discussions you can have:• Which is better: Coke or Pepsi?• What movie will the group see after class?• Who is the most influential historical figure?

Workshop: The Importance of Ground Rules


Alternative to the course case study:• Use the case study for Workshop 2.1• For the affinity diagram, use the focus statement “Morale in my organization

would improve if…”• Give each group one of the categories to investigate through the rest of the

exercises• Then take the answers of the focus statement through the next workshops

– Root cause– Feasibility– Developing potential initiatives– Objective development– Cost/benefit analysis

Real Example vs. Case Study


Developing potential initiatives can be a challenging process for the BA

If your instructor chooses, you can perform a workshop that allows you to apply some facilitation and decision-making techniques

Using the answers to your focus statement on the affinity diagram, go through this process:• Brainstorm potential initiatives• Use dot-voting to decide which initiatives you will investigate

This will give you a chance to apply facilitation skills to the group

Developing Potential Initiatives

business analysis introduction: defining successful...

Documents