Widely Adopted, Rarely Tested: The Effectiveness Evidence for Use Cases and User Stories

Abstract

Context. Use cases and user stories are among the most widely adopted requirements techniques in software engineering. Both were introduced from practice rather than derived from evidence, and both are now taught, tooled and expected as defaults.

Objective. To establish whether the widespread adoption of each technique is supported by evidence of its effectiveness. Research that extends a technique, or that measures what happens when it is applied one way rather than another, does not bear on that question: both presuppose the decision to adopt. What bears on it is evidence that adopting the technique produced an outcome that would not otherwise have occurred.

Method. We re-analyse two published datasets: the classification data of the largest systematic mapping of user story research (190 records, 2001-2021) and the complete primary-study list of a systematic mapping of use case impact in industry (47 studies, to 2018). We apply a tiered criterion to every study in the relevant subsets. Tier 1 requires that the study measure an effect of the technique on an outcome of interest. Tier 2 additionally requires a counterfactual: evidence that the outcome would have differed without the technique or with an alternative.

Results. The two cases fail differently, which is itself informative. On the user story side, 80.5 percent of mapped studies produce solution artefacts rather than knowledge about the technique; of the 15 studies the original authors classified as explanatory, six reach Tier 1 and none reaches Tier 2. Every Tier 1 study varies a property inside the technique, principally story quality or granularity, so what is measured is the effect of writing user stories differently, never the effect of using them. On the use case side the picture is stronger and different: 26 of 47 industrial studies reach Tier 1, overwhelmingly by measuring estimation accuracy against actuals, and exactly one reaches Tier 2, comparing use case point estimates against expert judgement. Both mappings also omit a body of evaluative work published in adjacent venues, and neither cites a 2009 mapping that aggregated 46 empirical evaluations of requirements specification techniques.

Conclusions. No, in both cases. Neither technique is unstudied, and on the use case side the measurement literature is substantial, but nearly all of it presupposes adoption. Across 237 studies, one tests the technique against a baseline in which it is absent; it was published in 2002 and concerns estimation. This result should be read as a lower bound: neither mapping’s classification scheme has a category for such a study, so we cannot exclude that others exist unretrieved. That limitation is itself a finding, and we relate it to the evidence-based software engineering agenda of 2004, of which the aggregation component was institutionalised while reporting standards were not.

Keywords: requirements engineering, use cases, user stories, empirical evaluation, evidence-based software engineering, tertiary study.

1. Introduction

Ask a requirements analyst why the team writes user stories, or use cases, and the answer is usually a version of “because that is how it is done here.” Both techniques are near-universal, taught, tooled and expected as defaults. This paper asks a single question: is that adoption supported by evidence that the techniques are effective?

Both techniques became standard without prior evaluation, and in both a research literature grew up afterwards. We examine each of those literatures in turn. Since the two emerged three decades apart, from different methodological traditions, and are studied by different communities under different secondary-study conventions, a pattern appearing in both is unlikely to be a property of either.

Our contributions:

1. A criterion for what would count as evidence supporting adoption, distinguishing it from the much larger body of work that presupposes adoption (Section 2).
2. A study-by-study re-analysis of two published datasets, one per technique, applying that criterion (Sections 5 and 6).
3. The answer, which is that one study across 237 qualifies (Section 7).
4. A qualification on that answer: the field’s aggregation machinery would not reliably surface such studies if they existed, so the count is a lower bound of uncertain tightness (Section 8).

2. What would count as evidence

Three claims are routinely treated as one.

Adoption is the extent to which a technique is used. Validation is evidence that it produces some benefit. Counterfactual evidence is evidence that the benefit would not have arisen otherwise.

Only the third supports a decision to adopt. The first supports nothing, though it is frequently offered as though it did.

Operationally we grade each study on two tiers.

Tier 1. The study empirically measures an effect of the technique, or of a variation within it, on an outcome specifiable in advance: estimation accuracy, requirements understandability, completeness, defect counts, cost of change, ease of test derivation, maintenance effort, or stakeholder agreement. Perceived benefit reported in a survey does not qualify; conformance of an artefact to its own template does not qualify, since template conformance is not an outcome of interest.

