• Save
13 Continuous and Collaborative Validation: A Field Study of Requirements Knowledge in Agile
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

13 Continuous and Collaborative Validation: A Field Study of Requirements Knowledge in Agile

on

  • 1,757 views

 

Statistics

Views

Total Views
1,757
Views on SlideShare
1,753
Embed Views
4

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 4

http://www.slideshare.net 4

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
  • User Stories User Story Checklist High Level Test Cases Unit Test Cases Code Acceptance Test Cases Conversations

13 Continuous and Collaborative Validation: A Field Study of Requirements Knowledge in Agile Presentation Transcript

  • 1. Continuous and Collaborative Validation Rosalva E. Gallardo-Valencia and Susan Elliott Sim A Field Study of Requirements Knowledge in Agile University of California, Irvine MARK’09 - Second International Workshop on Managing Requirements Knowledge
  • 2.
    • Traditional definitions of Requirements Validation do not fit agile practices.
    • We performed a field site to study Agile Validation of written and live Requirements Knowledge.
    • How is Agile Validation of Requirements Knowledge performed?
      • It is done mainly through conversations around user stories, checklists, and test cases.
      • It is done before the iteration starts and during each iteration.
      • It is done in the context of each user story.
      • It is done by all team members.
    Summary
  • 3. What is Requirements Validation?
    • Requirements Validation has been defined as:
        • “ The process of evaluating software at the end of the software development process to ensure compliance with software requirements.” (Boehm, 1984)
    • This traditional definition works for projects where:
      • There is one main release on the project
      • Requirements are gathered up-front and stored in a specification document
    • These characteristics are not common in agile projects. But, requirements validation must still be done in some non-traditional way to meet customer needs.
  • 4. Research Question
    • How do agile projects perform validation without comprehensive documentation, and up-front requirements?
  • 5. Field Study - Method
    • Used qualitative research methods to collect and analyze the data.
    • Observed an agile team at work for two days.
      • Including daily stand-up meeting and Sprint Planning Meeting.
      • We also collected software artifacts.
    • Conducted 6 semi-structured interviews that lasted between 30-68 minutes.
  • 6. Field Site - Easy Retirement
    • Internet-based 401k service provider.
    • Main product: Web application that allows individuals to manage their own retirement investment plans.
    • Software team: 1 Scrum Master, 1 Product Owner, 1 Technical manager, 7 programmers and testers.
    • Agile methods used: Scrum, daily stand-up meeting, user stories, continuous integration, on-site customer, and automated acceptance testing.
  • 7. Written and Live Requirements Knowledge
  • 8. Requirements Knowledge in Agile – Pre-Iteration Business People Scrum Master Product Owner Programmers Testers C |EMCV US = User Story 1.1 Request functionality - |E-C- 1.2 Talk about functionality C |E-C- 1.3 Present requested functionality C |--C- 1.4 Ask questions and identify sw pieces C |-MCV Brainstorming Meeting 1.5 Ask for estimation of US C |-M-- Iteration Prioritization Meeting 1.6 Ask for priority of US C |EM-- 1.7 Ask for details and satisfaction conditions C |E-CV US Checklists 1.8 Fill out - |-M-- 1.9 Ask questions, if needed C |E-CV
  • 9. Requirements Knowledge in Agile – Iteration Planning Business People Scrum Master Product Owner Programmers Testers C |EMCV Iteration Planning Meeting US = User Story 2.3 Ask questions to determine tasks C |-MCV - |-MC- USs 2.2 Create 2.1 Explain USs C |--C- C |-MCV 2.4 Coordinate tasks and test cases needed -|-MC- Task Cards 2.5 Create Test Cards 2.5 Create
  • 10. Requirements Knowledge in Agile – Intra-Iteration Business People Scrum Master Product Owner Programmers Testers C |EMCV US = User Story C |-MCV 3.2 Ask questions about functionality - |-MC- High Level Test Cases 3.1 Write C |E-CV 3.3 Ask questions, if needed 3.4 Update - |-MC- - |-MC- Acceptance Test Cases 3.5 Write C |-MCV 3.6 Ask questions about functionality C |E-CV 3.7 Ask questions, if needed 3.8 Ask for background info about functionality C |--C- - |--C- High Level Test Cases 3.9 Read C |E-CV 3.11 Ask questions, if needed C |-MCV 3.10 Ask questions about functionality - |---- Unit Test Cases 3.12 Write - |---- Code 3.13 Write - |---V Acceptance Test Cases 3.14 Run C |--C- 3.15 Give feedback about Acceptance Test Cases
  • 11. Agile Validation is Continuous
    • Validation takes place before and during each iteration.
    Written and live knowledge used to validate requirements - Conversations between Testers and PO, PO and Business People, and Programmers and PO. Acceptance Test Cases Intra-Iteration - Conversations between Programmers and PO, and Testers and PO. - Conversations between Programmers and Testers. - Iteration Planning - Conversations between Programmers and PO, and Testers and PO. - Conversations between PO and Business People. - Pre-Iteration Live Knowledge Written Knowledge Stage
  • 12. Agile Validation is Continuous
    • Within an iteration, user stories are validated individually.
      • Shared understanding of the user story.
      • A user story is validated when:
        • It is discussed.
        • It is broken down into tasks and tests.
        • It is written on index cards.
        • High level test cases are created.
        • Acceptance test cases are run.
  • 13. Agile Validation is Collaborative
    • Every member of the development team is responsible for validation.
    • Members ask questions to make sure they have the correct understanding.
    • The Product Owner, Programmers, and Testers can trigger validation and also validate requirements.
    • If the Product Owner misses some details, these could be discovered later in the iteration by other team members.
  • 14. Implications
    • For practitioners of agile
      • Think about test cases and acceptance criteria during requirements elicitation.
      • Encourage question asking.
      • Write test cases even for the obvious success scenarios.
    • For researchers
      • Broaden the definition of validation to include activities that ensure that a software system is being built to the customer’s satisfaction in the absence of a specification document.
  • 15. Future Work
    • Analyze interview data from two other field sites.
    • Compare and contrast requirements knowledge and agile validation among the three field sites.
    • Look for companies that use agile practices and observe their software team.
  • 16.
    • Traditional definitions of Requirements Validation do not fit agile practices.
    • We performed a field site to study Agile Validation of written and live Requirements Knowledge.
    • How is Agile Validation of Requirements Knowledge performed?
      • It is done mainly through conversations around user stories, checklists, and test cases.
      • It is done before the iteration starts and during each iteration.
      • It is done in the context of each user story.
      • It is done by all team members.
    Summary
  • 17. Questions? Thanks