Page 303 -
P. 303

274           PART THREE  CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING


                          Throughout evaluation and solution synthesis, the analyst's primary  focus is on
         ?  What should  "what," not "how." What data does the system produce and consume, what functions
            be my
         primary focus at  must the system perform, what behaviors does the system exhibit, what interfaces
         this stage?
                       are defined and what constraints apply? 1
                          During the evaluation and solution synthesis activity, the analyst creates models
                       of the system in an effort to better understand data and control flow, functional pro-
                       cessing, operational behavior, and information content. The model serves as a foun-
                       dation for software design and as the basis for the creation of specifications for the
                       software.
                          In Chapter 2, we noted that detailed specifications may not be possible at this
                       stage. The customer may be unsure of precisely what is required. The developer may
                       be unsure that a specific approach will properly accomplish function and perfor-
                       mance. For these, and many other reasons, an alternative approach to requirements
                       analysis, called prototyping, may be conducted. We discuss prototyping later in this
                       chapter.



                11.2   REQUIREMENTS ELICITATION FOR SOFTWARE
                       Before requirements can be analyzed, modeled, or specified they must be gathered
                       through an elicitation process. A customer has a problem that may be amenable to
                       a computer-based solution. A developer responds to the customer's request for help.
                       Communication has begun. But, as we have already noted, the road from communi-
                       cation to understanding is often full of potholes.

                       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.
   298   299   300   301   302   303   304   305   306   307   308