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

92   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


                      Ideally,  the  feature  tree  would  be  supported  in  the  modeling  tool
                      being used. If not, any graphical media could be used to illustrate the
                      full scope of features in the idealized product. Of course, not all the
                      features identified would make it into the final product; they would
                      need to be prioritized. After an analysis effort to expand the product
                      features into well-defined, testable requirements, a product release
                      would  then  be  specified  with  the  desired  features.  During  initial
                      product definition, a feature model is kept relatively “lightweight.”
                      However, the same model can be extended to fully support a product
                      line. It can also be used to define product variations or customization
                      that  may  be  made  by  the  user  after  delivery.  Feature  models  are
                      especially useful in identifying test cases where the system can be
                      configured by the user after delivery.

                      Analyzing Product Features and Creating a Use Case Model
                      Once we have a draft set of features, we are able to start creating a
                      model from which we will derive all our customer requirements (all
                      of them, before ranking). Product features become high-level abstract
                      use cases, from which we start the decomposition process to elicit
                      details that will become requirements (Figure 4.9). As we go through
                      each of the features, scenarios are created describing the feature in
                      action; the scenario diagrams describe the usage details (Figure 4.10),
                      and the use case diagrams provide structural information; e.g., which
                      other use cases (or processes) are included or sometimes included
                      (called extending use cases).




                                                         Delete Event
                                                         Creation Date:2/26/2006
                                                         Modification Date:1/15/2007
                                                         Modified By:RDM
                                                         Status:Preliminary


                                                            <<extend>>
                       Official
                              Delete event   Delete event
                                interface
                                                     <<include>>
                                    <<include>>                 Delete event from
                                              <<include>>      competitor calendar
                        Delete event from
                         team calendar             Delete event from
                                                    event calendar
                                  Delete event record from
                                     results database

                      FIGURE 4.9  Use case decomposition
   118   119   120   121   122   123   124   125   126   127   128