Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Adopting Use Case Descriptions for Requirements Specification: an Industrial Case Study

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read After five years of industrial data, only one use-case quality defect—solution-orientation—showed a clear effect on downstream design time.

desk verdict Roughly: the descriptive adoption story is credible and worth reading, but the inferential RQ2 has an unresolved unit-of-analysis problem and the abstract oversells solution-orientation. read the letter →

arxiv 2506.13303 v1 pith:5QUMDD5Q submitted 2025-06-16 cs.SE

Julian Frattini , Anja Frattini This is my paper · ORCID
classification cs.SE
keywords usecasedescriptionsrequirementsengineeringqualityindustrialstudycausalinferenceBayesiandataanalysissolution-orientationdesigntime
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Use case descriptions are a standard way to write functional requirements, but textbook advice on how to write good ones has rarely been tested against real projects. This paper studies five years of requirements from a globally distributed telecom company—1,188 business requirements containing 1,192 use cases—and asks whether the recommended quality rules actually mattered. The descriptive finding is that practice deviates from the textbooks: most use cases were titles rather than full templates, passive voice was common, and adoption grew only after active management promotion. The inferential finding is that, of all the quality heuristics tested, only solution-orientation showed a clear impact: use cases that describe system-internal white-box interactions, or that are placed in a "Solution Proposal" section, were associated with longer design time. The paper concludes that quality research on use cases should focus on the few factors that show observable effects rather than the full checklist.

What carries the argument

The machinery is a combination of manual quality annotation and statistical causal inference. Template-style use cases were scored on the seven quality heuristics—coverage, cogent, coherent, consistent abstraction, consistent structure, consistent grammar, consideration of alternatives—operationalized as attributes like white-box steps, misplaced variations, coherence, and grammar consistency. Causal directed acyclic graphs (DAGs) make the assumed relationships explicit, and Bayesian regression models using backdoor adjustment estimate the average causal effect of each use-case property on design time, measured as days spent in the design stage. The central distinction carrying the main result is black-box versus white-box interaction level, which defines solution-orientation.

What would settle it

A re-analysis that adds author identity, requirement priority, and stakeholder pressure to the adjustment sets would falsify the solution-orientation claim if the estimated effect of white-box steps on design time disappears; likewise, a controlled experiment where the same requirements are written with and without white-box steps and design time is measured could settle the direction.

Watch

Extended reading notes

Core claim

The paper's central claim is that most established use-case quality recommendations did not correspond to measurable differences in practice, and that the exception—solution-orientation—worked in the direction textbooks warn about. Across 273 template-style use cases manually evaluated against a seven-criterion quality checklist, the number of white-box steps (steps describing system-internal interactions rather than user-system interactions) and the location of the use case in the "Solution Proposal" section both predicted longer time spent in the design stage. Other findings ran against the guidelines: use cases with more misplaced variations in the main scenario were associated with shorter design time, and most coherence or grammar measures had no detectable effect. The authors interpret this as evidence that use-case quality research should be steered toward empirically impactful phenomena.

Load-bearing premise

The conclusions assume that the causal diagrams behind the statistical models capture all important common causes of use-case quality and design time; if unmeasured factors like author skill, requirement importance, or stakeholder pressure also drive both, the estimated effects may not be causal.

Editorial extensions

