The idea of Continuous Requirements Engineering in relation to a Human-Centered Agile Development Process is discussed. First, it is argued that Continuous Requirements Engineering has to cover design-time and runtime aspects. In this way maintenance is covered as well. Second, arguments are provided for integrating aspects of usability and user experience into requirements specifications. This has to be done continuously. Therefore, the term Continuous Human-Centered Development is introduced and discussed. Based on a process model for SCRUM some aspects of integrating HCD into the development process are discussed.
Agile software development methods like Scrum have become popular during the last years because of their flexibility to adapt to dynamic changing application domains and changing user’s needs during software development. They prevent the failure of projects because otherwise it takes too much time from finalized requirements specifications to first tests of the developed system However, these agile methods still focus on a limited period of time for the software development. A longer period of the application of the developed software and their maintenance are not part of these methods.
However, monitoring of running systems might be useful. In this way Continuous Requirements Engineering might be a way to focus on the integration of software development and maintenance for agile development methods.
Additionally, we believe that especially a human-centered approach leads to software systems that are usable and provide good user experience. Its integration into agile methods is another challenge.
The paper is structured in the following way. First, we describe our point of view of Continuous Requirements Engineering and its further development. Second, the Human-Centered Development Process is discussed. Third, an agile development process is suggested that includes Continues Requirements Engineering and as a part of the Continuous Human-Centered Development. The paper closes with a summary and an outlook.
Current engineering-based approaches are rooted into well elaborated systems models, enterprise architectures, ontologies, and information logistics representations. They provide transparency, reliability, and security in the whole lifecycle of the system. Currently such approaches are designed and mainly applied to large enterprises that have relatively long change cycles. In case such changes have to be performed more frequently a much higher flexibility is required. For such systems the engineering processes grow into continuous engineering that requires continuous requirements engineering (CRE). CRE can only be successful if it combines rigid engineering principles with agility, emergence, and spontaneity to support sustainability and viability of the systems under development.
Smaller scale enterprises need new approaches, methods, and tools to be capable to embrace the growing variety of opportunities and challenges offered by fast changing and hardly predictable environment. In this type of systems, continuous requirements engineering can be a solution if it is integrated with management and design approaches.
It is well known that flawed requirements cause a lot of problems. Some projects totally fail because of that, others waste a lot of money because the correction of resulted errors in the implementation is very time consuming and labor intensive. Therefore, new ideas in identifying the correct requirements are very important.
A framework for Continuous Requirements Engineering for self-adapting systems
was provided by Qureshi et al. in [
They provided a framework that is called CARE (Continuous Adaptive Requirements Engineering) for building self-adapting systems. They distinguish requirements engineering during design-time and run-time that is related to design-time reasoning and run-time reasoning for such specific systems.
Leah Goldin et al. [
Reuse of requirements specification might be one way to reduce time to market. However, there are still a lot of aspects to consider like the kind of specification languages for functional and non-function requirements.
For the handling of BPMN and S-BPM specifications concepts for reusable
components were presented in [
The idea of Continuous Requirements Engineering allows the adaptation of requirements not only during the whole design time but also during runtime. Even the adaptation of requirements during the whole design time is already an innovation for a lot of current projects. To extend this option of changing requirements to runtime is even a bigger challenge.
Within the S-BPM approach the executable design is directly specified in a notation of a diagram. These specifications are interpreted during runtime. Therefore, no transformation is necessary. Users can articulate their requirements by providing refined specifications of behavior components. This manipulation of S-BPM diagrams changes the control flow of the running system. There is even no need to stop the running system.
Indeed, the approach is very similar to CARE presented by Qureshi et al. in [
In both cases, S-BPM and CARE, users are considered to be as possible creators of such models. However, the manipulation of models can also be done by any stakeholder.
Additionally, in cases where models can drive the generation process, as in the MDA approach, requirements models can be transformed automatically to runtime models for execution. We will come back to this later in the context of Human-Centered Design.
In the same way as agile development methods are popular for software engineering experts Human-Centered Design (HCD) is popular for usability and user experience experts. It focusses on tasks users have to perform, usability and user experience, aspects that do not play their important role for software engineers in general. They focus often on the technical aspects of an application only.
One of the main reasons for the success of HCD is that the context of use and the evaluation of design solutions play an important role. User requirements are more important than technical features that software engineers might like. It is more likely that users get what they really want.
The HCD process is standardized by ISO 9241-210. It consists of a planning phase and four phases that are performed in an iterative way.
Within the first phase analysts try to understand the context of use. Stakeholders are identified. Their roles and tasks are analyzed and typical application scenarios are specified. Additionally, artefacts and tools they work with are captured. Last but not least the environment in which the application has to be performed is analyzed. This is done according to the location, the surrounding objects and people. Sometimes the available services are important as well.
Based on this analysis user requirements are specified. Additionally to the goals of users functional and nonfunctional requirements are collected. Domain specific requirements might be important as well. This is e.g. the case when domain specific standards exists that have to be fulfilled by the application.
First design solutions are produced afterwards to fulfill the identified requirements. Such design solutions include first ideas of user interfaces.
The design solutions are evaluated in the last phase of the HCD process. If the requirements of the users are met the development process comes to an end and the implementation of the application core can be performed. Otherwise, there are three possible continuations. If there are serious problems one has to analyze the context of use again and has to proceed with the first phase. In case the general analysis of the context of use seems to be correct but some requirements were specified in the wrong way, one has to rewrite some requirements or identify some new ones. Finally, it can be possible that only new design solutions are necessary. In this case requirements are specified in the right way but the design solutions have to be improved. Fig. 1gives a visual impression of the discussed HCD process model. in the following figure.
The presented process model suggests having a common initial phase for developers and HCI
specialists. Afterwards there are activities of both groups. Unfortunately, it is not quite clear in
which order these activities are performed. Additionally, the requirements elicitation is a little
bit too much uncoupled from the software development process. A stronger coupling was
suggested by Paul et al. [
There are several attempts to integrate HCI aspects like usability into agile development
processes. Examples of discussions about process models can also be found in [
In cycle two developers implement the design solutions from cycle one and in parallel their
code from cycle one is tested by HCI experts. Additionally, they design for the next cycle and
analyze for the cycle after the next cycle. This is the general development pattern. In some way
interaction designers work two cycles ahead to developers in analyzing customer data and one
cycle ahead in developing design solutions. A similar approach by separating the activities of
analysts and developers was presented in [
Human-Centered Development should also not be done only once during design time. It has to be continuously performed during the whole development process. It has even to be processed during runtime. The development cycle of analysts (within the cyclic iteration) is executed in parallel to the cycle of the developers. Details of the necessary specifications within this cycle are presented in Fig. 5. It should run at least one cycle ahead. However, some companies reported privately that they successfully applied the characterized approach without analyzing the human aspects one cycle ahead. In such cases user interface evaluation did not yield to new requirements. In general, it would be better to analyze more precisely and evaluate different alternative solutions.
This may be related to the fact that the human aspect becomes more and more important for interactive systems. Usability and user experience are key factors of success or failure of software.
It is important to have UX-specialists within the development team. Additionally, all members of the development team should be trained in the fundamentals requirements elicitation and usability evaluation. There has to be a common ground on these aspects.
Kuusinen analyses in 13 the allocation of tasks between HCI specialists and developers in agile development projects. Her studies delivered two main results.
First, HCI specialists and developers cooperate on user-interface design, while other UX aspects are downplayed.
Second, many UX-related tasks were successfully handled by developers alone.
Kuusinen suggests a task-oriented integration approach especially for projects with minimal UX resources. This is in line with the suggested process model, where task models have to be created at the beginning of the HCD process.
Innovation has always to be discussed from a human perspective. Technological innovation is important but it has to consider humans in their role as different stakeholders.
Agile development methods often focus on customers while User-Centered Design focusses on users. Both aspects have to be considered during Continuous HumanCentered Design.
We already mentioned the possibility of generating software based on models. We
have been working for several years on task-based generation of interactive systems.
Fischer et al. [
Supporting user interface generation based on models by tools allows the exploration of different designs alternatives in a cheap way. The production of solutions in the HCD process is supported effectively in this way. There might be a new push for applying models if the model-driven development of user interfaces can be used within the agile context.
The paper discussed the ideas of Continuous Requirements Engineering and HumanCentered Agile Software Development. It argues for having Continuous Requirements Engineering during the whole design-time as well as during the whole runtime. In this way changing requirements have be considered all the time and projects have to be managed during the whole life-cycle of a software system. Development teams can be reduced in size. However, according to this approach they should be always available. The analysis phase never stops.
Continuous Human-Centered Development is suggested as part of the Continuous Requirements Engineering, which means an integration of aspects of usability engineering as well as requirements engineering into the continuous agile development process. A process model for integrating Continuous Human-Centered Development into Continuous Requirements Engineering is provided and possible applications of model-driven technologies for UI-aspects are discussed.