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

E
                             r
                           e
                               :
                              2

                          t
                        a
                       h
                                                     i
                                                  n
                                                    g
                         p
                                             n
                                            e
                                          m

                                               s
                                              t
                                         e
                                     q
                                    e
                                   R
                                        r
                                        i
                                      u
                                                     n
                                                                   a
                                                                  f
                                                                     t
                                                                    c
                      C C h a p t e r   2 :      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      21 21
                                                                              g
                                                                 i
                                                                t
                                                                            l
                                                                           e
                                                                             n
                                                                             i
                                                                       M

                                                                         d
                                                                        o
                                                         r

                                                          i
                                                           n
                                                            g
                                                        e
                                                       e
                                                              A
                                                               r
                         Thus, the key components of requirements engineering artifact
                      modeling are
                          •  An RE artifact model as a measurable reference model that
                             can be used to support interdisciplinary communication and
                             specifications development
                          •  A process tailoring approach that specializes the RE artifact
                             model to specific organizational or project needs
                          •  RE artifact-centered process guidelines that define completion
                             levels of the RE artifact model. The specified completion levels
                             form a baseline for measuring project progress and artifact
                             quality.
                 2.2   RE Taxonomy   1
                      It is important that all stakeholders and process participants in the
                      development  of  products  understand  the  meaning  of  each
                      requirements  engineering  term  to  represent  the  same  thing.  If,  for
                      example,  customers,  product  managers,  and  manufacturing
                      understand the term “feature” to mean different things, there may be
                      difficulty with quality assurance tasks and related productivity. While
                      universal definitions exist for many terms in requirements engineering,
                      there is still disagreement within the RE research community as to the
                      meaning  of  some  terms  such  as  “nonfunctional  requirement.”
                      Consequently, it may be necessary for an organization or project to
                      create its own set of definitions wherever there is the potential for
                      misunderstandings.
                         We recommend that a project or product team have a glossary of
                      terms. An enterprise-wide dictionary is always preferable but may
                      not be feasible; e.g., different parts of an organization may be working
                      in different domains.
                         A  taxonomy  is  a  collection  of  controlled  vocabulary  terms
                      organized  into  a  hierarchical  structure.  Taxonomies  are  commonly
                      used  to  classify  things;  e.g.,  a  taxonomy  of  the  insect  world.  An
                      example of a taxonomy for requirements is given in Figure 2.1. In
                      well-structured taxonomies, each term has only one parent. However,
                      depending on need, it is possible to have poly-hierarchies where
                      a  term  can  have  more  than  one  parent.  Figure  2.2  illustrates  the
                      difficulty of creating taxonomies; i.e., there may be multiple ways of
                      representing concepts. Note that a term can appear in more than one
                      place in a taxonomy.
                      1   www.metamodel.com/article.php?story=20030115211223271
   43   44   45   46   47   48   49   50   51   52   53