Download - Reqts Elicitation
-
8/3/2019 Reqts Elicitation
1/54
Requirements Elicitation
CS 6300
Fall, 2000
-
8/3/2019 Reqts Elicitation
2/54
Requirements (1)
_ What are requirements and why arethey important?
_ Problem frames
_ Requirements elicitation
_ Strategies
System & actor identification
Use case & scenario analysis
_ Requirements refinement and validation
-
8/3/2019 Reqts Elicitation
3/54
What are requirements?
Properties of a planned system or productthat 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
-
8/3/2019 Reqts Elicitation
4/54
Engineering and human-
oriented approaches_ Requirements occur at boundary between the human
and the engineered
Soft and hard / Wet and dry
_ Human-oriented issues
Understanding the systems context, reaching consensus,
tracking issues, etc.
_ Engineering-oriented issues
Analytic methods, documentation quality, modeling,feasibility analysis, etc.
-
8/3/2019 Reqts Elicitation
5/54
Cost of Delay in Fixing
Requirements Errors
Cos t tofix
0
20
40
60
80
100
120
140
160
180
200
Cos t tofix
Re qts . de finition
DesignCoding
Unit tes ting
Pos t-de live ry
Data: Boehm & Papaccio (1988)IEEE Trans. Software Eng.
Nominalunit cost
20-fold increaseduring devt.
200-fold increaseafter delivery
-
8/3/2019 Reqts Elicitation
6/54
Requirements and system
fitness_ Well-understood
requirements_ Poorly understood
requirements
-
8/3/2019 Reqts Elicitation
7/54
Requirements faults:
(What were trying to avoid)Vagueness
Incompleteness
Gold-plating
Inconsistency
UnfeasibilityPoor writing
-
8/3/2019 Reqts Elicitation
8/54
Software Lifecycle Activities
ApplicationDomainObjects
SubSystems
class...
class...
class...
Implementation Domain
Objects
SourceCode
TestCases
?
Expressed inTerms Of
Structured By
ImplementedBy
Realized By VerifiedBy
System
Design
Object
Design
Implemen-
tationTesting
class....?
Requirements
Elicitation
Use CaseModel
Requirements
Analysis
Or textual requirements
-
8/3/2019 Reqts Elicitation
9/54
Figure 4-1. Products of requirements elicitation and analysis (UML activitydiagram).
Requirements
Elicitation
analysis model:Model
systemspecification
:Model
Analysis
-
8/3/2019 Reqts Elicitation
10/54
System Specification vs
Requirements Analysis Model_ Both focus on the requirements from the
users view of the system.
_ System specification uses naturallanguage (derived from problemstatement)
_ Requirements analysis model usesformal or semi-formal notation (e.g.,UML)
-
8/3/2019 Reqts Elicitation
11/54
Types of Requirements_ Functional requirements: Describe the interactions
between the system and its environment independentfrom 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
2:00am-2:01am and 3:00am-3:01am
_ Constraints(Pseudo requirements): Imposed by theclient or the environment in which the system will operate The implementation language must be COBOL. Must interface to the dispatcher system written in 1956.
-
8/3/2019 Reqts Elicitation
12/54
What is usually not in the
Requirements?_ System structure, implementation technology
_ Development methodology
_ Development environment_ Implementation language
_ Reusability
_ But descriptions of the real-world domainsare in the requirements (even though they arenot required)
-
8/3/2019 Reqts Elicitation
13/54
Figure 4-2. A System is a collection of real world Phenomena. A Model isa collection of Concepts that represent the Systems Phenomena. Many
Models can represent different aspects of the same System. Anunambiguous Model corresponds to only one System.
describes
*1
* *
Model System
Concept Phenomenon
-
8/3/2019 Reqts Elicitation
14/54
Key concepts:
is vs. ought
Domain Envt.
Sys.
NowFuture
Development& delivery
The way thingsare now
The way were assuming things will be
What well make the system do
-
8/3/2019 Reqts Elicitation
15/54
Case Example:
Scheduling and Scheduler
Domain Envt.
Sys.
NowFuture
Development& delivery
How people scheduleWhat meetings are
How people will scheduleWhat meetings will now be
Spec. of scheduler software
-
8/3/2019 Reqts Elicitation
16/54
The system and the world
(Jackson, 2000)
This is the
system
(a.k.a. a
machine)
This is the
real world
How the RW
should be
Customer
Interface
phenomenaRequired
phenomena
-
8/3/2019 Reqts Elicitation
17/54
Example of information
displayproblem frame
Knowabout
appts.
feature
What they
say about
appts.
Appt. model
is correctAppt.
model
Calendar
display
Time
frame Calendar iscorrect w.r.t.
queries
Display a
calendar
feature
Lexical domains
Constructed domain
-
8/3/2019 Reqts Elicitation
18/54
Example of controlled
behaviorproblem frame
Appts. with
alarms
Phone svc.
Passage of
time Correct &
timely
call
Wake-up
call
feature
Controlled domain
-
8/3/2019 Reqts Elicitation
19/54
Requirements Elicitation
Activities_ Identify actors
_ Identify scenarios
_ Identify use cases
_ Identify relationships among use cases
_
Refine use cases_ Identify nonfunctional requirements
_ Identify participating objects
-
8/3/2019 Reqts Elicitation
20/54
Requirements Elicitation
_ Challenging activity
_ Requires collaboration of people with differentbackgrounds
User with application domain knowledge Developer with implementation domain knowledge
_ Bridging the gap between user anddeveloper:
Scenarios: Example of the use of the system interms of a series of interactions with between theuser and the system
Use cases: Abstraction that describes a class of
scenarios
-
8/3/2019 Reqts Elicitation
21/54
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 newenvironment
Triggered by technology enabler or new market needs
-
8/3/2019 Reqts Elicitation
22/54
Key concepts:
Use cases and scenarios
Id like it to
blah blah
When PQR, the
system shallXYZ
abstract / general descriptions
Blahing Suppose a user called a mtgfor next week. The system querieseveryones online calendar andfinds that there....
concrete / specific descriptions
-
8/3/2019 Reqts Elicitation
23/54
Case Example:
Scheduling scenarios_ Scheduling a meeting without problems
_ Someone remembers an appointment
and cant attend
_ Theres no convenient time
_ Theres no venue available
_ The notification mechanism breaksdown
_ Meeting bumped by CEO
-
8/3/2019 Reqts Elicitation
24/54
Figure 4-12. Activities ofJAD (UML activity
diagram). The heart of JADis the Session activity
during which allstakeholders design and
agree to a system
specification. The activitiesprior to the Session
maximizes its efficiency.The production of the
Final document ensures
that the decisions made
during the Session arecaptured.
Management
definition guide
Project
definitionResearch
Preparation
Session
Session agendaPreliminary specification
Working document
Session script
Scribe forms
Final document
preparationFinal document
-
8/3/2019 Reqts Elicitation
25/54
System Identification
_ Development of a system is not just done bytaking a snapshot of a scene (domain)
_ Definition of the system boundary What is inside, what is outside?
_ How can we identify the purpose of asystem?
_ Requirements Process:
Requirements Elicitation: Definition of the systemin terms understood by the customer
Analysis: Technical specification of the system interms understood by the developer.
-
8/3/2019 Reqts Elicitation
26/54
Use cases
_ Most systems have several major inputevents to which theyre supposed to respond
Ignore the subsidiary directives & additional inputsfor now
Major does not mean frequent
_ E.g. calling a meeting, canceling a meeting,
becoming a new user of the system,remodeling rooms,...
dont forget these administrative/configuration use
cases
-
8/3/2019 Reqts Elicitation
27/54
Actors
_ Actors are
Things that performactions
Either actors in theworld
Or actors in themachine
_ For example
Actors in the world
User roles
Organizations
Physical devices
External systems
Nature
Actors in the machine
The system as a whole
Architecturalcomponents
-
8/3/2019 Reqts Elicitation
28/54
Figure 4-4. Actors of the FRIEND system. FieldOfficers not only have
access to different functionality, they use different computers to access thesystem.
FieldOfficer DispatcherFRIEND
Q: What is the context diagram for the PA system?
Q1: How much is in the PA -v- its environment?Q2: Given that, what are the actors?
-
8/3/2019 Reqts Elicitation
29/54
SetTime use case
-
8/3/2019 Reqts Elicitation
30/54
Figure 4-8. Example of communication relationships among actors anduse cases in FRIEND (UML use case diagram). The FieldOfficerinitiates the ReportEmergency use case and the Dispatcher initiatesthe OpenIncident and AllocateResources use cases.FieldOfficers cannot directly open an incident or allocate resources on
their own.
ReportEmergency
FieldOfficer Dispatcher OpenIncident
AllocateResources
-
8/3/2019 Reqts Elicitation
31/54
Figure 4-9. Example of use of extend relationship (UML use casediagram). ConnectionDown extends the ReportEmergency use case.The ReportEmergency use case becomes shorter and solely focused on
emergency reporting.
ReportEmergency
FieldOfficerConnectionDown
-
8/3/2019 Reqts Elicitation
32/54
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.
ViewMap
OpenIncident
AllocateResources
-
8/3/2019 Reqts Elicitation
33/54
Scenarios
_ A narrative description of what people
do and experience as they try to make
use of computer systems andapplications [M. Carrol, Scenario-basedDesign, Wiley, 1995]
_ A concrete, focused, informaldescription of a single feature of the
system used by a single actor.
-
8/3/2019 Reqts Elicitation
34/54
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 greenfieldengineering 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 userthrough a system
-
8/3/2019 Reqts Elicitation
35/54
Why Scenarios?
_ Requirements analysis is a form of learning
Examples reinforce principles & help you learnthem and their limits
_ Providing requirements involves explainingtacit knowledge
Examples are invaluable in articulating processesand problems customers dont often think about
_ Requirements analysis is often a form ofdesign
How would this work? is a standard design
question
-
8/3/2019 Reqts Elicitation
36/54
Scenario Exploration
_ Scenario exploration is the process of understandingplanned system behavior by walking throughpossibilities.
The goal may be just to get an idea of what the system willdo and whether it is really needed.
Or it may be a more structured process: to evaluatealternative allocations by considering concrete behaviorsthat illustrate the interactions in each case.
Or considering the consequences of obstacles, and whetherthey are severe.
Or considering the consequences of defending against ormitigating obstacles, and whether the costs are worth it.
-
8/3/2019 Reqts Elicitation
37/54
Envisionment through scenarios_ Scenarios are descriptions of actual or imagined
sequencesof events esp. good for examining exceptions/graceful degradation
Specifications are Abstract
General
Exhaustive in
coverage ofsituations
Authoritative
Boring
Scenarios are Concrete
Particular / Specific
Selective with
respect to salientsituations
Illustrative
Compelling
-
8/3/2019 Reqts Elicitation
38/54
Case Example:
Spec. & scenario fragments When the initiator
indicates completion
of the definition of themeeting constraints,the system shallcomplete undefined
constraints withdefault values andshall query theexternal calendar asfollows....
Pointy-hairedmanager (PHM)
wants to organize ameeting to discuss thedrone-to-cube ratioand enters the names
Dilbert and Wallyas invitees andtomorrow by 5pm as
latest time. Thesystem queries the...
-
8/3/2019 Reqts Elicitation
39/54
Issues with Scenarios
_ What is the appropriate level of detail forscenarios?
_ How should scenarios be described andrelated to other software descriptions?
esp. existing architecture
_ Which are the right scenarios to explore?
-
8/3/2019 Reqts Elicitation
40/54
Instantiating Actors and
Actions_ Many design teams find it useful to give
instances of actors, actions and data
Pointy-haired manager, not initiator Dilbert, Wally & PHM, not invitees
Tomorrows cube mtg, not the meeting
_ Useful when
Communicating with non-technical customers
Design team has dangerously little domainknowledge
Scenarios are well-chosen, not just cute
-
8/3/2019 Reqts Elicitation
41/54
How do we find scenarios?
_ Dont expect the client to be verbal if thesystem does not exist (greenfieldengineering)
_ 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/3/2019 Reqts Elicitation
42/54
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
-
8/3/2019 Reqts Elicitation
43/54
Key concept:
Requirements refinementVague, ambiguous Clear, precise
Id like it to
blah blah
When PQR, the
system shallXYZrefinement(possiblyincremental)
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
-
8/3/2019 Reqts Elicitation
44/54
Objectives & requirements
Systems exist to meet goals orobjectives
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
-
8/3/2019 Reqts Elicitation
45/54
Pre-requirements traceability
Pre-reqts. traceability shows where reqt.traces from
thus, objectives are rationale for reqts.
1.1 The system shall
blah, blah...
1.2 If the co-worker
is blah, blah, the
system shall inform
the user ...
1.2.1...
Reqts.
IMPROVE blah blah
MAINTAIN user
awareness of blah
Objectives
-
8/3/2019 Reqts Elicitation
46/54
Case Example:
Refining a fuzzy requirementThe system shall improve the
responsiveness to customer complaints
The system shall improve theresponsiveness to customer
complaints
.
When the customer-service clerkenters the customer code, the system
shall recommend the next customer-
service action
-
8/3/2019 Reqts Elicitation
47/54
Key concept:
Inquiry cycles_ Requirements
criticism(challenging
documentedrequirements) isabout askingthe right
questions at theright times
Reqts.documentation
raise
questions
analyze,
research &
decide
Annotatedreqts.
refine
reqts.
Refinedreqts.
-
8/3/2019 Reqts Elicitation
48/54
Case Illustration:
Inquiry-driven refinementsProjectoutline Questions
of clarificationQuestions about
exceptional cases
...etc
idealizedfunctionalspec.
robustfunctionalspec.
-
8/3/2019 Reqts Elicitation
49/54
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 thatcontradict each other
Clarity:
There are no ambiguities in the requirements.
-
8/3/2019 Reqts Elicitation
50/54
Requirements Validation
Criteria (continued)_ Realism:
Requirements can be implemented and
delivered_ Traceability:
Each system function can be traced to a
corresponding set of functionalrequirements
-
8/3/2019 Reqts Elicitation
51/54
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 aresponse being required before an envt. event
-
8/3/2019 Reqts Elicitation
52/54
Testable usability
requirementsConvenience / usability / familiarity /
friendliness objectives
Specification of expected userperformance
Ability to do a task without help within Xminutes of using system for 1st time
Average performance time for error-freetask
-
8/3/2019 Reqts Elicitation
53/54
Case example: Testable
quality requirementsPerformance
If there are feasible meeting times, the systemshould in 95% cases schedule a meeting within 5seconds of meeting constraints having beenentered
Usability
A person should be able to fill in the schedulingconstraints for an N-person meeting in fewer than5*N keystrokes/mouse-clicks
S
-
8/3/2019 Reqts Elicitation
54/54
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?