Page 74 - Software and Systems Requirements Engineering in Practice
P. 74

46   S o f t w a r e   &   S y s t e m s   R e q u i r e m e n t s   E n g i n e e r i n g :   I n   P r a c t i c e


                      many functions within the insurance industry, there were interactions
                      with sales, marketing, policy writing, accounting, and independent
                      insurance agents. The requirements gathering was being done in a
                      distributed fashion, so it was important to ensure that there was no
                      duplication of work, and that time was not spent on topics that were
                      out  of  scope  (e.g.,  how  marketing  uses  underwriting  information).
                      High-level, color-coded models were used to indicate the distribution
                      of work and identify out-of-scope topics (see Figure 3.3).

                      Understanding of Product Needs Is Incomplete
                      Analysts  are  often  asked  to  help  define  requirements  for  products
                      where the stakeholders are uncertain of their needs. Sometimes they
                      are even uncertain as to what the business goals are. There are several
                      techniques that can be used to assist in clarifying customer needs. One
                      method, prototyping, is discussed in detail in Chapter 9. Sometimes,
                      just the act of eliciting requirements with several stakeholders present
                      will stimulate discussion and help to clarify customers’ needs. Another
                      technique  that  we  recommend  is  to  start  by  creating  marketing
                      literature, a user manual, or lightweight specification sheets for the
                      product. For example, create a simple, two-page marketing brochure
                      or fictional product advertisement that might be given to customers:
                          •  Is it what the customers want and need?
                          •  Is it feasible to build (with the available technology, time, and
                             budget)?
                          •  Does  it  adequately  describe,  at  a  high  level,  the  proposed
                             product features?
                          •  Does it indicate why customers should buy it (e.g., over the
                             competitive products)?

                         Such a mock marketing brochure development task might lead to
                      the conclusion that not enough is known about the market, or perhaps
                      the business goals are not clear enough. If work does go forward to



                                                        <<include>>
                                <<include>>
                                       Fleet Automotive Insurance
                                                        <<include>>
                                               <<include>>       Marketing

                             Accounting
                                                            Sales
                                          Underwriting
                      FIGURE 3.3  Using color to identify subjects that are out of scope
   69   70   71   72   73   74   75   76   77   78   79