Tier 2. The study additionally establishes a counterfactual. The measured outcome is set against a baseline in which the technique is absent, replaced, or applied differently in a way that could have been chosen instead. The baseline need not be another named technique; expert judgement, an unaided condition, or an alternative representation all qualify. What is required is that the study could in principle have found the technique not to help.

Only Tier 2 bears on adoption. Tier 1 marks studies that measure something real, which is worth recording, but a Tier 1 result answers a question that begins after the decision to adopt has been made. A literature can be large, rigorous and entirely Tier 1, and in that case it tells us how the technique behaves without giving any reason to have chosen it. Everything below Tier 1 is further still from the question, and we grade it only to show how the corpora are composed.

We note that Tier 2 is demanding in software engineering for reasons that are not the field’s fault, and we return to this in Section 8.3.

3. Background

3.1. Two techniques, introduced the same way

Use cases were introduced by Jacobson in the late 1980s from work on Ericsson telecommunications systems, replacing a list of functions with scenarios of interaction between actor and system. Absorption into UML and the Rational Unified Process made the proposal a standard.

User stories emerged from Extreme Programming in the late 1990s with an anti-documentary claim: the card is a promise to converse, not a specification. The surviving artefact is the template popularised by Cohn in 2004; in the survey by Lucassen et al., 59 percent of respondents reported using it.

Neither was introduced on the basis of an evaluation. In both cases the sequence was experience, then a book, then diffusion, then research. This is unremarkable in itself. Many useful things are invented before they are explained. It is the reason the two make comparable cases.

3.2. The secondary literature

On user stories: Amna and Poels produced the broadest mapping, 2001-2021, whose dataset we re-analyse. Raharjana et al. reviewed NLP applications. Sporsem et al. synthesised 14 industry studies into five propositions, concluding that theoretical understanding of user story use in practice remains limited.

On use cases: Tiwari and Gupta reviewed 119 studies of use case specifications, 1992-2014, identifying roughly twenty distinct proposed templates. Barros-Justo, Benitti and Tiwari mapped industrial impact, selecting 47 primary studies from 4431 retrieved; their list we also re-analyse. El-Attar and Miller derived 21 anti-patterns from 84 studies. Qazi et al. reviewed use-case-based testing across 45 studies. Santos et al. examined variability description in textual use cases and report finding no experimental study comparing the identified templates for ease of use or comprehensibility.

Across requirements quality generally, Montgomery et al. screened 6905 papers and retained 105, observing that the artefacts studied are usually called simply “requirements,” with little work targeting concrete types.

A prior contribution deserves particular credit. Condori-Fernández et al. mapped empirical evaluation of software requirements specification techniques, categorising 46 primary studies, and found understandability the most commonly evaluated aspect, experiments the most common method, and academic environments the most common context. Published in 2009 in the empirical software engineering community, it is the closest existing aggregation of the evidence we set out to characterise. Neither of the two mappings we re-analyse cites it.

4. Method

A tertiary study with secondary re-analysis of two published datasets.

Dataset acquisition. Amna and Poels publish their classification dataset openly; we retrieved Clean datasource_SMS_4.xlsx and reproduced its distributions. Barros-Justo et al. publish their complete primary-study list as Appendix I, with per-study descriptions in their results sections; we extracted all 47 references.

Subset selection. For user stories we took the Explanation outcome class, defined by the original authors as studies explaining observed problems and practices or their effect on other variables, which is the class that could contain effect measurement. For use cases we took all 47, since that corpus is already restricted to industrial application and is small enough to classify exhaustively.

Classification. Each study was graded T0, T1 or T2 per Section 2. For the 15 user story studies we retrieved published abstracts and, where openly accessible, full texts. For the 47 use case studies we used the full references plus the per-study descriptions the original authors give in their results sections. Both classifications are supplied as supplementary files.

Supplementary search. We additionally searched outside both mappings for evaluative studies of either technique, using pre-declared queries and citation chaining, to test whether the mappings’ coverage is complete. This search is structured and reproducible but not database-driven; Section 9 states the consequences.

5. Case A: user stories

5.1. What the corpus contains

The published dataset holds 190 records; the paper reports 186 unique studies, and its percentages are consistent with a denominator of 190. We compute against 190.

