24
Better Translating Customer Expectations into Design Requirements Lawrence Chung Dept. of Computer Science Erik Jonsson School of Engineering and Computer Science The University of Texas at Dallas For Better, SPRING 2008 Requirements Engineering:

Better Translating Customer Expectations into Design Requirements Lawrence Chung Dept. of Computer Science Erik Jonsson School of Engineering and Computer

Embed Size (px)

Citation preview

Better Translating Customer Expectations into Design Requirements

Lawrence ChungDept. of Computer Science

Erik Jonsson School of Engineering and Computer Science

The University of Texas at Dallas

For Better, SPRING 2008

Requirements Engineering:

Customer Expectations?

With cellular phones: “… enhancements enable the best possible operation of your mobile … in various conditions. …

The earpiece fits in either ear allowing for convenient and reliable access to all basic call controls. ... To maximize call security, the headset also supports … the wireless connection for compatible … models.”

With home networking: “… is the total home networking solution … linking variety of digital home appliances as one. It enables you to enjoy convenient, pleasant, comfortable, and reliable living environment at any time and any place.

• Customer Expectations : according to J. Musathe ability of the system to behave consistently

in a user-acceptable manner

when operating within the environment for which the system was intended.

MTBFMTBF

MTTFMTTFMTTRMTTR

Availability = [MTTF/(MTTF + MTTR)] x 100%

What does “reliability” mean?

• Design Requirements:theory and practice of hardware reliability are well established; some try to adopt them for software - one popular metric for hardware reliability is mean-time-to-failure (MTTF)

• Sometimes reliability requirements take the form:

"The software shall have no more than X bugs/1K LOC"

Measure bugs at delivery time, based on a Monte Carlo statistical analysis of random events.

A Big Gap! Project overrun/failure!

Major Issues – The Standish “Chaos” Report

Requirements Engineering Process

Functional Requirements

Non-Functional Requirements

Outline

NFR

FR

Process

Issues

What should be done (e.g., use cell to control garage door)

How should it be done (e.g., use cell to control garage door, “fast” and “in a secure manner”)

Quality (incl. QoS), Cost, Time-to-Market, …

Do Requirements Matter? If so, how do we make them better?

10. Other

9. Reliable Estimates

8. Formal Methodology

7. Firm Basic Requirements

6. Standard Software Infrastructure

5. Minimized Scope

4. Clear Business Objectives

3. Experienced Project Manager

2. User Involvement

1. Executive Management Support

Project Success Factors

The Standish Group Report, ‘01 – The “Chaos” Report (www.standishgroup.com), yearly since 1994

28%

49%23%

completed on time and on budget

canceled before completion

overran original estimates

-Time overrun averaged 63%- Cost overrun averaged 45%

Issues

137,000 projects

65,000 projects

78,000 projects

The CHAOS CHAOS Ten

What Factors Contribute to Project Failure?

Standish Group, ‘01 (www.standishgroup.com)

The CHAOS CHAOS TenThe CHAOS CHAOS Ten

“The definition of insanity is doing the same thing over and over again and expecting a different result.” [Albert Einstein]

Issues

Correct [IEEE 830-1993, § 4.3.2, 1994] – Is a true statement of something the system must do.

Complete– Describes all significant requirements of concern to the user.

Consistent– Does not conflict with other requirements.

Unambiguous– Is subject to one and only one interpretation.

Verifiable– Can be tested cost effectively.

Ranked for importance and stability– Can be sorted based on customer importance and stability of the requirement itself.

• Modifiable– Changes do not affect the structure and style of the set.

Traceable– The origin of each requirement can be found.

Understandable– Comprehended by users and developers.

Better Translating Customer Expectations into Design Requirements

Issues

Moreneeds

Better process/methodology & notationneeds

Requirements Engineering Process 3 fundamental activities:

understand, (formally) describe, attain an agreement on, the problem

User

ProblemDomain

Elicitation Validation

• Elicitation: determine what’s really needed, why needed, whom to talk to

• Specification: produce a (formal) RS model: translate "vague" into "concrete", etc.; make various decisions on what & how

