Requirements engineering in agile

2,554 views
2,361 views

Published on

The bottleneck has moved, developers are not the bottleneck. Requirements errors are the greatest source of defects and quality problems. Requirements engineering agile style.

Requirements engineering in agile

  1. 1. Requirements Engineering in Agile Tricode Professional Services www.tricode.nl 28-05-2010 Madalina Cerchia
  2. 2. <ul><li>Developers are NOT the bottleneck: </li></ul><ul><ul><li>Faster machines with Gigaspaces </li></ul></ul><ul><ul><li>Better languages: Java, Ruby, Scala </li></ul></ul><ul><ul><li>Better tools: IntelliJ, Eclipse </li></ul></ul><ul><ul><li>Better practices: Test-Driven Development, Pair Programming, SCRUM… </li></ul></ul><ul><li>Less rework- > more productivity </li></ul><ul><li>Lean thinking-> less code (1) </li></ul><ul><li>(1) Allan Kelly, “Changing Software” </li></ul>The bottleneck has moved
  3. 3. Bottleneck is Requirements <ul><li>Requirements errors are the greatest source of defects and quality problems </li></ul><ul><li>Most of errors originate in requirements and design activity </li></ul><ul><li>Only 5% originate in programming </li></ul><ul><li>Fixing requirements errors eats up roughly one-third (2) of your project budget </li></ul><ul><li>Requirements are NOT a document: </li></ul><ul><ul><li>Dialogue </li></ul></ul><ul><li>(2) Hooks and Farry 2001 </li></ul>
  4. 4. Scrum process <ul><li>Each iteration begins with good requirements </li></ul>
  5. 5. Requirements challenges in Agile
  6. 6. <ul><li>Challenge 1: Does the business know what it wants? </li></ul><ul><li> “ I’ll know it when I see it” </li></ul><ul><li>New domain </li></ul><ul><li>Highly innovative product </li></ul>
  7. 7. <ul><li>Challenge 2 : “Working software over comprehensive documentation” </li></ul><ul><li>Agile doesn’t mean that you don’t need requirements </li></ul><ul><li>Agile means you successively elaborate requirements </li></ul><ul><li>“ Just-Good-Enough” requirements </li></ul>
  8. 8. Challenge 3 : Dependencies between geographically distributed teams <ul><li>More difficult to coordinate work activities between teams </li></ul><ul><li>Does a User Story provide enough context? </li></ul>
  9. 9. <ul><li>Business, Analysts and Designers work a “Sprint” ahead of the development </li></ul><ul><li>Write Use Cases when it’s needed (alternative scenarios) </li></ul><ul><li>Development teams should coordinate their activities </li></ul>Possible solutions:
  10. 10. How to gather requirements -best practices-
  11. 11. <ul><li>Capture the “the Big-picture” </li></ul><ul><li>Artifacts: Data Flow Diagrams </li></ul>Agile practices to gather requirements (1/4)
  12. 12. <ul><li>Data Flow Diagram (DFD) - used to visualize the flow of data in a given context. </li></ul><ul><li>Common applications: </li></ul><ul><ul><li>Design of an existing business process </li></ul></ul><ul><ul><li>Define the upfront roadmap </li></ul></ul><ul><li>Common misapplications: </li></ul><ul><li>Over specification by &quot;drilling down&quot; into sub processes with more DFD’s. </li></ul><ul><li>Tool: white board, CASE tools, Visio, etc. </li></ul><ul><li>Example: </li></ul>
  13. 13. “ Order Processing” Data Flow
  14. 14. <ul><li>Identify Use Cases- define how the new product will work </li></ul><ul><li>UML Artifacts: Use Cases Diagram </li></ul>Agile practices to gather requirements (2/4)
  15. 15. <ul><li>Use Case Diagram (UCD) - graphical overview of the functionality provided by a system in terms of actors and their goals ( use case ) </li></ul><ul><li>Common applications: </li></ul><ul><li>Analysis of system functions that are performed by which actor </li></ul><ul><li>Common misapplications: </li></ul><ul><li>Identification of usage requirements </li></ul><ul><li>Example: </li></ul>
  16. 16. “ Manage Users” Use Case diagram
  17. 17. <ul><li>Model a bit ahead- focus on individual Use Cases for the first release </li></ul><ul><li>Artifacts: </li></ul><ul><ul><li>Business Process Diagram (BPM) </li></ul></ul><ul><ul><li>Domain Model Diagram (DMD) </li></ul></ul><ul><ul><li>State Diagram (SD) </li></ul></ul>Agile practices to gather requirements (3/4)
  18. 18. <ul><li>1. Business Process Diagram (BPD)- provides a notation that is intuitive to business users yet able to represent complex process semantics </li></ul><ul><li>Common applications: </li></ul><ul><li>Identifying the business process in an intuitive manner </li></ul><ul><li>Common misapplications: </li></ul><ul><li>Document technical requirements </li></ul><ul><li>Example: </li></ul>
  19. 19. “ Register Appointment” Business Process
  20. 20. <ul><li>2. Data Modeling Diagram (DMD)- shows relationships between entities within system, domain etc. </li></ul><ul><li>Common applications: </li></ul><ul><li>Explore domain concepts with project stakeholders </li></ul><ul><li>Common misapplications: </li></ul><ul><li> Complete data models up front! </li></ul><ul><li>Simple tool: </li></ul><ul><li>White board, Enterprise Architect, Visio, SmartDraw, etc. </li></ul>
  21. 21. <ul><li>3. State diagram (SD)- describes the behavior of complex object </li></ul><ul><li>Common applications: </li></ul><ul><li>Analyze a complex business process </li></ul><ul><li>Common misapplications: </li></ul><ul><li>Design the behavior of several objects </li></ul><ul><li>Design the behavior of a simple object </li></ul><ul><li>Example: </li></ul>
  22. 22. Application releases- state diagram
  23. 23. <ul><li>Preliminary design mockups prototyping </li></ul><ul><ul><li>document navigation, usability, look & feel without investing the time and money to develop the entire products </li></ul></ul><ul><li>Tools: Balsamiq Mockups, iRise </li></ul>Agile practices to gather requirements (4/4)
  24. 24. Useful resources <ul><li>http://www.agilemodeling.com/ </li></ul><ul><li>http://modernanalyst.com/ </li></ul><ul><li>http://www.omg.org/spec/UML/2.2/ </li></ul>

×