Nonfunctional Requirements (System Qualities) Agile Style: by Dean Leffingwell and Ryan Shriver Agile 2010 Orlando, FL

Agile Software
Requirements
Lean Requirements Practices for
Teams, Programs, and the Enterprise
Dean Leffingwell
Foreword by Don Reinertsen
Nonfunctional Requirements Agile Software Development Series
(System Qualities) Agile Style

Alistair Cockburn and Jim Highsmith,
Series Editors
Agile Software
Requirements
By Dean Leffingwell
Dean Leffingwell
and Ryan Shriver

Agile 2010 Agile Software Development Series

Series Editors
Orlando, FL
© 2010 Leffingwell and, LLC. and Ryan Shriver

About Dean Leffingwell Agile Software
Requirements
Dean Leffingwell
Agile Software Development Series

Series Editors
Agile Software
Requirements
Dean Leffingwell

Series Editors
© 2010 Leffingwell and, LLC. and Ryan Shriver 2

About Ryan Shriver Agile Software
Requirements
Dean Leffingwell

Series Editors

Agile Software
Requirements
Dean Leffingwell

Series Editors
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

Agile Software
Requirements
Dean Leffingwell

Series Editors
NONFUNCTIONAL
REQUIREMENTS IN AGILE
CONTEXT
The Agile Team in The Enterprise Agile Software
Requirements
There can be a large number of Dean Leffingwell

teams in the enterprise

“pods” of 5-10 teams building a

Series Editors
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

Their work is based on the user story Agile Software
Requirements
Dean Leffingwell

Series Editors
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”

Stories drive iterations Agile Software
Requirements
Dean Leffingwell

Series Editors
Story A
Fixed Resources
Story B
Story C
Plan
Story D
Story E
Story F
Story …
Fixed Time (Iteration)

Stories are maintained in the teams Agile Software
Requirements
backlog Dean Leffingwell

There is only one backlog Agile Software Development Series

Series Editors
for the team Backlog Item
All work comes from the

backlog Is one of
If isn't a user story (defect,

etc) it still goes in the
Implemented by
backlog Story Task
1 1..*
“If there isn’t a story in the

backlog, it ain’t gonna
happen”

A test and quality-centric approach Agile Software
Requirements
Dean Leffingwell
Teams perform unit testing


Series Editors
Backlog Item
and functional testing for
every story
Is one of
The details of the story go

into the functional test,
where they are the
Implemented by
persistent representation Story 1 1..*
Task
of system behavior Done when 1
passes
Stories are temporal (not 1..*
maintained after Acceptance Test

implementation) 1
Consists of
1..* 1..*
Unit Test Functional Test

Scaling requires rethinking Agile Software
Requirements
Dean Leffingwell
  Assume a program requires Agile Software Development Series

Series Editors
–  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?
And further Agile Software
Requirements
Dean Leffingwell
  And, even if I know 100 things that “as a <role> I Agile Software Development Series

Series Editors
can <activity> so that <business value>”, can do
what Features does the system offer to its user

and what benefits does it provide?
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 Faster and more facile use
application for phone users – ease
adoption

So we need an additional level of planning Agile Software
Requirements
Dean Leffingwell
Features
Product & Release Cycle

Series Editors
Drives
Release
Vision
Stories
Release Planning
Release Scope
and Boundaries Iteration Cycle
Iteration Planning
Feedback Develop &

Review &
- Adjust Adapt
Test

Which creates an iteration and release Agile Software
Requirements
pattern Dean Leffingwell


Series Editors
Stories
Release timebox
So we need to extend the information Agile Software
Requirements
model Dean Leffingwell


Series Editors
Features are Backlog Item

another kind of
Backlog Item
Is one of
Realized by Implemented by
Feature 0,1 1..*
Story 1 1..*
Task
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
Features also require testing Agile Software
Requirements
Dean Leffingwell

Series Editors
Backlog Item
Is one of
Feature 0,1 1..*
Story 1 1..*
Task
1 1
Done when
passes
1..*
Features typically span
many teams Acceptance Test
Sometimes, a special team is dedicated for

the purpose of testing system level
features
What about nonfunctional requirements? Agile Software
Requirements
Dean Leffingwell
  Features and user stories express functional Agile Software Development Series

