Dead Code Doesn’t Talk - Authentic Requirements Elicitation in Introductory Software Engineering - Case Study Findings

Sep 12, 2026

Upload by Miles

Requirements elicitation is central to software engineering communication, yet undergraduate curricula often treat it as a theoretical topic rather than a lived client interaction. This paper reports a case study from an Introduction to Software Engineering course where 20 student teams elicited requirements for a Java-based 2D game, using 18 campus doctoral and postdoctoral researchers as authentic clients. Across four phases, the teams produced 203 requirements, SRS documents rated 6.79/10, and prototype demos scoring 7.21. A pre/post survey showed significant gains in all eight soft-skill dimensions, especially stakeholder empathy and negotiation.

LanguageEnglish

CategoryPresentations

FormatPDF

Pages6

Reading Time2 min

AccessFree to download

Abstract

I. Introduction

Communication and the requirements gap

Context and course design

Contributions

II. Related Work

Requirements engineering education

Stakeholder involvement and outcomes

Soft skills in computing curricula

Experiential and project-based learning

Dead Code Doesn’t Talk: Authentic Requirements Elicitation in Introductory Software Engineering Santiago Berrezueta-Guzman Technical University of Munich Heilbronn, Germany Vanesa Metaj Technical University of Munich Heilbronn, Germany Stefan Wagner Technical University of Munich Heilbronn, Germany arXiv :2604 .072 1 1v 1 [ cs .CE] 8 Apr 2026 Abstract—Requirements elicitation is among the most communication-intensive activities in software engineering, yet it receives limited explicit treatment in undergraduate curricula. This paper presents a case study of an Introduction to Software Engineering course in which 20 student teams applied requirements elicitation practices to a Java-based 2D game they had built in a prior programming course, engaging 18 campus doctoral and postdoctoral researchers as authentic clients. Structured across four phases—preparation, client meeting, requirements elaboration, and a prototype sprint—the activity produced 203 elicited requirements, SRS documents with a mean quality score of 6.79 ± 1.08 out of 10, and prototype demonstrations scoring 7.21±1 .15. A pre/post self-assessment survey revealed statistically significant improvements across all eight measured soft-skill dimensions, with the largest gains in Stakeholder Empathy (∆ = +1 .33) and Negotiation (∆ = +1 . 13). Thematic analysis of reflective reports identified four dominant learning themes, with the tension between client wishes and technical feasibility cited asthe most professionally relevant experience. Our findings suggest that anchoring elicitation practice to a student-authored artifact lowers cognitive barriers while increasing authenticity, and that campus researchers serve as an accessible and effective proxy client for programs without established industry partnerships. Index Terms—Requirements Elicitation, Software Engineering Education, Soft Skills, Project-Based Learning, Stakeholder Communication, Agile Development, Client Interaction I. INTRODUCTION The software engineering profession demands more than technical proficiency. Studies consistently show that communication failures, unclear requirements, and stakeholder misalignment remain among the leading causes of project failure [1] . Despite this, introductory software engineering courses often treat requirements engineering as a theoretical module—taught via textbooks, followed by a simplified inclass exercise—rather than as a live, socially embedded practice [2] . The result is a well-documented gap: graduates can describe the phases of the Software Development Life Cycle (SDLC) but struggle to conduct a productive client interview, manage conflicting stakeholder priorities, or translate ambiguous natural-language requests into actionable specification artefacts [3], [4] . This case study comes from a B.Sc. Information Engineering programme. In the first semester, students take Fundamentals of Programming (FoP), which uses a Project-Based Learning approach built around a 2D Maze Runner game in Java. By the end of the course, each team has a working, documented codebase covering object-oriented design, collision logic, maze loading, and a GUI. In the next semester, the same students take Introduction to Software Engineering (ISE) . Instead of starting from scratch, ISE builds directly on what they already made: teams approach real campus stakeholders, run requirements-elicitation sessions, and write formal specification documents for extensions to their own game. This creates a genuinely authentic learning context—students know their codebase inside out, clients can interact with a live prototype, and the resulting feature requests are both technically grounded and user-driven. This paper makes the following contributions: (1) A replicable pedagogical design for embedding client-facing requirements elicitation into an introductory SE course using a preexisting student artefact. (2) A structured analysis of how diverse client backgrounds (n

FAQs

How was authentic requirements elicitation implemented in the course case study?

Twenty student teams applied requirements elicitation practices to a Java-based 2D game, using 18 campus doctoral and postdoctoral researchers as client proxies through structured phases.

What measurable outputs did the student teams produce?

The teams produced 203 elicited requirements, generated SRS documents with a mean quality score of 6.79 ± 1.08 out of 10, and delivered prototype demonstrations scoring 7.21 ± 1.15.

What improvements did students show in soft skills?

A pre/post self-assessment survey found statistically significant improvements across eight soft-skill dimensions, with the largest gains in Stakeholder Empathy (Δ = +1.33) and Negotiation (Δ = +1.13).

Sep 12, 2026

Upload by Miles