Initiating the Process

11.2.1 Initiating the Process

The most commonly used requirements elicitation technique is to conduct a meet- ing or interview. The first meeting between a software engineer (the analyst) and the

"He who asks a customer can be likened to the awkwardness of a first date between two adolescents. question is a fool for

five minutes; he Neither person knows what to say or ask; both are worried that what they do say will who does not ask a

be misinterpreted; both are thinking about where it might lead (both likely have rad- question remains a

ically different expectations here); both want to get the thing over with, but at the fool forever."

same time, both want it to be a success.

Chinese Proverb

Yet, communication must be initiated. Gause and Weinberg [GAU89] suggest that the analyst start by asking context-free questions. That is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself. The first set of context-free questions focuses on the customer, the overall goals, and the benefits. For example, the analyst might ask:

1 Davis [DAV93] argues that the terms what and how are too vague. For an interesting discussion of this issue, the reader should refer to his book.

• Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution? • Is there another source for the solution that you need?

These questions help to identify all stakeholders who will have interest in the soft- ware to be built. In addition, the questions identify the measurable benefit of a suc- cessful implementation and possible alternatives to custom software development.

The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution:

• How would you characterize "good" output that would be generated by a successful solution?

“Plain question and plain answer make

• What problem(s) will this solution address? the shortest road out

• Can you show me (or describe) the environment in which the solution will be of most

used? perplexities.”

Mark Twain

• Will special performance issues or constraints affect the way the solution is approached?

The final set of questions focuses on the effectiveness of the meeting. Gause and Weinberg [GAU89] call these meta-questions and propose the following (abbreviated) list:

• Are you the right person to answer these questions? Are your answers "offi- cial"?

If a system or product will serve many users,

• Are my questions relevant to the problem that you have?

be absolutely certain • Am I asking too many questions? that requirements are elicited from a

• Can anyone else provide additional information? representative

• Should I be asking you anything else? cross-section of users. If only one user

These questions (and others) will help to "break the ice" and initiate the communi- defines all

cation that is essential to successful analysis. But a question and answer meeting for- requirements,

mat is not an approach that has been overwhelmingly successful. In fact, the Q&A acceptance risk is high.

session should be used for the first encounter only and then replaced by a meeting format that combines elements of problem solving, negotiation, and specification. An approach to meetings of this type is presented in the next section.