Series Editors
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

NFRs can be considered as constraints Agile Software
Requirements
on new development Dean Leffingwell


Series Editors
Constrained by Non-functional
Backlog Item 0..* 0..* Requirement
Is one of
Feature 0,1 1..*
Story 1 1..*
Task
1 1
Done when
passes
1..*
Acceptance Test

Examples Agile Software
Requirements
Dean Leffingwell

Series Editors
Backlog Item Nonfunctional requirement
As a consumer I want to All utility

be notified of any planned notifications shall be
brownouts that could Constrained by displayed within one
affect my home minute of event
All web interfaces

As a mail user, I want to must be designed to
use folders to organize meet accessibility
Constrained by requirements of
my mail for easier access
http://www.w3.org/
WAI/intro/atag.php

NFRs may be expressed in user voice Agile Software
Requirements
form (or not) Dean Leffingwell


Series Editors
All messages shall All open source

NFR –
be displayed in software must be Update mobile
traditional
less than one approved by the app with new logo
expression
minute CFO
As a consumer I
want to be As your CFO, I
notified of any need to make sure
messages from we don’t use any As a product
the utility in less manager, I need
open source
User than one minute to make sure we
software that I
voice form of arrival so that haven’t approved, update the logo to
I can take so we don’t have satisfy marketing
appropriate action license exposure
quickly
works, adds value adds some value doesn’t add much

value
NFRS must also be tested Agile Software
Requirements
Dean Leffingwell
Often requires Agile Software Development Series
specialty skills
Series Editors
and tools Constrained by Nonfunctional

Backlog Item 0..* 0..* Requirements
May also be Compliant when
passes
1..*
province of Is one of
0..*
system team System Qualities Tests
Feature
1
0,1 1..*
Story 1 1..*
Task
1 1
Done when
passes
1..*
Acceptance Test
NFR

NFRs in the Agile Testing Matrix Agile Software
Requirements
Dean Leffingwell
Automated
Manual
& Manual

Series Editors
Automated Tools
Source: Brian Marick; Crispen and Gregory:

Agile Testing, Leffingwell: Agile Software
Requirements © 2010 Leffingwell and, LLC. and Ryan Shriver
Sources of Nonfunctional Requirements Agile Software
Requirements
Dean Leffingwell

Series Editors
Source: Wikipedia

Persisting Nonfunctional Requirements Agile Software
Requirements
Dean Leffingwell
  Create a special backlog in your agile project

management tool Agile Software Development Series

Series Editors
  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
Nonfunc'onal Requirements in the Big Picture
©2009 Leffingwell, LLC.
H H
H H

Agile Software
Requirements
Dean Leffingwell

Series Editors
Today’s Exercise:
IDENTIFYING AND
QUANTIFYING QUALITIES

Today You Will Learn How To Agile Software
Requirements
Dean Leffingwell

Series Editors
  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

Exercise Background Agile Software
Requirements
Dean Leffingwell
  Objective
–  Identify highest priority quality improvements

Series Editors
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
29
Important Concept: Ends vs. Means Agile Software
Requirements
Dean Leffingwell
Levels of Concern
Series Editors
Organization Ends
Objectives
Exercise Focus
Means Ends
Product Products,
Qualities
Features
Means
Design Design,
Architecture

Page 1
Instruc'ons Stakeholders Quali'es
Stakeholders are the en..es we’re trying to Quali.es reflect “how well” the product
deliver value to by building a product performs, not “what” func.ons it performs
1.  Pair up with a partner and spend 2
minutes brainstorming a list of Examples: Business Sponsor, Customer, User,
Examples: Usability, Responsiveness,
stakeholders Opera.ons
Throughput
2.  Next, with your partner spend 2

minutes iden=fying the top 2
quali=es for improvement for the
most important stakeholder

Right Qualities for Software Agile Software
Requirements
Dean Leffingwell
  Functionality
–  Features, User Stories, Capabilities, Security

Series Editors
  Usability
–  Human factors, Aesthetics, Consistency, Documentation
  Reliability
–  Availability, Recoverability, Accuracy
  Performance
