Upload
rolf-cummings
View
218
Download
2
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