How Do I Know What Questions to Ask WHITE PAPER

REQUIREMENTS MANAGEMENT & BUSINESS ANALYSIS

WHITE PAPER byRoxanne Miller, CBAP

How Do I Know What Questions to Ask?


1 Copyright©2014 Requirements Quest® www.RequirementsQuest.com | 608‐850‐6377

ContentsIntroduction .............................................................................................................................................. 2

Activity 1: Document Assumptions ........................................................................................................... 4

Activity 2: Identify the Requirements Levels ............................................................................................ 6

Activity 3: Identify the Success Criteria ................................................................................................... 10

Activity 4: Identify the Stakeholders ....................................................................................................... 13

Activity 5: Apply the Requirements Framework ..................................................................................... 20

Activity 6: Evaluate the Results ............................................................................................................... 24

Summary ................................................................................................................................................. 26

References .............................................................................................................................................. 26

About the Author .................................................................................................................................... 27

About Requirements Quest .................................................................................................................... 27


www.RequirementsQuest.com | 608‐850‐6377 Copyright©2014 Requirements Quest® 2

Introduction

The Man Who Asked Questions

“About 2,400 years ago in Athens a man was put to death for asking too many questions,” is the opening of a chapter in Nigel Warburton’s book A Little History of Philosophy. Warburton continues to write, “Snub-nosed, podgy, shabby and a bit strange, Socrates did not fit in.” Viewed by people as charismatic with a brilliant mind, Socrates was unique, but also irritating and extremely annoying. As Socrates shuffled around the marketplace, he often stopped people and asked them straightforward—yet awkward—questions.

The meaning of the word ‘philosopher’ in Greek is ‘love of wisdom’. The value of wisdom was based on reasoning and asking questions, and not on believing something simply because someone important has told you something is true. Wisdom, according to Socrates, wasn’t about knowing a lot of facts and how to do something. Rather, wisdom meant understanding the nature of our existence and the limits of what we can know.

The Man Who Didn’t Ask Enough Questions

About 15 years ago, an employee of a global software consultancy company experienced a tragic end to a project. Thankfully, unlike Socrates, he was not put to death. The tragic ending to that project was that the company involved was forced out of business by its national government for non-compliance. How can you avoid tragic project outcomes? Get better at asking questions!

The purpose of this white paper is to convey six activities for asking questions in a continuous cycle

for eliciting requirements (depicted in Figure 1):

1. Document Assumptions.

2. Identify the Requirements Hierarchy.

3. Identify the Success Criteria.

4. Identify the Stakeholders.

5. Apply the Requirements Framework.

6. Evaluate the Results.



Figure1–SixActivitiesforAskingQuestions

1 DocumentAssumptions

2 Identify the Requirements Levels

4 Identify theStakeholders

5 Apply theRequirements

Framework3 Identity the

Success Criteria

6 Evaluate the Results

How Do I

Know What

Questions

to Ask?

ThroughtheEyesofaRequirementsProducer

The six activities described in this white paper can help you, as a Requirements Producer, get better

at knowing what questions to ask the stakeholders on your projects.

A Requirements Producer is any individual who is responsible for capturing the requirements—

eliciting, analyzing, representing, validating, and managing changes to the requirements. They are also

responsible for managing the requirements to ensure compliance and integration throughout the

development or installation of the system. Business Analysis is a term commonly used to encompass

the activities performed by the requirements producer.

When performing activities within a requirements management process, there are essentially two

key groups of stakeholders to ask questions: Requirements Suppliers and Requirements Receivers.

Stakeholder, is defined as, any person who the Requirements Producer interacts with throughout the

project lifecycle who has:



a vested interest in the project outcome,

decision‐making authority,

expertise in business and technology,

vision of the future business state,

finally, a role in the project implementation process.

A Requirements Supplier is any individual who is responsible for defining the business needs to be

satisfied. This includes supplying all the detail from the initial idea or inception through each

incremental iteration of the system development and implementation. The other key contributor, a

Requirements Receiver, is any individual who receives and uses the requirements specifications as the

input to develop their work products relating to implementing the requirements.

1 DocumentAssumptions

Activity1:DocumentAssumptions

The primary question in this activity is one that you ask yourself, “What do and don’t I assume to

know?”

It is essential that you condition yourself to identify assumptions—yours and those of your

stakeholders. Conditioning yourself to identify assumptions translates to writing them down and

discussing them with your stakeholders. The assumptions you’ve made are either true/correct or

false/incorrect. If an assumption is validated as false, then you need to take corrective actions until you

reach what is validated as true.

Some people start writing down everything that comes to mind about the project (some call this a

‘brain dump’). You might jot down sentences, phrases, single words, or even sketch out a picture. Often

people use a mind mapping technique to organize their thoughts.

Conversely, you might be ‘brain dead’ when facing a blank canvas, and you need some structure to

get you moving forward. Write down what you assume to know and not know about several categories

of assumptions. A template such as the example in Table 1 might help you identify assumptions.

Making a list of things you’re unsure of or don’t know becomes a catalyst for generating lots of

questions. Furthermore, you can add to the list by asking your stakeholders about what they have

assumed.

Of course, a blend of ‘brain dump’ and structure can be applied with fantastic results. For example,

consider taking a blank piece of paper for each user role identified to be in the scope of your



requirements. Focusing on one user role at a time and one blank sheet of paper, write down your

thoughts and assumptions for that user role. Then for each role, find someone who can validate what

you’ve written down (also refer to activity ‘4:IdentifytheStakeholders’).

Table1–ATemplateforIdentifyingAssumptions

Category (A) I assume to know (X) about [(A)].

I’m unsure or don’t know (Y) about [(A)].

Questions that I have about [(A)].

a. Purpose and scope of the project

b. Business processes affected

