Your SlideShare is downloading. ×
0
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Case Studies in Just-in-Time Requirements Analysis
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Case Studies in Just-in-Time Requirements Analysis

1,371

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 …

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
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,371
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Case Studies In JIT Requirements Analysis Neil Ernst and Gail Murphy University of British Columbianernst@cs.ubc.ca | murphy@cs.ubc.ca
  • 2. Just-In-Time Requirements practices are different yet effective
  • 3. “Traditional” RERequirements team separate and siloed, “transom-style” handoffs 3
  • 4. “Traditional” RETypically (if not ideally) done once, at inception 4
  • 5. “Traditional” REStore artifacts in management tool 5
  • 6. Pejoratively called:Big Requirements Up Front 6
  • 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. Research Questions1. How does JIT RE manifest itself in practice? 2. What problems might be encountered? 8
  • 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. Flexible Indexing Inverted index: terms point to containing documentsFlexible indexing: add frequency, weights, boosts directly to index 10
  • 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. “ "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. 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. Common Practices (JIT In Practice)• Just-in-Time Requirements• Feature-oriented• As-needed Traceability• Exploratory and iterative development• Community-mindedness 14
  • 15. Departures• No big-picture thinking• No separate prioritization• Unclear feature provenance• No repeatable elicitation or reuse 15
  • 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. 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. Ultimate Empirical Question Diminishing RE return Idealized RE Reality? Software Value Perception Amount of RE 18
  • 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. Just-In-Time Requirements practices are different yet effective when? how? why? Neil Ernst • @neilernst • neilernst.net 20

×