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

ç          ç  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


                      $ERIVATION !NALYSIS
                      $ERIVATION  ANALYSIS  IS  CONCERNED  WITH  DISCOVERING  THE  ORIGIN  OR
                      RATIONALE OF A FUNCTION  MODULE  ETC  4HE RELEVANT DESIGNS ARE TRACED
                      BACK FIRST TO THE REQUIREMENTS  AND THEN FROM THE REQUIREMENTS TO THE
                      STAKEHOLDERS  REQUESTS  OR MARKET DEMANDS OR BUSINESS GOALS  THAT
                      LED TO THE DECISION TO ADD THE REQUIREMENT TO THE PRODUCT  !LTERNATIVELY
                      A PRODUCT COMPONENT OR COMPONENT REQUIREMENT IS TRACED BACK TO THE
                      ORIGINAL RATIONALE FOR CREATING IT  $ERIVATION IS NECESSARY TO UNDERSTAND
                      WHY A FEATURE OR FUNCTION IS IN A PRODUCT  WITHOUT WHICH INTELLIGENT
                      DECISIONS REGARDING A CHANGE TO THE REQUIREMENT CANNOT BE MADE

                      #OVERAGE !NALYSIS
                      #OVERAGE  ANALYSIS  MEASURES  THE  RATIO  OF  DEFINED  TO  ACTUAL  PRODUCT
                      FEATURES  )T IS USED TO DETERMINE WHETHER THE REQUIREMENTS OR FEATURES
                      OF INTEREST HAVE BEEN IMPLEMENTED IN THE PRODUCT  4HIS IS ACCOMPLISHED
                      BY TRACING FROM THE ORIGINAL SYSTEM  OR CONTRACT  REQUIREMENTS DIRECTLY
                      TO TEST CASES  .OTE THAT THE TESTS ARE THE BEST WAY TO MEASURE COMPLETION
                      OR  COMPLIANCE  AS  DESIGNS  MAY  NOT  HAVE  BEEN  IMPLEMENTED   )F  A
                      PRODUCT  IS  RELEASED  TO  THE  MARKET  WITHOUT  THE  FEATURES  DEEMED  AS
                      BEING IMPORTANT  IT MAY FAIL  )F THE PRODUCT IS BEING DELIVERED AS PART
                      OF  A  CONTRACT   THEN  COVERAGE  ANALYSIS  IS  USED  TO  MEASURE  CONTRACT
                      COMPLIANCE  E G   WHAT WAS AGREED ON VERSUS WHAT IS CURRENTLY BEING
                      DELIVERED  4HE ARCHITECT CAN ALSO USE COVERAGE ANALYSIS TO ASSIST WITH
                      AN IMPACT ANALYSIS  THAT IS  THE COST OF MAKING A CHANGE MAY BE LOWER
                      IF IMPLEMENTATION OF A PRODUCT FEATURE HAS NOT YET STARTED

                      2OUTINE 2EQUIREMENTS -ANAGEMENT !CTIVITIES
                      2OUTINE REQUIREMENTS MANAGEMENT ACTIVITIES ARE THOSE THAT TAKE PLACE
                      ON MOST  IF NOT ALL PROJECTS  4HEY MAY NOT INVOLVE A LOT OF MANUAL
                      EFFORT  BUT DEPENDING ON THE NATURE OF THE PROJECT  THEY MAY BE CRUCIAL
                      TO A POSITIVE OUTCOME

                      )DENTIFYING 6OLATILE 2EQUIREMENTS
                      6OLATILITY IS USUALLY MEASURED BY GATHERING STATISTICS FROM A REQUIREMENTS
                      DATA MANAGEMENT SYSTEM  2$-3   /NE OF THE ADVANTAGES OF AN 2$-3
                      IS THAT WHENEVER A REQUIREMENT IS CHANGED  VERSION MANAGEMENT IS
                      TRANSPARENT TO THE USER  -OST  IF NOT ALL  2$-3 PRODUCTS CAN PROVIDE
                      VOLATILITY REPORTS  )F THEY DO NOT  THEN IT IS USUALLY A SIMPLE MATTER TO
                      CREATE SUCH A REPORT  4WO METRICS ARE OF SPECIAL INTEREST  THE VOLATILITY
                      OF  THE  OVERALL  REQUIREMENT  SET  AND  THE  VOLATILITY  OF  INDIVIDUAL
                      REQUIREMENTS   !  BASELINE  TYPICALLY  CANNOT  BE  ESTABLISHED  UNTIL
                      AGGREGATE VOLATILITY  NUMBER OF REQUIREMENTS CHANGING PER UNIT OF
                      TIME   DROPS  TO  A  SUFFICIENTLY  LOW  VALUE  THAT  THE  REQUIREMENTS  ARE
                      DEEMED STABLE  4HE POINT AT WHICH THAT OCCURS WILL BE DIFFERENT FOR
                      DIFFERENT TYPES OF PROJECTS  +EEP IN MIND THAT A VOLATILITY METRIC IS
                      ONLY VALID WHERE ALL THE REQUIREMENTS ANALYZED ARE AT THE SAME LEVEL
                       E G   HIGH LEVEL CUSTOMER REQUIREMENTS
   227   228   229   230   231   232   233   234   235   236   237