c. Business areas affected

d. Roles affected (who is performing the processes?)

e. Internal and external interfaces affected

f. Expectations and capabilities of the end-user

g. Technological environment being implemented

h. Other projects being worked on that affect this project

i. Other products being developed at the same time as this product

j. Availability of resources (people, hardware, and software)

k. Dependencies on external (outside the project, department, business area, or the company as a whole) people or systems

l. Expectations of the solution team



2 Identify the Requirements Levels

Activity2:IdentifytheRequirementsLevels

“Where am I?” is a primary question to ask yourself in this activity. The objective is to identify

where you are in your requirements approach. The approach that I use includes three distinct levels of

requirements, or what I refer to as a Requirements Hierarchy, as shown in Figure 2. The pyramid depicts

the proportional relationship between the levels: business, user, and system. That is, there are usually a

large quantity of system requirements necessary to support a few number of business requirements.

Additionally, the hierarchy is generally used to drive a top‐down approach to eliciting requirements.

Start with the high‐level business requirements and drill down to the detailed system‐level

requirements. The levels are explained in the paragraphs that follow, as well as some suggested

questions you might ask within each level.

Figure2–RequirementsHierarchy(Levels)

Business‐level requirements represent the high‐level objectives of the organization, customer or

client. These requirements typically come from several stakeholders, including but certainly not limited

to, the funding sponsor for a project, the acquiring customer, the manager of the users, the marketing

department, and a product visionary. The business requirements describe why the organization is

implementing the system (why the project is being done), and the objectives the organization hopes to

achieve (measurable business benefits that align with the organization’s vision).

User‐level requirements bridge the needs of the business (business‐level requirements) and the

requirements of the solution to be developed (system‐level requirements). User requirements describe

user goals or tasks that the users must be able to perform with the product. User requirements identify

what the user will be able to do with the system. I define the term user as anyone who affects or is

BusinessRequirements

UserRequirements

SystemRequirements



affected by the product. This definition includes people, computer applications, machines, robots, and

external systems and interfaces. The users interact with the business process under development or

enhancement, as well as other people and things (computers and so on). The users receive products

(information and materials) and services from the business process or system.

System‐level requirements describe what functions the business process (whether manual or

automated) must enable the users to perform (functional requirements), and the attributes and

constraints of the environment that affect how well the users perform those functions (nonfunctional

requirements). A ‘system’ can be a computer, a software application, a subsystem, a whole business

enterprise, or a manual process performed by a human.

Within the system level requirements, there are two viewpoints: system function/feature and

system environment. The functional requirements (system function/feature view) describe

functionality that must be built into the business process to enable the users to perform their business

goals or tasks. A “feature” is a set of logically related functional requirements that provides a capability

to the user and enables the accomplishment of the user’s business goal.

Nonfunctional requirements describe the system environment view or characteristics of the system.

They describe the constraints imposed on the design and construction of the system, as well as quality

attributes related to the user need for operation, revision, and ability to handle change or growth

(transition).

Simply defined, while functional requirements describe what the system must do, the nonfunctional

requirements define how well it must do it. For a deeper understanding of nonfunctional requirements,

I recommend that you read my book The Quest for Software Requirements (Miller 2009). This book was

written with specific emphasis on these vital, yet frequently missed and overlooked requirements.

The Purpose and Point of View of each requirements level is summarized in Table 2.



Table2–PointofViewandPurposeofRequirementsLevels

Level Point of View Purpose Primary Question

Business Sponsor Define the business objectives and benefits from doing the project.

What are the high-level objectives and business benefits for doing the project?

User End-user Identify the user of the product or system, or performers in the business process. Describe the user goals or tasks that the user wants to perform.

What are the user roles, user goals, and inputs and outputs of information and materials associated with each goal?

System (Functional) Feature/Function Describe the functions that the business process must enable the users to perform.

What must the system do to support each user role in accomplishing the user goals?

System (Nonfunctional)

Environment Identify the characteristics of the system that affect how well the users perform functions and tasks.

How well does the system support the users in day-to-day operations? How easy is it to revise and transition the system?

Some examples of questions for each requirements level are listed in Table 3. I inserted customized

bullets in each column for ease of reference in group study discussions, and they serve no other

intended or unintended purpose.



Table3–ExampleQuestionsbyLevelofRequirements

Business Requirements

User Requirements System Requirements

Functional Nonfunctional Ba. What is the

business vision?

Bb. What is the purpose of the business area?

Bc. What are the goals for the project?

Bd. What are the objectives needed to reach the goals?

Be. What are the benefits from doing the project?

Bf. What are the critical success factors?

Bg. What business processes support the business purpose?

Bh. Describe “what” is done currently.

Bi. Who will benefit from this product or system?

Bj. Who may be opposed to this product or system?

Bk. Who are the experts in this business process?

Bl. What are your success metrics?

Bm. What are the key business issues you face today?

Bn. What could prevent you from meeting your business objectives?

Ua. Who will use the system under development?

Ub. Who performs tasks or activities in the business processes?

Uc. What department or business area is impacted by this system function?

Ud. What business areas are affected by changes to the system?

Ue. Who benefits the most from this project?

Uf. Who does this system interface with?

Ug. Who is the source of information that is input to the system?

Uh. Who is the recipient of information from the system?

Ui. What external organizations interact with the system?

Uj. What government agencies require information from the system?

Uk. What regulatory agencies require information from the system?

Ul. Who needs to access the system?

Um. What role(s) might be alleviated if this process is automated?

Un. What work does the system help the business unit to perform?

Fa. What does the system have to do to support each end-user?

Fb. When the user does “x”, the system does what?

Fc. What data must be received (input processing)?

Fd. What data must be produced (output processing)?

Fe. What data must be retrieved, stored, and transferred?

