Requirements Elicitation - PowerPoint

Document Sample
Requirements Elicitation - PowerPoint Powered By Docstoc
					                Requirements Elicitation
Ref: Bruegge & Dutoit. Requirements Elicitation, p. B-1 to B-21 in the course notes



specification of the system in a way that the client can understand

participants need to be able to communicate and understand each other

the earlier errors are detected the cheaper they are to correct
                Requirements Elicitation
The Nature of 'Requirements'

Functional requirements [section 4.3.1]

functions that the system has to deliver (you can specify a series of instructions to
do these things) e.g.

     allow a new customer to be registered

     ensure that a student cannot enrol twice

     produce a report showing all outstanding debts

     functional requirements state what is required, not how to do it
                 Requirements Elicitation
The Nature of 'Requirements'

Non-functional requirements [section 4.3.2]
things that are not related to functionality e.g.

          response time
          precision of numerical data
          user friendly-ness
          documentation requirements

Pseudo requirements [section 4.3.2]
implementation/SE process restrictions placed on the system by the client e.g.

          implementation language
          formal approach for safety critical software development
           Requirements Elicitation Activities

    Objective: to map a problem into a system specification represented as a set of
    actors, scenarios and use cases.

Requirements Elicitation activities include:
1   identify actors [section 4.4.1]
2   identify scenarios [4.4.2]
3   identify use cases [4.4.3]
4   identify relationships between use cases [4.4.5]
This will lead to the development of the UML Use Case diagram
    The development of a use case diagram is an analysis activity rather than a
    design activity.
           Requirements Elicitation Activities

    Identify the Actors
   An actor is an external entity that interacts with the system. Actors can be a person
    or an external system.
   Actors define classes of functionality.
   If an actor is a person, it is the role that he/she plays that is important, not their job
    title. The same role may be performed by many different people with different titles.
    For example in a particular bank branch, deposits and withdrawals may be processed
    by Fred (a customer service officer) and Jane (a manager). In this case the actor
    could be named teller (or customer service officer...).
Some questions for the identification of actors:
   which user groups are supported by the system to perform their work?
   which user groups execute the systems main functions?
   which user groups perform secondary functions, such as maintenance and
   will the system interact with any external hardware or software system?
                                   An example
    Example Actors (Figure 4-4, pB-11 Course Notes)


     FieldOfficier                                              Dispatcher

