Apology Bounced Check to the Bank - DOC

Document Sample
Apology Bounced Check to the Bank - DOC Powered By Docstoc

Design of User Interfaces (Misbah Islam)

Representing Requirements
Scenarios and Use Cases

Introduction to Scenarios and Use Cases:

In order to elicit requirements we have to acquire knowledge about the domain
and the activities that are usually performed in the system. Each activity is
associated with a given goal and can be performed by a set of actors or actor

The description of a specific goal-related activity (for given actor instance or data
conditions) may be called a Scenario.

A use case also is also meant to achieve the same purpose but is more general as
it is meant to cover all possible actor instances and data conditions. Use cases
are important because the set of all use case descriptions specifies the complete
functionality of the system.

Car Fender Bender (accident) Claim

Example: Scenario

System under discussion:         Federal Union Insurance Company
Primary Actor:                   John Smith, the claimant
Goal:                            John Smith gets paid for his car accident
Conditions:                      Everything is in order

Outcome:                         Insurance company pays claim

   1. John Smith submits claim with substantiating data to the local office

   2. Insurance company verifies claimant owns a valid policy (failure here
      probably means goal failure)

   3. Insurance company assigns agent (Mr. Jack Strong) to examine case

   4. Agent verifies all details are within policy guidelines. (an interaction
      between the agent and secondary actors)

   5. Insurance company pays claimant (implies all preceding goals managed to

Example Use Case:

System under discussion:         Federal Union Insurance Company
Primary Actor:                   The claimant
Goals:                           Get paid for car accident

Outcome of use case: (success path)

   1.   Claimant submits claim with substantiating data.
   2.   Insurance company verifies claimant owns a valid policy
   3.   Insurance company assigns agent to examine case
   4.   Agent verifies all details are within policy guidelines
   5.   Insurance company pays claimant

Extensions of use case: (exceptions / error paths)

   -    1a. Submitted data is incomplete:
   -    1a1. Insurance company requests missing information
   -    1a2. Claimant supplies missing information
   -    2a. Claimant does not own a valid policy
   -    2a1. Insurance company declines claim, notifies claimant, records all this,
             and terminates proceedings.
   -    3a. No agents are available at this time
   -    3a1. (What does the insurance company do here?)
   -    4a. Accident violates basic policy guidelines:
   -    4a1. Insurance company declines claim, notifies claimant, records all this,
             and terminates proceedings.
   -    4b. Accident violates some minor policy guidelines:
   -    4b1. Insurance company begins negotiation with claimant as to degree of
             payment to be made.

Variations on use case:

   -    1. Claimant is
             i. a person
            ii. another insurance company
           iii. the government
   -    5. Payment is by
             i. check
            ii. interbank transfer
           iii. automatic prepayment of next instalment
           iv. creation and payment of another policy

Definitions of Scenarios and Use Cases:

Scenario is used as an example to illustrate common cases and the flow of events
and the involved actors. The focus is on understandability. It is described from the
perspective of one or more actors or situations.

          -   Is an instance of a use case describing a concrete set of actions.
          -   A sequence of interactions between the actor/s and the system
              occurring under certain (system) conditions, to achieve the primary
              actor's goal.

Desirable Properties of Scenarios:

Scenario representation should conform to these properties:

      No Domain knowledge in the representation
      Understandable to people with different backgrounds
      Support for both diagram representation and description
      Data structure independence
      If domain knowledge is added these can be adapted as building blocks for
       requirements specification
      Provide insight into temporal and causal behaviour

The task of a developer is to analyze existing scenarios and to come up with new,
better and efficient scenarios. The developer should not try to implement the old
and inefficient modes of operation.

Representing Scenarios:

      Through scenario template
      Using sequence diagrams
      State charts

Uses of Scenarios:

In addition to be used as a source for developing use cases, scenarios can be
used to form customized Scripts and Storyboards describing how the system may
be put to use by various actors in different circumstances.

For example, a tourist may use a fixed set of ordered scenarios (in the form of a
script) to negotiate and purchase holiday tickets. He may also set up a
„storyboard‟ of his entire program describing what he did or will do while on

Triggering of Scenarios:

Can be an event or state which initiates the start of actor-system interactions
which continue until the goal is delivered or abandoned. The system is supposed
to complete whatever responsibilities it has with respect to the interaction.


Actors are basically users of the system. Actors are external entities (people or
other systems) who interact with the system to achieve a desired goal.

Use Case:

Use Cases are what happens when actors interact with the system. An actor uses
the system to achieve a desired goal. By recording all the ways our system is used
("cases of use" or Use Cases) we can find out the requirements of our system.

A use case can be defined as

      The specification of a sequence of actions, including variants, that a system
       (or other entity) can perform, interacting with actors of the system

      A sequence of transactions in a system whose task is to yield value to an
       individual actor of the system

      A collection of possible scenarios concerning the system and the actor.

      A use case is specified from the perspective of the primary actor‟s goal. It is
       system‟s responsibility to help achieve that goal. The use case must show
       how the primary actor's goal might be delivered or might fail.

For use cases to be included in formal requirements they should be sufficient
detail to allow their transformation into design requirements, high level design and
test specifications.

Use case and OO Design:

Unlike OO design where the emphasis is on objects, the constraints on their use
and their behaviour, the use cases emphasize ordering, e.g.

“When a customer places and order, the order and credit limit are validated, the
database is updated if these are OK and confirmation number is issued”.

OO designers need to transform use case descriptions into objects and behaviour.
The sequentiality can be built-in using constraints and state machines.

Change cases:

 Are specialized use cases intended to capture anticipated future changes to a
design. Change cases have links to affected use cases. Change cases cater to the
following situations: It is a good idea to write change cases where ever possible.

      Functionality changes
      Market and business requirement changes
      Operational changes such as new policies or operational processes
      Technology related changes

Representing Use cases:

      Structured English (Template) description of

          -   Main
          -   Alternative
          -   Exceptional behaviours

      Interaction Diagram showing different paths of actor interactions

          -   iteration
          -   repetition
          -   branching, and
          -   parallelism

       Pre-and post conditions may also be specified.

      Interface Specifications for each actor. The interface is a contract that the
       actor must provide to other actors.

       A contract may involve execution of multiple use cases. Internally use
       cases may also provide contracts shared by multiple actors.

      State-transition diagram in which a stimulus from an actor will cause the
       use case to leave its current state and perform a transaction. Each
       transaction is associated with pre- and post-conditions.

How to create Use Cases:

Use case can be created using the following methodologies:

      Structured Analysis Structured Design (SASD) or top down
       hierarchical design.
      Unstructured aggregation - Collect and classification of all the “shall”
       statements of the form

       “When the free memory goes below 32 K, the operating system shall
       do garbage collection and free block aggregation”.

       “When the credit balance is less than $100 the system shall post a
       warning note and shall not credit any interest on the account”.

      Scenario story-driven discovery - use cases are discovered by
       analyzing written descriptions of day-to-day activity or desired
      Actor or responsibility discovery - first define the actors and roles,
       then define their collaborations and responsibilities

Relationship between Scenarios and Use Cases:

The relationship between a use case and a scenario can be described as

      Specialization of a use case
      An instance of a use case and
      As a component of a use case
      A possible (data or condition dependent) path in the use case

           Collection of                    Collection of
            Use Cases                        Scenarios

                                             A Specific
             A Specific
             Use Case

Validation and review of Use cases:

Once use cases are designed these need to be validated and reviewed. The
following questions need to be answered:

      Is the Use Case complete? Are there any details that need to be added?
      Is the actor's goal going to be properly met?
      Are there any procedural or requirement changes that can be proposed to
       simplify the process?
      Are there any additional Goals of the Actors that are not addressed?
      Any other Actors that should have been considered?

Use case refinement and relationships:

In addition to validation there is also a need to discover commonalities or
redundancies between use cases and to promote re-usability (good SE practice).

The following operations can be done to achieve this:

Extend relationship: Use case A extends use case B, if B includes the behaviour of
A under certain conditions.

Example: Fire reporting system:

There are two actors Field Officer and a Dispatcher. The Field Officer employs a
use case called ‘Report Fire’ and then communicates with the Dispatcher to
allocate resources.

If somehow the Field Officer is unable to get through via normal means, he then
invokes another Use case called ‘Report Fire under Emergency’ which is an
extension of the first, since it uses other channels to get through.

Include relationship: If use case A functionality is common to the operations of B
and C then both B and C can include use case A.

Example: Both the Field Officer and the Dispatcher to invoke a common use case
called ‘View City Map’. We need to write ‘View City Map’ only once and it can be
included in the use cases wherever it is needed.

Specialization relationship: If use case A and B want to customize use case C for
their purposes then they can specialize C as C(A) and C(B) and then include.

Example: The Field Officer and the Dispatcher need to see the city map at different
levels of detail, then they can specialize ‘View City Map’ according to their

Use case Template:

The following are the typical fields in a Use case template:

         Name: the name of the use case
         Goal: the goal of the use case
         Primary actor: The actor using the system to achieve the goal
         Secondary actors: Needed to achieve Primary actor‟s goal
         Scope: the scope that the use case is covering (System, Sub-function)
         Level: system, user, summary (collection of user level, e.g. Config DB)
         Preconditions: any prerequisites before the use case can be started
         Success Condition: what is considered a successful end to the use case
         Failure Condition: what is considered a failed end to the use case
         Trigger: what external event happens that triggers its start
         Notes: Performance issues, frequency of use and other issues.
         Scenario Descriptions: These can be of the types

          -   Main (success) path
          -   Extension: Failure path, Recovery path

An Example Use Case Template:

   Use Case               Sell Parts to Customer
   Goal                   Customer issues request directly to Our company,
                          expects Parts to be shipped and to be invoiced
   Priority               Very High
   Performance            1. Order Acceptance Turn Around Time: 8 hours
                          2. Shipping Time:Min: 5 working days. 1 day additional per
                             1000 Items, if Items > 5000
                          3. Bill reception: 21 Working days
   Frequency              10 Orders per day
   Scope                  Company, Subcontractor/s. Customer Base
   Preconditions          Customer Credit Rating >= A
   End Conditions:        1. Customer receives the Parts.
   Success                2. My company receives amount.
                          3. Customer Credit Rating  A++ if $ > 10K
   End Conditions:        1. My company cannot ship on time, full quantity or with
   Failure                   acceptable quality. Company reputation  A--
                          2. Customer cannot pay. Credit rating  A--
   Actors: Primary        Customer’s agent or computer
   Actors: Secondary      Bank, Shipping Agent, Subcontractor
   Trigger                Receipt of Purchase Order via email or Web
   Subordinate            1. Purchase Order Acceptance
   Use cases

                        2. Manufacturing Order (Internal)
                        3. Subcontractor Order/Billing/Invoicing
                        4. Bill reception
                        5. Credit Rating Adjustment
                        6. Returned Parts Handling
Super ordinate          Manage Customer Relationship
Use cases
Scenario Descriptions   Steps
Main Course
                          1     Customer RFQ received
                          2     Response sent (price list, delivery date etc)
                          3     Customer Order received
                          4     Customer Credit Rating and Limit evaluated
                          5     Inventory is checked and shipping note issues
                          6     Parts collected.
                                Pre-shipping verification: Quality and Quantity
                        7       Parts Shipped. Invoice prepared and shipped
                        8       Customer Acceptance Test successful
                        9       Invoice is paid by the customer
Scenario Descriptions Steps
                         4e     Customer Credit Rating and Limit is NOK
                                4.e.1: Email Customer Order that may not be (fully)

                         5e     Inventory is not sufficient
                                5e.1: Internal/subcontract order to re-supply issued.

                         6e     Pre-shipment verification (Quality, Quantity) NOK
                                6e.1: Re-supply order issued
                                6e.2: Failed products sent back for corrective action

                         7e     Shipping delay
                                7e.1: Customer notified

                         8e     Customer acceptance test NOK
                                8e.1: Tests reproduced
                                8e.1e: Error is confirmed
                                8e.1e.1: Apology issued
                                8e.1e.2: Root Cause Analysis (RCA) done
                                8e.1e.3: Shipment recalled
                                8e.1e.4: New shipment prepared
                                (after new verification tests)

                                 8e.1.1: Error is not confirmed
                                 8e.1.2: Customer requested to redo/recalibrate

                          9e.1   Customer payment not received before due date
                          9e.2   Customer check bounced
                                 9e.1.1: Reminder(s) sent
                                 9e.2.1: Reminder sent
                          9e.3   Payment not received.
                                 9e.3.1: Credit rating adjusted.
                                 9e.3.2: Legal proceeding initiated

Exercise: Rewrite the following Use case in the form of a template

Restaurant use case:

   a. The actor Guest enters the restaurant
   b. The actor Guest has the possibility of leaving his/her coat in the cloakroom,
      after which he/she is shown to a table and given a menu.
   c. When the actor Guest has had sufficient time to make up his/her mind,
      he/she is asked to state his/her order. Alternatively, Guest can attract the
      waiter's attention so that the order can be placed.
   d. When the Guest has ordered, the kitchen is informed what food and
      beverages the order contains.
   e. In the kitchen, certain basic ingredients, such as sauces, rice, and potatoes,
      have already been prepared. Cooking therefore involves collecting together
      these basic ingredients, adding spices and so on and sorting out what
      needs to be done just before the dish is served. Also, the required
      beverages are fetched from the refrigerator.
   f. When the dish is ready, it is served to the actor Guest. When it has been
      eaten, the actor is expected to attract the waiter's attention in order to pay.
   g. Once payment has been made, Guest can fetch his/her coat from the
      cloakroom and leave the restaurant. The use case is then complete."

Shared By:
Description: Apology Bounced Check to the Bank document sample