Business Analysis Session 10

Planning and Eliciting RequirementsRAM N SANGWAN

WWW.RNSANGWAN.COM

YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA

TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

Agenda

• The Requirements Work Plan (RWP)

• Components of the RWP

• Identifying good questions for elicitation

• Active listening

• Categories and types of elicitation techniques

The Requirements Work Plan (RWP)

• The IIBA has a knowledge area in the BA Body of Knowledge dedicated to

requirements planning and management.

• This is one of six knowledge areas, which indicates the industry feels

requirements planning is important.

• Preparing the Requirements Work Plan gives you a chance to take a step

back, analyze the scope of work, and determine the best techniques and

approach to facilitating the requirements work.

Components of RWP

1. Project Type

2. Project Scope

3. Project stakeholders and their role on the project

4. Requirements activities/tasks/deliverables and time and duration estimatesfor each

5. Identify milestones in the above activities for development and delivery of

requirements

6. Requirements assumptions and risks

Identifying good questions for elicitation

• A critical part of preparing for requirements elicitation is identifying a list of

questions.

• You definitely want to avoid securing valuable stakeholder time only to be

lost about what questions to ask!

• Some stakeholders will talk your ear off (forcing you to gently interrupt

them to keep the meeting on track), but others need to be led through a

structured conversation.

What is a Requirements Questionnaire?

A requirements questionnaire is a list of questions about the project requirements.

Typically the questions are organized by feature (or business requirement or projectobjective).

Essentially each high-level requirement from your scope document should have alist of questions to further refine your understanding. For Example:

• How requirements questions

• Where requirements questions

• When requirements questions

• Who requirements questions

• What requirements questions

• Why requirements questions

How requirements questions

• How will you use this feature?

• Is this feature a process and, if so, what are the steps? Or, what questions

can I ask to ascertain the steps?

• How might we meet this business need?

• How might we think about this feature a bit differently?

• How will we know this is complete?

Where requirements questions

• Where does the process start?

• Where would the user access this feature?

• Where would the user be located physically when using this feature?

• Where would the results be visible?

When requirements questions

• When will this feature be used?

• When do you need to know about…?

• When will the feature fail?

• When will we be ready to start?

Who requirements questions

• Who will use this feature?

• Who will deliver the inputs for the feature?

• Who will receive the outputs of the feature?

• Who will learn about the results of someone using this feature?

• Who can I ask to learn more about this?

What requirements questions

• What do I know about this feature?

• What does this feature need to do?

• What is the end result of doing this?

• What are the pieces of this feature?

• What needs to happen next?

• What must happen before?

• What if….? Think of all the alternative scenarios and ask questions about

what should happen if those scenarios are true.

• What needs to be tracked?

Why requirements questions

• Why questions are great wrap-up questions as they help confirm that the

requirements you just elicited map back to a need you identified when you

scoped the project.

• Is there any other way to accomplish this?

• Does this feature meet the business need and solve the problem we’re

trying to solve?

Active Listening

Active Listening is a method used to listen and respond to others in a structured

and deliberate way.

It requires a listener to understand and actively evaluate what he or she

heard.

Actively listening can be used to achieve a number of goals.

• One of the more common goals of actively listening is to ensure that the

listener accurately understands what the speaker has said by replying back

to the speaker and paraphrasing what they believe they have just heard

(“So, if I understood you correctly…”).

Active Listening Contd..

• The speaker can either acknowledge that the listener’s understanding was

accurate or can quickly identify any misunderstanding that the listener may

have.

• Actively listening helps the listener avoid incorrect conclusions due to

unintentional assumptions that the listener may have made.

• It’s important to note that a listener that employs active listening is not

necessarily agreeing with the speaker.

• Another goal of actively listening is for the listener to extract additional

information from the speaker.

• While listening to the speaker, the listener may notice something in the speaker’s

tone or body language. By responding to the speaker with phrases such as“you seem to feel …” the speaker has the opportunity to confirm or correct thelistener’s understanding.

Active Listening Contd..

• As a business analyst, being able to listen is a primary component of

your Business Analyst skills set.

• You need to listen to the project sponsor to figure out what the project is all

about. You need to listen to your stakeholders to understand what their needs

and wants are. You need to listen to the technology folks to make sure thatthey understand what the requirements really mean.

