Case Studies in Just-in-Time Requirements Analysis
20
Case Studies In JIT Requirements Analysis Neil Ernst and Gail Murphy University of British Columbia [email protected] | [email protected]
-
Upload
neil-ernst -
Category
Technology
-
view
1.314 -
download
0
description
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.
Transcript of Case Studies in Just-in-Time Requirements Analysis
Case Studies In JIT Requirements
Analysis
Neil Ernst and Gail MurphyUniversity of British Columbia
Just-In-Time Requirements practices are different yet effective
“Traditional” RE
3
Requirements team separate and siloed, “transom-style” handoffs
“Traditional” RE
4
Typically (if not ideally) done once, at inception
“Traditional” RE
5
Store artifacts in management tool
6
Pejoratively called:Big Requirements Up Front
Just-in-time RE
e.g. specification by example, behavior-driven development (BDD), feature driven development, user stories, acceptance testing.
lightweight and iterative (?)
7
developers talk to “Product Owner”
assume change and react, rather than plan
RE is ongoing and continuous
Research Questions
1. How does JIT RE manifest itself in practice?
2. What problems might be encountered?
8
Methodology
Choose 3 software projects that are successful, relatively distinct and open*.
Study each project’s software process holistically, starting at the task level.
Choose a representative requirement for detailed study.
9
Flexible Indexing
10
Inverted index: terms point to containing documentsFlexible indexing: add frequency, weights, boosts directly to
index
2004: Idea proposed on wiki (Doug Cutting)
2006: Email discussion about implementation (Grant Ingersoll)
2008: First JIRA ticket created (Michael McCandless)
2010: Feature branch integrated into trunk (all)
2012: Feature ships as 4.0 Alpha
2009: Feature progress misses release 2.9; code later released for stress testing by others (McCandless)
2009: Unicode incompatibility detected (Robert Muir)
"Have you tried any actual tests swapping these approaches in as your terms index impl?”
“No – changing something like this requires a lot of coding, so it's 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.]
“
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
Common Practices (JIT In Practice)
• Just-in-Time Requirements
• Feature-oriented
• As-needed Traceability
• Exploratory and iterative development
• Community-mindedness
14
Departures
• No big-picture thinking
• No separate prioritization
• Unclear feature provenance
• No repeatable elicitation or reuse
15
Understanding RE Practices
Ad-hoc List Links Models Req Spec
Ad-hoc
Simple Priority
Multiple dimensions
Reflective
Requirements+Management
Requ
iremen
ts+Ana
lysis
Personal)projects
Firefox
Lucene
CONNECT
16
But ...
“I chose RE as a research area [after seeing] that insufficient RE causes inconsistent, incomplete and
incorrect requirements specifications and is responsible for a significant number of problems encountered in
development projects.” – Klaus Pohl, preface to RE textbook
17
Ultimate Empirical Question
Amount of RE
Softw
are V
alue
Idealized RE
Perception
Reality?
Diminishing RE return
18
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
20Neil Ernst • @neilernst • neilernst.net
Just-In-Time Requirements practices are different yet effective
when? how?why?
