Keywords

1 Introduction

There are many names that can be given to the process of collecting end user requirements, for example, requirements gathering, requirements elicitation and requirements engineering. For the purpose of this chapter, we will use the term requirements elicitation. When developing (entertainment-focused) computer games, requirements elicitation is often disregarded, or if requirements are collected, this is often done quite late in the development process (Kasurinen, Maglyas, & Smolander, 2014). Serious games differ in this regard due to their primary focus on learning (or pedagogy). Here, an in-depth understanding of the end user characteristics and needs is vital early on to ensure the game can fulfil its intended purpose.

Abugabah and Alfarraj (2015) found that a large portion of projects did not meet their end users’ needs. Furthermore, an even larger number were seen to exceed their budget. A well-known example is the BBC Digital Media Initiative which cost over £98 million and was abandoned after 5 years because it failed to “keep pace with new developments and requirements within both the BBC and wider broadcasting industry”. Ultimately, if a product does not comply with end user requirements, the project is not a success (Hickey & Davis, 2003; Kasurinen et al., 2014). Thus, the collection of user requirements has the power to determine the success or failure of a project (Davis, Hickey, & Moreno, 2006; Kumar & Sharma, 2015; Lane, O’Raghallaigh, & Sammon, 2016; Nuseibeh & Easterbrook, 2000). If incorrect information is gathered, requirements are misinterpreted or change through the course of development, projects may have to be abandoned or rescued with considerable additional developmental costs.

There are many factors which can impact the efficacy of the requirements elicitation process. Successful gathering of user requirements is not simply a question of choosing the correct technique. The process hinges on many factors, for example, how the technique is carried out or even the mood of users, which can impact on the quality of the requirements gathered (Lane et al., 2016).

This chapter will discuss why end user requirements elicitation is so important. It will then progress to discuss different methods and techniques of collecting requirements, before looking at how to overcome possible challenges in the process. Finally, this chapter will discuss the processes used to collect end user requirements using the AUGGMED project (see Chap. 6 for project details) as a positive example.

2 The Importance of User Requirements Elicitation for Serious Game Development

Unlike computer games for entertainment where the game is frequently designed by the development team with few early interventions from end users (Kasurinen et al., 2014), serious games are more utilitarian and centred around end user needs. It is therefore imperative that end users are involved in the design of the game to ensure that their pedagogical needs are met (Hauge, Duin, Oliveira, & Thoben, 2006). Conversely, whilst the game is being developed, it is also important to have input from developers in the requirements gathering process, as this will ensure that the created is of sufficient quality and that expectations for a game system are not set unreasonably high for the given budget.

The main purpose of requirements gathering is thus to capture the expectations and needs of intended end users. It ensures that the game is developed from multiple perspectives (i.e. designers and intended users) and that designers obtain specific information and details to create a holistic vision of what the final product will and should encompass.

There often are tensions about what is required of the system after the initial game proposal, as end users likely have little experience of developing games and may struggle to envisage the end product (Hauge et al., 2006). Leffingwell (1997), for instance, found that 40–60% of errors in a system were attributable to errors in requirements elicitation or in the analysis phase of a project (also Hauge et al., 2006). Requirements gathering can act as a bridge between developers and end users that helps to ensure that both sides are on the same page and share the same perspective about the final product (Lane et al., 2016).

3 User Requirements Elicitation Techniques

User requirements elicitation for serious games can be (and often is) an iterative process of refining low-level concepts into a highly detailed prioritised list of requirements. According to Kumar and Sharma (2015), end user requirements gathering includes four stages:

  1. 1.

    Elicitation – identification of the relevant stakeholders, reason(s) to develop the system, user roles and characteristics, external interfaces, non-functional requirements and specific quality and reliability targets and to establish a clear vision of the project

  2. 2.

    Analysis and specification – development of a conceptual model of the game, prioritising the requirements and analysing the risks

  3. 3.

    Validation – verification that requirements correspond to users’ needs using iterative feedback from stakeholders

  4. 4.

    Management – monitoring that the process adheres to user requirements, including the measurement of defects and controlling modification in requirements

Others have separated these four phases into six stages, separating analysis and specification into their own disparate stages and adding a verification stage (e.g. Courage & Baxter, 2005).

3.1 Participant Recruitment

End users for serious games are often trainees or trainers in a specific professional field, for example police officers training interviewing techniques (see Chap. 1) or first responders preparing for the handling of major crisis events (see Chap. 10). The type of end users should be established at an early stage of the game/concept design process to ensure that their expectations and needs inform the design process from the very start.

Depending on the nature of the project, end users may be stakeholders in the development project, reducing barriers to the recruitment. If end user stakeholders are not directly involved in the development project, then relevant end users will need to be recruited externally. In both cases, care needs to be taken to achieve a sufficient number and diversity of relevant individuals.

Once the end users are enrolled in the process, an important part of the requirements elicitation process involves getting to know the end users, obtaining an understanding of their roles, attitudes, values, skills, knowledge and behaviours in relevant situations. This in-depth knowledge is captured in a persona (or multiple personas) to guide the game design and development process.

3.2 Choosing Methodologies

