Requirements Elicitation

1
Requirements Elicitation

• CS 4320
• Fall, 2001

2
What are requirements?

• Properties of a planned system or product that
  are desired by its customer
• What kinds of properties?
• Functional / non-functional requirements
• What is the scope of the system?
• System / environment software / process
• Are requirements absolute? What if they conflict?
• Requirements / preferences
• Who are the customers? What if they disagree?
• Stakeholders / viewpoints. Trade-offs /
  negotiation

3
Cost of Delay in Fixing Requirements Errors
Data Boehm Papaccio (1988) IEEE Trans.
Software Eng.
200-fold increase after delivery
Nominal unit cost
20-fold increase during devt.
4
Figure 4-1. Products of requirements elicitation
and analysis (UML activity diagram).
5
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


6
Key conceptsis vs. ought
Now
Future
Development delivery
Domain
Envt.
Sys.
The way things are now
What well make the system do
The way were assuming things will be
7
Case ExampleScheduling and Scheduler
Now
Future
Development delivery
Domain
Envt.
Sys.
How people schedule What meetings are
Spec. of scheduler software
How people will schedule What meetings will now be
8
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
9
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
10
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
11
Figure 4-5. warehouseOnFire scenario for the
ReportEmergency use case.
12
Figure 4-6. An example of use case
ReportEmergency.
13
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.
14
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.
15
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.
16
Requirements faults(What were trying to avoid)

• Vagueness
• Incompleteness
• Gold-plating
• Inconsistency
• Unfeasibility
• Poor writing

17
Key conceptRequirements refinement

• What kinds of refinement are there?
• Making a vague statement more precise
• Saying what the system should do vs. its users
• Dealing with not-yet considered situations

18
Case ExampleRefining a fuzzy requirement
The system shall improve the responsiveness to
customer complaints
The system shall improve the responsiveness to
customer complaints . When the customer-service
clerk enters the customer code, the system shall
recommend the next customer-service action
19
Testable performance requirements

• Objectives to accelerate process or minimize
  delay
• Specify in terms of average duration or wait time
• but convenience (the real objective) often
  depends on eradicating excessive wait times
• Or by specifying ceiling on duration or wait time
• but often not technically feasible to guarantee
• So usually by putting ceiling on 95/99 cases
• Absolute deadlines are functional reqts.
• Hard real-time reqts. are substitutes for a
  response being required before an envt. event

20
Testable usability requirements

• Convenience / usability / familiarity /
  friendliness objectives
• Specification of expected user performance
• Ability to do a task without help within X
  minutes of using system for 1st time
• Average performance time for error-free task

21
Case example Testable quality requirements

• Performance
• If there are feasible meeting times, the system
  should in 95 cases schedule a meeting within 5
  seconds of meeting constraints having been
  entered
• Usability
• A person should be able to fill in the scheduling
  constraints for an N-person meeting in fewer than
  5N keystrokes/mouse-clicks

22
Objectives requirements

• Systems exist to meet goals or objectives
• Goals are not final requirements
• may be ambiguous and inconsistent
• not absolute (some take priority)
• idealized rather than implementable
• not allocated to product
• Goals are not business processes
• processes are implementations of goals

23
Pre-requirements traceability

• Pre-reqts. traceability shows where reqt. traces
  fromthus, objectives are rationale for
  reqts.