If this is right

  • Adopting template-style use cases will not by itself shorten the design phase; the format's visible benefit in this data was for high-complexity requirements, where it produced the least variable design time.
  • Quality assurance efforts for use cases should concentrate on solution-orientation—removing white-box steps and keeping use cases in the requirements section—rather than on grammar and structural heuristics that showed no effect.
  • The textbook rule to keep alternative paths out of the main scenario is called into question: more misplaced variations were associated with shorter design time in the studied company.
  • For the case company, the single actionable requirements-engineering lever identified is use-case location: placing a use case in the Business Requirements section makes white-box steps much less likely at every complexity level.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension would be an intervention study where solution-oriented use cases are rewritten as black-box user-system interactions and design time is tracked; the paper's causal model predicts this would shorten the design stage.
  • The results imply that requirements quality checklists should be empirically validated against downstream activity outcomes before being adopted, since stylistic heuristics can be neutral or even inversely related to performance.
  • The adoption curve suggests that deliberate management promotion, not intrinsic usefulness alone, drove the format's spread; future adoption studies should measure promotion intensity as a variable.
  • The negative association between misplaced variations and design time could be explained by the cost of cross-referencing numbered extensions; a targeted experiment could test whether inline alternatives reduce cognitive load.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This paper reports an industrial case study at a large, globally distributed telecom BSS company. The authors analyze 1,188 business requirements and 1,192 use-case-like descriptions authored between 2020 and 2024, manually annotate the 273 template-style use cases against seven quality heuristics from Phalp et al., and use Bayesian statistical causal inference to estimate (RQ2) how use-case quality attributes affect design-stage duration and (RQ3) how requirements-engineering process factors affect selected quality attributes. The descriptive results show that adoption grew only after active management promotion, that template-style use cases form a minority (22.9%), that many use cases are solution-oriented and located in 'Solution Proposal' sections, and that actual practice deviates from the textbook 7-C guidelines. The inferential results are presented as mostly null, with solution-orientation (white-box steps and UC location) and, less clearly, explicit actors associated with longer design time; RQ3 finds mainly that location and complexity predict white-box steps. The abstract concludes that only a few phenomena such as solution-orientation show an actual impact in practice.

Significance. The paper's main strength is its rare longitudinal, industrially grounded dataset. The manual review of all 1,188 requirements with a documented extraction guideline, the use of established quality criteria from prior literature, the explicit causal DAGs, and the replication package with mocked data are concrete assets that make the descriptive adoption findings credible and reusable. If the inferential claims can be made sound, the paper would make a useful contribution to requirements-quality research by providing field evidence on which textbook UC-quality recommendations matter in practice. The finding that only solution-orientation, not most other 7-C heuristics, predicts downstream design activity is a falsifiable, practically relevant result. At present, however, the unit-of-analysis problem and the overstatement of significance mean that the inferential part is not yet a reliable basis for the abstract's causal wording.

major comments (4)
  1. [III-C1/III-C2, V-C3] The RQ2 analysis contains a unit-of-analysis mismatch that is load-bearing for the abstract's claim about solution-orientation. Design time is measured once per business requirement (Section III-B5), while predictors such as white-box steps, UC location, and explicit actors are attributes of individual template-style UCs (Tables II-IV). Section III-C1 describes aggregation of UC-level attributes to the requirement level only for descriptive visualization; the manuscript never states how the RQ2 regression data were constructed. If the models use one row per UC, requirements with multiple template UCs contribute duplicated design-time outcomes, violating independence and overstating precision. If they use one row per requirement, the aggregation method (sum, mean, or mode) is unspecified and information about mixed UC locations is lost. Section V-C3's admission that no hierarchical models were considered makes this omission acute. Please report the exact data construction and re-estimate the models with a requirement-level random intercept or an equivalent clustered analysis.
  2. [IV-B2, V-A] The paper overstates the statistical support for solution-orientation. In Section IV-B2, Figure 17 shows credible intervals that overlap across locations, and Figure 18 shows wide intervals for both white-box steps and explicit actors; Section IV-B3 explicitly labels the consecutive-steps effect non-significant. Yet Section V-A describes solution-orientation as a significant factor, and Section V-B reports that the managers perceived the effects as significant. The phrase 'significant' should be reserved for a stated posterior criterion, and the relevant effect estimates with credible intervals should be reported in the text rather than only in figures. As written, the abstract's causal claim about solution-orientation rests on mean directions rather than on inferential evidence.
  3. [III-C2a, V-C1] The causal-sufficiency assumption of the DAGs is not quantified. The manuscript acknowledges in Section V-C1 that unobserved confounders such as author skill, stakeholder pressure, and requirement importance may affect both UC quality and design time, but it does not assess how strong such confounding would need to be to explain away the reported effects. Because the headline result is precisely a causal claim about white-box steps and UC location increasing design time, a sensitivity analysis (e.g., E-value or bias-formula bounds) or an explicit argument about the plausible direction and magnitude of unobserved confounding would materially strengthen the conclusion.
  4. [IV-C] The selection of the four outcome variables for RQ3 is not principled. Section IV-C states that the authors investigate the four most significant UC quality factors, but the RQ2 results in Section IV-B1 report no meaningful effect for number of use cases, and Section IV-B2 gives no significance statement for explicit actors with all intervals overlapping. The criterion for 'most significant' should be defined (e.g., posterior probability of a positive or negative effect, width of credible interval, or minimum effect size) and applied consistently, otherwise the set of RQ3 outcomes appears selected without a stated rule.