Ff. What calculations must be performed?

Fg. What data must be edited?

Fh. What data need to be validated?

Fi. What errors will the system be expected to handle?

Fj. What business exceptions must the system handle?

Fk. What business rules need to be enforced by the system?

Fl. What audits must the system conduct?

Fm. What tallies, timers, triggers, and schedules does the system have to maintain?

Fn. What tasks and activities does the system automate?

Na. How well is the system guarded against unauthorized access? (Access Security)

Nb. How dependable is the system during normal operating times? (Availability)

Nc. What are the system’s capabilities regarding capacity, throughput, and response time? (Efficiency)

Nd. How accurate and authentic are the data captured by the system? (Integrity)

Ne. How immune is the system from failure? (Reliability)

Nf. How resilient is the system from failure? (Survivability)

Ng. How easy is it to learn and operate the system? (Usability)

Nh. How easy is it to modify the system to work in different environments? (Flexibility)

Ni. How easy is it to upkeep and repair the system? (Maintainability)

Nj. How easy is it to expand or upgrade the system’s capabilities? (Scalability)

Nk. How easy is it to show that the system performs its functions? (Verifiability)

Nl. How easy is it to interface with another system? (Interoperability)

Nm. How easy is it to transport the system? (Portability)

Nn. How easy is it to convert the hardware and software for use in other business functions? (Reusability)



3 Identity theSuccess Criteria

Activity3:IdentifytheSuccessCriteria

“Where am I going?” is a primary question to ask in this activity. The objective of activity 3 is to

determine your action plan for getting where you want to be and how you’re going to get there.

Identifying the success criteria combines two activities: selecting the sources of requirements and

defining the objectives and deliverables of each elicitation technique. Preparation starts with you.

Success is as much about what you do and how you do it, as it is about the approach or process you

apply. It is your skills, talents, energy, enthusiasm, and positive attitude that make the difference.

PREPARATION is the link between ordinary people and extraordinary interviews.

3a:SelectSourcesofRequirements

“What sources of requirements are available to me?” and “What elicitation techniques will help

me get where I want to be?” are questions to help identify elicitation tasks.

The time invested in preparation will help you to avoid costly rework. There are numerous sources

and techniques for eliciting requirements such as the following:

ENTERPRISE ANALYSIS to gain an understanding of the current state of the business process.

This is usually done by creating a variety of models that help people ‘see’ their business.

REQUIREMENTS DOCUMENTS for current systems, as well as specifications from previous

projects can uncover potentially reusable materials, thus saving time and avoiding

duplication of effort.

PROBLEM REPORTS, ENHANCEMENT OR CHANGE REQUESTS for a current application.

FORM ANALYSIS to understand the communication channels in the organization. A form is

simply a way to structure data entry and retrieval.

BUSINESS ARTIFACTS such as training manuals, end‐user documentation, and procedure

guides.



MARKETING SURVEYS AND USER QUESTIONNAIRES. These are great techniques to use when

there is a very broad audience of stakeholders with little or no opportunity (time or cost) to

elicit from all of them.

OBSERVING USERS AT WORK. Observation may be performed in an active‐visible manner or

a passive‐invisible manner.

EXPERIENCING LIFE AS A USER. Figuratively, walk in the user’s shoes for a day. This is only

possible when the work is not too complex or dangerous. Working alongside users can help

you understand the problems they encounter.

SCENARIO ANALYSIS of user tasks. In the most general sense, a scenario is a step‐by‐step

account of what an end‐user does to achieve a desired goal. A set of logically‐related

scenarios (associated to the same user goal) can help the solution team see the big picture

of the work performed.

INTERVIEWS and discussions with end‐users and stakeholders. This is the most direct way

to find out what the users need—ask them. Read chapter 3—Interviewing Tips and Tools of

my book, The Quest for Software Requirements (Miller 2009), for details on how to prepare

for and conduct effective interviews.

WORKSHOPS with a group of stakeholders bring the right collection of people together, and

enable them to correct and improve on their own requirements (increasing buy‐in). The

workshop approach is a structured process, in which all participants contribute in building

the requirements deliverable.

Whether requirements are gathered from one or all of the above sources depends on what defines

the critical success of the project, the resources available (monetary, personnel, software and hardware,

and repositories of documents and data), and any schedule constraints under which the product or

service must be delivered. Based on the risks of developing the system, the solution team must select

the appropriate combination of resources to tap into.

3b:DefineObjectivesandDeliverables

Ask, “What is the objective and deliverable of this [requirements source]?” for each source and

technique to identify the desired outcome or result.

While an objective states what you want to accomplish, a deliverable is a specific, tangible artifact

that helps you to meet the objective. Some elicitation objectives and example deliverables are provided

in Table 4, as well as an example of a question that is answered in the representation of each

deliverable. The deliverables are listed alphabetically.

To better understand how models can be used to visualize requirements, you might explore Visual

Models for Software Requirements by Joy Beatty and Anthony Chen (2012), and works by Ellen

Gottesdiener (2002, 2005).



Table4–ElicitationObjectivesandExampleDeliverables

Elicitation Objective Example Deliverables What Questions Are Answered

Describe the business value of the system, and the benefits for doing the project.

Business Policy

Business Rules

Decision Table

Project Charter

Vision Statement

What business policies exist?

How is this supposed to operate?

How do you know what action to take?

Why do this project?

What are the goals of this business?

Describe the people, departments, and organizations that interact with one another in the business processes.

Context Diagram

Organization Chart

Process Decomposition Diagram

Process Map

Relationship Map

What roles interact with this system boundary?

What departments are affected by this project?

What processes are affected by this project?

What roles interact with each other in this process?

What entities are in the scope of the project?

Describe who uses the system, and their business processes and goals.

Process Map

Roles and Responsibilities Matrix

