Reqts Elicitation

8/3/2019 Reqts Elicitation

1/54

Requirements Elicitation

CS 6300

Fall, 2000


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


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


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.


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


6/54

Requirements and system

fitness_ Well-understood

requirements_ Poorly understood

requirements


7/54

Requirements faults:

(What were trying to avoid)Vagueness

Incompleteness

Gold-plating

Inconsistency

UnfeasibilityPoor writing


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


9/54

Figure 4-1. Products of requirements elicitation and analysis (UML activitydiagram).

Requirements

Elicitation

analysis model:Model

systemspecification

:Model

Analysis


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)


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.


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)


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


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


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


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


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


18/54

Example of controlled

behaviorproblem frame

Appts. with

alarms

Phone svc.

Passage of

time Correct &

timely

call

Wake-up

call

feature

Controlled domain


19/54


Activities_ Identify actors

_ Identify scenarios

_ Identify use cases

_ Identify relationships among use cases

_

Refine use cases_ Identify nonfunctional requirements

_ Identify participating objects


20/54


_ 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


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


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


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


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


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.


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


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


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?


29/54

SetTime use case


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


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


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


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.


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


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


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.


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


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


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?


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


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


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


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


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


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


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


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.


48/54

Case Illustration:

Inquiry-driven refinementsProjectoutline Questions

of clarificationQuestions about

exceptional cases

...etc

idealizedfunctionalspec.

robustfunctionalspec.


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.


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


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


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


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


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?

Documents

Reqts Elicitation