Page 304 -

CHAPTER 11 ANALYSIS CONCEPTS AND PRINCIPLES 275

• 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.

11.2.2 Facilitated Application Specification Techniques
Too often, customers and software engineers have an unconscious "us and them"
mind-set. Rather than working as a team to identify and refine requirements, each
constituency defines its own "territory" and communicates through a series of memos,