• Objective: This chunk aims at guiding the Requirements Engineer (RE) in discovering new goals  by reasoning on missing actions in a given scenario. This is based on rules that detect incompletnesses using a typology of actions. Goals express requirements expected to be satisfied by the system under construction.
  • Description :

    •  

    This chunk aims at refining a given requirement chunk <G, Sc> by suggesting new actions , that could be looked upon as goals refining G.
    It is described as plan guideline comprising three component guidelines. The Requirements Engineer (RE) shall first identify the candidate goals at lower level of abstraction than the goal G <(Scenario), Identify candidate goals>. For that, the RE shall first type the actions of the scenario <(Scenario), Type scenario actions> according to following classification:

    These classes of actions are coupled in three dependent action pairs : (service request, service provision), (information request, information provision) and (condition evaluation action, constrained flow of actions).   There exists a dependency among the two actions of a pair : any service request implies at least one service provision, an information request implies at least one information provision and a constrained flow of actions implies an action which evaluates the condition. Using these dependencies, pairs of classified actions are constructed <(Classified actions), Constructio a paire of actions (Ai, Aj)>. Every incomplete pair suggests a missing action <(Paire of actions (Ai, Aj)), Detect a missing action Am> which is inserted in the scenario <(Scenario, Missing action Am), Add missing action Am to the scenario>. Every new action is suggested as a candidate goal <(Missing action Am), Suggest a goel Gi according to Am>. Then the requirements engineer thas to validate each goal Gi of the set of candidate goals <(Goal Gi), Validate goal Gi>, and either to keep and name Gi <(Goal Gi), Name goal Gi> or discard it <(Goal Gi), Discard goal Gi>. The selected goals refine the initial goal G and are linked to G through refinement links <(Selected goals Gi), Link goals Gi to G with the refinement links>.

  • Example :  ATM case study

    •  

    Let us consider the requirement chunk RC1 in the ATM case study.

    Goal : Provide cash to our bank customer from ATM.
    Scenario:  1. The bank customer gets a card from the bank
                     2. Then, the bank customer withdraws cash from the ATM
                     3. The ATM reports cash transactions to the bank
    The Requirement Engineer (RE) uses the proposed classification in order to type Sc actions :
    ‘insert card’ service request
    ‘eject card’, ‘print receipt’, ‘deliver cash’ service provision
    ‘give prompt for code’, ‘display prompt for amount’ information request
    ‘input code’, ‘enter amount’ information provision
    ‘check if the card is valid’ condition evaluation action
    ‘if the card is valid’, ‘if the code is valid’, ‘if the amount is valid’, ‘if a receipt was asked by the user to the ATM’ constrained flow of actions.
    There exists a dependency among the two actions of a pair : any service request implies at least one service provision, an information request implies at least one information provision and a constrained flow of actions implies an action which evaluates the condition).

    Using these dependencies, pairs of actions are constructed. This leads in our example to the following pairs :

    (‘insert card’ ; ‘eject card’)
    (‘insert card’ ; ‘deliver cash’)
    ( ? ; ‘print receipt)
    (‘give prompt for code’; ‘input code’)
    (‘display prompt for amount’ ; ‘enter amount)
    (‘check if the card is valid ; ‘if the card is valid)
    ( ?  ; ‘if the code is valid)
    ( ? ; ‘if the amount is valid)
    ( ? ; ‘if a receipt was asked by the user to the ATM’)
    Every incomplete pair suggests a missing action which is inserted in the scenario.
    ____________________________________________________________________________________________________
    Initial state : The ATM is ready to serve. The user has a card.
    Flow of actions :
    1.  The user inserts the user’s card in the ATM.
    2.  The ATM checks if the card is valid.
    3.  If the card is valid
              4.  Then
              5.  A prompt for code is given by the ATM to the user.
              6.  The user inputs the code in the ATM.
              7.  The ATM checks if the code is valid.
              8.  If the code is valid
              9.  Then
                        10.  A prompt for amount is displayed by the ATM to the user.
                        11.  The users enters an amount in the ATM.
                   12.  The ATM checks if the amount is valid .
                        13.  If the amount is valid
                                    14.  Then
                                    15.  The ATM ejects the card to the user.
                               16.  The ATM asks the user if the user wants a receipt.
                                    17.  The user enters a choice in the ATM.
                                    18.  If a receipt was asked by the user to the ATM
                                    19.  Then
                                                20.  The ATM prints a receipt to the user.
                                                21.  The ATM delivers the cash to the user.
    Final state : The ATM is ready to serve. The user has cash. The user has the user’s card. The user has a receipt.
    ____________________________________________________________________________________________________________
    Every new action is suggested as a goal for the next step of refinement. The RE evaluates and names the selected goals. The RE proposes for the current example the two following goals :
     ‘Verify the code validity in a normal way’, and
     ‘Verify the amount validity in a normal way’.