A wide variety of methodologies exist for user requirements elicitation, ranging from interviewing to field studies (see Table 7.1). Several studies have aimed to determine the most effective method of requirements elicitation, often suggesting interviewing as the most appropriate approach (Davis et al., 2006). However, as Lane et al. (2016) suggest, it is difficult to assess the effectiveness of requirements gathering techniques quantitatively, as the fit of the method depends on the context of the project. Relatedly, Hickey and Davis (2003) found that design experts often tend to favour one specific data collection technique instead of evaluating the best techniques for the specific project and users in question. To avoid this bias, this section will discuss a range of common techniques and discuss where they may be most useful. This will help to make an informed decision about requirements gathering techniques driven by the context of the project.

Table 7.1 Strengths and weaknesses of typical requirement elicitation techniques. (Based on Courage & Baxter, 2005)
Full size table

Whichever method is chosen, it is vital to plan every method meticulously before starting the collection of requirements. An important consideration is the type of information designers wish to acquire from their end users. Another is the time and effort required to gather the relevant information. In Table 7.1, we list common methods to obtain end user requirements as well as their advantages and disadvantages. Beyond the techniques in Table 7.1, also newer and more elaborate approaches exist (e.g. gamification techniques; Kelly, de Boer, Uhlenbruck, & Webb, 2015).Footnote 1

3.3 Planning

Before the requirements gathering activities take place, it is important for end users to be made aware of the aims of the project and the benefits of the use of serious games to train and educate. It may also be beneficial to brief end users about the history of serious games and to provide examples of the game mechanics that can be employed in gamification and simulations (see Chap. 5) to provide end users with a clear understanding of what the project aims to achieve. It should be noted that by introducing demonstrations of serious games, users may be influenced in their requirements and expectations for game mechanics. For this reason, careful consideration is needed about when to demonstrate current serious game capabilities.

Whatever the chosen elicitation method, there are numerous aspects that will need to be planned. Often end users will have very busy schedules, especially when dealing with LEAs and first responders, so it can be a challenge to find a time convenient for all end users involved. In this case, methods that do not need to be moderated, such as surveys, may be preferable.

Requirements are often separated into functional and non-functional requirements. Functional requirements relate to front-end behaviours, whereas non-functional requirements refer to system capabilities such as performance and maintainability (Hauge et al., 2006). When planning requirements elicitation activities, both of these areas should be investigated.

Frequent questions guiding requirements elicitations are:

  • What are the current training capabilities and their strengths and weaknesses?

  • How could these be improved through the use of serious games and/or virtual reality?

  • What are the learning outcomes, and how will they be evaluated?

  • What game mechanics should be included in the game (e.g. score system, leader boards, etc.)?

  • What are the desired functionalities to be included in the game?

  • How adaptable should the game or simulation be?

  • What is the budget?

  • What is the timescale?

  • What are the system requirements (e.g. should it be run over a network)?

  • What will the style of the game be (e.g. will the game follow a story, or should it be more of a simulated scenario)?

  • What are the general technical abilities of the users?

These are just a few examples of questions that often appear in requirement elicitations. The aim should be to obtain as much initial information from end users as possible and then to refine ideas along the process.

Creating a relaxed atmosphere that avoids time pressure, a setup that is sensitive to potential conflicts between participants from disparate organisations (e.g. police officers and NGOs) and expert moderation facilitates the collection of meaningful and detailed requirements. An agenda for the day should be prepared and communicated early to participants. In the planning, it is important to allow sufficient time to explain the project and its purpose thoroughly, including the current state of the art, to ensure end users are aware of the aims, expectations towards them and their investments for the project.

Throughout the requirements gathering process, it can help to repeat the outcomes that have been recorded to ensure that participants agree with the information and none of the information has been misinterpreted or missed. To prevent loss of information the event should be recorded, either through careful minute taking or through video or voice recording. In case of the latter, consent must be explicitly given by all participants before recording any data.

3.4 Analysis

Analysis of the recorded information should begin immediately after the event, this will again prevent loss of data and misinterpretations. The following are common methods used to analyse results of end user requirements gathering:

  • Coding – Coding is a common analysis approach for qualitative data. It refers to the process of assigning summative words or short phrases to part of transcriptions or documents. These initial codes can then be combined into higher-order categories to identify common themes or unique and conflicting perspectives (Langdon, 1984).

  • Categorising – Can be used with both qualitative and quantitative data. It aims to identify common themes within the data and thus aids the summarisation and interpretation of data. Categorisation helps to prioritise the development of features within the system.

  • Affinity diagrams – The creation of an affinity diagram is generally a team activity between stakeholders involved in the end user requirements gathering. The data collected through brainstorming sessions is segmented into small pieces, which are then grouped according to relationships. It is important to approach this activity without preconceptions or predefined categories in mind to allow themes to evolve naturally throughout the process.

Results should always be validated. This can be done by presenting results or summaries of the results to stakeholders who were present at the event, or a new set of end users with the same characteristics. If multiple elicitation sessions are planned, a choice can be made whether to conduct an analysis between each session or once all the data has been collected. Whilst the second approach saves time, the first approach allows to adapt data collection (e.g. type of people invited to the sessions, type and content of questions or collection methods) to delve deeper into specific sub-themes.

