Você está na página 1de 54

Requirements Elicitation

CS 6300 Fall, 2000

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 System / environment; software / process Requirements / preferences Stakeholders / viewpoints. Trade-offs / negotiation

What is the scope of the system?

Are requirements absolute? What if they conflict?

Who are the customers? What if they disagree?

Engineering and humanoriented 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.

Cost of Delay in Fixing Requirements Errors


200 180 160 140 120 100 80 60 40 20 0
Data: Boehm & Papaccio (1988) IEEE Trans. Software Eng.

Re qts . de finitio n De s ig n Co ding Unit te s ting Po s t-de live ry

Nominal unit cost

Co s t to fix

200-fold increase after delivery 20-fold increase during devt.

Requirements and system fitness


_

Well-understood requirements

Poorly understood requirements

Requirements faults: (What were trying to avoid)


Vagueness Incompleteness Gold-plating

Inconsistency
Unfeasibility Poor

writing

Software Lifecycle Activities


Requirements Elicitation Requirements Analysis System Design Object Design Implementation Testing

Expressed in Terms Of

Structured By

Implemented By Realized By Verified By


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

Use Case Model

Application Implementat SubSystems ion Domain Domain Objects Objects

? class.... ? Test Cases

Source Code

Or textual requirements

Figure 4-1. Products of requirements elicitation and analysis (UML activity diagram).
Requirements Elicitation system specification :Model Analysis analysis model :Model

System Specification vs Requirements Analysis Model


_

Both focus on the requirements from the users 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)

Model

1 describes

System

*
Concept

* Phenomenon

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.

Key concepts: is vs. ought


Now Domain Development & delivery Envt. Future

Sys.

The way things are now

What well make the system do The way were assuming things will be

Case Example: Scheduling and Scheduler


Now Domain Development & delivery Envt. Future

Sys.

How people schedule What meetings are


Spec. of scheduler software How people will schedule What meetings will now be

The system and the world (Jackson, 2000)


Interface phenomena This is the system (a.k.a. a machine) Required phenomena

This is the real world

How the RW should be

Customer

Example of information display problem frame


Know about appts. feature Display a calendar feature

What they say about appts. Appt. model


Time frame Calendar display

Constructed domain
Appt. model is correct

Calendar is correct w.r.t. queries Lexical domains

Example of controlled behavior problem frame


Appts. with alarms Wake-up call feature

Passage of time
Phone svc.

Correct & timely call

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


abstract / general descriptions
Id like it to blah blah When PQR, the system shall XYZ

Blahing

Suppose a user called a mtg for next week. The system queries everyones online calendar and finds that there....

concrete / specific descriptions

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 breaks down Meeting bumped by CEO

Project definition

Management definition guide

Research

Figure 4-12. Activities of JAD (UML activity diagram). The heart of JAD Preliminary specification is the Session activity during which all stakeholders design and Preparation agree to a system specification. The activities prior to the Session Session maximizes its efficiency. The production of the Working document Final document ensures that the decisions made during the Session are Scribe forms captured.

Session agenda

script

Session

Final document preparation

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 theyre 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,...
dont forget these administrative/configuration use cases

Actors
_

Actors are

For example

Things that perform actions Either actors in the world Or actors in the machine

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

FRIEND

Dispatcher

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

<<initiate>> FieldOfficer ReportEmergency

Dispatcher

OpenIncident

AllocateResources

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.

FieldOfficer ReportEmergency

ConnectionDown <<extend>>

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.

<<include>> OpenIncident

ViewMap <<include>>
AllocateResources

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.

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.

Types of Scenarios
_

As-is scenario
Used in describing a current situation. Usually used during reengineering. 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 dont 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 Tomorrows 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?


_

Dont expect the client to be verbal if the system does not exist (greenfield engineering) 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

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
Id like it to blah blah

Clear, precise
When PQR, the system shall XYZ

refinement (possibly incremental)

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 processes are implementations of goals

Goals are not business processes

Pre-requirements traceability
Pre-reqts.

traceability shows where reqt. traces from


Objectives
IMPROVE blah blah

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

MAINTAIN user awareness of blah

thus, objectives are rationale for reqts.

Case Example: Refining 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 customerservice action

Key concept: Inquiry cycles


_

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

raise questions

Annotated reqts.

Reqts. documentation
Refined reqts.

analyze, research & decide

refine reqts.

Case Illustration: Inquiry-driven refinements


Project outline
idealized functional spec. Questions of clarification Questions about exceptional cases

robust functional spec.

...etc

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 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 but often not technically feasible to guarantee

Or by specifying ceiling on duration or wait time

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 of expected user

Specification

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?

Você também pode gostar