- 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:
- 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
- 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.
-
- Design of an existing business process
-
- Define the upfront roadmap
- Over specification by "drilling down" into sub processes with
more DFDs.
- Tool: white board, CASE tools, Visio, etc.
- 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 )
- Analysis of system functions that are performed by which
actor
- Identification of usage requirements
- 16. Manage Users Use Case diagram
- 17.
- Model a bit ahead- focus on individual Use Cases for the first
release
-
- Business Process Diagram (BPM)
-
- Domain Model Diagram (DMD)
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
- Identifying the business process in an intuitive manner
- Document technical requirements
- 19. Register Appointment Business Process
- 20.
- 2. Data Modeling Diagram (DMD)- shows relationships between
entities within system, domain etc.
- Explore domain concepts with project stakeholders
- Complete data models up front!
- White board, Enterprise Architect, Visio, SmartDraw, etc.
- 21.
- 3. State diagram (SD)- describes the behavior of complex
object
- Analyze a complex business process
- Design the behavior of several objects
- Design the behavior of a simple object
- 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/