Requirements engineering in agile
Upcoming SlideShare
Loading in...5
×
 

Requirements engineering in agile

on

  • 2,013 views

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

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

Statistics

Views

Total Views
2,013
Views on SlideShare
2,013
Embed Views
0

Actions

Likes
0
Downloads
54
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Requirements engineering in agile Requirements engineering in agile Presentation Transcript

    • Requirements Engineering in Agile Tricode Professional Services www.tricode.nl 28-05-2010 Madalina Cerchia
      • 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
    • 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
    • Scrum process
      • Each iteration begins with good requirements
    • Requirements challenges in Agile
      • Challenge 1: Does the business know what it wants?
      • “ I’ll know it when I see it”
      • New domain
      • Highly innovative product
      • Challenge 2 : “Working software over comprehensive documentation”
      • Agile doesn’t mean that you don’t need requirements
      • Agile means you successively elaborate requirements
      • “ Just-Good-Enough” requirements
    • Challenge 3 : Dependencies between geographically distributed teams
      • More difficult to coordinate work activities between teams
      • Does a User Story provide enough context?
      • Business, Analysts and Designers work a “Sprint” ahead of the development
      • Write Use Cases when it’s needed (alternative scenarios)
      • Development teams should coordinate their activities
      Possible solutions:
    • How to gather requirements -best practices-
      • Capture the “the Big-picture”
      • Artifacts: Data Flow Diagrams
      Agile practices to gather requirements (1/4)
      • 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 DFD’s.
      • Tool: white board, CASE tools, Visio, etc.
      • Example:
    • “ Order Processing” Data Flow
      • Identify Use Cases- define how the new product will work
      • UML Artifacts: Use Cases Diagram
      Agile practices to gather requirements (2/4)
      • 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:
    • “ Manage Users” Use Case diagram
      • 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)
      • 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:
    • “ Register Appointment” Business Process
      • 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.
      • 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:
    • Application releases- state diagram
      • 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)
    • Useful resources
      • http://www.agilemodeling.com/
      • http://modernanalyst.com/
      • http://www.omg.org/spec/UML/2.2/