Case studies in just-in-time requirements analysis
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
Many successful software projects do not follow the commonly assumed best practice of engineering well-formed requirements at project inception. Instead, the requirements are captured less formally, and only fully elaborated once the implementation begins, known as `just-in-time' requirements. 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-intime 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.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it