Scenario Analysis Table

Use Case

Use Case Diagram

Use Case Map

User Goals Table

User Roles Table

What roles interact in this process?

What are the responsibilities of each role?

What scenarios are related to this user goal?

What are the details of each scenario?

Who are the actors, and what are their goals?

What is the relationship between goals?

What goals does each role need to accomplish?

What are descriptions of the roles?

Describe the systems and user interfaces.

Event-Response Table

System Interface Table

User Interface Flow Diagram

What happens when the user does that?

What systems need information from this system?

How does the user navigate the system?

Describe the characteristics and constraints of the system, and how the system must perform.

Nonfunctional Requirements Specification

How well must the system function?

Describe the relationships between business data, the flow of data, and how the data is used to make decisions.

Context Diagram

Common Information Table

Data Dictionary

Data Flow Diagram

Report Table

State-Transition Diagram

What are inputs to and outputs from this system boundary?

What are the details of the inputs and outputs?

How are the data defined?

What are the relationships between data classes?

What reports do the user roles use?

What is the status as it goes through the process?



The requirements hierarchy is also a guide to the success criteria and where you want to go (refer to

activity ‘2:IdentifytheRequirementsLevel’). For example, if I’m just starting the project and I’m at

the business requirements level, then I want to define the business objectives and benefits from doing

the project. A simple, 1‐sentence format helps me to elicit this. When I’m preparing to interview the

project sponsor, I choose questions that will elicit responses such that I’ll be able to write (refer to Table

3 for example questions in the business requirements level):

The purpose of the [insert project name] is to [insert a description of what the project team is supposed to deliver or implement] so that [insert one to many specific, measurable business benefits that will be realized].

For example, The purpose of the Paxton Automated Teller Machine (ATM) Project is to purchase and install an ATM inside the Paxton Convenience Store so that:

i. Convenience Item Sales increase by 1% per month within six months following the installation. ii. ATM Fees Revenue in the first year following the installation is greater than the total

installation cost.

4 Identify theStakeholders

Activity4:IdentifytheStakeholders

Ask, “What does ‘Who’ know?” to identify who you’ll engage with to get where you want to go. In

this activity you want to focus first on what knowledge or subject matter expertise is needed, and

second on who has that knowledge. The objective is to make the best use of your time and that of your

stakeholders by only engaging those that can most effectively contribute to discussions.

Stakeholder profiling is a very effective, yet simple to use, technique for identifying stakeholders. A

stakeholder profile helps to get the appropriate representation of all interested and affected areas. The

stakeholder profile might be used to identify the appropriate individuals to involve on the project team

itself, and to identify the appropriate individuals as resources for requirements. The key to a successful

stakeholder profile is not only to identify an individual by name and the area that they represent, but

also to define the role and responsibilities that the individual will fulfill on the project. The following are

step‐by‐step procedures to help you engage the right stakeholders (based on chapter 2 of The Quest for

Software Requirements (Miller 2009)), and example questions for each step:



a. Identify stakeholder roles. “What roles are affected by the project?”

b. Brainstorm topics of expertise. “What business and technical knowledge do I need the

stakeholders to represent?”

c. List the names of potential stakeholders. “Who do I know that has the business and technical

expertise needed?”

d. Survey each potential stakeholder. “What specific knowledge and expertise does each

stakeholder have?”

e. Analyze the stakeholder surveys. “Do I have enough resources?” “How can I best utilize the

resources that I have?”

f. Secure stakeholder resources. “Are the needed resources available?” “Where are deficiencies in

expertise?”

4a:IdentifyStakeholderRoles

“What roles are affected by the project?”

The stakeholder profile begins by identifying a list of potential stakeholders using a three‐column

tabular format such as Table 5, which provides a simple example of a Potential Stakeholder List for the

‘Online Shopping Cart Project’. Reading from left to right, the columns are as follows:

STAKEHOLDER NAME. This column is used to identify each potential stakeholder.

TOPIC OF EXPERTISE. The middle column is used to identify the area or organizational

department the stakeholder represents, as well as the specific business expertise or

knowledge needed for the scope of the project.

STAKEHOLDER ROLE. This column is used to describe the stakeholder roles in the

requirements management process and their specific interest in the development of the

system or product.

Table5–PotentialStakeholderList

Stakeholder Name Topic of Expertise Stakeholder Role

Anthony Online payment processing Subject Matter Expert

Maria, Patrick Website development Developer

Sayed, Michael, Lucas Product fulfillment processing Subject Matter Expert

Patrick Website usability and design Design Analyst

Jinlee, Lucas Customer preferences and experience Customer

Elizabeth Online sales reconciliation Accounting

Sayed, Lucas Shipping rates Mailroom

Anthony Sales Taxation Accounting



The route taken to complete the deliverable is of no real concern to the audience who benefits from

the finished product. As is the case with so many templates used to create a deliverable, the sequence

taken to build it is not the same sequence in which the deliverable is read. The potential stakeholder list

is completed by working backwards—filling in the columns from right to left. Thus, completing the

“Stakeholder Role” column is the first step in the procedures to build the stakeholder profile.

You might consider developing a list of roles that are relevant to your organization. For example,

common roles in the insurance industry include agent, policyholder, claim adjuster, insured, beneficiary,

and claimant. Select the roles appropriate for the scope of the project as typically not all roles will

apply. As shown in Table 5, note that some stakeholder roles might apply more than once depending on

the scope of topics for the particular project (for example, Subject Matter Expert).

4b:BrainstormTopicsofExpertise

“What business and technical knowledge do I need the stakeholders to represent?”

This is the most critical of the six steps to building the stakeholder profile. Identifying why a

stakeholder might participate significantly decreases the likelihood of leaving out a key contributor.