• Validation: assure that the RS model satisfies the users’ needs

Domain knowledge Domain knowledge

User reqsUser feedback

Req. models

Val. result

knowledge

For more knowledge

(domain experts, laws, standards, policies, documents, etc.)

Process

Many variations and extensions

Specification

Alternative solutions explored, negotiated, defined, validated

Best solution chosen to meet the goals

Customer problem & expectations elicited, negotiated, defined, validated

in the context of the customer goals

Process From Customer Expectations into Design Requirements: A Roadmap

An interleaving and continuous loop: elicit, model, translate, specify, validate

Customers do NOT really know what they wantHelp them find out what they may expect

Customers do NOT really know about the solutionHelp them find out what choices they have

traceability!

Customer ExpectationsNon-FunctionalFunctional

Design RequirementsNon-FunctionalFunctional

traceability!

traceability!

Understanding and Modeling Functional Requirements

Describe the Problem in the Vision Document

User Documentation Specifications

Design Specifications

StakeholderRequests

Vision Document

SupplementarySpecificationUse-Case Model

• Communicates information between all parties – customer, management, marketing, and the project team.

• Provides initial customer feedback.

• Fosters general understanding of the product.

• Establishes scope and priority of high-level stakeholder requests and features.

• A system-level document that describes the “what” and “why” of the product.

Modeling Using UML, the de facto industry standard

FR

Object-oriented, facilitates communication , visual language

• Non-functional requirements are not treated as first-class citizens.

Adapted from [Copyright  © 1987 - 2001 Rational Software Corporation]

Understanding and Modeling Functional Requirements

Modeling Using UML, the de facto industry standard

FR

Use-Case Model Object ModelDynamic Model

Workflow ModelScenarios

A consortium of communicating agents

Establish common vocabulary => Domain Model

With cellular phones: “… enhancements enable the best possible operation

of your mobile … in various conditions. …

The earpiece fits in either ear allowing for convenient and reliable access to all basic call controls. ... To maximize call security, the headset also supports … the wireless connection for compatible … models.”

With home networking: “… is the total home networking solution …

linking variety of digital home appliances as one.

It enables you to enjoy convenient, pleasant, comfortable, and reliable living environment at any time and any place.

NFR Understanding and Modeling Non-Functional Requirements

• -ilities: understandability, usability, modifiability, inter-operability, reliability, portability, dependability, flexibility, availability, maintainability, scalability, (re-)configurability, customizability, adaptability, stability, variability, volatility, traceability, verifiability, predictability, compatibility, survivability, accessibility, …

• -ities: security, simplicity, clarity, ubiquity, integrity, safety, modularity, nomadicity, …

• -ness: user-friendliness, robustness, timeliness, responsiveness, correctness, completeness, conciseness, cohesiveness, …

• …and there are many more: convenience, comfort, performance, efficiency, accuracy, precision, slim, esthetics, consistency, coherence, fault tolerance, self-healing capability, autonomy, cost, development time, time-to-market, long-lasting battery, low coupling, …

What are Non-Functional Requirements? NFR

F: I Oadd: 2, 5 7

ambiguous, subjective, conflicting, global

NFRs:subjective in both definitions & solutions

Classification 2 - Process, Product and External considerations [Sommerville 1992]

Classification 1Classification 1 [Roman, IEEE Computer 1985][Roman, IEEE Computer 1985]

NFR

6 classes + 2-3 levels

3 classes + 2 levels

Classification 3Classification 3

NFRs:subjective in both definitions & solutions

NFR

Note correlations3 classes + 3 levels

FFunctionality Feature set capabilities, security, generality

UUsability Human factors aesthetics, consistency, documentation

RReliabilityFrequency/severity of failure,

recoverability, predictability, accuracy, MTBF

PPerformance Speed efficiency, resource usage, throughput, response time

SSupportability

Testability Extensibility Adaptability MaintainabilityCompatibility Configurability

Serviceability InstallabilityLocalizability Robustness

Dimensions of Quality –Components of FURP+ [Grady1992]

