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.

1. Case Studies In
JIT Requirements
Analysis
Neil Ernst and Gail Murphy
University of British Columbia
nernst@cs.ubc.ca | murphy@cs.ubc.ca

2. Just-In-Time Requirements practices are
different yet effective

3. “Traditional” RE
Requirements team separate and siloed, “transom-
style” handoffs
3

4. “Traditional” RE
Typically (if not ideally) done once, at inception
4

5. “Traditional” RE
Store artifacts in management tool
5

6. Pejoratively called:
Big Requirements Up Front
6

7. Just-in-time RE
assume change and react, rather than plan
RE is ongoing and continuous
lightweight 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 Questions
1. How does JIT RE manifest itself in practice?
2. What problems might be encountered?
8

9. 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

10. Flexible Indexing
Inverted index: terms point to containing documents
Flexible indexing: add frequency, weights, boosts directly to
index 10

11. 2004: Idea proposed on wiki (Doug Cutting)
2006: Email discussion about implementation (Grant
Ingersoll)
2008: First JIRA ticket created (Michael McCandless)
2009: Feature progress misses release 2.9; code later
released 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 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.]

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
Reflective
Requirements+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 and
incorrect 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