Forgetting a key contributor altogether, or bringing them in late in the development lifecycle, almost

inevitably results in costly rework.

I recommend a meeting (one‐on‐one or as a group) with an initial subset of stakeholders, such as

the sponsor, project manager, functional manager, a lead business subject matter expert, and a

technical lead to discuss the project scope. Current‐state business models and workflow diagrams, such

as those in Table 4 under activity ‘3:IdentifytheSuccessCriteria’, are reviewed for impacted business

areas.

In your brainstorming activity you might consider using a visual aid such as a flip chart shown in

Figure 3. Write the following as a title on the visual aid, “I need someone who knows ________?”

Repeat the question and fill in the blank for each symbol in all the business models.

The outcome of the brainstorming session is a list of business areas impacted and the specific topics

of business and technical knowledge that must be represented by the stakeholders selected to

participate. Use the resulting list of brainstormed topics to fill in the column headed “Topic of Expertise”

as shown in Table 5.



Figure3–VisualAidforBrainstorming‘TopicsofExpertise’

4c:ListtheNamesofPotentialStakeholders

“Who do I know that has the business and technical expertise needed?”

The “Stakeholder Name” column is completed by identifying one or more individuals believed to be

knowledgeable in each topic of expertise. In Table 5, for example, both Patrick and Maria are named as

potential stakeholders with knowledge of “website development.” Furthermore, one individual

stakeholder (for example, Sayed) might be named as knowledgeable in more than one topic.

In this step, it is important to avoid pre‐screening out potential stakeholders due to assumed

unavailability. Try to approach this step as if it were a perfect world, and anyone you choose will be

freed up to work on the project. Keep focused on the purpose of this step, which is simply identifying

potential stakeholders. The last three steps of the six‐step procedure will confirm which stakeholders

participate.

4d:SurveyEachPotentialStakeholder

“What specific knowledge and expertise does each stakeholder have?”

While the first three steps of the procedures to build the stakeholder profile result in a collective list

of several individuals representing various areas and roles, the stakeholder survey relates to a single

stakeholder or stakeholder group representative. The stakeholder survey is used to identify the depth of

knowledge that a potential stakeholder has in each of the topics of expertise needed for a particular

project.

I need someone who knows ______?



The template for the stakeholder survey, shown in Table 6, is created by replicating the “Topic of

Expertise” column from Step 4b.

Table6–StakeholderSurveyExample

Stakeholder Name: Anthony

Topic of Expertise Little Some Proficient Expert

Online Payment Processing √Website development √Product fulfillment processing √Website usability and design √Customer preferences and experience √Online sales reconciliation √Shipping Rates √Sales Taxation √

Each potential stakeholder is asked to complete the stakeholder survey and indicate his or her level

of expertise in each topic of expertise listed for the project. Four degrees of experience might be used as

follows:

Little = very limited or no experience.

Some = apprentice level or enough to be dangerous.

Proficient = familiar with topic and good understanding of the day‐to‐day tasks.

Expert = solid knowledge; person everyone goes to for help on the topic.

After the survey has been completed, ask for other potential stakeholders. For example, if my

interviewee indicates having little, no, or some experience, in any of the topics, I will ask, “Is there

anyone else you would go to with questions on these topics?” Any named individuals will be added to

the Potential Stakeholder List and will also be asked to complete the stakeholder survey.

Finally, ask each potential stakeholder to review the list of topics and ask, “Based on your

understanding of the scope of this project, what other topics of expertise should be added?

Removed?”



The key to this step is having each potential stakeholder fill out the survey for his or her expertise.

The survey is not filled out by the requirements producer, project manager, project sponsor, or any

other role involved in the project. If stakeholders inflate their experience level in any given topic area,

you’ll become aware of it during the interviews and meetings on the specific topic. On the other hand, if

stakeholders deflate their expertise (say, in an attempt to avoid participating in meetings), other

stakeholders will name that individual as an expert so you’ll probably end up inviting them anyway.

An organization might consider conducting these surveys and storing them for reuse on future

projects. The surveys might be organized by department, business unit, product, or process. When a

project starts, the business analyst can visit the repository to identify potential stakeholders. The

repository should be updated periodically to reflect the current expertise of stakeholders (for example,

add recent hires and remove people who retired).

4e:AnalyzetheStakeholderSurveys

“Do I have enough resources?” “How can I best utilize the resources that I have?”

The stakeholder surveys are compiled in a tabular format such as Table 7. This table uses the first

letter of each degree of experience. For example, where the stakeholder indicated little or no

experience, an “L” was inserted accordingly.

The stakeholder profile assessment is analyzed to make sure that all business topic areas for the

scope of the project are adequately represented. Each row (relating to a specific topic area) is reviewed

for adequate coverage. Ideally, you want to have at least two stakeholders in each topic that are either

proficient or expert. This assumes that the saying, “two heads are better than one,” holds true. Finding

at least two stakeholders in each topic also helps alleviate some of the inflated egos identified in Step

4a. Scanning Table 7, you should see that I might want to pick up a few more stakeholders in two of the

topic areas: online payment processing and sales taxation.

The stakeholder profile assessment can be utilized as a tool for requirements producers to organize

their elicitation activities, as well as to schedule meetings that work in conjunction with the availability

of the stakeholders. It also optimizes the utilization of project resources by decreasing the need to have

all stakeholders present for all meetings. For example, in Table 7, only Elizabeth and Anthony might be

invited to a discussion of the project requirements related to “online sales reconciliation.” Furthermore,

if I want to decrease involvement of an over‐utilized stakeholder, I could leave Lucas off the invite list for

discussions on “product fulfillment processing.”



Table 7 – Stakeholder Assessment

Topic of Expertise

Michael

Sayid

Jinlee

Elizab

eth

Lucas

Maria

Anthony

Patrick

