On Integrating Design Thinking for a Human-centered Requirements Engineering

Daniel Mendez; Falk Uebernickel; Jennifer Hehn; Manfred Broy; Walter Brenner

REVIEW 3 major objections 5 minor 1 references

On Integrating Design Thinking for a Human-centered Requirements Engineering

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read This paper argues for a systematic integration of Design Thinking and Requirements Engineering, grounded in a 40-artifact model, and proposes three strategies — upfront, infused, and continuous — for tailoring the combination to a…

desk verdict An honest, practitioner-oriented taxonomy of three DT/RE integration strategies, undercut somewhat by an under-validated and partly absent artifact model. read the letter →

arxiv 1908.07223 v2 pith:BWXJKRU2 submitted 2019-08-20 cs.SE

Jennifer Hehn , Daniel Mendez , Falk Uebernickel , Walter Brenner , Manfred Broy This is my paper · ORCID

classification cs.SE

keywords DesignThinkingRequirementsEngineeringartifactmodelintegrationstrategieshuman-centeredelicitationsoftwareprocessprototyping

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

The paper argues that Design Thinking and Requirements Engineering should not be treated as competing approaches: Requirements Engineering tends to assume that requirements are already there to be elicited, while Design Thinking tends to stop at a non-technical prototype without a path into software development. To make the connection explicit, the authors build a combined artifact model of 40 work products — 16 from Design Thinking, 16 from Requirements Engineering, and 8 shared — organized into context, requirements, and system layers. From this model they derive three integration strategies: running Design Thinking upfront, infusing selected Design Thinking tools into an existing Requirements Engineering process, and continuously integrating both throughout a project. A sympathetic reader would take the contribution to be a framework for choosing among these strategies based on problem uncertainty, organizational maturity, and the team's learning needs.

What carries the argument

The load-bearing object is the combined artifact model: a layered blueprint of the work products produced by Design Thinking and Requirements Engineering, grouped into context, requirements, and system layers and totaling 40 artifacts (16 Design Thinking, 16 Requirements Engineering, 8 shared). Artifacts — not processes or methods — are the unit of comparison because individual processes vary too much across projects. The model does the work of showing where the two approaches overlap, where they are complementary, and where each leaves a gap the other can fill; the three integration strategies are then read directly off that structure.

What would settle it

Collect the work products of a diverse sample of industrial Design Thinking and Requirements Engineering projects and check each against the 40-artifact model; any recurrent artifact that has no place in the context, requirements, or system layers — or that sits in a layer the model does not assign it to — would falsify the completeness claim. A second check: run the continuous strategy on a project and verify whether every item in the final software requirements specification can be traced back to a customer need expressed in a Design Thinking artifact, as the paper claims.

Watch

Extended reading notes

Core claim

The central claim is that the gap between Design Thinking and Requirements Engineering is not a difference in goals but a missing bridge of artifacts and process tailoring. The authors maintain that Design Thinking produces human-centered context artifacts — field studies, personas, opportunity areas, prototypes — that feed naturally into the requirements and system artifacts that Requirements Engineering already handles, and that Requirements Engineering supplies the technical realization that Design Thinking leaves open. They present a 40-artifact model spanning three layers: why the system is needed (context), which user-level requirements and features are necessary (requirements), and how the system is realized (system). Based on where the overlaps and gaps lie, they propose three integration strategies — upfront, infused, and continuous — each with characteristic duration, roles, outcomes, benefits, and challenges, illustrated by one industrial case per strategy.

Load-bearing premise

The whole argument rests on the assumption that the 40-artifact model is a valid and complete representation of what Design Thinking and Requirements Engineering actually produce, yet the model is drawn from the authors' own industrial experience and is not independently validated.

Editorial extensions

If this is right

Teams can locate their own blind spots by checking which of the 40 artifacts they currently produce; missing context-layer artifacts signal an under-explored problem space.
The upfront strategy is the right choice when both problem and solution are uncertain, and it yields a clear solution vision in roughly 3 to 12 weeks.
The infused strategy offers a low-adoption-hurdle entry point for organizations new to Design Thinking, adding one- to two-day focused workshops to existing Requirements Engineering activities.
The continuous strategy requires a dedicated human-centric requirements engineer role and management commitment over more than six months, but it is the only strategy that keeps the human-centered mindset alive through development.
Organizational Design Thinking maturity should steer the choice: start with infusion, advance to upfront, and attempt continuous integration only with sustained commitment.

Reading between the lines

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

The same 40-artifact model could serve as a diagnostic audit instrument: a team could map its current work products onto the blueprint to decide which strategy to adopt, a use the paper only implies.
If continuous integration works as described, the requirements engineer's role shifts from specification writing toward facilitation and user research, which would change hiring and training criteria in ways the paper does not detail.
The three case examples are one-to-one with the three strategies; a sharper test would be a single long-running project that moves from upfront to infused to continuous, checking whether the claimed traceability survives the transitions.
The model's boundary-object question could be turned into a concrete research method: compare artifacts across teams and look at which ones are reused or reinterpreted at handover, since the paper identifies prototypes as boundary objects but leaves the general mechanism open.

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.