FRIEND (a distributed IS for accident management), two `roles' that directly interact
   with the system are:
   FieldOfficer
    The role is FieldOfficer (the instances of this role are people e.g. alice a police officer,
    peter a fire officer, wendy an ambulance officer etc)
   Dispatcher
    the role is the person(S) who dispatch resources to the scene of an accident
                                 An example
    Identify the Scenarios

    A scenario is: [Bruegge & Dutoit]

   "a narrative description of what people do and experience as they try to make use of
    computer systems and applications"
   "a concrete, focused, informal description of a single feature of a system from the
    standpoint of a single actor"
    Scenarios can be identified through interviews with clients. It is important that the
    scenario is understandable by all participants (users, client, analyst/software
    engineer etc). Scenarios form an important record of what the system needs to do
    (from the users perspective), which is useful in later stages of development,
    including testing of the system, which can be based on scenarios.
    A scenario describes one situation; multiple situations require different scenarios. For
    example a warehouse fire where people are inside would have a different scenario to
    a fire where no people are inside. No attempt is made to describe decisions in a
    scenario, two possible outcomes would need two different scenarios to describe them
                       An example

There is no standard way to layout a scenario. In this subject we will use
the format used in Bruegge & Dutoit, which consists of the following:

scenario name

participating actor instances

flow of events (with the events numbered)

See fig 4-5, p B-13 for a scenario (warehouseOnFire) which describes the
situation when a police officer (in a FieldOfficer role) reports a fire and
a Dispatcher initiates the incident response
                            An example
        Example Scenario 1: Warehouse on Fire

        In the example, bob and alice are instances of FieldOfficer,
        and john is an instance of Dispatcher.

Scenario name warehouseOnFire

Participating   bob, alice: FieldOfficer
actor instances john: Dispatcher
Flow of events           Bob, driving down main street in his patrol
                          car notices smoke coming out of a
                          warehouse. His partner, Alice activates the
                          "Report Emergency" function from her
                          FRIEND laptop.
                         Alice enters the address of the building, a
                          brief description of its location (i.e. northwest
                          corner), and an emergency level. In addition
                          to a fire unit, she requests several paramedic
                          units on the scene, given that the area appears
                          to be relatively busy. She confirms her input
                          and waits for an acknowledgement.
                         John, the Dispatcher, is alerted to the
                          emergency by a beep of his workstation. He
                          reviews the information submitted by Alice
                          and acknowledges the report. He creates an
                          Incident and allocates a fire unit and two
                          paramedic units to the incident site and sends
                          their estimated arrival time (ETA) to Alice.
                         Alice receives the acknowledgement and the
                                     An example
Example Scenario 2: Breaking and Entering

The following is an an example of some interviews that could be used to derive a
Date: 2-Aug, 9:30am - 10:30am
Interviewer: Cathy McDonald (CM) Software Engineer
Interviewee: Jane Ray (JR) Police Officer

CM: Hello Jane, in this interview I would like to discuss some typical incidents that occur during your work

JR: Ok. Yesterday I investigated a breaking and entering. Is this the type of thing that you are after?

CM: Yes, please describe what happened.

JR: I was patrolling Main St in the CBD, when at 23:14 I noticed that the door on the shop at 123 Main St
showed signs of being forced open. I input the details into my laptop.

CM: What program did you use? What data did you input?

JR: I ran the "report emergency" program on my laptop. I then input the address of the building, and the
emergency level of the incident (moderate), requested a backup (this is department policy) and pressed the
transmit button.

CM: What happened then?

JR: I received a response within about 30 seconds indicating that a patrol car would be arriving in about 2
minutes. I confirmed that I had received the message.

CM: Thanks Jane.
                                       An example

Following the interview with Jane, an interview was conducted with the dispatcher who
handled the incident.
Date: 3-Aug, 10:00am - 10:30am
Interviewer: Cathy McDonald (CM) Software Engineer
Interviewee: Donna Smith (DS) Dispacher
CM: Hello Donna, I would like to discuss your part in processing an incident that
occurred the other day
DS: Ok. What was it?
CM: At approximately 23:14 on August 1st, Police officer Jane Ray (#12345) reported
an incident (#999-4), a suspected breaking and entering.
DS: I'll just check that. I received the report at 23:14:47, it was allocated an incident
number (#999-4), I reviewed the information and determined whether any patrol cars
were available in the area. As there was, I contacted them and sent an ETA to the
officer at the scene.
                            An example
 From the interviews the following scenario was created:
 In the example, jane is an instance of PoliceOfficer, and donna is
 an instance of Dispatcher.

Scenario name breakingAndEntering
Participating   jane: PoliceOfficer
actor instances donna: Dispatcher
Flow of events     1. Jane, while patrolling the CBD notices signs
                      of a forced entry into a shop. Jane activates
                      the "Report Emergency" function from her
                      FRIEND laptop.
                   2. Jane enters the address of the building, and
                      an emergency level. She requests a backup
                      unit. She confirms her input and waits for an
                   3. Donna, the Dispatcher, is alerted to the
                      emergency by a beep of her workstation. She
                      reviews the information submitted by Jane
                      and acknowledges the report. She creates an
                      Incident and allocates a police patrol car to
                      the incident site and sends their estimated
                      arrival time (ETA) to Jane.
                   4. Jane receives the acknowledgement and the

Questions for identifying scenarios:
   what are the tasks that the actor wants the system to perform?
   what information does the actor access? Who creates that data? Can it be modified or
    removed? By whom?
   which external changes does the actor need to inform the system about? How often?
   which events does the actor need to be informed by the system about?

Example Scenario Outlines
For example there may be four scenarios that cover a range of tasks that we want the
    accident management system (FRIEND) to support [see p B-14].
   A fire is detected in a warehouse; two field officers arrive at the scene and request
    resources. (Figure 4-5, pB-13)
   A car accident without casualties occurs on the highway. Police offers document the
    incident and manage traffic flow while the damaged vehicles are towed away
   A cat stuck in a tree. A fire truck is called to retrieve the cat
   An unprecedented earthquake seriously damages buildings and roads, spanning
    multiple incidents and triggering activation of a state wide emergency operations
                                   Use Cases

Identifying Use Cases
A use case is a general description of a scenario, or a scenario is an instance of a use
The use case is abstracted from scenarios. This is going from the specific (one or more
   scenarios e.g. warehouseOnFire, breakingAndEntering) that mention particular
   people (e.g. alice, bob) to a general case that describes the situation (the use case,
   e.g. ReportEmergency; and the roles e.g. FieldOfficer). Use cases can be used for
   existing or new systems.
A use case is initiated by an actor (i.e. a role), not an instance of an actor
                                    Use Cases

Again there is no strict standard way to layout a use case. In this subject we will use the
   format used in Bruegge & Dutoit, which has the following:
   use case name
   participating actors
   entry conditions
   flow of events (with the events numbered)
   exit conditions (if any)
   special requirements (if any)
                             Use Cases

Example Use Case -              Use case
                                              Report Emergency
   ReportEmergency (Bruegge &   name
                                Participating Initiated by FieldOfficer
   Dutoit, Figure 4-6 pB-15)    actors        Communicates with Dispatcher
                                Entry            1. The FieldOfficer activates the "Report
                                condition            Emergency" function of her terminal

The scenarios,                  Flow of          2. FRIEND responds by presenting a form to the
                                events              officer
warehouseOnFire and                              3. The FieldOfficer fills the form, by selecting
                                                    the emergency level, type, location, and brief
   breakingAndEntering are                          description of the situation. The FieldOfficer
   instances of the use                             also describes possible responses to the
                                                    emergency situation. Once the form is
   case, ReportEmergency.                           completed, the FieldOfficer submits the form,
                                                    at which point the Dispatcher is notified.
                                                 4. The Dispatcher reviews the submitted
                                                    information and creates an Incident in the
                                                    database by invoking the OpenIncident use
                                                    case. The Dispatcher selects a response and
                                                    acknowledges the emergency report.

                                Exit condition   5. The FieldOfficer receives the
                                                    acknowledgement and the selected response

                                Special             The FieldOfficer's report is acknowledged
                                requirements         within 30 seconds
                                                    The selected response arrives no later than 30
                                                     seconds after it is sent by the Dispatcher.
                               Use Case Diagrams

   to visualise each use case in the context of other use cases
   to show relationships between use cases and the actors
   see course notes [particularly pB-36-B-37]
   Use case diagram for ReportEmergency --- see fig 4-8, pB-18

                                                                   Open Incident

      FieldOfficer                           Dispatcher

                                                                   Allocate Resources
                          Report Emergency
                          Use Case Diagrams

Comments on notation

   actors are usually
    shown as stick figures
    of people, with the          «actor»
    name below                   Credit Card
if the actor does not            System
     represent a person
     (e.g. an external entity
                                                 Credit Card
     such as a Web Server)                       Authorization
     it can still be shown in                    System
     the same way or in a
     rectangle, with the
     stereotype «actor» and
     the name of the actor
                        Use Case Diagrams

Comments on notation
Use Cases
   Use cases are shown as         Report
    ellipses, with the use         Emergency
    case name usually
    inside the ellipse
   Alternatively the name
    may be placed below
    the ellipse - be
    consistent in the
    approach you use
                                   Report Emergency
                         Use Case Diagrams

Comments on notation
   Relationships are
    shown as a line
    between actors and use
    cases or use-cases and    FieldOfficer               Dispatcher
   The solid lines show                     Report
    communications                           Emergency
    (information flow)
    between the actors and
    use cases
   The lines are NOT
    directional data flows.
    It is NOT a data flow
                         Use Case Diagrams
Comments on notation
   Stereotypes is a label used
    to clarify a relationship
   UML has a number of           FieldOfficer                      Dispatcher
    predefined stereotypes. It
    is legal to create your own
    stereotypes, but these                              Report
    should be used rarely and                           Emergency
    only when warranted
   The « and » are called
    guillemets (and are
    preferred to << and >>)
   In the above diagram the
    stereotype «initiate» is
    used to show the actor that
    initiated the use case
      Next time ….
Use Case Diagrams (cont'd)