What should be the purpose of engineering

Requirements engineering

The definitions of the term 'requirements engineering' vary in detail. However, all definitions list certain core activities (determine, specify, test) that are carried out on requirements (system properties and framework conditions), see Fig. 1. The accompanying process, which tracks changes to requirements, manages requirements documents over their entire life cycle and the The core activities of requirements engineering plans, organizes and controls is called requirements management [CMU / SEI 2006, p. 143; Sommerville 2011, p. 111; Pohl 2010, p. 594].


Fig. 1: Requirements engineering and requirements management


Requirements describe the properties that a software system must have, as well as the framework conditions that apply to its life cycle (development, operation, maintenance) [IEEE Std. 610.12-1990, p. 62; Rupp et al. 2009, p. 17 f.]. Fig. 2 summarizes the types of requirements.

Fig. 2: Types of requirements

With regard to the properties of the software system, functional requirements and quality requirements can be distinguished [Sommerville 2011, p. 85; Pohl 2010, p. 17-19]:

  • Functional requirements indicate what the software system or individual components should do (and what not). Typically, these requirements are defined from the functional perspective (system input and output, error situations), from the data perspective (data structures and integrity conditions) and from the behavioral perspective (system states, state transitions, events) [Pohl 2010, p. 214-215].
  • Quality requirements specify criteria for the quality of the software system or individual system components. Examples of such requirements are reliability, usability and performance (from the point of view of the system user) as well as changeability and portability (from the point of view of the developer).

Framework conditions are requirements that limit the implementation options for a software system and can only be changed with difficulty or not at all. According to their origin, framework conditions can be classified as:

  • Technological: the existing, technical IT infrastructure in which the software system is to be operated and developed
  • Organizational: structure and process organization of the units that use the software (e.g. departments with special responsibilities) or develop (process models for development, project deadlines)
  • Legal: laws and guidelines to be complied with, e. B. with regard to data protection
  • Ethically: Customs of the respective culture, which the system must meet in order to be accepted (e.g. forms of address)

The requirements are formulated by a wide variety of stakeholders. Stakeholders are people or organizations with an interest in the planned software system, e.g. B. Funders, users, developers, administrators, the marketing department (in the software industry) as well as regulatory authorities and control bodies [Pohl 2010, p. 79].

Regardless of the type of requirement and the stakeholders involved, the requirements should be formulated in such a way that they are of high quality. Typical quality features for individual requirements are [IEEE Std. 610.12-1990; Pohl 2010, p. 300; Schienmann 2001, p. 177 ff.]:

  • Correctness: The requirement corresponds to the needs of the stakeholders.
  • Uniqueness: The formulation of the requirement allows only one valid interpretation.
  • Verifiability: Criteria or tests can be specified to demonstrate whether the requirement is met or not.
  • Traceability: The origin of the requirement and its development can be determined.

If the set of all requirements placed on a software system is considered, each requirement must be unique, must not overlap with other requirements (normalization) or contradict them (consistency). In addition, both the individual requirement and the requirement set must be Completely be, i.e. provide all information for the desired subject or all requirements for the software system.

Core activities

At its core, requirements engineering aims to determine, specify and check requirements. These activities do not follow one another linearly, but are linked to one another by jumps and repetitions (see Fig. 1). This becomes clear z. B. the checking of requirements, which occurs in connection with the determination (as analyzing) and after the specification (as validating). In detail, the core activities have the following content:

  • The determination is intended to find out both existing and potential requirements for the software system [Pohl 2010, p. 395]. Accordingly, there are different investigation techniques (see below).
  • The analysis (checking I) is used to classify and prioritize the unstructured requirements that have been determined [Sommerville 2011, 101]. The classification creates groups of closely related requirements; This makes redundant, overlapping or conflicting requirements clear. Negotiations between the various stakeholders resolve these problems and enable the prioritization of requirements (agreement) [Pohl 2010, p. 487].
  • Specifying converts the analyzed requirements into a standard form. The standard form specifies at least uniform attributes for each requirement (e.g. requirement templates [Rupp et al. 2009, p. 161 ff.]), In some cases also the complete structure of the requirements document (e.g. IEEE / ANSI 830-1998). In principle, such documentation regulations can be freely defined for each project [Pohl 2010, p. 332-350]. Models can complement the resulting documents.
  • Finally, the validation (testing II) checks whether the specified requirements actually represent what the stakeholders expect from the software system [Sommerville 2011, 110]. This is to ensure that the “correct” software system is developed on the basis of the requirements. If necessary, identified deficiencies in consistency, completeness or formal correctness as well as conflicts between requirements are corrected [Pohl 2010, p. 494-498].

Techniques for determining requirements

Existing requirements can be determined through surveys or analyzes, while new and innovative requirements can be determined primarily through the use of creativity techniques [Pohl 2010, p. 408-450; Rupp et al. 2009, p. 86 ff.].

Surveys can be carried out in writing or orally (as an interview); In both cases it is possible to use questionnaires. Since surveys can only capture requirements that the interviewed people are aware of and that can be articulated, this determination technique should be supplemented by at least one form of analysis.

Analyzes help to uncover unconscious requirements. The following analysis objects and thus types of analyzes can be distinguished:

  • Existing software systems (system analysis, e.g. legacy systems to be replaced, standard software)
  • Documents (document analysis, e.g. architecture manuals, user documents, bug reports, reference models)
  • Users in their use of the system (observation, apprenticing).

