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

E
                                                  n

                                              t
                                               s
                                                       e
                                                        e
                                                     n
                                                    g
                                                     i
                                             n
                                     q
                                      u
                                    e
                              2
                               :
                                          m
                                            e
                                         e
                                        i
                                        r
                                                         r
                                                                        o
                                                                         d
                                                                       M
                                                                     t

                                                                             n
                                                                              g
                                                                             i
                                                                           e
                                                                            l
                                                                    c

                                                              A
                                                            g
                                                          i
                                                           n
                                                                  f
                                                                   a
                                                                 i
                                                               r
                                                                t

                           e
                             r
                         p
                          t
                        a
                      C C h a p t e r   2 :      R R e q u i r e m e n t s   E n g i n e e r i n g   A r t i f a c t   M o d e l i n g      27 27
                       h
                      If  templates  with  the  appropriate  attributes  are  filled  in  for  each
                      artifact, process definition is much simpler (see the section “Extending
                      an Artifact Model to Augment Process Definition”).
                 2.3   RE Artifact Model
                      An RE artifact model (REAM) is a meta-model for the structuring of
                      requirements engineering work products. A meta-model is an explicit
                      model of the constructs and rules needed to build specific models
                      within a domain of interest. An RE artifact model contains all the
                      artifacts  referenced,  modified,  or  created  during  requirements
                      engineering activities. The artifacts shown on REAM diagrams are
                      those that are actually used in a project, and they each have a name
                      and definition.
                         Upon first glance, the REAM diagram may appear similar to a
                      software  class  diagram.  However,  there  are  some  significant
                      differences. A software class diagram may show many different types
                      of relationships between objects, whereas an RE artifact model only
                      shows simple associations (a single solid line). For example,
                          •  Classes shown on a class diagram may have methods and
                             attributes; an RE artifact only has a name and description.
                          •  A  class  diagram  may  show  abstract  classes,  or  classes  for
                             which there is no physical representation; an artifact model
                             only shows real objects that will be used or created during a
                             requirements engineering activity.
                         An artifact model is different than a taxonomy in that it is a graph
                      rather than a tree, has many more artifacts than what would be in a
                      taxonomy, and typically contains many domain specific extensions.
                         Both a REAM and a taxonomy can be multitiered, so that selecting
                      an object can open onto a different diagram. However, care must be
                      taken  in  that  while  a  taxonomy  lends  itself  well  to  a  hierarchical
                      approach, artifact models tend to be flatter. For example, an object on
                      one REAM diagram might have a relationship with an object on a
                      different diagram.
                      Elements of an Artifact Model
                      A fragment of an artifact model is shown in Figure 2.7. It consists of
                      the following elements:
                                             * Participates in *
                                  Actor      1     Initiates       *  Use Case
                      FIGURE 2.7  Simple artifact model
   49   50   51   52   53   54   55   56   57   58   59