minor comments (5)
  1. [II-A] There is a typo in the sentence 'the format in which a UC descirption may be specified'; 'descirption' should be 'description'.
  2. [IV-B2] The text contains an unresolved placeholder: 'This hints at the negative effect of solution-orientation which we will discuss in ??.' The cross-reference needs to be completed.
  3. [III-B2] The manual extraction procedure is described as involving independent extraction followed by discussion, but no inter-rater agreement statistic is reported. Since the descriptive and inferential results depend on these manual judgments, reporting a measure such as Cohen's kappa for at least a subsample would increase confidence in the extraction.
  4. [IV-A2, Figure 16] The y-axis of Figure 16 is labeled 'Requirements' but the plot shows percentages; the label should be 'Share of requirements' to avoid confusion.
  5. [III-C2c, Figures 17-20] The figures report credible intervals but none of the marginal-effect plots includes the numerical posterior mean and interval values in the caption or text; adding these values would make the reported overlaps and distinctions easier to assess.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the study's empirical chain is self-contained against the data.

full rationale

The paper's derivation chain is empirical rather than self-referential. RQ2's outcome variable, design time (Section III-B5), is measured independently from Jira stage timestamps, and the UC quality predictors (Tables III-IV) are manually extracted or derived from sequence diagrams following external guidelines (Phalp et al. [11]). The Bayesian models use uninformative priors with prior predictive checks (Section III-C2c), so no fitted constant is renamed as a prediction. The causal DAGs (Section III-C2a) state assumptions and are explicitly disclosed as falsifiable modeling choices, not as results derived from the data. Self-citations such as [4], [10], [25], and [47] support the framing of requirements quality and the analysis approach, but the abstract's solution-orientation finding is supported by the marginal effects in Figures 17-18, which are estimated from the collected data. The manuscript's own limitations — unobserved confounders (Section V-C1), construct validity of the guidelines and design-time proxy (V-C2), and the absence of hierarchical models (V-C3) — are validity threats, not circular reductions; they do not make any equation or fitted parameter equivalent to the conclusion. Under the hard rule requiring a demonstrated Eq. = Eq. or fitted-parameter-as-prediction reduction, none exists here.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No free parameters are fitted to the outcome; the Bayesian models use uninformative priors. The central inferences rest on four domain assumptions: correct causal DAGs, design time as a performance proxy, validity of the 7 Cs operationalization, and reliability of manual annotation.

assumptions (4)
  • domain assumption The causal DAGs correctly specify the confounding structure; complexity is the only modeled common cause of requirement form and design time.
    Introduced in Section III-C2a and Figure 3. If unobserved confounders such as author skill, stakeholder pressure, or requirement importance affect both UC quality and design time, the RQ2/RQ3 estimates are biased.
  • domain assumption Design time (S2 duration in days) is a valid operationalization of the performance of the subsequent solution design phase.
    Section III-B5. The paper acknowledges this is a simplistic proxy and that triangulation with other attributes like solution correctness is needed.
  • domain assumption Phalp et al.'s 7 Cs quality heuristics, as operationalized by the authors, capture use case quality.
    Sections II-B and III-B3. The paper itself questions the construct validity of these guidelines given limited prior empirical evidence.
  • domain assumption Manual annotations (form, fields, quality attributes, sequence diagram translations) are reliable.
    Section III-B2 describes guideline testing on 29.5% of data, but no inter-rater reliability statistic is reported, leaving measurement reliability unquantified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Adopting Use Case Descriptions for Requirements Specification: an Industrial Case Study." pith.science (2026). https://pith.science/paper/5QUMDD5Q

