Chapter 4, Requirements Elicitation Continued

1
Chapter 4, Requirements Elicitation - Continued
2
Software Lifecycle Activities
System Design
Object Design
Implemen- tation
Testing
Requirements Elicitation
Requirements Analysis
Implemented By
Expressed in Terms Of
Structured By
Realized By
Verified By
?
?
Application Domain Objects
Implementation Domain Objects
Use Case Model
Source Code
SubSystems
Test Cases
3
Requirements Elicitation Activities

• Identify actors
• Identify scenarios
• Identify use cases
• Identify relationships among use cases
• Refine use cases
• Identify nonfunctional requirements
• Identify participating objects

4
Scenarios

• A narrative description of what people do and
  experience as they try to make use of computer
  systems and applications M. Carrol,
  Scenario-based Design, Wiley, 1995
• A concrete, focused, informal description of a
  single feature of the system used by a single
  actor.
• Scenarios can have many different uses during the
  software lifecycle

5
A Good Scenario?

• Example 1. The guest makes a reservation with
  the hotel. The hotel will take as many
  reservations as it has rooms available. When a
  guest arrives, he or she is processed by the
  registration clerk. The clerk will check the
  details provided by the guest with those that are
  already recorded. Sometimes guests do not make a
  reservation before they arrive. Some guests want
  to stay in non-smoking rooms. Roberts et al.,
  1998 68

6
Types of Scenarios

• As-is scenario
• Used in describing a current situation. Usually
  used during re-engineering. The user describes
  the system.
• Visionary scenario
• Used to describe a future system. Usually
  described in greenfield engineering or
  reengineering.
• Can often not be done by the user or developer
  alone
• Evaluation scenario
• User tasks against which the system is to be
  evaluated
• Training scenario
• Step by step instructions designed to guide a
  novice user through a system

7
How do we find scenarios?

• Dont expect the client to be verbal if the
  system does not exist (greenfield engineering)
• Dont wait for information even if the system
  exists
• Engage in a dialectic approach (evolutionary,
  incremental)
• You help the client to formulate the requirements
• The client helps you to understand the
  requirements
• The requirements evolve while the scenarios are
  being developed

8
Heuristics for finding Scenarios

• Ask yourself or the client the following
  questions
• What are the primary tasks that the system needs
  to perform?
• What data will the actor create, store, change,
  remove or add in the system?
• What external changes does the system need to
  know about?
• What changes or events will the actor of the
  system need to be informed about?
• Insist on task observation if the system already
  exists (interface engineering or reengineering)
• Ask to speak to the end user, not just to the
  software contractor
• Expect resistance and try to overcome it

9
Example Scenario

• It is 2 o'clock in the morning, and Ian cannot
  get his new HyperCam software to install
  properly. He points his browser to
  www.camerahype.com, gets the splash page, and
  waits for the corporate home page to appear. He
  scrolls down the page and clicks on the tech
  support link. On the provided form, he types his
  name, then gets his customer ID off the packing
  slip for the HyperCam and types it in. He clicks
  the Submit button. He scans the Tech Support home
  page and finally clicks on the GIF showing a
  befuddled user with a packing crate. This takes
  him to the Installation Help page, where he
  begins filling out the Incident Report form.
  Dissatisfied with the suggestion supplied by the
  system after the form is submitted, he goes to
  the Contact Us page and sends an email message.

10
Example Use Case

• The use case begins when the customer goes to the
  Customer Log-On page. There, the customer types
  in his/her name and customer ID on the form and
  submits it. The system then displays the Tech
  Support home page with a list of Problem
  Categories. The customer clicks on Installation
  Help within the list, and the system supplies the
  Incident Report Form. The customer completes and
  submits the form, and the system presents a
  suggested resolution.

11
Detailed Narrative Use Case
A cash withdrawal transaction is started from
within a session when the customer chooses cash
withdrawal from the menu of possible transaction
types. The customer chooses a type of account to
withdraw from (e.g., checking) from a menu of
possible accounts, and then chooses a dollar
amount from a menu of possible amounts. The
system verifies that it has sufficient money on
hand to satisfy the request. If not, it reports a
failure to the session, which initiates the
Failed Transaction Extension to report the
problem. if there is sufficient cash it sends the
customer's card number, PIN, chosen account and
amount to the bank, which either approves or
disapproves the transaction. If the transaction
is approved, the machine dispenses the correct
amount of cash and issues a receipt. If the
transaction is disapproved due to an incorrect
PIN, the Incorrect PIN extension is executed. All
other disapprovals are reported to the session,
which initiates the Failed Transaction Extension.
The bank is notified whether or not an approved
transaction was completed in its entirety by the
machine if it is completed then the bank
completes debiting the customer's account for the
amount. Bjork, 1998 used with permission
12
Figure 4-8. Example of communication
relationships among actors and use cases in
FRIEND (UML use case diagram). The FieldOfficer
initiates the ReportEmergency use case and the
Dispatcher initiates the OpenIncident and
AllocateResources use cases. FieldOfficers cannot
directly open an incident or allocate resources
on their own.
13
Figure 4-9. Example of use of extend relationship
(UML use case diagram). ConnectionDown extends
the ReportEmergency use case. The ReportEmergency
use case becomes shorter and solely focused on
emergency reporting.
14
Figure 4-10. Example of include relationships
among use cases. ViewMap describes the flow of
events for viewing a city map (e.g., scrolling,
zooming, query by street name) and is used by
both OpenIncident and AllocateResources use
cases.
15
Figure 4-12. Activities of JAD (UML activity
diagram). The heart of JAD is the Session
activity during which all stakeholders design and
agree to a system specification. The activities
prior to the Session maximizes its efficiency.
The production of the Final document ensures that
the decisions made during the Session are
captured.
Project definition
Management definition guide
Research
Session agenda
Preliminary specification
Preparation
Session script
Session
Working document
Scribe forms
Final document preparation
Final document
16
Summary

• Requirements Elicitation
• Greenfield Engineering, Reengineering, Interface
  Engineering
• Scenarios
• Great way to establish communication with client
• As-Is Scenarios, Visionary scenarios, Evaluation
  scenarios Training scenarios
• Use cases Abstraction of scenarios
• Pure functional decomposition is bad
• Leads to unmaintainable code
• Pure object identification is bad
• May lead to wrong objects, wrong attributes,
  wrong methods
• The key to successful analysis
• Start with use cases and then find the
  participating objects
• If somebody asks What is this?, do not answer
  right away. Return the question or observe What
  is it used for?