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

ç          ç  3 O F T W A R E ç   ç 3 Y S T E M S ç 2 E Q U I R E M E N T S ç % N G I N E E R I N G   ç ) N ç 0 R A C T I C E



                       /RGANIZATIONAL )SSUES )MPACTING
                       2EQUIREMENTS -ANAGEMENT
                      ! REQUIREMENTS ENGINEERING MANAGEMENT PLAN  2%-0  SHOULD NOT BE
                      CREATED WITHOUT TAKING A HOLISTIC LOOK AT OTHER PROCESSES ASSOCIATED
                      WITH  SYSTEMS  DEVELOPMENT   E G    MANUFACTURING   HARDWARE
                      DEVELOPMENT   SOFTWARE  DEVELOPMENT   TESTING   AND  MAINTENANCE   !
                      TYPICAL MISTAKE WHEN SETTING UP A 2%-0 IS TO IGNORE UPSTREAM AND
                      DOWNSTREAM PROCESSES  4HEY ARE VERY NECESSARY TO UNDERSTAND THE
                      CONTEXT OF ANY 2- PROCESSES PUT IN PLACE  FOR EXAMPLE

                          v  (OW ARE BUSINESS GOALS AND POLICIES CREATED
                          v  7HERE ARE THEY KEPT
                          v  (OW  CAN  WE  MAINTAIN  TRACES  BETWEEN  GOALS   POLICIES   AND
                             REQUIREMENTS SUCH THAT THE IMPACT OF A CHANGE IN BUSINESS
                             DIRECTION  E G   CHANGE IN GOAL  CAN BE MEASURED

                         3INCE  BUSINESS  RULES  DERIVE  FROM  POLICIES   THE  IMPACT  OF  POLICY
                      CHANGES MUST BE MEASURABLE  E G   WHAT RULES WILL HAVE TO CHANGE IF
                      THIS POLICY CHANGES
                         .OTE THAT FOR SMALLER PROJECTS  PROCESSES SHOULD NOT BE TOP HEAVY
                      BUT RATHER AS LEAN AS POSSIBLE  -OST IMPORTANT  WHEN LEAVING ACTIVITIES
                      AND WORK PRODUCTS OUT OF A PROCESS  IS TO LEAVE THEM OUT BY COMMISSION
                      AND NOT BY OMISSION  E G   FORGETTING ABOUT THEM
                         !NOTHER  ORGANIZATIONAL  ISSUE  IS  THAT  OF  DISTRIBUTED  ENGINEERING
                      WORK  SEE #HAPTER      $ISTRIBUTING THE EFFORT CARRIES WITH IT ADDITIONAL
                      CHALLENGES  AS SHOWN IN 4ABLE
                         )N GENERAL  ANY DISTRIBUTED EFFORT SHOULD HAVE STRONG LEADERSHIP AT
                      THE  PROJECT  MANAGEMENT  AND  TECHNICAL  LEAD  LEVELS   FACE TO FACE
                      RELATIONSHIP  BUILDING  AND  TRAINING  PRIOR  TO  PROJECT  INITIATION   A  CLEAR
                      CHAIN OF COMMAND  CLEAR DEFINITION OF ROLES AND RESPONSIBILITIES  A WELL
                      DEFINED   WELL UNDERSTOOD  REQUIREMENTS  ENGINEERING  PROCESS   AND  A
                      LIAISON AT EACH SITE WITH RESPONSIBILITY FOR ALL COMMUNICATIONS ACTIVITIES

                      #REATING A 2EQUIREMENTS $ATABASE
                      &OR SMALL PROJECTS  REQUIREMENTS CAN BE MANAGED USING SPREADSHEETS
                      (OWEVER  AS A PROJECT REACHES A CRITICAL SIZE  SAY     REQUIREMENTS OR
                      MORE  IT BECOMES NECESSARY TO USE A DATABASE TO HOLD INFORMATION
                      !CTIVITIES SUCH AS CONFIGURATION MANAGEMENT  MANAGING TRACEABILITY
                      GENERATING  SPECIFICATIONS   AND  EXTRACTING  METRICS  ARE  ACCOMPLISHED
                      WITH  MUCH  LESS  EFFORT  USING  ONE  OF  THE  COMMERCIALLY  AVAILABLE
                      REQUIREMENTS ENGINEERING DATA MANAGEMENT FACILITIES
                         #OMMERCIAL  DATA  MANAGEMENT  TOOLS  CAN  DO  A  VERY  NICE  JOB  OF
                      TRACKING REQUIREMENTS CHANGES AS THEY DO FINE GRAIN VERSION CONTROL
                      &OR EXAMPLE  JUST CHANGING THE PRIORITY OF A REQUIREMENT WILL RESULT IN
                      A NEW REQUIREMENT VERSION BEING CREATED AS WELL AS AN AUDIT TRAIL  SO
   241   242   243   244   245   246   247   248   249   250   251