@misc{pith2026250613303,
  author       = {Pith},
  title        = {Pith review of: Adopting Use Case Descriptions for Requirements Specification: an Industrial Case Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5QUMDD5Q}},
  note         = {Machine review of arXiv:2506.13303}
}
read the original abstract

Context: Use case (UC) descriptions are a prominent format for specifying functional requirements. Existing literature abounds with recommendations on how to write high-quality UC descriptions but lacks insights into (1) their real-world adoption, (2) whether these recommendations correspond to actual quality, and (3) which factors influence the quality of UCs. Objectives: We aim to contribute empirical evidence about the adoption of UC descriptions in a large, globally distributed case company. Methods: We surveyed 1188 business requirements of a case company that were elicited from 2020-01-01 until 2024-12-31 and contained 1192 UCs in various forms. Among these, we manually evaluated the 273 template-style UC descriptions against established quality guidelines. We generated descriptive statistics of the format's adoption over the surveyed time frame. Furthermore, we used inferential statistics to determine (a) how properties of the requirements engineering process affected the UC quality and (b) how UC quality affects subsequent software development activities. Results and Conclusions: Our descriptive results show how the adoption of UC descriptions in practice deviates from textbook recommendations. However, our inferential results suggest that only a few phenomena like solution-orientation show an actual impact in practice. These results can steer UC quality research into a more relevant direction.

Figures

Figures reproduced from arXiv: 2506.13303 by the authors.