NFR

Classification 4Classification 4

NFRs:subjective in both definitions & solutions

5 classes + 2 levels

Software Quality Tree [Boehm 1976]

NFR

Classification 5Classification 5

NFRs:subjective in both definitions & solutions

Note correlations

3 classes + 3 levels

Relationship Between Design Goals

Reliability

Low cost Increased ProductivityBackward-CompatibilityTraceability of requirementsRapid developmentFlexibility

ClientEnd User

(Customer,

PortabilityGood Documentation

RuntimeEfficiency

Sponsor)

Developer/Maintainer

Minimum # of errorsModifiability, ReadabilityReusability, AdaptabilityWell-defined interfaces

FunctionalityUser-friendlinessEase of UseEase of learningFault tolerantRobustness

NFR

Adapted from [Brugge]One possibility

Goal-Oriented Requirements Engineering: The NFR Framework, Tropos, KAOS, …

J. Mylopoulos, L. Chung, E. Yu, "From object-oriented to goal-oriented requirements analysis ", CACM, pp31-37.ACM Press

Object Model

E.g: A small portion of a hospital model for requirements analysis

Softgoal Interdependency Graph (SIG)

From NFR Softgoals to Op Softgoals (here, Use Cases)

NFR

FR

Treat NFRs as softgoals Refine them traceably Achieve them functionally Detect and resolve conflicts Prioritize throughout!

ambiguous, subjective, conflicting, global

Goals-Ops-Props-Scenarios

Goals

Operationalizations

Objects

PropertiesScenarios

Goals

Operationalizations

PropertiesScenarios

liveness liveness

antinegative

mis

safety

NFRs – Do’s & Don’ts Dos• Relate to FRs• Clarify scope/topic• Identify agents, whenever useful• Discover relationships between

definitions of NFRs• Discover relationships between solutions

to NFRs• Refine definitions as many times as

needed• Refine solutions as many times as needed• Prioritize• Discover conflicts• Safeguard against conflicts• Discover synergies• Discover operationalizations as reasons

for conflicts/synergies• Determine strengths of contributions• Justify strengths of contributions• Explore alternatives• Discover solutions from requirements• Discover requirements from solutions• Consider use of multiple solutions• Consider scenarios• If necessary, quantify• Evaluate, …subjectively, …objectively• Establish traceability

Don’ts• Absolute security, absolute reliabilty, absolute

safety, ….• One definition fits all• One solution solves all the problems• The contribution is such and such, since I say so• Refine the definition only once• They are falling down from the sky• Dissociate from FRs• May be more important than FRs, but should consume less resources• You name it; our system does it• No quantification, no existence• Everybody needs the same• Be only pessimistic• Asking why “+” reveals ignorance• Beg the question• Evaluate & only evaluate• Brainwash nothing but objectivity

NFR

Theoretical Foundations

The 4-variable model: SOF m M (REQ(m) = OUT(SOF(IN(m))))

M C

I O

REQ

SOF

IN OUT

The reference model (WRSPM):

D – Domain Properties (World, Enterprise, Business, Domain theory)

R - Requirements

S - SpecificationC – Computer

P - Program

P, C |= S

The goal model:

If R denotes the set of requirements, As the set of assumptions (expectations), S the set of software specifications, Ac the set of accuracy goals, and G the set of goals

complete if

complete if

complete if

NFRFR

FR

FR

FR NFR

SummaryBetter Translating Customer Expectations into Design Requirements

needs

Better

NFRFRProcessIssues

process/methodology & notation for

MoreCorrect, Complete, Consistent, Unambiguous, Verifiable, Ranked for importance and stability, Modifiable,Traceable, Understandable

Goal-OrientedObject-Oriented

Customer ExpectationsNon-FunctionalFunctional

Design RequirementsNon-FunctionalFunctional

elicitation, specification & validation of

needs

On-going Work

Component Reuse and Interoperability

Requirements & Architecture Patterns

NFRFRProcessIssues

Verification Using Model Checking

Security and Privacy Requirements Engineering