Evaluating Games-Based Learning

Evaluating Games-Based Learning

Thomas Hainey (University of the West of Scotland, UK) and Thomas Connolly (University of the West of Scotland, UK)
Copyright: © 2010 |Pages: 15
DOI: 10.4018/jvple.2010091705

Abstract

A highly important part of software engineering education is requirements collection and analysis, one of the initial stages of the Software Development Lifecycle. No other conceptual work is as difficult to rectify at a later stage or as damaging to the overall system if performed incorrectly. As software engineering is a field with a reputation for producing graduate engineers who are ill-prepared for real-life software engineering contexts, this paper suggests that traditional educational techniques (e.g. role-play, live-through case studies and paper-based case studies) are insufficient in themselves. In an attempt to address this problem we have developed a games-based learning application to teach requirements collection and analysis at the tertiary education level. One of the main problems with games-based learning is that there is a distinct lack of empirical evidence supporting the approach. This paper will describe the evaluation of the requirements collection and analysis process using a newly developed framework for the evaluation of games-based learning and will focus on evaluation from a pedagogical perspective.
Article Preview
Top

Problems In Teaching Requirements Collection And Analysis And Software Engineering

The problems associated with teaching software engineering have been discussed in detail in a previous study (Connolly et al., 2007). Problems specifically associated with teaching requirements collection and analysis are deeply rooted in the lack of definitional conformity to what a requirement is.

Software Requirements

The IEEE defines a requirement as “a condition or capability needed by a user to solve a problem or achieve an objective” or “a condition or capability that must be possessed by a system to satisfy a contract standard, specification or other formally imposed document.” A requirement is a statement specifying part of the required functionality of the system. One of the primary reasons that requirement capture and analysis is so problematic and complex is that a requirement can be expressed in different levels of abstraction or complexity. Sommerville (2007) emphasizes “the term requirement is not used in the software industry in a consistent way. In some cases, a requirement is simply a high-level, abstract statement of a service that the system should provide or a constraint on the system. At the other extreme, it is a detailed, formal definition of a system function” (p. 118). To combat the complication encountered by the different levels of abstraction, Sommerville (2007) distinguishes between user requirements and system requirements:

  • •

    User requirements (requirements of a high level of abstraction) are “statements, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate.” (p. 118)

  • •

    System requirements (requirements of a highly detailed nature describing what the system should do) “set out the system’s functions, services and operational constraints in detail. The system requirements document (sometimes called a functional specification) should be precise. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.” (p. 118)

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 11: 2 Issues (2021): Forthcoming, Available for Pre-Order
Volume 10: 2 Issues (2020)
Volume 9: 2 Issues (2019)
Volume 8: 2 Issues (2018)
Volume 7: 2 Issues (2017)
Volume 6: 1 Issue (2016)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing