0002: A case meets the reader's checklist of Runeson 2009
Decision: a case here is an experience report with repository measures, held to the 12-item reader's checklist of Runeson 2009, with a program for every count a program can take.
Status: accepted, 2026-11-02. Shape: decision record.
Context
- The first job was to name the published guideline a case must meet. The review found three candidates (baseline).
- The community standard for case studies excludes the experience report from its scope, and a case here is written by those who took part (Ralph 2020).
- The repository's name says case; the field's name for the genre is experience report, with a historical part from repositories.
Decision
- The baseline is the reader's checklist of Runeson 2009, items 39 to 50. A case answers each item, met or not met with a reason.
- The genre is stated in every case. The repository keeps its name.
- Measures from a history come from a program with a test, and print their cautions beside them. A hand count is marked.
- The shape of a case, shapes/case.md, is derived from the checklist.
Options that lost
| Option | Why it lost |
|---|---|
| The Case Study standard of Ralph 2020 alone | it excludes experience reports, and asks for observation the writers cannot give |
| The experience-report criteria of ICSE 2003 alone | a conference call, with no item on chain of evidence or validity |
| A medical checklist (Gagnier 2013, Tate 2016) | a different field; used by analogy for the idea of a timeline and a fixed list |
Consequences
- A case can be audited item by item, and a reader sees where triangulation is weak.
- Bad: the checklist assumes a researcher apart from the case. Item 48 stays hard for a report from inside, and the shape asks the author to say which sources were not independent.
- Bad: the grade is convention. No study shows the checklist makes a case more trusted.
- A later case can move to the Case Study standard if someone observes from outside; this record would be superseded then.