requirements engineering in agile

24
Requirements Engineering in Agile Tricode Professional Services www.tricode.nl 28-05-2010 Madalina Cerchia

Upload: tricode

Post on 21-Nov-2014

2.333 views

Category:

Documents


5 download

DESCRIPTION

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

TRANSCRIPT

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