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

149
                                                Q
                                                 u
                                           5
                                            :
                                                  a
                                                     t
                                                      y
                                                   l
                                                    i
                                    h
                                     a
                                                                              t
                                                                               s
                                      p
                                         r

                                       t
                                        e

                                                                    q
                                                                      u
                                                                  R
                                                                   e
                                                                       i
                                                                          m
                                                                           e
                                                                        r
                                                                         e

                                                          t
                                                           r
                                                        A
                                                         t
                                                            i
                                                               t
                                                                e
                                                             b
                                                              u
                                                                            n
                                   C C h a p t e r   5 :      Q u a l i t y   A t t r i b u t e   R e q u i r e m e n t s      149
                         “Softness” is a hallmark of architecture-influencing factors. Softness
                      is inevitable because much of the analysis must be performed before
                      the hard facts are known. We find that factors often need to capture
                      four  kinds  of  softness:  range,  change  over  time,  uncertainty,  and
                      negotiability. These can all be present in a single factor. For example,
                         “Customers’ networks currently have 100 to 100,000 nodes. The
                         upper end of this range will increase every two years by a factor
                         of 1.5 to 3. Our architecture may not have to cover the low end of
                         the range, if expected sales don’t justify the cost.”
                         This factor illustrates range (100 to 100,000 nodes), evolution over
                      time (will increase every two years), probability (factor of 1.5 to 3),
                      and  negotiability  (expected  sales  vs.  cost). Although  this  example
                      expresses  probability  with  numbers,  a  factor  is  permitted  to  use
                      qualitative words like “probably,” “likely,” “might,” and “could” to
                      express  uncertainty.  Negotiability  links  this  factor  to  other  factors,
                      giving some idea of how variations in one affect the other. Although
                      it may be tempting to split such a factor into four different factors,
                      each addressing one kind of softness, don’t make the split unless you
                      are confident that the different factors are relatively independent of
                      each other. Allowing softness in an architecture factor thus allows the
                      architect to document a factor and make plans concerning it before
                      the uncertainty is resolved.
                         Unlike requirements catalogs, the collection of architecture factors
                      does not have to be complete. Global analysis prioritizes them, finds
                      conflicts and tradeoffs between them, and finally reduces them to a
                      set of key issues that shape the architecture. The less important factors
                      will likely be ignored, for most purposes, so missing a few of them
                      is okay.
                      Issues
                      The purpose of documenting issues is to identify the aspects of the
                      project that are going to be hard to accomplish. A global analysis issue
                      is  a  potential  conflict  or  tradeoff  between  two  or  more  factors—
                      usually many more! For example, the issue “Aggressive Schedule”
                      might be described as, “The project probably can’t be completed in
                      the 14 months currently budgeted if we have to train our programmers
                      in  Java,  add  new  tools  to  our  development  environment,  and
                      implement all 75 major features, using a novel user interface concept.”
                      Implicit in that statement are the factors
                          •  Develop in 14 calendar months
                          •  Programmers don’t know Java
                          •  Seventy-five major features
                          •  Novel user interface concept
   178   179   180   181   182   183   184   185   186   187   188