Page 43 -
P. 43

28     FULLER  AND  DAVIS
                    Figure 3.1  The Requirements Appreciation Model




































                    challenges faced by the user and analyst when attempting to come to a mutual understanding
                    regarding a business situation of interest.
                      In requirements elicitation, there is often a common ground (a) where requirements are known
                    by both parties—what we call conspicuous requirements. These requirements are known and
                    understood by both the user and analyst due to their shared prior experiences in the domain of
                    interest. However, requirements outside this shared area represent a number of challenges to both
                    the analyst and the user.
                      One set of communication challenges exists when there are likely some potential requirements
                    (b) that are known by the analyst but not known by the user. These potential requirements come
                    about due to the unique experience the analyst has in the system domain that is not shared by the
                    user. Increasing the size of the shared area (a) usually comes about through the application of the
                    analyst’s experience and skills to identify patterns (Bolloju, 2004) or common system requirements,
                    effectively enlarging area (a) upward. The analyst must be able to effectively communicate these
                    potential requirements to the user to determine whether they are also requirements in the current
                    context (Davis, 1982). This application of the analyst’s experience in requirements elicitation
                    seeks to exploit the opportunity to reuse some previously derived design artifact (Purao, Storey,
                    and Han, 2003).
                      Another set of communication challenges exists when there are potential requirements (c) known
                    by the user, but not known by the analyst. These potential requirements come about due to the
                    unique experience the user has in the system domain that is not shared by the analyst. Unless the
                    user—typically an expert of some kind—can identify and articulate these requirements, they may
                    go unidentified and unshared with the analyst, limiting the functionality of the system. To identify
   38   39   40   41   42   43   44   45   46   47   48