Online Payment Processing S L S S S S P S

Website development L L S L L E L P

Product fulfillment processing P E L S P L S L

Website usability and design L L S L L P L P

Customer preferences and experience

S S E S P S S S

Online sales reconciliation S S L P S S E L

Shipping Rates S P L S E L L S

Sales Taxation S S L S S S E L

Key: L = Little or no experience; S = Some experience; P = Proficient; E = Expert

4f:SecureStakeholderResources

“Are the needed resources available?” “Where are deficiencies in expertise?”

Secure the needed stakeholders by meeting with the project manager, project sponsor, and/or a

stakeholder’s supervisor. Confirm the availability of stakeholders for the project timeline.

It is conceivable on some topics for no one to have a great deal of expertise. Unavailable or

nonexistent resources may pose a significant project risk. This was certainly the case on one project I

worked on—for a system intended to include brand‐new technology, and no internal stakeholder had

experience with the new technology.

The stakeholder profiling assessment might highlight opportunities for cross‐training. For example,

there is a potential project risk in a shortage of resources that are knowledgeable in the areas of online

payment processing and sales taxation. As shown in Table 7, Anthony is the only resource that has



indicated a degree of expertise of proficient or expert in these two areas. To minimize risk going

forward, perhaps Elizabeth is trained in these knowledge areas.

5 Apply theRequirements

Framework

Activity5:ApplytheRequirementsFramework

“What is the focus of each stakeholder’s viewpoint?” is a primary question to ask in this activity.

The objective of activity 5 is to ask questions of the stakeholders based on their perspective:

requirements supplier’s view and requirements receiver’s view. I use a structure that I call the

Requirements Framework, which is explained in the following subsections. However, before I explain

the requirements framework, I would like you to consider adopting a simple concept: all businesses are

the same.

AllBusinessesAretheSameThat’s right; I said all businesses are the same—at least from the viewpoint of the requirements

producer.

In its basic essence, every business can be described as the transfer of information and materials from one party to another.

Of course I could make this description broader by including the exchange of goods and services

between parties. However, I want to keep the concept simple. In my role as a business analyst

consultant, it doesn’t matter to me what my client’s business is. My approach to asking questions is the

same regardless of industry and/or type of project. By keeping my focus on this basic business

description, I’m able to understand the business as a whole first, and then progress to the detailed

complexities (usually due to technology). As technologies advance, businesses evolve and apply the

technologies with the goal of making the transfer of information and materials from one party to

another faster and cheaper.

RequirementsFocusPointsKeeping in mind that all businesses are the same (the transfer of information and materials from one

party to another), you can formulate questions in an iterative and incremental cycle. There are six

logical areas of interest as shown in Figure 4.



Figure4–RequirementsFocusPoints

Incrementally and continuously cycle through the focus points as follows:

1. What (Data)—What information and materials are needed? Start with the area of interest

called WHAT. The focus here is on data (information and materials). Simply stated, WHAT is

needed?

2. Who (Roles)—Who needs the information and materials? This area of interest focuses on who

or what (in the case of automation). These “who’s” and “what’s” are referred to as roles. In

summary, WHO needs the WHAT?

3. Why (Purpose)—Why is the information and materials needed? This focus area helps you

understand why or purpose. Ask questions to find out WHY the WHO needs the WHAT? In an

interview with someone who represents the role, you might ask, “Why do you want this

information?” or “What is the purpose of having this information?” The WHY often describes

the reason for or the work that a role performs.

4. When (Timing)—When is the information and materials needed? This area of interest focuses

on when or timing. Incrementally build upon what you’ve already elicited. For each WHY,

WHEN does the WHO need the WHAT? WHEN is often associated literally to what time of day

within a time zone. However, WHEN can also refer to the sequence of events, triggers, business

cycles, as well as the transformation of states.

5. Where (Logistics)—Where are the information and materials used? This focus area is

concerned with where. Continuing to incrementally build upon the previous interests, for each

WHO and WHY, WHERE is the WHAT used?

6. How (Process)—How is the information and materials used? This area of interest focuses on

procedures and process. Note that this is not to be confused with ‘how’ to design the system.

HOW does the WHO use the WHAT?



It is better to ask a few well-thought-out questions than a lot of questions without thinking.

ARequirementsFramework

The six requirements focus points and the stakeholder viewpoints (suppliers and receivers) are

combined to form a structure for asking questions referred to as a Requirements Framework, which is

based on John Zachman’s framework (Zachman 1987). While a software development lifecycle (SDLC)

defines the stages or phases required to develop a system, a requirements framework defines the

perspectives of the roles in the development lifecycle, and the view that each role has in the

development and implementation of requirements throughout the lifecycle stages. While agreeing in

general with the meaning behind Zachman’s framework, for the sake of simplicity, I respectfully

modified the matrix to coincide with the application on eliciting requirements. A detailed explanation of

the modifications is included in Chapter 1 of The Quest for Software Requirements (Miller 2009). Table 8

illustrates the resulting modified version of the Requirements Framework.

Table8–RequirementsFramework

DATA

(what)

ROLES

(who)

PURPOSE

(why)

TIMING

(when)

LOGISTICS

(where)

PROCESS

(how)

Scope, Business Model, Operations

Requirements Supplier’s View

Identify and define the data used by the business enterprise

Identify and define who performs a role in the business processes

Identify and define the business goals and strategies

Identify and define the events and triggers of business processing

Identify and define the enterprise locations and network

Identify and define processes and procedures of the business

System Model, Design, Construction

Requirements Receiver’s View

Design, construct, and test data entities

Design, construct, and test interfaces and system work

Design, construct, and test system to enforce business rules

Design, construct, and test system cycles

Design, construct, and test system location and network

Design, construct, and test system processing

5a:RequirementsFrameworkPerspectives(Rows)

The rows of the matrix represent the different perspectives or viewpoints of the contributing requirements roles:



Requirements Supplier’s View: The requirements supplier is any individual who is

responsible for defining the business needs to be satisfied. This includes supplying all the

detail from the initial idea or inception through each incremental iteration of the system

development. The requirements supplier’s view includes scope, business models and

operations. Scope defines the vision and mission of the enterprise. Business models convey

the conceptual nature of the business (structure, processes, organization, and so on).

Operations define what the new system is going to be.

Requirements Receiver’s View: A requirements receiver is any individual who receives

and uses the requirements specifications as the input to develop their work products

relating to implementing the requirements. They assist in the requirements process by

validating individual requirements, primarily for feasibility, completeness, and conflicts.

They can assist in validating additional quality characteristics such as necessity, priority, and

traceability. The requirements receiver’s view includes system, technology and components

aspects of development. System models are used to explore optional solutions. Technology

and construction components are used to demonstrate feasibility of the system under

development.

5b:RequirementFrameworkAreasofInterest(Columns)

The columns of the matrix represent the areas of interest that are viewed from each perspective:

DATA (what): This column relates to the information used by the enterprise. Functional

requirements describe the data while the nonfunctional requirements are about the data.

ROLES (who): This column comprises the people and organizations or other systems that

are involved or interact with the business enterprise. The functional requirements address

the interaction between the role and the business process while the nonfunctional

requirements are about taking care of the roles.

PURPOSE (why): The motivation behind what the business does is described in this

column. The functional requirements describe the ends and means while the nonfunctional

requirements describe the environment to support the accomplishment of the ends and

means.

TIMING (when): This column identifies the effects of time on the business enterprise.

Functional requirements describe the processing of events while nonfunctional

requirements describe the timing of the events.

LOGISTICS (where): Logistics is concerned with the geographical distribution of the data

and functions of the enterprise. Functional requirements describe locations while

nonfunctional requirements support the locations.

PROCESS (how): This column incorporates the processes and procedures the enterprise

executes. Functional requirements describe the processes while nonfunctional

requirements support the processes.



5c.RequirementsFrameworkApplied

The requirements framework described above is used as the foundation for organizing the lists of

possible elicitation questions contained in Part II of The Quest for Software Requirements (Miller 2009).

The book presents over 2,000 suggested questions across 14 nonfunctional categories. The questions

are first grouped under the six areas of interest and further separated by perspective (Requirements

Suppliers and Requirements Receivers).

Examples of questions that might be asked to elicit reliability requirements (reliability is the extent

to which the system consistently performs the specified functions without failure) are shown in Table 9.

Table9–ExampleReliabilityQuestions

Requirements Supplier Perspective Requirements Receiver Perspective

Data What system failure reports are needed? What data exist for use in rigorous testing to achieve the level of desired reliability?

Roles What users have a greater need for reliability?

Who gets called when system outages occur?

Purpose What is the cost of lost business when the expected level of reliability is not achieved?

What is the history/track record for similar installations of vendor components?

Timing During what time periods is system reliability most critical?

When are system upgrades and fixes migrated into production?

Logistics How does system reliability vary by business location?

What resources are needed at each business location to restore a system?

Process What escalation procedures are required during an outage?

How is the system monitored for detection of errors that do not cause an outage?

6 Evaluate the Results

Activity6:EvaluatetheResults

“How did I do?” is a primary question to ask in activity 6. The objective is to follow a continuous

‘process improvement’ cycle. There is tremendous value in knowing where you are before you go down

a path to somewhere else, charting your course, and reflecting on lessons learned from your

experiences. The six activities for asking questions are intended to be a continuous cycle for process



improvement. Similar to one that Wiegers and Beatty (2013) describes, a process improvement cycle

includes four stages:

Assess current practices. The assessment lays the foundation for making good choices about

changes you want to make. Some questions you might ask to assess current practices are:

o What are my strengths and shortcomings?

o What are strengths and weaknesses of the stakeholders on your project?

o Does my organization have a repeatable requirements management process? If so,

do I follow it, and how well? If not, what can I do to help implement a process?

o For each elicitation technique used, do I follow industry best practices?

Plan improvement actions. Tactical action plans target specific areas for improvement such

as the elicitation techniques you use. Keep in mind that you don’t have to try to get better

at everything at the same time. It is probably best to identify a couple action items and

master those before taking on more. I always say, “Iterative and incremental is better.”

Some questions you might ask to plan improvement actions are:

o Where do I want to go, and how will I get there?

o What can I do to improve my skills in the elicitation techniques that I use?

o How can I conduct a better workshop?

o How can I get more information from my face‐to‐face interviews?

o What books might I read?

o What self‐study materials are available to me?

o What online and classroom training courses are available to me?

o Who can help me develop my skills?

o What techniques haven’t I used before, and how might they help on this project?

Execute new processes and techniques. You’ve assessed your current practices and created

a plan. Now for the real challenge—executing the plan. Executing your plan means doing

something different so that you yield better results than the current way you do something.

Even individuals and teams with the best outlooks can have a limited capacity to absorb

change.

Evaluate the results. Your ability to critique yourself, as well as receive constructive

criticism from others, will help you perform even better on future activities. Some

questions you might ask to evaluate the results are:

o What went well? What didn’t go well?

o What would I change?

o If I could do this over again, what would I do differently?

o Did I get positive or negative feedback from the stakeholders regarding the process

or techniques that I used?

o Did the stakeholders understand the models that I created and the techniques that I

used?



o What didn’t I ask this time that I want to ask next time?

Accept the fact that you’re human and there is a learning curve. It takes time to plan and try new

techniques and processes. Don’t be overly hard on yourself. Educate your stakeholders about the

