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

150   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


                         To document an issue, record

                          •  Name  A short phrase
                          •  Brief description  One or two sentences
                          •  Factors  involved  Names  of,  and  links  to,  the  factors  that
                             conflict with each other to create this issue.
                          •  Why it’s hard  The challenges facing the project team; e.g.,
                             meeting  functionality,  schedule,  budget,  schedule,  quality,
                             performance constraints.
                          •  Expert  The subject matter expert
                          •  Owner,  status,  priority,  etc.  The  usual  requirements
                             management attributes
                          •  Discussion  Additional information that came up when the
                             issue was uncovered. This may include potential strategies
                             for  resolving  the  issue,  before  the  strategies  have  been
                             separately documented.
                         Sometimes, an issue is identified that does not seem to reflect a
                      conflict between factors. That’s okay. Document it first, and figure out
                      the factor conflicts later.

                          •  If  you’re  lucky,  thinking  about  what  makes  the  issue  hard
                             will suggest a new factor.
                          •  Sometimes  the  factor  conflict  won’t  become  apparent  until
                             you consider the architectural alternatives surrounding the
                             issue.
                          •  If nothing else, there will usually be a conflict with cost and/
                             or schedule.
                          •  Or, it may turn out that something that appeared to be difficult
                             didn’t really make a difference to the architecture after all.
                      Strategies
                      A strategy is a proposed decision that addresses one or more significant
                      issues. Many strategies are simply architectural design decisions, such
                      as  the  decision  to  implement  asynchronous  communication  using
                      loosely coupled event channels instead of tighter-coupled publishers
                      and  subscribers.  However,  in  global  analysis,  an  issue  can  involve
                      both  technical  and  managerial  factors,  and  so  the  strategy  may  be
                      technical, managerial, or a combination. For example, if the issue is
                      “ASP  programming  is  best  done  in  Java  for  this  product,  but  our
                      programmers only know C++,” the architect and the project manager
                      could  choose  to  “retrain  our  programmers  in  JSP,”  “buy  an  ASP
                      development environment for C++,” or “use some C++ programmers
                      to write C++ applets, and retrain others to write JSP.”
   179   180   181   182   183   184   185   186   187   188   189