Requirements Elicitation

Requirements (1)

_ What are requirements and why are they important?

_ Problem frames_ Requirements elicitation_ Strategies

– System & actor identification– Use case & scenario analysis

_ Requirements refinement and validation

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

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 system’s context, reaching consensus,

tracking issues, etc.

_ Engineering-oriented issues– Analytic methods, documentation quality, modeling,

feasibility analysis, etc.

Cost of Delay in Fixing Requirements Errors

Cos t tofix

020406080

100120140160180200

Cos t tofix

Re qts . definitionDe s ignCodingUnit tes tingPos t-de live ry

Data: Boehm & Papaccio (1988)IEEE Trans. Software Eng.

Nominalunit cost

20-fold increaseduring devt.

200-fold increaseafter delivery

Requirements and system fitness

_ Well-understood requirements

_ Poorly understood requirements

Requirements faults:(What we’re trying to avoid)

Vagueness Incompleteness Gold-plating Inconsistency Unfeasibility Poor writing

Software Lifecycle Activities

Application

Domain Objects

SubSystems

class...class...class...

Implementation

Domain Objects

SourceCode

Test Cases

?

Expressed in Terms Of

Structured By

Implemented

ByRealized By Verified By

SystemDesign

ObjectDesign

Implemen-tation

Testing

class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

Or textual requirements

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

RequirementsElicitation

analysis model:Model

systemspecification

:Model

Analysis

System Specification vs Requirements Analysis Model

_ Both focus on the requirements from the user’s view of the system.

_ System specification uses natural language (derived from problem statement)

_ Requirements analysis model uses formal or semi-formal notation (e.g., UML)

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 2:00am-

2:01am and 3:00am-3:01am

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

What is usually not in the Requirements?

_ System structure, implementation technology_ Development methodology_ Development environment_ Implementation language_ Reusability

_ But descriptions of the real-world domains are in the requirements (even though they are not required)

Figure 4-2. A System is a collection of real world Phenomena. A Model is a collection of Concepts that represent the System’s Phenomena. Many

Models can represent different aspects of the same System. An unambiguous Model corresponds to only one System.

describes

*1

* *

Model System

Concept Phenomenon

Key concepts:“is” vs. “ought”

Domain Envt.

Sys.

Now FutureDevelopment& delivery

The way thingsare now

The way we’re assuming things will beWhat we’ll make the system do

Case Example:Scheduling and Scheduler

Domain Envt.

Sys.

Now FutureDevelopment& delivery

How people scheduleWhat meetings are

How people will scheduleWhat meetings will now be

Spec. of scheduler software

The system and the world(Jackson, 2000)

This is the“system”(a.k.a. a

machine)

This is the“real world”

How the RWshould be

Customer

Interfacephenomena

Requiredphenomena

Example of information display problem frame

“Knowaboutappts.”feature

What theysay aboutappts.

Appt. modelis “correct”Appt.

model

Calendardisplay

Timeframe Calendar is

correct w.r.t.queries

“Display acalendar”feature

Lexical domains

Constructed domain

Example of controlled behavior problem frame

Appts. withalarms

Phone svc.

Passage oftime Correct &

timelycall

“Wake-upcall”feature

Controlled domain

Requirements Elicitation Activities

_ Identify actors_ Identify scenarios_ Identify use cases_ Identify relationships among use cases_ Refine use cases_ Identify nonfunctional requirements_ Identify participating objects

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

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

Key concepts:Use cases and scenarios

I’d like it toblah blah

When PQR, thesystem shallXYZ

abstract / general descriptions

Blah’ing Suppose a user called a mtgfor next week. The system queries everyone’s online calendar andfinds that there....

concrete / specific descriptions

Case Example:Scheduling scenarios

_ Scheduling a meeting without problems_ Someone remembers an appointment

and can’t attend_ There’s no convenient time_ There’s no venue available_ The notification mechanism breaks down_ Meeting bumped by CEO

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.

Managementdefinition guide

Projectdefinition