Desk Editor's Note

read the letter

Short version: this is an honest position piece. The authors name three integration strategies — upfront, infused, continuous — that are a clean, memorable taxonomy for combining Design Thinking and Requirements Engineering, and they anchor it in a 40-artifact model across context/requirements/system layers. The taxonomy is the useful part; the artifact model is plausible but asserted rather than demonstrated, and most of the detail lives in a Web Extra that is not in the manuscript.

Credit where due: the paper is plainly written and properly scoped. It opens as a position paper, draws on the authors' industrial experience, and closes with genuinely candid open challenges — they admit that 'we cannot yet unfold a complete picture' of how principles, work results, and methods relate. That is the right stance. The three short case examples in Table 1 are concrete and illustrate each strategy. The authors also lean on their own prior work for the artifact model, which is reasonable here since those are the pieces they are extending.

The soft spots are in proportion. The central claim is a postulate — that we need integration — which is fine for a position piece, but the load-bearing piece is the artifact model. The three strategies are derived from that model, so if the model overfits the authors' own projects, the strategies may not generalize. The paper gives counts of 40 artifacts but only a compact figure; a reader cannot audit the categories, dependencies, or overlaps. All three case examples are successful adoptions from the authors' own practice, with no negative cases, baselines, or outcome metrics. That selection-bias risk is real, though not damning for an experience report. There are also minor typos ('Desin', 'tracebale') and a bit of self-citation prominence, but nothing that affects the argument.

Who is this for? Practitioners and educators who want a vocabulary for DT/RE integration, and researchers who want a starting point for more rigorous empirical work. It deserves a serious referee — not because the evidence is strong, but because the taxonomy is useful and the authors are transparent about their limits. A good review should push them to include the full artifact model or explicitly frame it as provisional, and to add at least one less successful case for contrast.

Referee Report

3 major / 5 minor

Summary. This position paper argues that effective integration of Design Thinking (DT) and Requirements Engineering (RE) is needed, and it draws on the authors' industrial and teaching experience to compare the two approaches through an artifact model. The paper proposes three integration strategies: upfront DT, infused DT, and continuous DT, each summarized in Table 1 with characteristics, outcomes, roles, benefits, challenges, and a supporting case example. It concludes with open research challenges concerning principles, boundary objects, methods, roles, and project situations. The paper is explicitly a position piece and does not claim to provide formal validation; its central assertion is a postulate about the need for integration.

Significance. If the proposed artifact model and the three integration strategies are accepted as a useful synthesis of industrial practice, the paper provides a concrete vocabulary and starting point for practitioners and researchers working at the DT/RE interface. The distinction among upfront, infused, and continuous strategies, with practical duration estimates and role suggestions, is a valuable framing that goes beyond earlier position statements. The paper is transparent about its nature, and the inclusion of three illustrative case examples is helpful, though anecdotal. The main significance is in structuring a debate and offering actionable heuristics, rather than in providing empirically validated results. The acknowledged incompleteness of the artifact model limits the strength of the claimed generality.

major comments (3)

[Section 3.1, Fig. 2] The artifact model of 40 artifacts is load-bearing for the three integration strategies in Section 3.2, but the full model is not included in the paper; the authors refer only to a Web Extra. Because readers cannot audit the artifact categories, their dependencies, or the criteria for attributing artifacts to DT, RE, or both, the derivation of the strategies is not independently checkable. Moreover, Section 4 concedes that 'we cannot yet unfold a complete picture' of how the work products relate, which weakens the implicit completeness of the inventory. I recommend either including the full artifact model in an appendix or explicitly re-framing the strategies as provisional observations that do not depend on a comprehensive model.
[Table 1, Case Examples] The three case examples are uniformly successful adoptions of the respective strategies (Alpha Insurance for upfront, Beta Enterprises for infused, Gamma Energy for continuous). No negative case, failed adoption, or boundary condition is discussed. As a result, the reader cannot infer when a strategy is likely to fail or which project characteristics are essential for the claimed benefits. The paper should add at least one counterexample or a discussion of observed limitations, or otherwise temper the prescriptive claims to reflect the absence of evidence about failure modes.
[Section 1 and Section 4] The central claim is stated as a postulate ('We postulate that we need an effective integration of Design Thinking and Requirements Engineering'), which is not directly falsifiable. The testable load-bearing components are the artifact model and the three strategies, yet the paper does not specify what evidence would count against them. For a position paper this is acceptable, but the manuscript would be stronger if it provided a minimal evaluation protocol—for example, how one would measure whether an upfront, infused, or continuous strategy achieved its intended outcomes—so that later empirical work can be designed. As written, the claims risk being unfalsifiable.

minor comments (5)

