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

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


                             PLACEHOLDER REPRESENTATIONS OF THE SEEMINGLY IRRELEVANT STEPS
                             TO  ENABLE  STAKEHOLDER  REVIEW   4HE  LEVEL  OF  DETAIL  USED  FOR
                             INDIVIDUAL STEPS VARIES ACCORDING TO THE STAKEHOLDERS  NEED
                             FOR CLARIFICATION  SUCH THAT THE MOST NOVEL  UNCERTAIN  OR RISKY
                             STEPS WILL BE EXPLORED MOST THOROUGHLY
                          v  )F THE STORYBOARD DESCRIBES A NONTRIVIAL DYNAMIC BEHAVIOR  IT
                             SHOULD BE SUMMARIZED IN THE FORM OF A BEHAVIOR MODEL  -OST
                             STAKEHOLDERS WILL UNDERSTAND THE SEMANTICS OF SIMPLE STATE
                             BASED MODELS  SUCH AS STATE MACHINES  PARTICULARLY IF NO CYCLIC
                             BEHAVIORS ARE INVOLVED
                          v  7HEN  A  REQUIREMENTS  ENGINEER  ELABORATES  A  STORYBOARD
                             TOGETHER WITH A DOMAIN STAKEHOLDER  THE FOLLOWING QUESTIONS
                             SHOULD  BE  ADDRESSED  WITH  RESPECT  TO  EACH  STEP  OF  A
                             STORYBOARDED SCENARIO
                             v  !RE  ALL  ALLOWED OPTIONAL  INTERACTIONS  ENUMERATED   !RE
                               THEIR EFFECTS DESCRIBED
                             v  !RE  ALL  DISABLED  OR  FORBIDDEN  INTERACTIONS  ENUMERATED
                               !RE THE REASONS CLARIFIED
                             v  $OES THE STAKEHOLDER AGREE WITH THE ENABLED AND DISABLED
                               INTERACTIONS  7HY NOT
                             v  !RE  ALL  THE  VISUAL  ITEMS  PROPOSED  FOR  THIS  SCREEN STEP
                               CONSISTENT  WITH  THE  USER S  NEEDS   7OULD  DIFFERENT
                               PRESENTATIONS BE USEFUL
                             v  !RE THERE VISUAL ITEMS THAT ARE MISSING  7HAT WOULD THE
                               STAKEHOLDER WANT TO SEE AND WHY
                             v  )S THERE PROPER EMPHASIS ON THE IMPORTANT DATA ASPECTS IN
                               A GIVEN STEP  7HAT IS THE IMPORTANT DATA AND WHY  4HIS
                               LEVEL OF DISCUSSION IS MOST LIKELY TO INVOLVE 5) DESIGNERS
                               BUT IT IS VERY IMPORTANT FOR THE DEVELOPERS TO STAY INVOLVED
                               IN ORDER TO PROVIDE INPUT ON WHAT SCREEN REPRESENTATION
                               TECHNOLOGY CAN OR CAN T DO

                      %XECUTABLE 0ROTOTYPES
                      #ERTAIN  ASPECTS  OF  APPLICATION  BEHAVIOR  CAN  BE  MODELED  USING  A
                      DESCRIPTIVE NOTATION  AND THEN ENACTED BY AN ENGINE THAT INTERPRETS
                      THE MODEL  4HIS TYPE OF PROTOTYPING IS SIMILAR TO USING   $ MODELING
                      SOFTWARE TO REPRESENT PHYSICAL MODELS  &OR EXAMPLE  THE PROTOTYPE
                      CAN GIVE AN OVERVIEW AND FLYTHROUGH CAPABILITY  AND EVEN PROVIDE
                      SOME ANALYSIS IF THE MODEL ALLOWS IT
                         &ULLY EXECUTABLE PROTOTYPES ARE THE MOST GENERIC ALTERNATIVE FOR
                      CREATING A REALISTIC AND UNAMBIGUOUS REPRESENTATION OF SOME ASPECT
                      OF  THE  APPLICATION   4HE  PRIMARY  BENEFIT  OF  DEVELOPING  EXECUTABLE
                      PROTOTYPES IS THAT THEY INCLUDE SOME ABILITY TO VERIFY THE SOLUTION  AS
                      WELL  AS  DIRECTLY  INTRODUCING  REALISTIC  ELEMENTS  INTO  THE  ANALYSIS  OF
   281   282   283   284   285   286   287   288   289   290   291