Requirements:
the Last Bottleneck
Bill Karwin
ZendCon • Santa Clara • 2010/11/3
Me
• Software developer
• C, Java, Perl, PHP, Ruby
• SQL maven
• Author of new book
SQL Antipatterns
cost
the greatest single cost
in producing software is
programmer time
code faster!
Tools for reducing programmer time
• Dynamic languages
• Lots of functions
• OO design
• Code reuse
• Code generation
• ID...
• Tools help productivity for coding and
error removal
• But not so much for requirements
management
Error removal is the most time-
consuming part of development
Facts and Fallacies of Software Engineering, Robert L. Glass
Cost to fix a defect
Software Requirements, Karl E.Wiegers
Code Complete, Steve McConnell
code faster?
code less!
Front-load the project
Facts and Fallacies of Software Engineering, Robert L. Glass
managing requirements
reduces project cost
so why don’t we do it?
“We practice
Agile Development, so we
don’t need requirements.”
Really?
Agile Manifesto?
Principle #2:
“Welcome changing requirements,
even late in development.”
http://www.agilemanifesto.org/
Test-Driven Design?
“TDD is very good at detailed specification and
validation, but not so good at thinking through
bigger ...
Extreme Programming?
Extreme Programming Explained: Embrace Change, Kent Beck
Coding
If you don’t code, you
haven’t done a...
Scrum?
• Product Backlog: the prioritized list of
desired project outcomes/features
http://www.scrumalliance.org/learn_abo...
Repeat for each Agile iteration
“Every time the design
changes, we have to update
the requirements doc.”
“Requirements are not architecture.
Requirements are not design,
nor are they interface.
Requirements are need.”
The Pragm...
do not dictate the
implementation
in the requirements
Decoupling
• Familiar principle of OO design
• Interface vs. implementation
• Design patterns (Strategy, Bridge, etc.)
Decouple requirements from solutions
Solution 2
C#, .NET
Solution 1
Java, Spring
Solution 3
PHP
Require-
ments
☒
☑
☒
“How much detail
is enough?”
“If it takes more than 15 minutes to
determine what it is that you’re building,
the spec wasn’t done properly.”
Really?
• Imagine your boss has a great idea
• He’s going to describe his idea to you
• You’re to code it while he’s gone
• He has...
How much is enough?
• Probably a bit more than 15 minutes
• But not a whole book
• Focus on goals to satisfy, not design o...
“No one reads
requirements docs anyway.”
• Right—if the docs aren’t helpful
• Make the docs helpful to developers
• Describe what to build, not how
SMART goals
specific
measurable
achievable
results-oriented
timely
Specific
• Be concrete; use action verbs
• Users will have an intuitive experience using our
software.
• Users will be able...
Specific
• Also specify what the project does not need
• Support all browsers, full stop. It doesn’t matter
how obscure or ...
Measurable
• Describe testable or quantifiable goals
• The web site will work at web scale.
• The web site will serve up to...
Measurable
• Measure progress as well as final result
• The whole site must have no security issues.
• Certify that each ap...
Achievable
• Set goals that are feasible and possible;
stay appropriate to scope
• Our site will change the way people
com...
Results-oriented
• Describe outputs or results—not activities
• Developers will always strive to achieve optimal
performan...
Results-oriented
• Describe outputs or results—not activities
• The developers will use LAMP stack, REST
architecture, scr...
Time-related
• Use specific, realistic deadlines;
include milestones, schedule
• We need our web site to go live sooner rat...
Evaluation
• Often forgotten phase
• Testing is part of this of course
• Other review of how well you met the
requirements...
manage requirements
to develop more
efficiently
decouple requirements
from solutions
be SMART
SQL Antipatterns:
Avoiding the Pitfalls
of Database Programming
http://www.pragprog.com/titles/bksqla/
Copyright 2010 Bill Karwin
www.slideshare.net/billkarwin
Released under a Creative Commons 3.0 License:
http://creativecom...
Requirements the Last Bottleneck
Upcoming SlideShare
Loading in...5
×

Requirements the Last Bottleneck

3,166

Published on

Software developers love tools for coding, debugging, testing, and configuration management. The more these tools improve the How of coding, the more we see that we're behind the curve on improving the What, Why, and When. If you've been on a project that seemed vague, adrift, and endless, this talk can help. Make your projects run SMART.

Published in: Technology