process and technique that you’re applying and ask for their support. “Good” requirements are the

result of a collaborative team effort, and better results will happen when you follow good processes and

best practices.

Summary

This white paper presented six activities for asking questions during requirements elicitation. Each activity has a primary question for you to ask:

1. Document Assumptions. “What do and don’t I know?”

2. Identify the Requirements Hierarchy. “Where am I?”

3. Identify the Success Criteria. “Where am I going?”

4. Identify the Stakeholders. “What does ‘Who’ know?”

5. Apply the Requirements Framework. “What?” “Who?” “Why?” “When?” “Where?” “How?”

6. Evaluate the Results. “How did I do?”

Finally, you might ask, “Where can I get a quick‐reference poster of the content from this white paper?” Visit: http://www.requirementsquest.com/products/how‐do‐i‐know‐what‐questions‐to‐ask‐poster.

References[Beatty and Chen 2012] Beatty, Joy, and Anthony Chen, 2012. Visual Models for Software Requirements.

Microsoft Press.

[Gottesdiener, 2002] Gottesdiener, Ellen, 2002. Requirements By Collaboration: Workshops for Defining Needs. Addison‐Wesley.

[Gottesdiener, 2005] Gottesdiener, Ellen, 2005. The Software Requirements Memory Jogger. Goal/QPC. [Miller, 2009] Miller, Roxanne E., 2009. The Quest for Software Requirements. MavenMark Books. [Wiegers, 2013] Wiegers, Karl E., and Joy Beatty, 2013. Software Requirements, 3rd Edition. Microsoft

Press. [Zachman, 1987] Zackman, John, 1987. “A Framework for Information Systems Architecture,” IBM

Systems Journal, 26:3 (IBM Publication G321‐5298).



AbouttheAuthor

Roxanne Miller

Requirements Quest, Inc.

Website: www.RequirementsQuest.com

LinkedIn: www.linkedin.com/in/RequirementsQuest

Twitter: @ReqSuperFreak

A self‐proclaimed “Requirements Super Freak”, Roxanne Miller has been consulting on requirements

process improvement, as well as business analysis best practices for over 20 years. Roxanne is an active member of the IIBA®, and is a Certified Business Analysis Professional™ (CBAP®). She founded the IIBA Greater Madison Chapter, Wisconsin, USA, and served as President from 2006 to 2011. Additionally, Roxanne helped Wisconsin IIBA chapters unite and launch an annual event, WI BADD® (Wisconsin Business Analyst Development Day; www.wibadd.org), which is devoted to the education, development, and networking opportunities for business analysis professionals.

Roxanne’s book, The Quest for Software Requirements, is a first‐of‐its‐kind reference guide with over

2,000 suggested elicitation questions and a tested framework to help individuals make their project work more efficient and effective. Roxanne has been involved in the Information Technology (IT) industry since 1984 and founded Requirements Quest® in 2001. Roxanne earned a bachelor degree in Management Information Systems (MIS) at the University of Wisconsin—Eau Claire, USA.

Looking for an engaging speaker? Roxanne’s hard‐won expertise, passion, and high‐energy

presentation style make her a popular, frequent speaker at business analysis industry conferences such as BusinessAnalystWorld. She delivers information‐packed, practical advice and real‐world stories from her work with state universities, government agencies and Fortune 500 enterprises spanning multiple industries.

To learn more about Roxanne, or to contact her, visit http://www.requirementsquest.com/about‐

us/meet‐roxanne.

AboutRequirementsQuestRequirements Quest is an industry leader in requirements management and business analysis

consultancy. Requirements Quest is renowned for its Requirements Quest Process™, a superior, repeatable approach to requirements elicitation, analysis, representation, and validation, which is deployed on client consulting engagements. Requirements Quest’s core competency is Requirements



Management Process Improvement, as well as Business Analysis Skills Development and Coaching. As a solution‐driven consulting company, Requirements Quest is devoted to working with organizations to improve their requirements development and management processes, and committed to developing the skills of business analysis practitioners.

Requirements Quest is a chartered Endorsed Education Provider of IIBA®, and has enhanced the

skills of thousands of practitioners in business analysis and requirements management techniques. Requirements Quest’s unique training provides a role‐based approach to implementing requirements practices. Quality requirements and successful software projects are not the sole responsibility of the business analyst role; rather, quality requirements are the result of collaboration from multiple stakeholders.

The Requirements Quest logo (“the hand”) symbolizes the importance of user involvement, both

internal and external, as a critical factor for project success. The goal of a successful Requirements Management Process is to get a consistent interpretation of the requirements from all the stakeholders. Requirements Quest applies a proven repeatable, five‐stage Requirements Management Process that significantly elevates the involvement of the right stakeholders, and fosters a collaborative team approach with increased commitment to the requirements.

The five stages of the process are symbolized by the five fingers on “the hand.” The first four fingers

represent the iterative activities of requirements development: Elicitation, Analysis, Representation, and Validation. Upon successful refinement, detailing, and approval, the requirements are baselined in the Change Control stage (represented by the thumb) where requests for change are monitored to maintain scope.

Requirements Quest’s highly‐credible consultants are IIBA® Certified Business Analysis

Professionals™ (CBAP®). They bring years of practical experience and knowledge into your organization, and work diligently to transfer that knowledge and promote the development of your own internal requirements expertise. Requirements Quest’s goal is bringing your business into focus® so you can achieve effective and efficient business results. To learn more about Requirements Quest’s consulting services, visit http://www.RequirementsQuest.com.

Posters NOW Available!

Order yours today!Visit www.RequirementsQuest.com

Date post:	14-Feb-2016
Category:	Documents
Upload:	daniel-khaw
View:	224 times
Download:	0 times

How Do I Know What Questions to Ask WHITE PAPER

Documents