The four artefact-producing classes total 153 studies, or 80.5 percent, against 37 producing Description or Explanation. This reproduces the split the original authors report. For our purposes these 153 are simply out of scope: a new algorithm for story point estimation or a new ontology for writing stories extends the technique and presupposes its use, so it cannot bear on whether the technique should be used. We note the proportion to show how little of the corpus could in principle answer our question, and proceed to the part that could.

By research type: Validation research 87 (45.8 percent), Proposed-of-solution 53 (27.9 percent), Evaluation research 50 (26.3 percent). These describe how thoroughly a contribution was assessed, not what kind of contribution it is. A validated new algorithm remains an algorithm.

Over time: 6 studies 2001-2007, 35 in 2008-2014, 149 in 2015-2021. The field is young and expanding rapidly.

5.2. The explanatory subset, graded

Fifteen studies, the earliest from 2014.

Six studies reach Tier 1. None reaches Tier 2.

The composition of the Tier 1 group is the substantive finding. Every one of the six varies something inside the technique: story quality in S52 and S151, granularity in S140, a supporting artefact in S164, the modeling task in S28. In S151, both groups receive user stories; one set is raw, the other improved using the QUS framework. What these studies measure is the effect of writing user stories differently. None measures the effect of using them.

S9 deserves separate comment because its title, “The use and effectiveness of user stories in practice,” promises what the corpus otherwise lacks. Its evidence is survey and interview data on perceived effectiveness, which we grade T0 not as a criticism of the study, which does not claim otherwise, but because perception is not the outcome a practitioner is deciding about.

6. Case B: use cases

6.1. What the corpus contains

Barros-Justo et al. selected 47 primary studies from 4431 retrieved, 5805 including snowballing, covering industrial application of use cases to September 2018. Their own classification: 22 studies (47 percent) evaluation research, 16 solution proposals, 9 experience reports. They identified eight advantage categories, most frequently estimation (18 studies), analysis (13) and automation (8), and four disadvantage categories, most frequently inconsistent scenario granularity and the absence of a standardised format.

This corpus differs from Case A in a way that matters. It was assembled specifically to find industrial impact, so it is pre-filtered towards studies that measured something in a real setting.

6.2. The corpus, graded

Twenty-six studies reach Tier 1. Twenty are T0. Exactly one reaches Tier 2.

The Tier 1 group is dominated by estimation. Fourteen of the twenty-six measure estimation accuracy against actuals: development effort, maintenance effort, test execution effort, test suite size, project size, cost. This is genuine outcome measurement with an unambiguous ground truth, and it is a stronger empirical base than anything in Case A. The remainder measure defect data from industrial use cases, comprehension and specification quality, test generation outcomes, or class elicitation.

The single Tier 2 study is SP11, Anda’s 2002 comparison of effort estimates derived from use case points against expert estimates. It qualifies because expert judgement is a baseline that could have been chosen instead, and the study could in principle have found use case points inferior. To our knowledge this is the only study in either corpus that puts the technique at risk of being found unhelpful.

6.3. The template problem

A separate pattern appears in the wider use case literature. Tiwari and Gupta identified roughly twenty distinct proposed templates across 119 studies, with template usability compared by a single study, conducted academically. Santos et al., mapping variability description in textual use cases, report that they found no experimental study comparing the nine templates they identified for ease of use or comprehensibility.

Twenty variants, one comparison. This is the proliferation-without-selection pattern that also characterises the 80.5 percent solution share in Case A, arriving by a different route.

6.4. Two observations from the original authors

Barros-Justo et al. report that none of their 47 selected papers offered access to raw data, which they state drastically reduced the possibility of replicating those studies. They also suggest in their conclusions that journal editors could influence authors by making a validity threats report a prerequisite for publication. Both bear directly on Section 8.

7. What the two cases share, and what they do not

7.1. They do not fail the same way

The temptation is to report a uniform absence. The data do not support it.

Case A has a small effect literature and no counterfactual literature. Case B has a substantial effect literature, anchored in estimation accuracy where ground truth is available, and a counterfactual literature of one study. Case A’s problem is that most research builds tools; Case B’s problem is that most research measures the technique’s outputs without ever asking what would have happened otherwise.

The corpora also differ in ways that limit direct comparison, and we do not draw one. Case B was pre-filtered for industrial impact, which raises its Tier 1 rate by construction and excludes the academic experiments where controlled designs concentrate. Case A covers a broader topical range and a longer recent period.

7.2. What they do share

Three things.