Figure 1
Figure 1. Mapping of RQs to the studied Context them perform [9], [10]. Consequently, prior research proposed quality criteria for writing “good” UCs [11]–[13]. However, literature lacks empirical insights into the adoption and ap￾plication of UCs in practice, but also whether the proposed quality criteria actually support the usability of the artifact. We argue that both are fundamental for problem-oriented research and to e… view at source ↗
Figure 2
Figure 2. Exemplary template-style UC description containing the defects [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Causal DAG of the adoption effect 2) Inferential Statistics: To answer RQ2 and RQ3, we employ a Bayesian data analysis (BDA) approach for statistical causal inference (SCI) [42], [43]. While BDA is not yet com￾monplace in SE research [44], its principled approach within a causal framework allows dealing with confounders [45] which is particularly relevant in our observational case study setting. Due to limited space… view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Marginal effect of the requirement form High Complexity Medium Complexity Low Complexity 50 100 150 Design Time [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Marginal effect of the complexity level predictor [54]. We select uninformative priors (e.g., normal distributions centered around 0 with a wide standard deviation) to encode our uncertainty about the existence and strength of an effect. Once we confirmed the eligibili…
Figure 7
Figure 7. Figure 7: UC from the case in informal form Use case 1.1 Maiden Deploy of Single Site (OCS/BLR SOT19) [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 9
Figure 9. Figure 9: UC from the case in user story form (italics from the original) Title: New Micro-service Level: System Main scenario: 1. A new Micro-service for Generic Batch utility is created including the creation of a new docker image, helmfile integration, pipeline establishment.…
Figure 10
Figure 10. Figure 10: UC from the case in template form [PITH_FULL_IMAGE:figures/full_fig_p007_10.png]
Figure 11
Figure 11. Figure 11: Distribution of steps Explicit actors Actors Entities 0.0 2.5 5.0 7.5 [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 16
Figure 16. Figure 16: Evolution of UC forms [PITH_FULL_IMAGE:figures/full_fig_p008_16.png]
Figure 17
Figure 17. Figure 17: Marginal effect of UC location on design time [PITH_FULL_IMAGE:figures/full_fig_p009_17.png]
Figure 18
Figure 18. Figure 18: Marginal effect of white-box steps and explicit actors [PITH_FULL_IMAGE:figures/full_fig_p009_18.png]
Figure 21
Figure 21. Figure 21: Conditional effect of location and complexity [PITH_FULL_IMAGE:figures/full_fig_p010_21.png]
Figure 19
Figure 19. Figure 19: Additionally, incoherent steps were understood as a [PITH_FULL_IMAGE:figures/full_fig_p010_19.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. TraceDev: A Traceability-Driven Multi-agent Framework for Requirement-to-Code Development

    cs.SE 2026-07 conditional novelty 6.0 of 10

    A traceability-graph-driven multi-agent framework improves LLM-based repository-level code generation from use cases, reaching 53-57% functional success on ETOUR/SMOS versus 13-25% for ChatDev and MetaGPT.

Reference graph

Works this paper leans on

57 extracted references · 49 canonical work pages · cited by 1 Pith paper

  1. [1]

    Improving requirements en- gineering by artefact orientation,

    D. M ´endez Fern ´andez and R. Wieringa, “Improving requirements en- gineering by artefact orientation,” in Product-Focused Software Process Improvement: 14th International Conference, PROFES 2013, Paphos, Cyprus, June 12-14, 2013. Proceedings 14 . Springer, 2013, pp. 108– 122

    work page 2013

  2. [2]

    Artefacts in software engineering: a fundamental positioning,

    D. M ´endez Fern ´andez, W. B ¨ohm, A. V ogelsang, J. Mund, M. Broy, M. Kuhrmann, and T. Weyer, “Artefacts in software engineering: a fundamental positioning,” Software & Systems Modeling , vol. 18, pp. 2777–2786, 2019

    work page 2019

  3. [3]

    A glossary of requirements engineering terminology,

    M. Glinz, “A glossary of requirements engineering terminology,” Stan- dard Glossary of the Certified Professional for Requirements Engineer- ing (CPRE) Studies and Exam, Version , vol. 1, p. 56, 2011

    work page 2011

  4. [4]

    Measuring the fitness-for-purpose of requirements: An initial model of activities and attributes,

    J. Frattini, J. Fischbach, D. Fucci, M. Unterkalmsteiner, and D. Mendez, “Measuring the fitness-for-purpose of requirements: An initial model of activities and attributes,” in 2024 IEEE 32nd International Requirements Engineering Conference (RE) . IEEE, 2024, pp. 398–406

    work page 2024

  5. [5]

    Artefact-based require- ments engineering: the amdire approach,

    D. M ´endez Fern ´andez and B. Penzenstadler, “Artefact-based require- ments engineering: the amdire approach,” Requirements Engineering , vol. 20, no. 4, pp. 405–434, 2015

    2015

  6. [6]

    A meta model for artefact-orientation: fundamentals and lessons learned in requirements engineering,

    D. M ´endez Fern´andez, B. Penzenstadler, M. Kuhrmann, and M. Broy, “A meta model for artefact-orientation: fundamentals and lessons learned in requirements engineering,” in Model Driven Engineering Languages and Systems: 13th International Conference, MODELS 2010, Oslo, Norway, October 3-8, 2010, Proceedings, Part II 13 . Springer, 2010, pp. 183– 197

    work page 2010

  7. [7]

    Jacobson, Object-oriented software engineering: a use case driven approach

    I. Jacobson, Object-oriented software engineering: a use case driven approach. Pearson Education India, 1993

    work page 1993

  8. [8]

    Basic use case template,

    A. Cockburn, “Basic use case template,” Humans and Technology, Technical Report, vol. 96, p. 28, 1998

    work page 1998

Show all 57 references
  1. [9]

    Requirements quality is quality in use,

    H. Femmer and A. V ogelsang, “Requirements quality is quality in use,” IEEE Software, vol. 36, no. 3, pp. 83–91, 2018

    2018

  2. [10]

    Requirements quality research: a harmonized theory, evaluation, and roadmap,

    J. Frattini, L. Montgomery, J. Fischbach, D. Mendez, D. Fucci, and M. Unterkalmsteiner, “Requirements quality research: a harmonized theory, evaluation, and roadmap,” Requirements engineering , vol. 28, no. 4, pp. 507–520, 2023

    2023

  3. [11]

    Assessing the quality of use case descriptions,

    K. T. Phalp, J. Vincent, and K. Cox, “Assessing the quality of use case descriptions,” Software Quality Journal , vol. 15, pp. 69–97, 2007

    2007

  4. [12]

    Adolph, Patterns for effective use cases

    S. Adolph, Patterns for effective use cases . Pearson Education India, 2002

    2002

  5. [13]

    An empirical study on assessing the quality of use case metrics,

    C. Usdadiya, S. Tiwari, and A. Banerjee, “An empirical study on assessing the quality of use case metrics,” in Proceedings of the 12th Innovations in Software Engineering Conference (formerly known as India Software Engineering Conference) , 2019, pp. 1–11

    2019

  6. [14]

    Structuring use cases with goals,

    A. Cockburn, “Structuring use cases with goals,” Journal of object- oriented programming, vol. 10, no. 5, pp. 56–62, 1997

    1997

  7. [15]

    The use of scenarios in design,

    B. A. Nardi, “The use of scenarios in design,” ACM Sigchi Bulletin , vol. 24, no. 4, pp. 13–14, 1992

    1992

  8. [16]

    Stevens and R

    P. Stevens and R. J. Pooley, Using UML: software engineering with objects and components . Pearson Education, 2006

    2006

  9. [17]

    Rosenberg and K

    D. Rosenberg and K. Scott, Use case driven object modeling with UML . Springer, 1999

    1999

  10. [18]

    Use case formats: Requirements, analysis, and design,

    R. J. Harwood, “Use case formats: Requirements, analysis, and design,” JOOP, vol. 9, no. 8, pp. 54–57, 1997

    1997

  11. [19]

    Cockburn and L

    A. Cockburn and L. Cockburn, Writing effective use cases . Pearson Education India, 2008

    2008

  12. [20]

    Empirical studies of construction and application of use case models,

    B. Anda, “Empirical studies of construction and application of use case models,” University of Oslo, Norway , 2003

    2003

  13. [21]

    Use cases: requirements in context,

    D. Kulak and E. Guiney, “Use cases: requirements in context,” ACM SIGSOFT Software Engineering Notes , vol. 26, no. 1, pp. 101–101, 2001

    2001

  14. [22]

    It’s the activities, stupid! a new perspective on re quality,

    H. Femmer, J. Mund, and D. M. Fern ´andez, “It’s the activities, stupid! a new perspective on re quality,” in 2015 IEEE/ACM 2nd International Workshop on Requirements Engineering and Testing . IEEE, 2015, pp. 13–19

    2015

  15. [23]

    Empirical research on requirements quality: a systematic mapping study,

    L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, and W. Maalej, “Empirical research on requirements quality: a systematic mapping study,” Requirements Engineering, vol. 27, no. 2, pp. 183–209, 2022

    2022

  16. [24]

    Software engineering economics,

    B. W. Boehm, “Software engineering economics,” IEEE transactions on Software Engineering, no. 1, pp. 4–21, 1984

    1984

  17. [25]

    A live extensible ontology of quality factors for textual requirements,

    J. Frattini, L. Montgomery, J. Fischbach, M. Unterkalmsteiner, D. Mendez, and D. Fucci, “A live extensible ontology of quality factors for textual requirements,” in 2022 IEEE 30th international requirements engineering conference (RE) . IEEE, 2022, pp. 274–280

    2022

  18. [26]

    Rapid quality assurance with requirements smells,

    H. Femmer, D. M. Fern ´andez, S. Wagner, and S. Eder, “Rapid quality assurance with requirements smells,” Journal of Systems and Software , vol. 123, pp. 190–213, 2017

    2017

  19. [27]

    An essential textual use case meta- model based on an analysis of existing proposals

    F. L. Siqueira and P. S. M. Silva, “An essential textual use case meta- model based on an analysis of existing proposals.” in WER, 2011

    2011

  20. [28]

    Guiding use case authoring: Results of an empirical study,

    C. B. Achour, C. Rolland, N. Maiden, and C. Souveyet, “Guiding use case authoring: Results of an empirical study,” in Proceedings IEEE International Symposium on Requirements Engineering (Cat. No. PR00188). IEEE, 1999, pp. 36–43

    1999

  21. [29]

    Constructing high quality use case models: a systematic review of current practices,

    M. El-Attar and J. Miller, “Constructing high quality use case models: a systematic review of current practices,” Requirements Engineering , vol. 17, pp. 187–201, 2012

    2012

  22. [30]

    Improving coherence in written communication,

    M. J. Traxler and M. A. Gernsbacher, “Improving coherence in written communication,” Coherence in spontaneous text , pp. 215–238, 1995

    1995

  23. [31]

    Field study on requirements engineering: Investigation of artefacts, project parameters, and execution strategies,

    D. M. Fernandez, S. Wagner, K. Lochmann, A. Baumann, and H. de Carne, “Field study on requirements engineering: Investigation of artefacts, project parameters, and execution strategies,” Information and Software Technology, vol. 54, no. 2, pp. 162–178, 2012

    2012

  24. [32]

    Replicating the crews use case authoring guidelines experiment,

    K. Cox and K. Phalp, “Replicating the crews use case authoring guidelines experiment,” Empirical Software Engineering , vol. 5, pp. 245–267, 2000

    2000

  25. [33]

    An experiment in inspecting the quality of use case descriptions,

    K. Cox, A. Aurum, and R. Jeffery, “An experiment in inspecting the quality of use case descriptions,” Journal of Research and Practice in Information Technology, vol. 36, no. 4, pp. 211–229, 2004

    2004

  26. [34]

    A systematic literature review of use case specifications research,

    S. Tiwari and A. Gupta, “A systematic literature review of use case specifications research,” Information and Software Technology , vol. 67, pp. 128–158, 2015

    2015

  27. [35]

    Case study research in software engineering—it is a case, and it is a study, but is it a case study?

    C. Wohlin, “Case study research in software engineering—it is a case, and it is a study, but is it a case study?” Information and Software Technology, vol. 133, p. 106514, 2021

    2021

  28. [36]

    Guidelines for conducting and reporting case study research in software engineering,

    P. Runeson and M. H ¨ost, “Guidelines for conducting and reporting case study research in software engineering,” Empirical software engineering, vol. 14, pp. 131–164, 2009

    2009

  29. [37]

    Robson and K

    C. Robson and K. McCartan, Real world research. Blackwell Oxford, 2002, vol. 2

    2002

  30. [38]

    The focus group method as an empirical tool in software engineering,

    J. Kontio, J. Bragge, and L. Lehtola, “The focus group method as an empirical tool in software engineering,” in Guide to advanced empirical software engineering. Springer, 2008, pp. 93–116

    2008

  31. [39]

    The case research strategy in studies of information systems,

    I. Benbasat, D. K. Goldstein, and M. Mead, “The case research strategy in studies of information systems,” MIS quarterly, pp. 369–386, 1987

    1987

  32. [40]

    Sampling in software engineering research: A critical review and guidelines,

    S. Baltes and P. Ralph, “Sampling in software engineering research: A critical review and guidelines,” Empirical Software Engineering, vol. 27, no. 4, p. 94, 2022

    2022

  33. [41]

    Cohn, User stories applied: For agile software development

    M. Cohn, User stories applied: For agile software development . Addison-Wesley Professional, 2004

    2004

  34. [42]

    McElreath, Statistical rethinking: A Bayesian course with examples in R and Stan

    R. McElreath, Statistical rethinking: A Bayesian course with examples in R and Stan . Chapman and Hall/CRC, 2018

    2018

  35. [43]

    Pearl, Causality

    J. Pearl, Causality. Cambridge university press, 2009

    2009

  36. [44]

    Bayesian data analysis in em- pirical software engineering research,

    C. A. Furia, R. Feldt, and R. Torkar, “Bayesian data analysis in em- pirical software engineering research,” IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1786–1810, 2019

    2019

  37. [45]

    Applying bayesian analysis guide- lines to empirical software engineering data: The case of programming languages and code quality,

    C. A. Furia, R. Torkar, and R. Feldt, “Applying bayesian analysis guide- lines to empirical software engineering data: The case of programming languages and code quality,”ACM Transactions on Software Engineering and Methodology (TOSEM) , vol. 31, no. 3, pp. 1–38, 2022

    2022

  38. [46]

    Bayesian data analysis in em- pirical software engineering: The case of missing data,

    R. Torkar, R. Feldt, and C. A. Furia, “Bayesian data analysis in em- pirical software engineering: The case of missing data,” Contemporary Empirical Methods in Software Engineering , pp. 289–324, 2020

    2020

  39. [47]

    Applying bayesian data analysis for causal inference about requirements quality: a controlled experiment,

    J. Frattini, D. Fucci, R. Torkar, L. Montgomery, M. Unterkalmsteiner, J. Fischbach, and D. Mendez, “Applying bayesian data analysis for causal inference about requirements quality: a controlled experiment,” Empirical Software Engineering , vol. 30, no. 1, p. 29, 2025

    2025

  40. [48]

    Applications of statistical causal inference in software engineering,

    J. Siebert, “Applications of statistical causal inference in software engineering,” Information and Software Technology, vol. 159, p. 107198, 2023

    2023

  41. [49]

    Causal inference,

    J. Pearl, “Causal inference,” Causality: objectives and assessment , pp. 39–58, 2010

    2010

  42. [50]

    Graphical causal models,

    F. Elwert, “Graphical causal models,” in Handbook of causal analysis for social research. Springer, 2013, pp. 245–273

    2013

  43. [51]

    A crash course in good and bad controls,

    C. Cinelli, A. Forney, and J. Pearl, “A crash course in good and bad controls,” Sociological Methods & Research , vol. 53, no. 3, pp. 1071– 1104, 2024

    2024

  44. [52]

    E. T. Jaynes, Probability theory: The logic of science . Cambridge: Cambridge University Press, 2003

    2003

  45. [53]

    Reliability of researcher capacity esti- mates and count data dispersion: A comparison of poisson, negative binomial, and conway-maxwell-poisson models,

    B. Forthmann and P. Doebler, “Reliability of researcher capacity esti- mates and count data dispersion: A comparison of poisson, negative binomial, and conway-maxwell-poisson models,” Scientometrics, vol. 126, no. 4, pp. 3337–3354, 2021

    2021

  46. [54]

    Choosing priors in Bayesian ecological models by simulating from the prior predictive distribution,

    J. S. Wesner and J. P. Pomeranz, “Choosing priors in Bayesian ecological models by simulating from the prior predictive distribution,” Ecosphere, vol. 12, no. 9, p. e03739, 2021

    2021

  47. [55]

    Brooks, A

    S. Brooks, A. Gelman, G. Jones, and X.-L. Meng, Handbook of Markov Chain Monte Carlo . CRC press, 2011

    2011

  48. [56]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost, M. C. Ohlsson, B. Regnell, A. Wessl´en et al. , Experimentation in software engineering . Springer, 2012, vol. 236

    2012

  49. [57]

    An investigation of use case quality in a large safety-critical software development project,

    B. Anda, K. Hansen, and G. Sand, “An investigation of use case quality in a large safety-critical software development project,” Information and Software Technology, vol. 51, no. 12, pp. 1699–1711, 2009

    2009

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.