Digital technologies can improve the daily lives of people with cognitive disabilities, allowing them to participate and communicate in society. However the success of a technical product depends not only on the price or lifespan, but also on its user experience. To ensure user satisfaction when creating new technology or products, it is necessary to know their needs. This article presents methods of requirements analysis and elicitation for digital participation together with people with cognitive impairments.
1 Introduction
The topic of human-machine-interaction for people with cognitive disabilities requires an interdisciplinary approach, taking into account methodological as well as legal, ethical and social implications that have hardly been found in research and development up to date. Up to now, computer software has only been developed sporadically with accessibility for people with cognitive disabilities in mind.
Before developing a user interface, as in any product development, understanding the requirements of the target group is an important aspect in order to obtain results that are accepted, desired and usable by the customer.
Anzeige
Current studies show that in general there is a persistent discrepancy between requirements engineering research and requirements engineering in practice, which leads software developers to ignore the needs of users [1]. The situation is even more serious for people with cognitive disabilities, as many methods of requirements engineering cannot be applied 1 to 1, or have never been tested before.
Therefore, developers usually assume that the target group has suspected requirements and create the product without their direct involvement. Although there are concepts for requirements analysis for the development process of common software products, rarely one of them directly asks users with cognitive disabilities during the design phase. At the earliest when the product is almost ready, they are included in the test phase and integrated as test users. The result for the target group is often dissatisfaction and frustration due to poor user experience and product usability. This paper presents a new approach to involve people with cognitive disabilities in software development from the initial design phase to develop products that meet their needs.
2 State of the Art
Requirements engineering in today’s software engineering process usually starts with a problem description and the environmental conditions of the system to be developed and ends in concrete requirements that can be implemented by software developers [1, 2]. Current state of the art techniques can be categorized in [6]:
requirements elicitation and discovery,
requirements modelling,
analysis and specification.
Each category hosts different techniques and methods that can be used to determine the requirements of potential users. This paper will focus on requirements elicitation and discovery which is about describing the functionality, reliability, efficiency and usability of the system to be developed so that it suites the end users’ needs [1]. Common techniques for requirement’s engineering were categorized by Nuseibeh and Easterbrook [7] in the following groups:
Traditional techniques: These techniques include questionnaires, surveys and analysis of existing documentation to collect the requirements of end-users [8].
Prototyping: Requirements are collected by prototyping either with pen and paper or with a real software product. This allows developers, designers and end-users to work closely together and specify the requirements.
Group elicitation techniques: Group techniques aim to foster stakeholder agreement and buy-in, while exploiting team dynamics to elicit a richer understanding of the needs [7]. Common examples for this techniques include brainstorming, focus groups, rapid application development and workshops.
Contextual techniques: Here the requirements are gathered by observation of costumers and end-users directly at the customer’s workplace. Examples for contextual techniques are participant observation where the observer gets the requirements from observing team discussions, interviews, documents and non-verbal interaction.
Cognitive techniques: Cognitive techniques allow analyzing and gathering information up to the human thinking level [9]. They include protocol analysis, where an experts performs a task while thinking aloud and an observer documents the cognitive processes used to perform the task. Another method is card sorting, where stakeholders are asked to sort cards into groups.
Model-driven techniques: These techniques analyze the information that is gathered by the system and use this model to drive the elicitation process.
Anzeige
Most of these techniques were never used in cooperation with people with cognitive disabilities, therefore many of today’s systems are not developed and designed for people with cognitive disabilities. A common prejudice in the scientific community is that people with intellectual disabilities are not very reliable interview partners, as they would not be able to give valid answers in the context of surveys [15]. We would like to overcome this and show that with appropriate preparations and adapted research tools and methods the target group may gain a position to work on its own behalf. On the other hand, the involvement of the target groups as peer researchers always requires a high willingness and intuition of the researchers and developers.
3 Design and Method
For requirements elicitation of software an integrative design oriented research approach supporting and including peer researchers has to be created. This approach will be done by combining two existing design methods: Inclusive Participatory Action Research – IPAR [5] and User Centred Design – UCD [16].
The IPAR method by Janice Ollerton is a variation of the Participatory Action Research (PAR). IPAR includes people with cognitive disabilities in all steps. IPAR provides a framework for integrative participatory action research (fusion of integrative research approaches and participatory action research). It is a practical, alternative methodology for integrative research design with accessible data collection and analysis tools. IPAR questions the traditional research relationships in which research is conducted instead of with people with intellectual disabilities.
UCD [16] is a design methodology that puts users at the heart of the design process. In particular when it comes to systems and appliances for a mass-consumer market the involvement of user groups at all stages of research processes has proven to be essential for better usability and improved product/output quality. Studies underline that reasonable investment in UCD leads to substantial return in terms of higher efficiency, less maintenance, less complaints and higher usage/client rates.
The integration of IPAR and UCD should provide the basis for the participation of co-researchers with cognitive disabilities. In order to develop proper methods and tools as methodology, individual steps within the requirements engineering process, such as requirements elicitation methods, are selected, developed and evaluated together with people with different competencies. This is done by:
Evaluating current methods and tools for requirements engineering: Literature research and well-known findings of existing tools will be examined and formally tested if they suit the needs of the target group.
Developing new methods that suites the needs of the target group: This will be done by Design-Based Research. DBR uses a mix of methods to analyse and improve the methods of UCD [3].
Resulting methods and processes will be applied to a real software project where people with cognitive disabilities (peer researchers) will be involved.
4 Approach
4.1 Recruiting and Instruction
In order to select, adapt and to develop methods for requirements elicitation people with cognitive disabilities are invited to participate in a real software project as peer researchers. This was initiated with a first workshop that provided them with an overview on the goals of the project and about the working conditions. This workshop is of utter importance and should create a common understanding on the functionality and purpose of the software that is going to be developed within the software project.
4.2 Requirement Analysis and Methods
In the next step selected methods and tools for requirements elicitation will be tested and evaluated with the co-researchers. The specification can be clarified by the user perspective with use cases. These include the functional requirements described by the participants, for example what is missing, what is disturbing and what is good. In a first step, the following methods, which seem to be useful for requirement analysis, were selected:
Focus group: A focus group shares their thoughts, feelings and attitudes towards an already existing software product or prototype [10]. This is especially useful as input for new software systems as feedback from users identify useful features and problems in existing systems. The focus group is a moderated group discussion. First, the topic/task of the session is determined. Usually 6–10 peer researchers or potential target group members participate in a session. They share their attitudes and thoughts, for example about an existing software product or prototype. These results help to review existing concepts and to gain new ideas and input for new software systems. A moderator chairs the session by providing help, asks questions, sums up and makes sure that the focus is not lost during the discussions. This method can be used in any phase of the UCD.
User stories: This method provides an alternative to the focus group. The requirements of the user are collected at the beginning of a development by user stories of himself and formally documented to identify the extent of a system [11]. In doing so, the user goals and intentions are e.g. noted on an index card. In the simplest case, these can be just one or two sentences. Then a priority is given by the peer researcher (from 1 to 5 where 1 is the highest priority, or high, medium, low).
Use cases: Here, peer researchers can have a voice from the user’s perspective. They can report on their real-life experiences and share their thoughts on what applications of a system or product they needed [12]. This specifies the requirements for a system and defines the features that the system should have for the end users. The functional variety of a product or software is broken down into understandable and related units. Use cases are also an instrument to find out who should use the product and what the product should do for the user.
Storyboard: Storyboards use illustrations/images that are shown one after the other, for example to visualize an interactive media sequence in advance [13]. It illustrates interactions between a person and the product or software. Peer researchers are then able to use these images to contribute their own ideas and views on the required features of the software or product.
The Easy Cognitive Walkthrough: This method is a modified version of the cognitive walkthrough method - a procedure in which peer researchers, as experts, with or without the support of a test moderator, perform tasks with the product that were previously described as a typical task, taking into account the expected knowledge and skills of the target group [14]. Each step is analysed by the co-researchers from the perspective of another user and thus problems and required features should be identified.
4.3 Communication Is Necessary
Inclusive requirements engineering in a software project, requires intensive communication between all participating stakeholders. This exchange can be done during daily meetings of relatively short duration, reflection rounds or workshops for the collection of requirements.
When stakeholders, with or without cognitive disabilities are willing to exchange information and communicate within the project, requirements and needs of stakeholders are easier detected resulting in a better product.
5 Current Results
Currently the first methods are tested and evaluated with the co-researchers in a software project, dealing with the creation of a browser-extension helping people with cognitive disabilities to improve their ability to browse and understand web-content.
A preliminary evaluation of testing the different methods with end-users shows that a requirement analysis with the target group is feasible and that the people with cognitive disabilities are reliable interview partners which are quite capable of expressing their needs in this way. It is being observed that all peer researchers take their task very seriously and on the other hand they show interest and a certain degree of personal responsibility.
As can be seen in Fig. 1 the cooperation between peer researchers and developers in a focus group are quite positive. Peer researchers actively participated in the process and expressed their requirements and needs. On the other hand software developers and designer got a deeper insight in the requirements of their end users which led to new interaction and information presentation concepts. In this project the peer researchers are located in the same building as software developers and designers, which allows short communication way and fosters exchange of thoughts which is very positive.
Fig. 1.
Performing the focus group method with co-researchers on a prototype interface
×
Regarding the software development process itself an agile software development process seemed appropriate for the target group. This implies that the peer researchers and developers constantly work together on their own behalf during the project.
Acknowledgments
This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No. 780529).
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