–  Responsiveness, Throughput, Scalability
  Supportability
–  Maintainability, Testability, Extensibility, Adaptability, Serviceability,
Configurability, Portability, Compatibility
Source: FURPS model developed at Hewlett-Packard and documented by Robert Grady and
Deborah Caswell in Software Metrics: Establishing a Company Wide Program (1987)
Requirements
Dean Leffingwell

Series Editors
  Identify the right qualities

  Quantify them for clarity


How to Define a Quality Agile Software
Requirements
Dean Leffingwell
Name: In the form Quality.SubQuality

Series Editors
Step 1 Scale: What to measure (units)

Meter: How to measure (method)
Target: Success level to achieve

Step 2 Constraint: Failure level to avoid
Baseline: Current level
Optional Elements
Definitions: To clarify terminology and meaning
[Qualifiers]: Specificity and Reusable Scales
<- Sources: Additional transparency and credibility
Source: Based on Planguage from Competitive Engineering by Tom Gilb

Real Product Examples – Step 1 Agile Software
Requirements
Dean Leffingwell
Name: Usability.Efficiency
Scale: Number of Actions to complete a Transaction from a Location Agile Software Development Series

Series Editors
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
Alternative Syntax
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

Page 2 Quality Defini'on Quality
Step 1: Iden'fy name, appropriate scale of measure and method of Name:
measuring
Name: In the form Quality.SubQuality Scale:

Scale: What to measure (units)
Step 2: Establish Baseline and set appropriate targets and constraints Meter:
Constraint: Failure level to avoid
Baseline Constraint Target
[Qualifiers]: Specificity and Reusable Scales
<-‐ Sources: Addi=onal transparency and credibility
Defini'ons: To clarify terminology and meaning
Quality Example Quality

Name: Usability.Efficiency Name:
Scale: Number of Ac=ons to complete a Transac=on from the
Home Page Scale:
Meter: Average observed results from usertes=ng.com
usability tests
Ac=ons: One of {Data entry, Scroll, Click}. Default is All. Meter:
Transac=on: One of {Registra=on, Purchase}
Baseline Constraint Target Baseline Constraint Target

[Registra=on; 2010]: [Registra=on; 2011]: [Registra=on; 2011]:
80 72 <-‐ 10% 48 <-‐ 40%
[Purchase; 2010]: 60 improvement improvement
[Purchase; 2011]: 54 [Purchase; 2011]: 42
<-‐ 10% improvement <-‐ 30% improvement
Baselines Agile Software
Requirements
Dean Leffingwell
Common methods for establishing Baseline levels


Series Editors
include
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

Targets and Constraints Agile Software
Requirements
Dean Leffingwell
Common methods for establishing Target and Agile Software Development Series
Constraint levels include

Series Editors
Method Description
Improvement from the Baseline Plan a 20% - 40% improvement over
current levels by next year
Comparison with Leading Benchmarking yourself against leading

Competitors competitors and setting levels based on
their capabilities
Comparison with your Industry Benchmarking yourself against your

Leaders industry leaders, such as trying to be in
Gartner’s Magic Quadrant
Comparison with other Industry Benchmarking yourself against other

Leaders industries known for great levels of quality,
such as Nordstrom’s customer service
Visualizing Qualities Agile Software
Requirements
Baselines, Targets and Constraints exist along a continuum

Dean Leffingwell
Constraint / Baseline Target


Series Editors
Fail Improvement Success
0% 100%
Constraint Baseline Target
0% 30% 100%
-20% 0% 100%
Real Product Examples – Steps 1 & 2 Agile Software
Requirements
Dean Leffingwell
Name: Usability
Scales:
Efficiency: Number of Actions to complete a Transaction from a Location Agile Software Development Series

Series Editors
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
Baseline:
Efficiency [eCommerce; Release 1]: 103 actions <- Average of 10 usability tests
Conversion [eCommerce; Q4 2009 – Q2 2010]: 0.37% <- Current state
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

Page 2 Quality Defini'on Quality
Step 1: Iden'fy name, appropriate scale of measure and method of Name:
measuring
Name: In the form Quality.SubQuality Scale:

Scale: What to measure (units)
Step 2: Establish Baseline and set appropriate targets and constraints Meter:
Constraint: Failure level to avoid
[Qualifiers]: Specificity and Reusable Scales
<-‐ Sources: Addi=onal transparency and credibility
Defini'ons: To clarify terminology and meaning
Quality Example Quality

Name: Usability.Efficiency Name:
Scale: Number of Ac=ons to complete a Transac=on from the
Home Page Scale:
Meter: Average observed results from usertes=ng.com
usability tests
Ac=ons: One of {Data entry, Scroll, Click}. Default is All. Meter:
Transac=on: One of {Registra=on, Purchase}
Baseline Constraint Target Baseline Constraint Target

[Registra=on; 2010]: [Registra=on; 2011]: [Registra=on; 2011]:
80 72 <-‐ 10% 48 <-‐ 40%
[Purchase; 2010]: 60 improvement improvement
[Purchase; 2011]: 54 [Purchase; 2011]: 42
<-‐ 10% improvement <-‐ 30% improvement
Requirements
Dean Leffingwell

Series Editors
  Identify the right qualities

  Quantify them for clarity


Impact Estimation Agile Software
Requirements
Dean Leffingwell
Estimating the impact of means (designs, architecture) on

ends (qualities) to determine the best “bang for the buck” Agile Software Development Series

Series Editors
Impact estimation spreadsheet available from theagileengineer.com

Agile Software
Requirements
Dean Leffingwell

Series Editors
THANK YOU

Nonfunctional Requirements (System Qualities) Agile Style: by Dean Leffingwell and Ryan Shriver Agile 2010 Orlando, FL

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Nonfunctional Requirements (System Qualities) Agile Style: by Dean Leffingwell and Ryan Shriver Agile 2010 Orlando, FL

Hochgeladen von

Copyright:

Verfügbare Formate

Agile Software

Nonfunctional Requirements Agile Software Development Series

(System Qualities) Agile Style

and Ryan Shriver

Alistair Cockburn and Jim Highsmith,

© 2010 Leffingwell and, LLC. and Ryan Shriver

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

© 2010 Leffingwell and, LLC. and Ryan Shriver 2

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

© 2010 Leffingwell and, LLC. and Ryan Shriver 3

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

The first 90% of the code takes 90% of

© 2010 Leffingwell and, LLC. and Ryan Shriver 4

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

There can be a large number of Dean Leffingwell

teams in the enterprise

Alistair Cockburn and Jim Highsmith,

“pods” of 5-10 teams building a

feature, component, or subsystem

Some product lines require

However, the structure of each

© 2010 Leffingwell and, LLC. and Ryan Shriver

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

“As a Gmail user, I can select and highlight

© 2010 Leffingwell and, LLC. and Ryan Shriver

Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

Fixed Time (Iteration)

© 2010 Leffingwell and, LLC. and Ryan Shriver 8

backlog Dean Leffingwell

There is only one backlog Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

for the team Backlog Item

All work comes from the

If isn't a user story (defect,

“If there isn’t a story in the

© 2010 Leffingwell and, LLC. and Ryan Shriver

Teams perform unit testing

Alistair Cockburn and Jim Highsmith,

The details of the story go

Stories are temporal (not 1..*

maintained after Acceptance Test

Unit Test Functional Test

© 2010 Leffingwell and, LLC. and Ryan Shriver

 Assume a program requires Agile Software Development Series

Alistair Cockburn and Jim Highsmith,

– 200 practitioners, (25 agile teams) to deliver a product

Alistair Cockburn and Jim Highsmith,

can <activity> so that <business value>”, can do

what Features does the system offer to its user

© 2010 Leffingwell and, LLC. and Ryan Shriver 12

Product & Release Cycle

Feedback Develop &

© 2010 Leffingwell and, LLC. and Ryan Shriver 13

pattern Dean Leffingwell

  Assume a program requires Agile Software Development Series

–  200 practitioners, (25 agile teams) to deliver a product

  Create a special backlog in your agile project

  Put them on a wiki or other project repository

  Sources, Examples and Templates:

  Identify the right qualities

  Quantify them for clarity

2.  Next, with your partner spend 2

  Identify the right qualities

  Quantify them for clarity