First, the counterfactual is missing in both. Across 237 studies in two corpora, one study tests the technique against a baseline in which it is absent. It was published in 2002.

Second, both corpora omit evaluative work published in adjacent venues. Our supplementary search located studies evaluating requirements notations in conceptual modeling, program comprehension and empirical software engineering venues, none of which appears in either mapping, and neither mapping cites the 2009 Condori-Fernández aggregation of 46 such evaluations. Both mappings are methodologically careful; the Barros-Justo team scored their protocol against Petersen’s rubric at 9 of 11. The omission is not carelessness.

Third, and connecting the first two: neither classification framework has a category for the study a practitioner would want. Amna and Poels classify by research outcome type, so a counterfactual evaluation is not an algorithm, model, framework, prototype, description or explanation in any natural way. Barros-Justo et al. classify by advantage and disadvantage category, which presupposes the technique was used and asks what followed. Neither scheme is wrong for its purpose. Both make the counterfactual question invisible, and they do so independently of each other.

8. Discussion

8.1. What the answer means

It does not mean either technique is ineffective. It does not mean the research is poor; much of it is careful, and the use case estimation literature in particular is a solid body of measurement.

It means the adoption of both techniques rests on something other than demonstrated benefit over not adopting them, and that the literature which grew up afterwards has largely not supplied that. Where effects are measured, they are the effects of variations within a practice already assumed.

For practitioners the implication is narrow but real. Publication counts are not evidence for adopting a technique, and neither is the existence of a large careful literature, if that literature never asks the question being decided.

8.2. Why the count is a lower bound

The 2004 EBSE paper proposed three infrastructure elements: a methodology for aggregating empirical results, guidelines for conducting and reporting studies, and packaging of evidence for practitioners.

The first was institutionalised thoroughly. The Keele guidelines of 2007 and the mapping methodology of Petersen et al. are standard, and both datasets we re-analyse were produced under them.

That is why our answer needs a qualification. Aggregation inherits whatever the primary literature makes findable, and a literature with no convention for declaring what was manipulated, what the baseline was, and what outcome was pre-specified does not make counterfactual studies findable. No amount of rigour in the review recovers what the search cannot see. Barros-Justo et al. report the same problem from inside their corpus: no raw data in any of 47 studies. Our count of one is therefore a lower bound, and we cannot say how tight a bound it is.

In clinical research the reporting standard preceded useful aggregation for exactly this reason. CONSORT did not improve individual trials; it made their designs legible, and legibility is what distinguishes a systematic review from a count. Software engineering built the aggregation half first and has run it on unstructured input for two decades.

8.3. The counterfactual is genuinely hard here

We do not want to present Tier 2 as a standard the field has lazily declined to meet.

Kitchenham, Dybå and Jørgensen named two obstacles specific to the domain. Individual differences in developer ability are large enough to swamp a method’s effect, in a way that clinician skill does not swamp a drug’s effect. And a technique’s consequences often appear years later in maintenance cost, while studies run for weeks, so what gets measured is what fits inside a study.

A counterfactual test of a requirements technique requires withholding it from a comparable project, which is expensive, ethically awkward in industry, and confounded by exactly the ability differences Kitchenham identified. The single Tier 2 study we found sidesteps this by using estimation, where a baseline method exists and ground truth arrives on its own schedule. That is likely why the only counterfactual in either corpus is an estimation study, and it suggests where further ones could be found.

8.4. A request made three times

The mechanism that worked in clinical research was journal policy. It has been requested in software engineering at least three times by independent teams.

In 2002, Kitchenham and colleagues closed their empirical research guidelines by asking journal editorial boards to convert the recommendations into reviewer guidelines and publication policy.

In 2019, Barros-Justo, Benitti and Tiwari suggested that journal editors could require a validity threats report as a prerequisite for publication.

In 2020, Dalpiaz and Sturm called for evaluating requirements notations across tasks and providing evidence for notation selection, which presupposes a literature in which such evaluations are declarable and findable.

None produced a general standard. We note the recurrence over eighteen years without claiming to explain it; the obstacle is evidently not that the idea has gone unstated.

9. Threats to validity

Construct validity. The tiering is ours. Tier 2 in particular could be drawn more permissively, for example by admitting within-technique manipulations as counterfactuals, which would move several Case A studies. We regard the distinction between varying a practice and testing whether to adopt it as the one a practitioner needs, but the choice is contestable and the raw classifications are supplied so it can be redrawn.

