using different types of questions to uncover requirements

Using Different Types of Questions to Uncover

Requirements

Presented For SoftEd, July 20/21, 2021

By Eugenia C. Schmidt PMP CBAP PMI-PBA

We will be starting shortly….This session will be recorded and available to view after the webinar.To ask a question during the webinar, be sure to use the Q&A function in Zoom.

© 2020 VITINAR | All Other Rights Reserved

Do you ever find yourself stuck during an interview when you do

not know what question to ask next, or how to pull out the

requirements you need from the stakeholder? Being good at

asking good questions will make your job as a business analyst

less stressful. Know how different types of questions can be

applied in different ways. Not only will you learn how to produce

some of your own questions, but you will also be provided with

some great examples that you can walk away with and start

applying right away!

Presentation Abstract


• Get a quick overview of various question type examples.

• Gain awareness of how assumptions developed early in an initiative become questions during analysis.

• Examine the business analysis knowledge that can help trigger more probing questions.

• Pick up some hints and tips on how to manage communications so it is perceived less like an interrogation and more like an inquiry.

As an attendee, you can expect to:

Expected Outcomes

“The worst question you can ask during a requirements discussion is, ‘What do you want?’ The second-worst question is, ‘What are your requirements?’ No one knows quite how to answer these questions. Customers and other elicitation participants might not share the analyst’s understanding of what a requirement is.”

– Karl E. Wiegers, More About Software Requirements

VIT817 V1


Asking Good Questions

• Gaining Understanding

• Tell me more about the current patient check-in

process?

• Probing for Information (leverage checklists)

• What concerns do you have with the new instant

prescription process as defined in the process flow?

• Test Assumptions

• Does everyone have that same

understanding of how that process works?


Open vs. Closed Ended

• Open-ended are nondirective

• Closed-ended are directive

• Blend different types

• Put in sequence.

• How do you plan to use this feature? [Open]

• Has this feature caused you any problems in the past? [Closed]

• Can you elaborate on the problem that caused you the most pain? [Open]


Context Free

• All open-ended questions

• Very high level, general questions

• Can be applied in any situation

• Anything else?

• What else?

• Is that it?

• Can I recap?

• Can you restate that a different

way?

• Can you show me?

• Can you give me some

examples?

• Say some more about that.

• Can you elaborate?


Probing and Fact-Finding Questions


Funnel Questioning

• Start with closed ended

(easy factual questions)

• Starts with general

questions

• Then dive to detail

• Increases trust &

confidence

Is this for external customers? [yes]

Are they residential only? [yes]

Is Canada included? [no]

Great, then we only have to deal with the USregulations. Right?


Collaborative & Confirming Questions

• Taps into feeling, concerns

• Taps into hidden

assumptions

• Promotes calmness

• Promotes open discussions

• Guides group to agreement

• How is that different than

what was said?

• Do I understand you

correctly that…

• What are the benefits or

impacts to you

personally?

• Can you live with the

decision?


Leading Questions

• Suggests particular answer

• Can lead to particular outcome

• Generally undesirable

(may direct to false

information)

Leading: If you used the job aid

provided, that would fix the

problem, wouldn’t it? (suggests an

answer)

Better: What suggestions do you

have for fixing the problem? (get

their ideas with an open ended

question)

Follow up with: Why would you

resolve it that way? (get to root

cause/requirements through

probing)


Meta Questions

• Questions about

questions

• Checking;

• Right person

• Right level of detail

• Within scope

• Why do you think that question

is important to ask?

• Are these questions relevant to

you?

• Are these the right questions to

ask about the product? What

would you ask?

• You appear upset by that last

question, are you?


Activity: Which Types?

I just walked into your computer department at a retail store. You approached

me to ask if I needed any help. I said “Absolutely. I need a laptop.”. What

might be some examples of different types of questions you would ask me so

you could direct me to the right product. Describe why you would ask me

those types of questions.


What are Assumptions

• Believed to be true and sets expectations

• A place holder to manage the “unknowns” and

still move forward

• Should be tested as soon as possible

• Helps to define scope, but may change

• Helps gain agreement on understanding

• Will have many before requirements analysis is

performed (Business Case and Project Charter)


Turning Assumptions to Questions

Assumptions are made here

They get validated here

Assumptions turn into questions, then requirements, then solutions here

See Appendix for Easy-Read Version


Example Assumption Impacts to BA

Assumptions Business Analysis Impact

Included or excluded features of a product

Scope definition, validation needed during analysis

Technology platforms or other solution specifications

Verify it is not a constraint. If not, ensure it aligns to requirements to see if assumption changed, may impact timeline and budget if different solution is recommended. If it is or becomes a constraint, that will impact which requirements are feasible and expectations must be managed.

Organizations that will or will not be impacted

Must be validated during stakeholder analysis and may impact scope of work in addition to scope of the solution.

Skill levels of users Impacts non-functional requirements (usability)

Availability of resources or business operations impacts

Requirement sources may not be available when needed during analysis

R


Use Checklists for Questions

• Business and solution Domains

• Requirement classifications

• Gap analysis questions

