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 and Specification
Activities

• Identify, describe actors
• Identify, describe scenarios
• Identify, describe use cases
• functional, non-functional requirements
• Identify relationships among use cases
• Validate, refine use cases

4
Requirements Elicitation, Specification, and
Analysis

• Requirements Elicitation and Specification
  Definition of the system in terms understood by
  the customer
• Determine and capture the purpose of a system
• Definition of the system boundary (scope)
• What is inside, what is outside?
• Specification of the systems capabilities
• functional and non-functional
• may be captured in a variety of notations or
  approaches
• e.g., semi-formal use cases, formal Z, VDM,
  Statechart specifications
• Analysis Technical specification of the system
  in terms understood by the developer.

5
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

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

7
Requirements Validation and Quality Attributes

• Validation - critical step in the development
  process
• Question Are we building the right product?
• Some Requirements Quality 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.

8
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
• Refer to the IEEE recommended practice for
  software requirements specifications for
  additional quality criteria
• IEEE Std 830-1998 , 20 Oct. 1998

9
Types of Requirements Elicitation

• Greenfield Engineering
• Development starts from scratch, no prior system
  exists, the requirements are extracted from the
  end users, the client, applicable standards
• 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

10
Example of steps in formulating a use case

• 1. name the use case
• Use case name ReportEmergency
• should be a concise, verb phrase
• 2. find the actors
• Generalize the concrete names (Bob) to
  participating actors (Field officer)
• Participating Actors
• Field Officer (Bob and Alice in the Scenario)
• Dispatcher (John in the Scenario)
• 3. concentrate on the flow of events
• Use natural language
• Be specific, unambiguous, clear, correct, concise
  

11
Example of steps in formulating a use case

• Formulate the Flow of Events (preliminary
  version)
• The FieldOfficer activates the Report Emergency
  function on her terminal. FRIEND responds by
  presenting a form to the officer.
• The FieldOfficer fills the form, by selecting the
  emergency level, type, location, and brief
  description of the situation. The FieldOfficer
  also describes possible responses to the
  emergency situation. Once the form is completed,
  the FieldOfficer submits the form. The Dispatcher
  is notified.
• 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.
• The FieldOfficer receives the acknowledgment and
  the selected response.

12
Example of steps in formulating a use case

• Write down the exceptions
• The FieldOfficer is notified immediately if the
  connection between her terminal and the central
  is lost.
• These are captured as alternate flows in the use
  case
• Identify and write down any special requirements
• The FieldOfficers report is acknowledged within
  30 seconds

13
How to Specify a Use Case (Summary)

• Name of Use Case
• Actors
• Description of actors involved in use case
• Entry condition
• Use a syntactic phrase such as This use case
  starts when
• Normal Flow of Events
• natural language
• Exit condition
• Star with This use cases terminates when
• Alternate Flow of Events (Exceptions)
• Describe what happens if things go wrong
• Special Requirements
• List nonfunctional requirements and constraints

14
Use Case Model for Incident Management - UML
Dispatcher
FieldOf
f
icer
OpenIncident
ReportEmergency
AllocateResources
15
Use Case Associations

• Use case association relationship between use
  cases
• Important types
• Extends
• Include
• Generalization

16
ltltIncludegtgt Reuse of Existing Functionality

• Problem
• There are already existing functions. How can we
  reuse them?
• Solution
• The include association from a use case A to a
  use case B indicates that an instance of the use
  case A performs all the behavior described in the
  use case B (A delegates to B)
• Example
• The use case ViewMap describes behavior that
  can be used by the use case OpenIncident
  (ViewMap is factored out)
• Note The base case cannot exist alone. It is
  always called with the supplier use case

ltltincludegtgt
OpenIncident
ViewMap
Base Use Case
ltltincludegtgt
Supplier Use Case
AllocateResources
17
ltExtendgtgt Association for Use Cases

• Problem
• The functionality in the original problem
  statement needs to be extended to describe
  optional functionality.
• Solution
• An extend association from a use case A to a use
  case B indicates that use case B is an extension
  of use case A.
• Example
• The use case ReportEmergency is complete by
  itself , but can be extended by the use case
  Help for a specific scenario in which the user
  requires help
• i.e., Help is a capability that is not
  currently offered in the system
• Note In an extend assocation, the base use case
  can be executed without the use case extension

Help
ltltextendgtgt
FieldOfficer
ReportEmergency
18
Generalization association in use cases

• Problem
• You have generalization relationships among use
  cases and want to model this
• Solution
• The child use cases inherit the behavior and
  meaning of the parent use case and add or
  override some behavior.
• Example
• Consider the use case ValidateUser, responsible
  for verifying the identity of the user. The
  customer might require two realizations
  CheckPassword and CheckFingerprint

CheckPassword
Parent Case
Child Use Case
ValidateUser
CheckFingerprint
19
How do I find use cases?

• Find out what the user needs to do
• Task observation
• Questionnaires
• Interviews
• Describe scenarios
• Use mock-ups as visual support, story-boards
• Generalize the scenarios into use cases