Internal validity, Case A. Classification used published abstracts and, where openly accessible, full texts. Several of the fifteen remain behind paywalls and were graded from abstract and metadata.

Internal validity, Case B. This is the weaker classification. We used full references plus the per-study descriptions the original authors give in their results sections, not the primary texts. Tier 1 grading of the estimation studies is safe, since estimation accuracy is what those studies do. Grading of the remaining categories is less certain, and a missed Tier 2 study cannot be excluded. Full-text verification of the 47 is the necessary next step.

Corpus non-equivalence. The two corpora were assembled for different purposes, so their tier rates are not commensurable. Case B is pre-filtered for industrial application, which raises its Tier 1 rate by construction and excludes the academic experiments where controlled designs concentrate.

Search completeness. Section 7.2 rests on a structured but not database-driven search, conducted with a general web search engine rather than through Scopus, IEEE Xplore, ACM DL, Web of Science and Springer with exportable result sets. It suffices to show that both mappings omit relevant work; it cannot support a count of how much. We note the irony of this limitation in a paper about reporting standards and state it plainly rather than describing the search as systematic.

Reliability. Classification was performed by one rater without a second coder; no inter-rater agreement is available. Both classified subsets are supplied so the grading can be repeated and disputed.

Attribution. Sections 7.2, 8.2 and 8.4 offer mechanisms and observations, not findings. We had no access to screening records or editorial decisions.

External validity. Each re-analysis inherits its mapping’s limitations: search strings, venue coverage, English-language restriction, and cut-offs at 2018 and 2021 respectively.

Dataset discrepancy. The user story dataset contains 190 records against 186 unique studies reported in the paper; we could not resolve this, and no duplicate titles are present. The use case paper reports removing one duplicate from an initial 48. Neither affects the graded subsets.

10. Conclusion

The question was whether the widespread adoption of use cases and user stories is supported by evidence that they are effective. The answer, in both cases, is no.

This is not because the techniques are unstudied. Two systematic mappings hold 237 studies between them, and much of that work is careful. But nearly all of it presupposes the decision to adopt. On the user story side most of the corpus builds tools for the technique, and the six studies that measure an effect measure the effect of writing user stories differently. On the use case side there is a substantial body of measurement, concentrated in estimation accuracy where ground truth is cheap, but it measures what follows from using the technique rather than whether using it helped.

One study across the 237 puts the technique at risk of being found unhelpful, by setting use case point estimates against expert judgement. It was published in 2002.

That count is a lower bound of unknown tightness. Neither mapping’s classification scheme has a category for a study about whether to adopt a technique, so such studies would not be reliably retrieved even if they existed, and our supplementary search found evaluative work in adjacent venues that neither mapping contains. The counterfactual is also genuinely hard to test here, for the reasons set out in Section 8.3, and its absence is not simply negligence.

Both of those qualifications point the same way. Before the field can say how much evidence for adoption exists, it needs primary studies that declare what was manipulated, against what baseline, and toward what pre-specified outcome, so that a review can find them. That was the second of the three elements proposed in 2004, it has been requested of journals at least three times since, and it has not been adopted.

Until it is, secondary studies will keep finding little evidence, and will not be able to say whether that is because little exists or because their instruments cannot find it.

Data availability

The user story dataset is published by Amna and Poels at https://github.com/anisamna/SMS_UserStory. The use case primary-study list is Appendix I of Barros-Justo et al., with their extraction form at http://doi.org/10.6084/m9.figshare.7959425. Both graded classifications are supplied as supplementary files.

References

