Definition

Requirementsdefine what a potentially new system must be capable of to solve a specific problem or need [114]. Literature separates requirements into functional and non-functional requirements [31, 43, 131, 154, 212]. Functional requirements are "[...] a function that a system or system component must be able to perform."

[114] as the IEEE standard states. In the literature, there is a broad consensus about this term, as Glinz [84] found. For example, Glinz shows literature that provides similar definitions, such as requirements are "what the product must do" [206] or "what the system should do" [229]. In the Book “Managing Require-ments Knowledge”, Maalej and Thurimella state that the term requirement is similar to features, but that it has a larger scope and more technical focus [154].

For non-functional requirements, there is no agreed-on definition, as Glinz [84]

showed in 2007. In this work, we follow the definition given by Glinz, which is

“A non-functional requirement is an attribute of or a constraint on a system” [84].

Stakeholders are a group of people that are involved in deciding the require-ments of a system. Typical stakeholders are, among others, customers, develop-ers, project managdevelop-ers, andusers[85]. The decision-making process of stakehold-ers is often about choosing between alternative requirements that can apply to solve a specific issue [154, 196]. Stakeholders have various backgrounds as they can come from, e.g., business, marketing, law, project management, design, and development, and therefore, have diverse roles and tasks [154]. Stakeholders typi-cally express their needs for a system in natural language, although that language may be ambiguous as the stakeholders’ perspectives and backgrounds differ [60].

Requirements engineering is the process of formulating, documenting, and

systematically maintaining software requirements [131]. Similarily, Sawyer, Som-merville, and Viller define requirements engineering as “Requirements engineer-ing is concerned with the discovery of required properties (the requirements) and their transformation into a form which will serve as the basis for development of a product which will exhibit those properties.” [219]. However, as technical issues may arise during the development or the needs of stakeholders may evolve, requirements engineering is not a single-phase process. On the contrary, requirements engineering is a continuous and iterative process that must adapt to change [26, 60, 219]. The literature highlights the importance of change man-agement [154] as requirements engineering is a complex process that might not get all of the necessary requirements right from the start of a project. Reasons for this are, among others, that clients are unsure what the final product should be, stakeholders have tacit knowledge, or any event or wrong decision during the project may impact the solution. Poorly managed requirements lead to risks in the project, such as exceeding the budget or failing the project, making re-quirements engineering one of the most critical processes in projects. Boehm and Basili [25] found that identifying and fixing a problem in the software after its de-ployment often costs 100 times more than identifying it during the requirements and design phase [25]. Second, the authors also show that projects spend about 40-50% of effort in avoidable reworking, which again highlights the importance of requirements engineering.

Requirements engineering is a process composed of activities. Kotonya and Sommerville define the activities of the requirements engineering process as re-quirements elicitation, rere-quirements analysis and negotiation, rere-quirements doc-umentation, and requirements validation [131]. Ramesh and Cao [202], as well as Martin et al. [160] highlight that the initially proposed requirements engineering process is linear, which is in contrast to the idea that requirements engineering must adapt to change. In a later publication, Sawyer, Sommerville, and Viller [219] introduced potential improvements to the requirements engineering pro-cess, suggesting a cyclic representation of the activities. We cite the authors’

suggestion, which determined the following three activities as part of the cyclic representation [219].

1. Requirements elicitation. Given a statement of organisational needs and other inputs, different requirements sources (stakeholders, domain experts,

operating regulations etc.) are consulted to understand the problem and the application domain. The resulting requirements may be incomplete, vaguely expressed and unstructured.

2. Requirements analysis and validation. The requirements discovered during the elicitation phase are integrated and analysed. This is designed to identify problems such as missing information, inconsistencies and re-quirements conflicts.

3. Requirements negotiation. Problems discovered during analysis need to be resolved. The analysts and stakeholders clarify their understanding and consider possible solutions. This may require negotiation to establish the necessary trade-offs. The elicitation of further requirements information and the initiation of a further cycle may be necessary.

Besides these cyclic activities, the authors suggest addingrequirements man-agement as a cross-section activity that also stretches over the whole develop-ment process. It is the activity that is responsible for handling both new emerging requirements and general changes to exiting requirements. Requirements man-agement ensures requirements traceability and the enforcement of the change.

The overall goal of representing the requirements engineering process cyclic is to cope with the three challenges of the difficulty of elicitation, changes to re-quirements, and the limitations of time and costs [219]. The literature agreed on the importance of change management in requirements engineering, which led to several publications supporting a cyclic representation of the process [26, 111, 199]. Yet, the suggested cyclic representation is difficult to include in modern agile project management and development as the activities do not map to the agile concept [202].

Agile requirements engineering is the consequence of the non-sequential pro-cess of requirements engineering in modern agile projects. Its goal is to be highly adaptive to change in agile projects, which are iterative by nature. Ramesh, Cao, and Baskerville [202] present an empirical study discussing how the four requirements activities requirements elicitation, requirements analysis and nego-tiation,requirements documentation, andrequirements validationof Kotonya and Sommerville [131] can be used in agile projects. Ramesh et al. [202] suggest the

following. Perform requirements elicitation iteratively with face-to-face meet-ings with stakeholders instead of collecting requirements once before the start of the development. Similarly, requirements analysis and negotiation are also iterative and should be carried out with face-to-face meetings, constant plan-ning, and extreme prioritization. The authors further suggest that requirements documentation is not a formal process but that requirements are documented informally as, for example, alist of featuresor stories. Requirements validation includes theusersof the system to validate if the requirements reflect theusers’

current needs. Table 2.1 summarizes and compares the agile and traditional requirements engineering process.

Table 2.1: Traditional and agile approach for requirements engineering (RE) ac-tivities (taken from Ramesh et al. [202]).

RE activities Traditional RE Agile RE Agile practices to support RE activities Requirements

elicitation

Discovering all the requirements upfront

Iterative:

requirements evolve over time and are discovered throughout

the development process

Iterative RE, face-to-face communication

Requirements analysis and

negotiation

Focus on resolving conflicts

Focus on refining, changing and

prioritizing requirements

iteratively

Iterative RE, face-to-face communication, constant planning, extreme prioritization Requirements

documentation

Formal documentation contains detailed

requirements

No formal documentation

Face-to-face communication

Requirements validation

The consistency and completeness of

requirements document

Focus on ascertaining whether the requirements reflect

current user needs

Review meetings, face-to-face communication

Conclusion 1. Requirements define what a potential system must be capable of to solve a specific problem or need. Functional requirements are sometimes also called the features of the system. Stakeholders, for example, the users of the

system, decide about the requirements. Requirements engineering is a crucial process in projects as poorly managed requirements lead to major risks such as exceeded budgets or the failure of a project. These risks include, for example, requirements not known prior to the project or tacit knowledge of stakeholders.

Projects can cope with the risks if the requirements engineering process can adapt to change. Therefore, researchers suggested a cyclic representation of the process, which later led to agile requirements engineering, which better integrates into modern agile projects. Agile requirements engineering constantly involves the users to validate if the requirements match the users’ needs. Still, the research discussed suggests interacting with users in physical face-to-face meetings, which lead to significant issues as we elaborate in the following.