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
Defining the System Boundary What do you see?
4
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?
• 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.

5
System and Object identification

• Two important problems during requirements
  engineering and requirements analysis
• Identification of objects
• Definition of the system purpose
• Depending on the purpose of the system,
  different objects might be found
• What object is inside, what object is outside?
• How can we identify the purpose of a system?
• Scenarios
• Use cases Abstractions of scenarios

6
Products of requirements elicitation and analysis
Contract with the user
(UML activity diagram)
7
Can you develop this?
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
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!

11
Functional requirements for SatWatch

• SatWatch is a wrist watch that displays the time
  based on its current location. SatWatch uses GPS
  satellites (Global Positioning System) to
  determine its location and intemal data
  stnictures to convert this location into a time
  zone. The information stored in the watch and its
  accuracy measuring time (one hundredth of second
  uncertainty over five years) is such that the
  watch owner never needs to reset the time.
  SatWatch adjusts the time and date displayed as
  the watch owner crosses time zones and political
  boundaries (e.g., standard time vs. daylight
  savings time). For this reason, SatWatch has no
  buttons or controls available to the user.
• SatWatch has a two-line display showing, on the
  top line, the time (hour, minute, second, time
  zone) and, on the bottom line, the date (day of
  the week, day, month, year). The display
  technology used is such that the watch owner can
  see the time and date even under poor light
  conditions.
• When a new country or state institutes different
  rules for daylight savings time, the watch owner
  may upgrade the software of the watch using the
  WebifyWatch seria1 device (provided when the
  watch is purchased) and a persona1 computer
  connected to the Intemet. SatWatch complies with
  the physical, electrical, and software interfaces
  defined by WebifyWatch API 2.0.

12
Nonfunctional requirements for SatWatch

• SatWatch determines its location using GPS
  satellites, and as such, suffers from the same
  limitations as al1 other GPS devices (e.g., 100
  feet accuracy, inability to determine location at
  certain times of the day in mountainous regions).
  During blackout penods, SatWatch assumes that it
  does not cross a time zone or a political
  boundary. SatWatch corrects its time zone as soon
  as a blackout period ends.
• The battery life of SatWatch is limited to 5
  years, which is the estimated life cycle of the
  housing of SatWatch. The SatWatch housing is not
  designed to be opened once manufactured,
  preventing battery replacement and repairs.
  Instead, SatWatch is priced such that the watch
  owner is expected to buy a new SatWatch to
  replace a defective or old SatWatch.

13
Pseudorequirement for SatWatch

• Al1 related software associated with SatWatch,
  including the onboard software, will be written
  using Java, to comply with current company policy.

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

To be continued
15
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

16
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

17
Requirements Elicitation Activities

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

18
Identifying actors

• Actors represent external entities that interact
  with the system
• An actor can be an human or an external system
• Actors in the SatWatch example
• Watch owner
• GPS satellites
• WebifyWatch serial device

19
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

20
Scenario Example Warehouse on Fire

• Bob, driving down main street in his patrol car
  notices smoke coming out of a warehouse. His
  partner, Alice, reports the emergency from her
  car.
• Alice enters the address of the building, a brief
  description of its location (i.e., north west
  corner), and an emergency level. In addition to a
  fire unit, she requests several paramedic units
  on the scene given that area appear to be
  relatively busy. She confirms her input and waits
  for an acknowledgment.
• 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 allocates a fire unit and two
  paramedic units to the Incident site and sends
  their estimated arrival time (ETA) to Alice.
• Alice received the acknowledgment and the ETA.

21
Documentation schema for the scenario

• Scenario name warehouse0nFire
• Participating actor instances
• bob, alice FieldOfficer
• 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 severa1 paramedic units
  on the scene, given that the area appears to be
  relatively busy. She confirms her input and waits
  for an acknowledgment.
• 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 allocates a
  fire unit and two paramedic units to the Incident
  site and sends their estimated arrival time (ETA)
  to Alice.
• Alice receives the acknowledgment and the ETA.

22
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

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

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