Page 146 -

CHAPTER 5 SOFTWARE PROJECT PLANNING 117

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

• Are you the right person to answer these questions? Are answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions (and others) will help to "break the ice" and initiate the communi-
cation that is essential to establish the scope of the project. But a question and answer
meeting format is not an approach that has been overwhelmingly successful. In fact,
the Q&A session should be used for the first encounter only and then be replaced
by a meeting format that combines elements of problem solving, negotiation, and
specification.
Customers and software engineers often have an unconscious "us and them" mind-
XRef set. Rather than working as a team to identify and refine requirements, each con-
Requirements stituency defines its own "territory" and communicates through a series of memos,
elicitation techniques
are discussed in formal position papers, documents, and question and answer sessions. History has
Chapter 11. shown that this approach works poorly. Misunderstandings abound, important infor-
mation is omitted, and a successful working relationship is never established.
With these problems in mind, a number of independent investigators have devel-
oped a team-oriented approach to requirements gathering that can be applied to
help establish the scope of a project. Called facilitated application specification tech-
niques (FAST), this approach encourages the creation of a joint team of customers
and developers who work together to identify the problem, propose elements
of the solution, negotiate different approaches, and specify a preliminary set of
requirements.

5.3.2 Feasibility
Once scope has been identified (with the concurrence of the customer), it is reason-
able to ask: “Can we build software to meet this scope? Is the project feasible?” All
"It's 106 miles to
Chicago, we got a too often, software engineers rush past these questions (or are pushed past them by
full tank of gas, half impatient managers or customers), only to become mired in a project that is doomed
a pack of cigarettes, from the onset. Putnam and Myers [PUT97a] address this issue when they write:
it's dark and we're
wearing sunglasses. . . . not everything imaginable is feasible, not even in software, evanescent as it may appear
Hit it." to outsiders. On the contrary, software feasibility has four solid dimensions: Technology—
The Blues Brothers Is a project technically feasible? Is it within the state of the art? Can defects be reduced to
a level matching the application’s needs? Finance—Is it financially feasible? Can develop-
ment be completed at a cost the software organization, its client, or the market can afford?
Time—Will the project’s time-to-market beat the competition? Resources—Does the orga-
nization have the resources needed to succeed?