Research

Preparation

Session

Session agendaPreliminary specification

Working document

Session script

Scribe forms

Final documentpreparation

Final document

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?

_ How can we identify the purpose of a system?_ 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.

Use cases

_ Most systems have several major input events to which they’re supposed to respond– Ignore the subsidiary directives & additional inputs

for now

– “Major” does not mean “frequent”

_ E.g. calling a meeting, canceling a meeting, becoming a new user of the system, remodeling rooms,...– don’t forget these administrative/configuration use

cases

Actors

_ Actors are– Things that perform

actions– Either actors in the

world– Or actors in the

machine

_ For example– Actors in the world

• User roles• Organizations• Physical devices• External systems• Nature

– Actors in the machine• The system as a whole• Architectural

components

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

SetTime use case

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.

ReportEmergency

FieldOfficer Dispatcher OpenIncident

AllocateResources

<<initiate>>

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.

ReportEmergency

FieldOfficerConnectionDown

<<extend>>

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.

ViewMapOpenIncident

AllocateResources

<<include>>

<<include>>

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

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

Why Scenarios?_ Requirements analysis is a form of learning

– Examples reinforce principles & help you learn them and their limits

_ Providing requirements involves explaining tacit knowledge– Examples are invaluable in articulating processes

and problems customers don’t often think about

_ Requirements analysis is often a form of design– “How would this work?” is a standard design question

Scenario Exploration

_ Scenario exploration is the process of understanding planned system behavior by walking through possibilities.– The goal may be just to get an idea of what the system will do

and whether it is really needed.

– Or it may be a more structured process: to evaluate alternative allocations by considering concrete behaviors that illustrate the interactions in each case.

– Or considering the consequences of obstacles, and whether they are severe.

– Or considering the consequences of defending against or mitigating obstacles, and whether the costs are worth it.

Envisionment through scenarios_ Scenarios are descriptions of actual or imagined

sequences of events– esp. good for examining exceptions/graceful degradation

Specifications are Abstract General Exhaustive in

coverage of situations

Authoritative Boring

Scenarios are Concrete Particular / Specific Selective with

respect to salient situations

Illustrative Compelling

Case Example:Spec. & scenario fragments

When the initiator indicates completion of the definition of the meeting constraints, the system shall complete undefined constraints with default values and shall query the external calendar as follows....

Pointy-haired manager (PHM) wants to organize a meeting to discuss the drone-to-cube ratio and enters the names “Dilbert” and “Wally” as invitees and “tomorrow by 5pm” as latest time. The system queries the...

Issues with Scenarios

_ What is the appropriate level of detail for scenarios?

_ How should scenarios be described and related to other software descriptions?– esp. existing architecture

_ Which are the “right” scenarios to explore?

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”– “Tomorrow’s cube mtg”, not “the meeting”

_ Useful when– Communicating with non-technical customers– Design team has dangerously little domain knowledge– Scenarios are well-chosen, not just cute

How do we find scenarios?_ Don’t expect the client to be verbal if the system

does not exist (greenfield engineering) _ Don’t 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

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

Key concept:Requirements refinement

Vague, ambiguous Clear, precise

I’d like it toblah blah

When PQR, thesystem 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

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

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, thesystem shall inform the user ...1.2.1...

Reqts.

IMPROVE blah blah

MAINTAIN userawareness of blah

Objectives

Case Example:Refining a fuzzy requirementThe system shall improve the

responsiveness to customer complaints

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

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

Key concept:Inquiry cycles

_ Requirements criticism (challenging documented requirements) is about asking the right questions at the right times

Reqts.documentation

raisequestions

analyze,research &decide

Annotatedreqts.

refinereqts.

Refinedreqts.

Case Illustration:Inquiry-driven refinements

Projectoutline Questions

of clarificationQuestions about

exceptional cases

...etc

idealizedfunctionalspec.

robustfunctionalspec.

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 client’s 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.

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

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

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

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 5*N keystrokes/mouse-clicks

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