• Ambiguous words

• Risk categories

• Interface Assessment Checklist


Business Domain Checklist

Would you ask different questions if your company or organization

was:

❑Global vs. local

❑Public vs privately owned

❑Acquiring other companies

❑Growing very quickly vs. downsizing

❑Shifting resources organizationally

❑Moving business processes to another country

❑Very flat organization vs. a deep hierarchy

❑Others?


Solution Domain Checklist

Would you ask different questions if you knew that the following

were being considered:

❑Packaged solution

❑Cloud solution

❑Legacy system was a constraint

❑New security software implementation

❑New enterprise-wide technology standard


From the perspective of what the

system will provide

From the perspective of those that

interact with the system

From the perspective of the business

and project needs

Requirement Classification Checklist

Mor

e ef

fect

ive

and

prog

ress

ivel

y el

abor

ated

Classifying requirements into types helps us determine if we are missing anything.

See Appendix for Easy-Read Version


Non-Functional ChecklistWhat has changed?

Note that non-functional may also be referred to as “quality attributes”Categories based on list from Software Requirements Memory Jogger by Ellen Gottesdiener

Affecting the operation of

software

• Transactions?

• Number of users?

• Forecasted growth?

• User skill levels?

• Volume of data?

• Cycle time?

• System failures?

• Hacking attempts?

Deployment Environment

• Locations of users?

• User access?

• Difficulty to modify?

• Ease of changing configuration?

• Ease to move to different platform?

Development Environment

• Availability of processor capacity, space or bandwidth?

• Expense to change specific software?

• Expense to integrate with other software?

• Cost of testing?


Business Rules Checklist

• Behavioral

(a.k.a. Operational)

• Business Constraint

• Action Enabler

• Definitional

(a.k.a. Structural)

• Inferences

• Derivations

• Facts

Bu

sin

ess

Ru

les?


Gap Analysis

Current

System

Subsystem A

Feature 1(keep)

Feature 2

(remove)

Subsystem B

Feature 3

(change)

Hig

h L

evel to

Deta

il Level

Future

System

Subsystem A

Feature 1 Feature 2

Subsystem B

Feature 4

(added)Feature 3

CONTEXT

As-is to To-be

GAP ANALYSIS

What would you keep, remove, add or change (KRAC)?


Ambiguous Words Checklist

• All, Everything

• Adequate, Suitable

• Applicable, Relevant

• Approximately

• Appropriate, Reasonable

• Automatically

• Better, Best, Worst

• Clearly

• Compatible

• Completely

• Easy, Simple, Efficient

• Execute

• Fast, Rapid, Quick, Timely

• Fault-tolerant

• Few, Most, Least, Many

• Flexible

• Heavyweight, Lightweight

• Intuitive

• Maximum, Minimum

• Optionally, Sometimes

• Readily

• Robust

• Safely

• Seamless, Transparent

• Several

• User-friendly

• Usually


Risk Categories

External

Vendors & Suppliers

Organizational

Resource Movement &

Availability

OrganizationalCapability Gaps

Business Impact

Benefit or Value Realization

Environmental

Customer

Market

Regulatory

Governance

Portfolio Priorities

Strategic Change

Enterprise

Maturity

Quality Attributes

Complexity,Interfaces

& Integration

Hardware/Software

Architecture

Technical

Solution


Interface Assessment Checklist

Is it inbound or outbound

Which standards apply

Triggers, events that activates it

The frequency

Privacy or security rules

Data types and data controls

Validation rules and error handling

Variability to formats

Quality attribute characteristics

Expected volume and capacity

Headers and other unique identifiers

Pet

Pre

scri

pti

on

R

equ

est

Pharmacy


Summary: Hints and Tips for Questioning

27

What to Avoid

• Complex, multipart questions

• Asking a series of questions and not waiting for the answers

• Rushing through a series of questions using a script

• Using terminology that is foreign to your audience

Getting Good Answers

• Make sure you have the right

person

• Wait! Give them time to think!

• Check the environment, can

they talk openly?

• Invite elaboration (tell me

more)

• Provide context and stay

within scope

You won’t leave without some additional tools to use!

Appendix


Post Webinar Activity: Review 200+ Business Analysis Questions

1. Individually review 200+ Business Analysis Questions handout provided

with the webinar

2. Find two questions that you wish you would have asked (or wish someone

would have asked) on a previous project.

3. Alternately, find two questions that you will now ask on a current or future

project.

4. Share and discuss with peers.


Resources

• Business Analysis Body of Knowledge V3, by the International

Institute of Business Analysis (www.iiba.org)

• More About Software Requirements: Thorny Issues and Practical

Advice by Karl Wiegers

• Software Requirements Memory Jogger by Ellen Gottesdiener

• 200+ Business Analysis Questions by Eugenia C. Schmidt

(Handout)

http://www.iiba.org/


GinaS @SoftEd.com

www.linkedin.com/in/eugeniaschmidt

Thank you for joining us today. Questions?

mailto:[email protected]

http://www.linkedin.com/in/eugeniaschmidt

using different types of questions to uncover requirements

Documents