Chapter 4, Requirements Elicitation

1
Chapter 4, Requirements Elicitation
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
Defining the System Boundary What do you see?
5
System Identification

• Development of a system is not just done by
  taking a snapshot of a scene (domain)
• Definition of the system boundary
• What is inside, what is outside?
• How can we identify the purpose of a system?
• Requirements Process
• Requirements Elicitation Definition of the
  system in terms understood by the customer
• Analysis Technical specification of the system
  in terms understood by the developer.

6
Products of Requirements Process
7
System Specification vs Requirements Analysis
Model

• Both focus on the requirements from the users
  view of the system.
• System specification uses natural language
  (derived from problem statement)
• Requirements analysis model uses formal or
  semi-formal notation (e.g., UML)

8
Requirements Elicitation

• Challenging activity
• Requires collaboration of people with different
  backgrounds
• User with application domain knowledge
• Developer with implementation domain knowledge
• Bridging the gap between user and developer
• Scenarios Example of the use of the system in
  terms of a series of interactions with between
  the user and the system
• Use cases Abstraction that describes a class of
  scenarios

9
Types of Requirements

• Functional requirements Describe the
  interactions between the system and its
  environment independent from implementation
• The watch system must display the time based on
  its location
• Nonfunctional requirements User visible aspects
  of the system not directly related to functional
  behavior.
• The response time must be less than 1 second
• The accuracy must be within a second
• The watch must be available 24 hours a day except
  from 200am-201am and 300am-301am
• Constraints (Pseudo requirements) Imposed by
  the client or the environment in which the system
  will operate
• The implementation language must be COBOL.
• Must interface to the dispatcher system written
  in 1956.

10
Figure 4-2. A System is a collection of real
world Phenomena. A Model is a collection of
Concepts that represent the Systems Phenomena.
Many Models can represent different aspects of
the same System. An unambiguous Model corresponds
to only one System.

1
describes


11
What is usually not in the Requirements?

• System structure, implementation technology
• Development methodology
• Development environment
• Implementation language
• Reusability
• It is desirable that none of these above are
  constrained by the client. Fight for it!

12
Requirements Validation

• Critical step in the development process,
• Usually after requirements engineering or
  requirements analysis. Also at delivery
• Requirements validation criteria
• Correctness
• The requirements represent the clients view.
• Completeness
• All possible scenarios through the system are
  described, including exceptional behavior by the
  user or the system
• Consistency
• There are functional or nonfunctional
  requirements that contradict each other
• Clarity
• There are no ambiguities in the requirements.

13
Requirements Validation Criteria (continued)

• Realism
• Requirements can be implemented and delivered
• Traceability
• Each system function can be traced to a
  corresponding set of functional requirements

14
Requirements evolution

• Requirements change rapidly during requirements
  elicitation. Tool for managing requirements
• Requisite Pro from Rational
• Stores requirements in a repository
• Multi-user access
• Automatically creates a requirements document
  from the repository
• Provides traceability and change management
  throughout the project lifecycle
• http//www.rational.com/products/reqpro/

15
Types of Requirements Elicitation

• Greenfield Engineering
• Development starts from scratch, no prior system
  exists, the requirements are extracted from the
  end users and the client
• Triggered by user needs
• Re-engineering
• Re-design and/or re-implementation of an existing
  system using newer technology
• Triggered by technology enabler
• Interface Engineering
• Provide the services of an existing system in a
  new environment
• Triggered by technology enabler or new market
  needs

16
Figure 4-3. Actors for the SatWatch system.
WatchOwner moves the watch (possibly across time
zones) and consults it to know what time it is.
SatWatch interacts with GPS to compute its
position. WebifyWatch upgrades the data contained
in the watch to reflect changes in time policy
(e.g., changes in daylight savings time start and
end dates).
GPS
WatchOwner
WebifyWatch
17
Figure 4-4. Actors of the FRIEND system.
FieldOfficers not only have access to different
functionality, they use different computers to
access the system.
FieldOfficer
Dispatcher
18
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

19
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

20
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

21
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

22
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

23
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.

24
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.