• And lord knows, you have to listen to your manager to make sure that what you

are doing is in line with company policy.

• Sure, everyone has to listen to other people at times. However, as a business

analyst, listening is one of your primary Business Analyst skills.

Requirements Elicitation

• To elicit is to

• draw forth or bring out

• call forth or draw out

• Requirements elicitation is an active effort to extract information

from stakeholders and subject matter experts

• Elicitation is not a step or a task you do at a certain point. It is a set

of techniques you apply, appropriately, during the requirements

phase.

16

Why Not Requirements Gathering?

Requirements

GatheringRequirements

Elicitation

vs.

• Like collecting sea shells

• Take what you see

• More reactive, less proactive

17

Like archeology

Planned, deliberate search

More proactive, less reactive

Requirements Elicitation Techniques

Focus GroupsDocument AnalysisBrainstorming

ObservationInterviewsInterface Analysis

Survey/Questionnaire

Requirements

WorkshopsPrototypingProcess Modeling

18

#1 Brainstorming

Produce numerous ideas

Set a time limit

Make it visual

Designate a facilitator (usually the BA)

Watch group size! (ideally 6-8)

Establish ground rules

criteria for evaluating and rating ideas

do not allow criticism

limit discussion and evaluation

At the end, use criteria to evaluate ideas

Can be fun, productive, and motivating

19

#2 Document Analysis

Elicit information from existing documentation

Helpful when subject matter experts are not available or no longer

with the organization

Use relevant documentation to study and understand relevant

details

business plans, project charters, business rules, contracts, statements of work, memos,

emails, training materials, etc

20

#3 Focus Groups

Elicit information from a select group via a moderator

Very formal process

More structured

Usually has 6-12 attendees

Requires a skilled moderator

Promotes discussion

Asks open questions

Engages all members

Remains neutral

Saves time and cost from not conducting many individual interviews

21

#4 Interface Analysis

Identify interfaces between solutions and define requirements forthem

A basis for successful interoperability

Clarify boundaries of the applications

Identify interfacing stakeholders

Define the inputs and outputs of the interface

plus validation rules

and events that trigger the interactions

Some types of interfaces

to/from external applications

to/from internal applications

to/from external hardware devices

22

#5 Interviews

Ask questions geared toward uncovering information

Formal or informal

Directed at an individual or selected group

Maintain focus on the goals of the interview

Open-ended questions find information and gaps

Closed ended questions confirm and validate

Success depends on

Knowledge of interviewer and interviewee(s)

Experience of the interviewer

Skill in documenting discussions

Readiness of interviewee to provide information

Relationship between the parties

Not a good way to reach consensus (BABOK 2.0 – p.180)

23

#6 Observation

Study a stakeholder's work environment Good when documenting current or changing processes

Passive/Invisible

observer does not ask questions

takes notes

generally stays out of the way

Active/Visible

dialog with the user

while they are performing their work

May be disruptive

May be time consuming

May not observe all possible scenarios

24

#7 Process Modeling

Understand work with multiple steps, roles, or departments Initiated by an event

Activities to include

Manual

Automated

Combination of both

Visual nature may help some people

Can become complex and unwieldyif not structured carefully.

Complex processes should be broken intotheir components to aid in understanding

25

#8 Prototyping

Visually represent the user interface

Good validation measure

Great for interaction

Supports visual learners

Focus on the whole solution or just a specific area

Great for validating requirements and uncovering gaps

Can take lots of time if bogged down in the “hows” instead of

the “whats”

26

#9 Requirements Workshops

One the most effective techniques Have an agenda

Carefully select attendees

Use an experienced, neutral facilitator

Use a scribe (not the facilitator)

One or a few days in duration

Elicit information in a short period Too many participants slow it down

Too few participants cause gaps

Team member availability is an issue

Combine with other techniques interviews

surveys or questionnaires

prototyping for clarity

process modeling for understanding

27

#10 Survey/Questionnaire

Efficiently elicit information from many people Have a purpose

Appropriate audience

Establish a timeframe

Clear and concise questions

Focus on business objective

Support with follow-up interviews

Closed ended questions Range of possible responses is very well understood

Easier to analyze

Open ended questions Extra detail when the range of response is not well understood

Harder to analyze and quantify

Use selectively

28

ThankyouWWW.RNSANGWAN.COM