3.5 Management

The conscious management of end user requirements ensures that the project continuously complies with end users’ needs, even if they shift. Both developers and end users should be able to add unplanned features they believe will be beneficial. At the same time, repeated discussions should not lead to feature creep and overcomplicate the system, meaning that some requirements may have to be purposely left off the documentation (Courage & Baxter, 2005).

3.6 Verification

Throughout the development, a continuous engagement process should ensure that the chosen end users are still relevant and that their needs have not changed. This can be done by piloting the system in different iterations along the development process (cp. Chap. 6).

3.7 Negotiating Requirements

The requirements elicitation process focuses on discovering end user’s needs. This process also has an element of negotiation, as end users may wish to incorporate features into the game which may be out of scope or impossible to realise given the budget. Ahmad (2008) created a requirements negotiation spiral to illustrate common phases in the negotiation (see Fig. 7.1).

Fig. 7.1
figure 1

Requirements negotiation spiral. (Ahmad, 2008)

Full size image

The spiral starts with the identification of potential conflicts, which are common if users want functionalities that would exceed the given budget or timescales for the project. In this case, alternative solutions should be suggested. Once the alternative solutions have been agreed, they should be elaborated so that end users are aware of where the compromise has been made. This will help to forestall disagreements in the future and allow end users to make an informed decision about which solution they would like to pursue. If any parties involved are still unhappy at this point, renegotiations can be reopened.

4 Common Barriers in Requirements Elicitation and Possible Solutions

Even with meticulous planning prior to the requirements gathering activities, it is still possible to encounter unforeseen issues. Listed below are a number of common issues and suggestions on how to avoid or overcome them.

  • Language barriers  – Questions should be formatted in simple language, avoiding the use of technical terminology (if this terminology is necessary, a clear and concise explanation should be provided). Questions should be asked in the mother language of participants where possible to allow participants to express themselves in their mother language. If this is not possible, questions should be presented in both written and spoken forms as participants may feel more comfortable reading in foreign languages.

  • Lack of common understanding  – By frequently summarising the information that has been captured from participants, it allows the opportunity to correct misunderstandings and gaps early on and ensures that all of the information has been interpreted as intended.

  • Scope of information  – Methods of requirements gathering such as interviews and focus groups often unearth a plethora of information. This can make it difficult to analyse and draw conclusions, especially in terms of prioritising needs and requirements. When dealing with large amounts of data, collating the data into smaller common themes can help to summarise and interpret the data. At this stage it also good practice to go back to end users for validation of summaries.

  • Volatility  – It is not uncommon that requirements change over time. A series of end user requirement studies will retain the contact with the end user and ensure that they are informed about developments and content with the work that is being produced.

  • Bias  – Unconscious bias is sometimes hard to avoid. Special attention should be given to the wording of questions and instructions, as it is easy to ask leading questions or provide examples which may inflict opinions and views on participants. Good practice is to pilot questions, surveys, prompts and examples with a different group from the intended end users to make sure they are easy to understand. Further, interpretations should be checked by participants and against additional sources to avoid narrow or selective representations of results. Below are suggestions for the formulation of questions, especially in the context of interviews:

    • Avoid putting words into peoples’ mouth

    • Be aware of putting emphasis on specific words

    • Avoid using loaded words or words with positive or negative connotations in the study setting

    • Ensure the questions are formulated clearly and unambiguously

    • Keep questions short, as participants may struggle to remember complex questions and feel overwhelmed

    • Avoid or limit the use of closed questions, especially questions that can be answered with yes/no

  • Participants feel uneasy  – Participants should feel comfortable enough to express their views and opinions free from judgements of other participants or moderators. Interviews and focus groups can be an uncomfortable experience for participants if they feel they are being judged for giving an ‘incorrect’ or ‘embarrassing’ answer. To make the participants feel comfortable, the following strategies can be implemented:

    • Sessions should be conducted in five stages: introductions, warm-up questions, main questions, summary and wrap-up.

    • Participants should be interrupted as little as possible.

    • All focus should be on the subject to ensure that they feel their views are valued and important. Summarising in a non-judgemental way what the participants said can show that their views are being heard and noted.

  • Losing focus  – The moderator should ensure that the focus is kept on appropriate subjects and discussions do not veer off into irrelevant topics.

5 Conclusion

Requirements elicitation is a crucial milestone of the serious game development process. Without successfully collecting end user needs, it is impossible to create a product that is fit for purpose. As outlined above, the process of requirements gathering can be separated into five stages: elicitation, analysis, specification, validation/verification and management. The actual process of elicitation is flexible in the sense that data collection techniques need to be adopted to the specific situation and end users in a game development project. All requirements gathering activities should be thoroughly planned and any foreseeable barriers should be addressed prior to the event. Interviews are often argued to be the most effective method of eliciting requirements. However, more innovative techniques (e.g. playing games) can inspire additional insights. Although the initial session has probably the biggest impact in terms of starting the game development, further engagements should be of help throughout the process to ensure the development keeps on track with (changing) user requirements.