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

103
                                                             i
                                                            u
                                                               e
                                                              r
                                                           q
                                                 e
                                                t

                                                  r
                                                                m
                                                                        o
                                                                         d

                                                                       M
                                                                           e
                                                                   n
                                                                 e
                                                                     s
                                                                    t
                                               p
                                                                             n
                                                     :
                                                    4
                                                                              g
                                           C h a p t e r   4 :      R e q u i r e m e n t s   M o d e l i n g      103
                                                          e
                                                        R
                                                                             i
                                                                            l
                                           C
                                            h
                                             a
                  Symbol             Hyperlink To   Rationale
                  Abstract use case   Use case     An abstract use case is a
                  representing a set   diagram     placeholder for a product feature
                  of functions                     or concept and does not have
                                                   logic. It is the included use cases
                                                   that would have concrete logic.
                  Abstract use case   Use case     Abstract use cases and product
                  representing a     diagram       features may need to be
                  product feature                  decomposed several levels before
                                                   concrete, testable features or
                                                   use cases are reached. In order
                                                   to keep the diagrams simple, it is
                                                   necessary to be able to hyperlink
                                                   use case diagrams that continue
                                                   the hierarchy.
                  Concrete use case  Use case      Use cases with many ancillary
                                     diagram       processes may need to be
                                                   decomposed several levels.
                                                   The ability to put only one level
                                                   of decomposition on a diagram
                                                   reduces clutter and makes the
                                                   model more manageable.
                  Concrete use case  Activity      When a use case is concrete
                                     diagram       (e.g., testable), there may be
                                                   many possible paths. While
                                                   scenario diagrams are good for
                                                   showing one path, the best way
                                                   to see all the possible outcomes
                                                   or variations is to use an activity
                                                   diagram as an overview, showing,
                                                   in simplified fashion, all possible
                                                   paths that the process may take.
                  Concrete use case  Sequence      A use case is a process. One
                                     diagram       specific thread (e.g., a success
                                                   mode or a failure mode) is best
                                                   shown on one diagram for clarity.
                  Concrete use case  Activity      When a process is primarily
                                     diagram       sequential logic (e.g., an algorithm
                                                   or computation) activity diagrams
                                                   do a much better job of presenting
                                                   the logic than sequence diagrams,
                                                   showing activities, inputs, and
                                                   outputs.
                 TABLE 4.1  Example Hyperlinks
   130   131   132   133   134   135   136   137   138   139   140