Transcript of "Requirements the Last Bottleneck"

  1. 1. Requirements: the Last Bottleneck Bill Karwin ZendCon • Santa Clara • 2010/11/3
  2. 2. Me • Software developer • C, Java, Perl, PHP, Ruby • SQL maven • Author of new book SQL Antipatterns
  3. 3. cost
  4. 4. the greatest single cost in producing software is programmer time
  5. 5. code faster!
  6. 6. Tools for reducing programmer time • Dynamic languages • Lots of functions • OO design • Code reuse • Code generation • IDE’s • Frameworks • Source control • Test automation • Agile development
  7. 7. • Tools help productivity for coding and error removal • But not so much for requirements management
  8. 8. Error removal is the most time- consuming part of development Facts and Fallacies of Software Engineering, Robert L. Glass
  9. 9. Cost to fix a defect Software Requirements, Karl E.Wiegers Code Complete, Steve McConnell
  10. 10. code faster?
  11. 11. code less!
  12. 12. Front-load the project Facts and Fallacies of Software Engineering, Robert L. Glass
  13. 13. managing requirements reduces project cost
  14. 14. so why don’t we do it?
  15. 15. “We practice Agile Development, so we don’t need requirements.” Really?
  16. 16. Agile Manifesto? Principle #2: “Welcome changing requirements, even late in development.” http://www.agilemanifesto.org/
  17. 17. Test-Driven Design? “TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example).” Introduction toTest-Driven Design, Scott W.Ambler http://www.agiledata.org/essays/tdd.html
  18. 18. Extreme Programming? Extreme Programming Explained: Embrace Change, Kent Beck Coding If you don’t code, you haven’t done anything. Testing If you don’t test, you don’t know when you are done coding. Listening If you don’t listen you don’t know what to code or what to test. Design So you can keep coding and testing and listening indefinitely.
  19. 19. Scrum? • Product Backlog: the prioritized list of desired project outcomes/features http://www.scrumalliance.org/learn_about_scrum
  20. 20. Repeat for each Agile iteration
  21. 21. “Every time the design changes, we have to update the requirements doc.”
  22. 22. “Requirements are not architecture. Requirements are not design, nor are they interface. Requirements are need.” The Pragmatic Programmer: From Journeyman to Master,Andrew Hunt and David Thomas
  23. 23. do not dictate the implementation in the requirements
  24. 24. Decoupling • Familiar principle of OO design • Interface vs. implementation • Design patterns (Strategy, Bridge, etc.)
  25. 25. Decouple requirements from solutions Solution 2 C#, .NET Solution 1 Java, Spring Solution 3 PHP Require- ments ☒ ☑ ☒
  26. 26. “How much detail is enough?”
  27. 27. “If it takes more than 15 minutes to determine what it is that you’re building, the spec wasn’t done properly.” Really?
  28. 28. • Imagine your boss has a great idea • He’s going to describe his idea to you • You’re to code it while he’s gone • He has to leave in 15 minutes • Here’s his vision...
  29. 29. How much is enough? • Probably a bit more than 15 minutes • But not a whole book • Focus on goals to satisfy, not design or implementation
  30. 30. “No one reads requirements docs anyway.”
  31. 31. • Right—if the docs aren’t helpful • Make the docs helpful to developers • Describe what to build, not how
  32. 32. SMART goals
  33. 33. specific measurable achievable results-oriented timely
  34. 34. Specific • Be concrete; use action verbs • Users will have an intuitive experience using our software. • Users will be able to post textual content of 140 characters or fewer, and to search the content posted by others. ☒ ☑
  35. 35. Specific • Also specify what the project does not need • Support all browsers, full stop. It doesn’t matter how obscure or how old. • Test the browser brands/versions used by 97% of the target market. ☒ ☑
  36. 36. Measurable • Describe testable or quantifiable goals • The web site will work at web scale. • The web site will serve up to 10 million users; up to 10 thousand posting simultaneously; up to 500 thousand reading content stream. ☒ ☑
  37. 37. Measurable • Measure progress as well as final result • The whole site must have no security issues. • Certify that each application use case is secure. ☒ ☑
  38. 38. Achievable • Set goals that are feasible and possible; stay appropriate to scope • Our site will change the way people communicate on the web. • Our site will let users contribute bite-sized content and search the content stream by users, by lists of users, or by tags or trends. ☒ ☑
  39. 39. Results-oriented • Describe outputs or results—not activities • Developers will always strive to achieve optimal performance. • The landing page will respond in ~0.5 sec; other pages will respond in ~1.0 sec. ☒ ☑
  40. 40. Results-oriented • Describe outputs or results—not activities • The developers will use LAMP stack, REST architecture, scrum methodology, and git. • Don’t dictate technology choices, design, or methodology in requirements. ☒ ☑
  41. 41. Time-related • Use specific, realistic deadlines; include milestones, schedule • We need our web site to go live sooner rather than later. • Four weeks for design; three weeks for developing prototype; one week for performance testing; three weeks for refactoring; one week for final work and deployment. ☒ ☑
  42. 42. Evaluation • Often forgotten phase • Testing is part of this of course • Other review of how well you met the requirements • In Agile terms, delivery to customer • Spell out evaluation criteria in requirements
  43. 43. manage requirements to develop more efficiently
  44. 44. decouple requirements from solutions
  45. 45. be SMART
  46. 46. SQL Antipatterns: Avoiding the Pitfalls of Database Programming http://www.pragprog.com/titles/bksqla/
  47. 47. Copyright 2010 Bill Karwin www.slideshare.net/billkarwin Released under a Creative Commons 3.0 License: http://creativecommons.org/licenses/by-nc-nd/3.0/ You are free to share - to copy, distribute and transmit this work, under the following conditions: Attribution. You must attribute this work to Bill Karwin. Noncommercial. You may not use this work for commercial purposes. No Derivative Works. You may not alter, transform, or build upon this work.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×