© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Nonfunctional Requirements (System Qualities) Agile Style
By Dean Leffingwell and Ryan Shriver
Agile 2010 Orlando, FL
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
About Dean Leffingwell
2
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
About Ryan Shriver
3
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
4
The first 90% of the code takes 90% of the development time. The remaining 10% of the code takes up the other 90% of the time. -- Tom Cargill, Bell Labs
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
NONFUNCTIONAL REQUIREMENTS IN AGILE CONTEXT
5
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
The Agile Team in The Enterprise There can be a large number of teams in the enterprise
“pods” of 5-10 teams building a feature, component, or subsystem is not unusual
Some product lines require 30-40-50 teams to build
However, the structure of each team is largely the same
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Their work is based on the user story
User Story
As a <role> I can <activity>
So that <business value>
“As a Gmail user, I can select and highlight a conversation for further action”
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Stories drive iterations
Story A Story B Story C Story D Story E Story F
Story …
Plan
Fixe
d R
esou
rces
Fixed Time (Iteration)
8
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story
Is one of
Backlog Item
Task 1 1..*
Stories are maintained in the teams backlog
There is only one backlog for the team
All work comes from the backlog
If isn't a user story (defect, etc) it still goes in the backlog
“If there isn’t a story in the backlog, it ain’t gonna happen”
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story
Is one of
Backlog Item
Task 1 1..*
Acceptance Test
Done when passes
1..*
1
A test and quality-centric approach
Teams perform unit testing and functional testing for every story
The details of the story go into the functional test, where they are the persistent representation of system behavior
Stories are temporal (not maintained after implementation)
Unit Test Functional Test
Consists of 1
1..* 1..*
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Scaling requires rethinking
Assume a program requires – 200 practitioners, (25 agile teams) to deliver a product – The enterprise delivers software every 90 days in five, two
week iterations. – Each team averages 15 stories per iteration. – Number of stories that must be elaborated and delivered to
achieve the release objective = 25*5*15= 1,875!
How is an enterprise supposed to reason about things? – What is this new product going to actually do for our users? – If we have 900 stories complete, 50% done, what do we
actually have working? How would we describe 900 things? – How will we plan a release than contains 1,875 things?
And, what if it took 500 people? 11
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
And further
And, even if I know 100 things that “as a <role> I can <activity> so that <business value>”, can do
what Features does the system offer to its user and what benefits does it provide?
12
Feature Benefit Stars for conversations Highlight conversations of
special interests Colored label categorization Easy eye discrimination of
different types of stories (folder like metaphor)
Smart phone client application
Faster and more facile use for phone users – ease adoption
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
So we need an additional level of planning
Iteration Cycle
Drives
Feedback - Adjust
Product & Release Cycle
Release Vision
Release Planning Release Scope and Boundaries
13
Iteration Planning
Develop & Test Review &
Adapt
Features
Stories
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Which creates an iteration and release pattern
Stories
Release timebox
14
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature Realized by 0,1 1..*
Is one of
Backlog Item
Task 1 1..*
So we need to extend the information model
Features are another kind of Backlog Item
Introduce Gmail “Labels” as a “folder-like” conversation-organizing metaphor.
Or:
As a modestly skilled user, I can assign more than one colored label to a conversation so that I can see a conversation from multiple perspectives
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature Realized by
Is one of
Backlog Item
Task 1 1..*
Features also require testing
0,1 1..*
Acceptance Test
Done when passes
1..*
1 1
Features typically span many teams
Sometimes, a special team is dedicated for the purpose of testing system level features
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
What about nonfunctional requirements?
Features and user stories express functional requirements
But other requirements determine system quality as well: – Performance, reliability and security requirements – Industry and Regulatory Standards – Design constraints, such as those that provide common
behavior across like components
Typically, these system level qualities – Span multiple components/products/applications/
services/subsystems – Can often only be tested at the system level
17
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Implemented by Story Feature Realized by 0,1 1..*
Is one of
Backlog Item Non-functional Requirement
Constrained by
Task 1 1..*
Done when passes
1..*
1 1
0..* 0..*
NFRs can be considered as constraints on new development
Acceptance Test
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Examples
19
As a consumer I want to be notified of any planned
brownouts that could affect my home
All utility notifications shall be displayed within one
minute of event Constrained by
Nonfunctional requirement Backlog Item
As a mail user, I want to use folders to organize
my mail for easier access
All web interfaces must be designed to meet accessibility requirements of
http://www.w3.org/WAI/intro/atag.php
Constrained by
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
NFRs may be expressed in user voice form (or not)
20
NFR – traditional expression
As a consumer I want to be
notified of any messages from
the utility in less than one minute
of arrival so that I can take
appropriate action quickly
As your CFO, I need to make sure we don’t use any
open source software that I
haven’t approved, so we don’t have license exposure
adds some value
As a product manager, I need to make sure we
update the logo to satisfy marketing
doesn’t add much value
All messages shall be displayed in less than one
minute
User voice form
works, adds value
All open source software must be approved by the
CFO
Update mobile app with new logo
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
NFR
Implemented by Story Feature
Realized by
0,1 1..*
Is one of
Backlog Item Nonfunctional Requirements
Constrained by
Task 1 1..*
Acceptance Test
Done when passes
1..*
1 1
1..*
0..*
System Qualities Tests
Compliant when passes
0..* 0..*
NFRS must also be tested
Often requires specialty skills and tools
May also be province of system team
1
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
NFRs in the Agile Testing Matrix
Manual
Tools
Automated & Manual
Automated
Source: Brian Marick; Crispen and Gregory: Agile Testing, Leffingwell: Agile Software Requirements
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Sources of Nonfunctional Requirements
23
Source: Wikipedia
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Persisting Nonfunctional Requirements Create a special backlog in your agile project
management tool Put them on a wiki or other project repository Build a supplemental specification Include them as an appendix to the Definition of Done
for the project
Sources, Examples and Templates: – Rational Unified Process Supplemental Specification – Leffingwell: Agile Software Requirements: Lean Requirements
Practices for Teams, Programs and the Enterprise, Addison-Wesley 2010.
– Leffingwell and Widrig [2003] : Managing Software Requirements,: A Use Case Approach, , Addison-Wesley 2003
24
Nonfunc'onal Requirements in the Big Picture
H
H H
H
©2009 Leffingwell, LLC.
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
IDENTIFYING AND QUANTIFYING QUALITIES
Today’s Exercise:
26
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Today You Will Learn How To
Identify the right qualities – Those key qualities that deliver value to the
highest priority stakeholders early
Quantify them for clarity – To ensure stakeholder’s desires are clearly
understood by everyone
27
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Exercise Background
Objective – Identify highest priority quality improvements
for the 2011 Agile Conference Web Site
Exercise – Identify the highest priority qualities for the
most important stakeholders – Clearly define these qualities for focused
improvements
Assumptions – At some point during the conference you’ve
used the current web site – You want to help improve the web site
28
29
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Important Concept: Ends vs. Means
30
Ends Objectives
Means Products, Features
Ends Qualities
Means Design,
Architecture
Product
Organization
Design
Exercise Focus
Levels of Concern
Instruc'ons Stakeholders Quali'es
1. Pair up with a partner and spend 2 minutes brainstorming a list of stakeholders
2. Next, with your partner spend 2 minutes iden=fying the top 2 quali=es for improvement for the most important stakeholder
Stakeholders are the en..es we’re trying to deliver value to by building a product
Quali.es reflect “how well” the product performs, not “what” func.ons it performs
Examples: Usability, Responsiveness
Page 1
© 2010 Leffingwell and, LLC. and Ryan Shriver
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Right Qualities for Software
Functionality – Features, User Stories, Capabilities, Security
Usability – Human factors, Aesthetics, Consistency, Documentation
Reliability – Availability, Recoverability, Accuracy
Performance – Responsiveness, Throughput, Scalability
Supportability – Maintainability, Testability, Extensibility, Adaptability, Serviceability,
Configurability, Portability, Compatibility
32
Source: FURPS model developed at Hewlett-Packard and documented by Robert Grady and Deborah Caswell in Software Metrics: Establishing a Company Wide Program (1987)
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Today You Will Learn How To
Identify the right qualities – Those key qualities that deliver value to the
highest priority stakeholders early
Quantify them for clarity – To ensure stakeholder’s desires are clearly
understood by everyone
33
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
How to Define a Quality
34
Definitions: To clarify terminology and meaning [Qualifiers]: Specificity and Reusable Scales <- Sources: Additional transparency and credibility
Optional Elements
Name: In the form Quality.SubQuality Scale: What to measure (units) Meter: How to measure (method)
Step 1
Target: Success level to achieve Constraint: Failure level to avoid Baseline: Current level
Step 2
Source: Based on Planguage from Competitive Engineering by Tom Gilb
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Real Product Examples – Step 1
35
Name: Usability.Efficiency Scale: Number of Actions to complete a Transaction from a Location Meter: Average observed results from usertesting.com usability tests
Name: Usability.Conversion Scale: Percentage of Users who complete a Transaction after starting Meter: Google Analytics conversion report
Actions: One of {Data entry, Click, Scroll}. Default is All Actions Transaction: One of {eCommerce [Shop, Purchase], Self Service [Activate, Change Plan]} Location: One of {Home Page, My Account}. Default is Home Page
Name: Usability Scales: Efficiency: Number of Actions to complete a Transaction from a Location Conversion: Percentage of Users who complete a Transaction after starting Meters: Efficiency: Average observed results from usertesting.com usability tests Conversion: Google Analytics conversion report
Alternative Syntax
Quality Defini'on Quality Step 1: Iden'fy name, appropriate scale of measure and method of measuring
Name: In the form Quality.SubQuality Scale: What to measure (units) Meter: How to measure (method)
Step 2: Establish Baseline and set appropriate targets and constraints
Target: Success level to achieve Constraint: Failure level to avoid Baseline: Current level
[Qualifiers]: Specificity and Reusable Scales <-‐ Sources: Addi=onal transparency and credibility Defini'ons: To clarify terminology and meaning
Name:
Scale:
Meter:
Baseline Constraint Target
Quality Example Quality Name: Usability.Efficiency Scale: Number of Ac=ons to complete a Transac=on from the Home Page Meter: Average observed results from usertes=ng.com usability tests Ac=ons: One of {Data entry, Scroll, Click}. Default is All. Transac=on: One of {Registra=on, Purchase}
Name:
Scale:
Meter:
Baseline [Registra=on; 2010]:
80 [Purchase; 2010]: 60
Constraint [Registra=on; 2011]:
72 <-‐ 10% improvement
[Purchase; 2011]: 54 <-‐ 10% improvement
Target [Registra=on; 2010]:
48 <-‐ 40% improvement
[Purchase; 2010]: 42 <-‐ 30% improvement
Baseline Constraint Target
Page 2
© 2010 Leffingwell and, LLC. and Ryan Shriver
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Baselines
Method Description
Use Existing Meter Use existing method of measuring such as a report
Create a New Meter Create a new method of measuring. This requires the team to implement new capabilities in order to measure in the future
Estimate Do the best you can to estimate what the existing baseline is, even if there’s no supporting data. Use the <- source tag to indicate credibility of data
37
Common methods for establishing Baseline levels include
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Targets and Constraints
Method Description Improvement from the Baseline Plan a 20% - 40% improvement over
current levels by next year
Comparison with Leading Competitors
Benchmarking yourself against leading competitors and setting levels based on their capabilities
Comparison with your Industry Leaders
Benchmarking yourself against your industry leaders, such as trying to be in Gartner’s Magic Quadrant
Comparison with other Industry Leaders
Benchmarking yourself against other industries known for great levels of quality, such as Nordstrom’s customer service
38
Common methods for establishing Target and Constraint levels include
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Visualizing Qualities
39
Baselines, Targets and Constraints exist along a continuum of improvement
Fail
Constraint
0%
Target
100%
Baseline
30%
Success
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Real Product Examples – Steps 1 & 2
40
Name: Usability Scales: Efficiency: Number of Actions to complete a Transaction from a Location Conversion: Percentage of Users who complete a Transaction after starting Meters: Efficiency: Average observed results from usertesting.com usability tests Conversion: Google Analytics conversion report
Actions: One of {Data entry, Click, Scroll}. Default is All Actions Transaction: One of {eCommerce [Shop, Purchase], Self Service [Activate, Change Plan]} Location: One of {Home Page, My Account}. Default is Home Page
Target: Efficiency [eCommerce; Release 2]: 62 actions <- 40% reduction Conversion [eCommerce; Q4 2010 – Q2 2011]: 0.5% <- 30% increase, industry average Constraint: Efficiency [eCommerce; Release 2]: 93 actions <- 10% reduction Conversion [eCommerce; Q4 2010 – Q2 2011]: 0.43% <- 15% increase Baseline: Efficiency [eCommerce; Release 1]: 103 actions <- Average of 10 usability tests Conversion [eCommerce; Q4 2009 – Q2 2010]: 0.37% <- Current state
Quality Defini'on Quality Step 1: Iden'fy name, appropriate scale of measure and method of measuring
Name: In the form Quality.SubQuality Scale: What to measure (units) Meter: How to measure (method)
Step 2: Establish Baseline and set appropriate targets and constraints
Target: Success level to achieve Constraint: Failure level to avoid Baseline: Current level
[Qualifiers]: Specificity and Reusable Scales <-‐ Sources: Addi=onal transparency and credibility Defini'ons: To clarify terminology and meaning
Name:
Scale:
Meter:
Baseline Constraint Target
Quality Example Quality Name: Usability.Efficiency Scale: Number of Ac=ons to complete a Transac=on from the Home Page Meter: Average observed results from usertes=ng.com usability tests Ac=ons: One of {Data entry, Scroll, Click}. Default is All. Transac=on: One of {Registra=on, Purchase}
Name:
Scale:
Meter:
Baseline [Registra=on; 2010]:
80 [Purchase; 2010]: 60
Constraint [Registra=on; 2011]:
72 <-‐ 10% improvement
[Purchase; 2011]: 54 <-‐ 10% improvement
Target [Registra=on; 2010]:
48 <-‐ 40% improvement
[Purchase; 2010]: 42 <-‐ 30% improvement
Baseline Constraint Target
Page 2
© 2010 Leffingwell and, LLC. and Ryan Shriver
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
Today You Will Learn How To
Identify the right qualities – Those key qualities that deliver value to the
highest priority stakeholders early
Quantify them for clarity – To ensure stakeholder’s desires are clearly
understood by everyone
42
© 2010 Leffingwell and, LLC. and Ryan Shriver
Agile Software Development Series
Alistair Cockburn and Jim Highsmith, Series Editors
Agile Software RequirementsLean Requirements Practices for Teams, Programs, and the Enterprise
Dean LeffingwellForeword by Don Reinertsen
THANK YOU
43