[Section 3.2 heading] The heading contains a typo: 'Desin Thinking' should be 'Design Thinking'.
[Table 1, 'Outcome' row] In the continuous strategy column, 'tracebale' should be 'traceable'.
[Section 1, first sentence after the abstract] The text runs the section title into the body: '1 INTRODUCTIONREQUIREMENTS ENGINEERS often face the challenge...' A space or line break is missing after 'INTRODUCTION'.
[References] Several supporting references are self-citations (e.g., [3], [6], [7], [8], [9]). While this is not a problem by itself, the paper would be more convincing if it also cited independent work on DT/RE integration, agile-RE synergies, and artifacts in software engineering beyond the authors' own prior publications.
[Web Extra (www.dt4re.org)] The full artifact model is only available via the Web Extra. Please verify that the URL is stable and accessible, and consider including at least a summary table of the 40 artifacts in the manuscript so that the core model is self-contained.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the integration strategies are qualitative recommendations from experience, not predictions forced by the artifact model.

full rationale

The paper is a position paper whose central assertion is explicitly a postulate: 'We postulate that we need an effective integration of Design Thinking and Requirements Engineering.' There is no derivation chain that could collapse: Section 3.1 introduces the 40-artifact model as a blueprint 'based on our experiences as practitioners' rather than as a theorem, and Section 3.2 presents the three strategies as suggestions ('We suggest three approaches') grounded in that model and in illustrative, all-positive case examples, not as quantities fitted from the model. Several supporting references are authored or co-authored by the present authors ([3], [6], [7], [8], [9]), but none is invoked as a uniqueness theorem or as the sole justification of a prediction; for instance, [3] is used only to note that Design Thinking 'can appear as a set of single methods, tools, or even as a holistic approach.' The paper also concedes the incompleteness of its own framework: 'we cannot yet unfold a complete picture of how principles, work results, and methods as found in Design Thinking and other Software Engineering practices (beyond Requirements Engineering) exactly relate to each other.' That concession, along with the full model being placed in a Web Extra, is an external-validity limitation rather than circularity: no equation, fitted parameter, or definition is reused as its own output, and the recommendations retain independent qualitative content.

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

The paper's proposals rest primarily on experience-based assumptions about the applicability and completeness of the artifact model and the strategy taxonomy. No quantitative parameters are fit, apart from the conceptual role of a 'human-centric requirements engineer' introduced as a new role, which is not a physical invented entity.

assumptions (3)

domain assumption Design Thinking is applicable to requirements engineering contexts, especially in wicked problem settings.
The entire premise of integration relies on Design Thinking being a suitable approach for software requirements, asserted from the authors' experience and prior literature (Section 2).
ad hoc to paper The artifact model of 40 artifacts across context, requirements, and system layers is a valid representation of the work products of Design Thinking and Requirements Engineering.
The model is created from the authors' industrial experiences and not independently validated; the full model is only referenced as a Web Extra (Section 3.1).
ad hoc to paper The three integration strategies are distinct and cover the meaningful ways to combine Design Thinking and Requirements Engineering.
The strategies emerge from the authors' project experiences and are presented as a taxonomy, but no systematic survey or validation supports their completeness (Section 3.2).

how reviews work

0 comments

Cite this review

Pith. "Pith review of On Integrating Design Thinking for a Human-centered Requirements Engineering." pith.science (2026). https://pith.science/paper/BWXJKRU2

@misc{pith2026190807223,
  author       = {Pith},
  title        = {Pith review of: On Integrating Design Thinking for a Human-centered Requirements Engineering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BWXJKRU2}},
  note         = {Machine review of arXiv:1908.07223}
}

read the original abstract

In this position paper, we elaborate on the possibilities and needs to integrate Design Thinking into Requirements Engineering. We draw from our research and project experiences to compare what is understood as Design Thinking and Requirements Engineering considering their involved artifacts. We suggest three approaches for tailoring and integrating Design Thinking and Requirements Engineering with complementary synergies and point at open challenges for research and practice.

Figures

Figures reproduced from arXiv: 1908.07223 by the authors.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

1 extracted references · 1 canonical work pages

[1]

just there

IEEE SOFTWARE, MANUSCRIPT ID 1 On Integrating Design Thinking for a Human-centered Requirements Engineering Jennifer Hehn, Daniel Mendez, Falk Uebernickel, Walter Brenner, Manfred Broy Abstract— In this position paper, we elaborate on the possibilities and needs to integrate Design Thinking into Requirements Engineering. We draw from our research and proj...

work page 2013

Pith tools

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

[1] [1]

just there

IEEE SOFTWARE, MANUSCRIPT ID 1 On Integrating Design Thinking for a Human-centered Requirements Engineering Jennifer Hehn, Daniel Mendez, Falk Uebernickel, Walter Brenner, Manfred Broy Abstract— In this position paper, we elaborate on the possibilities and needs to integrate Design Thinking into Requirements Engineering. We draw from our research and proj...

work page 2013