The dangers of analyzes lie in the wrong starting point (incorrect documents, inauthentic behavior), distortions of perception and in cementing the existing and possibly no longer desired status quo.

In order to identify new, innovative requirements, creativity techniques are used, e.g. B. brainstorming, mind mapping or card techniques (CRC cards, snow cards [Rupp et al. 2009, p. 86 ff.]). In most cases, workshops are held with representatives from all stakeholder groups.

IT use

IT support plays an important role in requirements engineering. Tools of the Computer Aided Software Engineering (CASE) with the help of which requirements could be represented in certain modeling languages ​​[Konsynski et al. 1985; Teichrow et al. 1977]. However, precisely because of their abstraction from the natural language world of users, these modeling languages ​​were not very suitable for promoting common understanding between users and developers in the earlier phases of the requirements engineering process [Guinan et al. 1998]. In order to remedy this deficit, an attempt was first made to use existing groupware to support communication between users and developers; it was used, for example, to implement the principles of the Joint Application Development (JAD) adapted [Chen et al. 1991]. The groupware system Easy WinWin by Boehm et al. (2001) is one of the best-known systems of this type.

Recently, efforts have been made not only to promote personal exchange between users and developers through the accompanying use of IT tools, but to even substitute them. The necessity for this arises primarily from the increasing distance in terms of location and time - both within and between the groups of users and developers, since software is now often developed in globally distributed teams. The research concentrates on supporting all core activities of requirements engineering and requirements management holistically with the help of internet-based technologies [Dibbern et al. 2009; Gruenbacher et al. 2003; Lang et al. 2001; Seyff et al. 2005; Sinha et al. 2006].


Boehm, B .; Grunbacher, P .; Briggs, R.O .: Developing groupware for requirements negotiation: lessons learned. In: IEEE software 18 (2001), pp 46-55.

Carnegie Mellon Software Engineering Institute (CMU / SEI): CMMI® for Development, Version 1.2. CMU / SEI-2006-TR-008, ESC-TR-2006-008. Carnegie Mellon University,
August 2006.

Chen, M .; Nunamaker, J.F .: The Architecture and Design of a Collaborative Environment for Systems Definition, In: The DATA BASE for Advances in Information Systems 22 (1991), pp 22-28.

Dibbern, J .; Geisser, M .; Hildenbrand, T .; Heinzl, A .: Design, Implementation, and Evaluation of an ICT-Supported Collaboration Methodology for Distributed Requirements Determination. Working Paper 5/2009, University of Mannheim, 2009.

Gruenbacher, P .; Braunsberger, P .: Tool Support for Distributed Requirements Negotiation. In: Cimitile, A .; Lucia, A.D .; Gall, H. (Eds.)Cooperative Methods and Tools for Distributed Software Processes., Milano; Franco Angeli, pp. 56-66.

Guinan, P.J .; Cooprider, J.G .; Faraj, S .: Enabling Software Development Team Performance During Requirements Definition: A Behavioral Versus Technical Approach, In: Information Systems Research 9 (1998), pp 101-125.

Konsynski, B .; Kottemann, J .; Nunamaker, J .; Scott, J .: PLEXSYS-84: An Integrated Development Environment for Information Systems, In: Journal of Management Information Systems 1 (1985), pp 62-104.

Lang, M .; Duggan, J .: A Tool to Support Collaborative Software Requirements Management, In: Requirements engineering 6 (2001), pp 161-172.

Pohl, Klaus: Requirements Engineering: Fundamentals, Principles and Techniques. Berlin et al .: Springer, 2010.

Rupp, C. et al .: Requirements engineering and management: Professional, iterative requirements analysis for practice. 5th edition, Munich / Vienna: Hanser, 2009.

Seyff, N .; Kroiher, E .; Hoyer, C .; Grünbacher, P .: Enhancing GSS-based Requirements Negotiation with Distributed and Mobile Tools. In: IEEE (Ed.): Proceedings WETICE'05: 14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise. Los Alamitos: IEEE, 2005, pp. 87-92.

Schienmann, B .: Continuous requirements management: processes, techniques, tools. Munich et al .: Addison-Wesley, 2002.

Sinha, V .; Sengupta, B .; Chandra, S .: Enabling Collaboration in Distributed Requirements Management, In: IEEE software 23 (2006), pp 52-61.

Sommerville, Ian: Software Engineering. 9th edition, Harlow et al .: Addison-Wesley, 2011.

Teichrow, D .; Hershey, E.A .: PSL / PSA: A Computer-Aided Technique for Structured Documentation and Analysis of Information Processing Systems, In: IEEE Transactions on Software Engineering 3 (1977), pp 41-48.

IEEE: Recommended Practice for Software Requirements Specifications. IEEE Standard 830-1998. New York: The Institute of Electrical and Electronics Engineers, Inc., 1998.

IEEE: Standard Glossary of Software Engineering Terminology. IEEE Standard 610.12-1990. New York: The Institute of Electrical and Electronics Engineers, Inc., 1990.



Prof. Dr. Susanne Patig, IWI, University of Bern, Engehaldenstrasse 8, CH-3012 Bern, Switzerland

Author info


Prof. Dr. Jens Dibbern Institute for Information Systems Department Information Engineering University of Bern Engehaldenstr. 8, office 207 CH - 3012 Bern

Author info

Item Actions