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

148   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


                             confused with stability, a property indicating how strong the
                             consensus is for the current wording of a requirement.
                          •  Impact  This explains how the factor is likely to influence
                             the architecture.
                          •  Authority  This is the justification for including the factor in
                             the analysis. For example, it could be the name of a stakeholder
                             or  a  team  member,  references  to  requirements,  stakeholder
                             requests, or other project documents, or a phrase like “general
                             knowledge”  or  “past  experience.”  External  authorities  are
                             generally better than just listing a team member, but since you
                             are the architects, others do expect you to be the authority some
                             of the time. Also, there will be cases where you identify a factor
                             that you expect will become important to certain stakeholders
                             later. You  can  list  yourself  as  the  authority  temporarily,  and
                             comment on who else may become interested.
                          •  Expert  This is the subject matter expert for the factor.
                         In addition, each factor has other attributes equivalent to those
                      usually attached to requirements, such as unique ID, owner, status, or
                      stability.
                         An example textual description of a factor is given in Figure 5.3.
                         Although  storing  factors,  issues,  and  strategies  in  an  ordinary
                      text document can be adequate for small efforts, we would recommend
                      managing them with a general-purpose requirements management
                      tool, such as Teamcenter, Doors, or Requisite Pro, if your organization is
                      already using one. The key advantage of using a tool is being able to
                      look  at  the  same  text  either  as  a  narrative  document  or  as  a
                      requirements catalog.



                       1. Organizational Constraints
                       1.3 Management
                       1.3.5 Buy reporting subsystem
                       (Factor-37)
                       The reporting subsystem should be based on a commercial product, e.g. Crystal
                       Reports
                       Negotiability Previous reporting system was implemented in-house, so buying
                       COTS is not a rigid requirement. But competitors are already doing this.
                       Changeability Reporting features may become more specialized, making the
                       “buy” option less advantageous.
                       Impact Buying the market leading product has low development cost, risk, and
                       time to market, but introduces licensing costs and reduces product
                       differentiation.
                       Authority Features 135, 136, and 139, and SR 174 are from Jim Smith, who has
                       interviewed customers concerning reporting features.
                      FIGURE 5.3  Textual presentation of a factor
   177   178   179   180   181   182   183   184   185   186   187