1. Jacobson, I. Object-oriented development in an industrial environment. Proc. OOPSLA, 1987.
2. Jacobson, I. Use cases: Yesterday, today, and tomorrow. Software and Systems Modeling, 3, pp. 210-220, 2004.
3. Cohn, M. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
4. Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., Brinkkemper, S. The use and effectiveness of user stories in practice. Proc. REFSQ, 2016, pp. 205-222.
5. Amna, A. R., Poels, G. Systematic literature mapping of user story research. IEEE Access, 10, pp. 51723-51746, 2022. doi: 10.1109/ACCESS.2022.3173745.
6. Barros-Justo, J. L., Benitti, F. B. V., Tiwari, S. The impact of Use Cases in real-world software development projects: A systematic mapping study. Computer Standards and Interfaces, 66, 103362, 2019. doi: 10.1016/j.csi.2019.103362.
7. Tiwari, S., Gupta, A. A systematic literature review of use case specifications research. Information and Software Technology, 67, pp. 128-158, 2015. doi: 10.1016/j.infsof.2015.06.004.
8. Santos, I. S., Andrade, R. M. C., Neto, P. A. S. How to describe SPL variabilities in textual Use Cases: A systematic mapping study. Proc. SBCARS, 2014, pp. 64-73.
9. El-Attar, M., Miller, J. Constructing high quality Use Case models: A systematic review of current practices. Requirements Engineering, 17, pp. 187-201, 2012.
10. Qazi, A. M., Rauf, A., Minhas, N. M. A systematic review of Use Cases based software testing techniques. International Journal of Software Engineering and Its Applications, 10, pp. 337-360, 2016.
11. Montgomery, L., Fucci, D., Bouraffa, A., Scholz, L., Maalej, W. Empirical research on requirements quality: A systematic mapping study. Requirements Engineering, 2022.
12. Sporsem, T. E., Dingsøyr, T., Stol, K.-J. User stories as boundary objects in agile requirements engineering: A theoretical literature review. Journal of Systems and Software, 233, 112693, 2026. doi: 10.1016/j.jss.2025.112693.
13. Raharjana, I. K., Siahaan, D., Fatichah, C. User stories and natural language processing: A systematic literature review. IEEE Access, 9, pp. 53811-53826, 2021.
14. Condori-Fernández, N., Daneva, M., Sikkel, K., Wieringa, R., Dieste, O., Pastor, O. A systematic mapping study on empirical evaluation of software requirements specifications techniques. Proc. ESEM, 2009, pp. 502-505. doi: 10.1109/ESEM.2009.5314232.
15. Anda, B. Comparing effort estimates based on Use Case points with expert estimates. Proc. EASE, 2002.
16. Liskin, O., Pham, R., Kiesling, S., Schneider, K. Why we need a granularity concept for user stories. Proc. XP, LNBIP 179, 2014, pp. 110-125.
17. Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., Brinkkemper, S. Improving user story practice with the Grimm Method: A multiple case study in the software industry. Proc. REFSQ, 2017.
18. Wautelet, Y., Gielis, D., Poelmans, S., Heng, S. Evaluating the impact of user stories quality on the ability to understand and structure requirements. Proc. PoEM, LNBIP 369, 2019, pp. 3-19.
19. Dalpiaz, F., Sturm, A. Conceptualizing requirements using user stories and use cases: A controlled experiment. Proc. REFSQ, LNCS 12045, 2020, pp. 221-238. doi: 10.1007/978-3-030-44429-7_16.
20. Tsilionis, K., Amna, A. R., Heng, S., Poelmans, S., Poels, G. Controlled experiments on user stories’ modeling: Past, present, and future. CEUR Workshop Proceedings, 3134, 2022.
21. Kitchenham, B., Dybå, T., Jørgensen, M. Evidence-based software engineering. Proc. ICSE, 2004.
22. Kitchenham, B. A., Pfleeger, S. L., Pickard, L. M., Jones, P. W., Hoaglin, D. C., El Emam, K., Rosenberg, J. Preliminary guidelines for empirical research in software engineering. IEEE Transactions on Software Engineering, 28(8), pp. 721-734, 2002.
23. Kitchenham, B., Charters, S. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE-2007-01, Keele University, 2007.
24. Petersen, K., Vakkalanka, S., Kuzniarz, L. Guidelines for conducting systematic mapping studies in software engineering: An update. Information and Software Technology, 64, pp. 1-18, 2015.
25. Wieringa, R., Maiden, N., Mead, N., Rolland, C. Requirements engineering paper classification and evaluation criteria: A proposal and a discussion. Requirements Engineering, 11, pp. 102-107, 2006.
26. Cochrane, A. L. Effectiveness and Efficiency: Random Reflections on Health Services. Nuffield Provincial Hospitals Trust, 1972.
27. Moher, D., Schulz, K. F., Altman, D. G. The CONSORT statement. The Lancet, 357, 2001.