Case Studies in Just-in-Time Requirements Analysis


Published on

Many successful software projects do not follow the commonly assumed best practice of engineering well- formed requirements at project inception. Instead, the require- ments are captured less formally, and only fully elaborated once the implementation begins, known as ‘just-in-time’ require- ments. Given the apparent disparity between best practices and actual practices, several questions arise. One concerns the nature of requirements engineering in non-traditional forms. What types of tools and practices are used? Another is formative: what types of problems are encountered in just-in- time requirements, and how might we support organizations in solving those problems? In this paper we conduct separate case studies on the requirements practices of three open-source software projects. Using an individual task as the unit of analysis, we study how the project proceeds from requirement to implementation, in order to understand how each project manages requirements. We then comment on the benefits and problems of just-in-time requirements analysis. This allows us to propose research directions about requirements engineering in just-in-time settings. In particular, we see the need to better understand the context of practice, and the need to properly evaluate the cost of decisions. We propose a taxonomy to describe the requirements practices spectrum from fully formal to just-in-time.

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Case Studies in Just-in-Time Requirements Analysis

  1. 1. Case Studies In JIT Requirements Analysis Neil Ernst and Gail Murphy University of British |
  2. 2. Just-In-Time Requirements practices are different yet effective
  3. 3. “Traditional” RERequirements team separate and siloed, “transom-style” handoffs 3
  4. 4. “Traditional” RETypically (if not ideally) done once, at inception 4
  5. 5. “Traditional” REStore artifacts in management tool 5
  6. 6. Pejoratively called:Big Requirements Up Front 6
  7. 7. Just-in-time REassume change and react, rather than planRE is ongoing and continuouslightweight and iterative (?)developers talk to “Product Owner” e.g. specification by example, behavior- driven development (BDD), feature driven development, user stories, acceptance testing. 7
  8. 8. Research Questions1. How does JIT RE manifest itself in practice? 2. What problems might be encountered? 8
  9. 9. MethodologyChoose 3 software projects that are successful, relativelydistinct and open*.Study each project’s software process holistically, starting atthe task level.Choose a representative requirement for detailed study. 9
  10. 10. Flexible Indexing Inverted index: terms point to containing documentsFlexible indexing: add frequency, weights, boosts directly to index 10
  11. 11. 2004: Idea proposed on wiki (Doug Cutting)2006: Email discussion about implementation (GrantIngersoll)2008: First JIRA ticket created (Michael McCandless)2009: Feature progress misses release 2.9; code laterreleased for stress testing by others (McCandless)2009: Unicode incompatibility detected (Robert Muir)2010: Feature branch integrated into trunk (all)2012: Feature ships as 4.0 Alpha
  12. 12. “ "Have you tried any actual tests swapping these approaches in as your terms index impl?” “No – changing something like this requires a lot ofcoding, so its better to do thought experiments first to winnow down the options."“ Mike, this change to byte[ ] in TermRef will break backwards compatibility, without some special attention paid to the utf-16 to utf-8 conversion.“In my opinion it would be better to think in the future how we can improve lucene in the following ways: The term dictionary should be more "DFA-friendly", [etc.]
  13. 13. Observations (Lucene)• Requirements arise organically. Never nailed down.• Strategic vision emergent rather than directed. No hard deadlines.• JIRA is central to RE process.• Detailed knowledge lives inside the developer/requester. 13
  14. 14. Common Practices (JIT In Practice)• Just-in-Time Requirements• Feature-oriented• As-needed Traceability• Exploratory and iterative development• Community-mindedness 14
  15. 15. Departures• No big-picture thinking• No separate prioritization• Unclear feature provenance• No repeatable elicitation or reuse 15
  16. 16. Understanding RE Practices ReflectiveRequirements+Analysis Multiple dimensions CONNECT Firefox Simple Priority Lucene Ad-hoc Personal)projects Ad-hoc List Links Models Req Spec Requirements+Management 16
  17. 17. But ... “I chose RE as a research area [after seeing] that insufficient RE causes inconsistent, incomplete andincorrect requirements specifications and is responsible for a significant number of problems encountered in development projects.” – Klaus Pohl, preface to RE textbook 17
  18. 18. Ultimate Empirical Question Diminishing RE return Idealized RE Reality? Software Value Perception Amount of RE 18
  19. 19. Related Work• Plenty of industry focus: • Leffingwell, Agile Manifesto, Agile BABOK, BDD etc.• Social nature of RE in OSS explored by Walter Scacchi.• Emmanuel Letier exploring requirements prediction.• Marco Lormans and Arie Gurfinkel worked on requirements coverage. 19
  20. 20. Just-In-Time Requirements practices are different yet effective when? how? why? Neil Ernst • @neilernst • 20