Requirements engineering refers to the process of specifying, analyzing, documenting and main- taining requirements in the engineering design process [Nuseibeh and Easterbrook, 2000]. Som- merville [Sommerville, 2009] describes requirements engineering as “the process of finding out, ana- lyzing, documenting and checking the services and constraints for the system to be built”. According to Van Lamsweerde [van Lamsweerde, 2009], requirements engineering is “a coordinated set of ac- tivities for exploring, evaluating, documenting, consolidating, revising and adapting the objectives,
2.2. Requirements Engineering capabilities, qualities, constraints and assumptions that the system-to-be should meet based on prob- lems raised by the system-as-is and opportunities provided by new technologies”.
In this section, we start with the presentation of the key terminology and concepts in require- ments engineering. We introduce a requirements engineering framework which represents the build- ing blocks of requirements engineering. We then present the approaches for software requirements specification and documentation.
2.2.1 Software Requirements
There are various definitions and classifications of the term “requirement”. It is defined in the IEEE 610.12-1990 standard [IEE, 1990] as: (a) a system capability needed by a system user to solve a prob- lem or achieve an objective, (b) a capability that must be met by a system to satisfy a contract, standard or specification, and (c) a documented representation of a capability as in (a) or (b). “The description of the services and constraints for the system” is called a requirement by Sommerville [Sommerville, 2009], while the term “requirement” is defined as “ a property which must be exhibited by a system” in SWEBook [SWE, 2014]. We use the definition in the IEEE 610.12-1990 standard [IEE, 1990] as our working definition for requirements in the thesis.
There is a terminology to distinguish different types of requirements such as user requirements, system requirements, software requirements, and functional / non-functional requirements. For in- stance, the term “user requirement” is used for high-level abstract requirements, while the term “sys- tem requirement” is used for the detailed descriptions of what the system should do [Sommerville, 2009]. We consider software requirements and software system requirements as synonyms and as a specialization of system requirements for software systems in this thesis. Software requirements are often classified as functional, non-functional and constraints (see [Pohl, 2010] [Sommerville, 2009] [Lauesen, 2002] [Robertson and Robertson, 2006] [Wiegers and Beatty, 2013]).
• Functional Requirements. Functional requirements describe services the system should pro- vide. They may also state what the system should not do.
• Non-Functional Requirements. They are often called “quality attributes” of a system such as security, reliability, performance, maintainability, scalability, and usability.
• Constraints. They are organizational or technological requirements that restrict the way in which the system is developed [Robertson and Robertson, 2006] [Pohl, 2010].
2.2.2 Requirements Engineering Framework
The requirements engineering framework introduced by Pohl [Pohl, 2010] represents the key elements of a requirements engineering process. The framework consists of the following building blocks (see Fig. 2.2):
• System context: Software system requirements are heavily influenced by the context of the system under development. The system context consists of various aspects that are related to
Core activities Documentation Elicitation Negotiation Requirements artefacts Goals Scenarios Solution-oriented requirements System Context Subject
Facet UsageFacet IT SystemFacet DevelopmentFacet
Cr os s- secti ona l Acti vi ty M ana gement Cr os s- secti ona l Acti vi ty Va lid ati on
Figure 2.1. The Requirements Engineering Framework [Pohl, 2010]
the system to be developed, such as business processes, hardware and software components, third-party systems, standards and stakeholders [Pohl, 2010]. It is structured into four facets: subject facet, i.e., all objects and events in the system context, usage facet, i.e., all aspects that are related to the system usage, IT system facet, i.e., all aspects of the operational and technical environment including policies, strategies and guidelines, and development facet, i.e., all aspects of the context that are related to the development processes of the system.
• Core requirements engineering activities: The core activities concern the understanding of the requirements, the documentation and specification of the elicited requirements, and the identification and resolution of conflicts between various stakeholders.
• Cross-sectional activities: These activities support the core activities and secure the results of requirements engineering. The validation activity aims at detecting defects in the requirements, checking the compliance between the core activities, and validating whether the core activities have been properly followed. The management activity comprises the management of the re- quirements artifacts, the planning and control of the core requirements engineering activities, and the identification of changes in the system context.
• Requirement artifacts: The requirements engineering framework distinguishes three main
artifacts: goal, scenarios, and solution-oriented requirements. We describe the details of those artifacts in Section 2.2.3.
2.2. Requirements Engineering
2.2.3 Requirements Artifacts
The term “requirement artifact” refers to a documented requirement [Pohl, 2010]. As mentioned in Section 2.2.2, there are three main types of requirements artifacts: goals, scenarios and solution- oriented requirements.
2.2.3.1 Goals
Goals are used to document stakeholders’ intentions and refine the overall system objective into smaller objectives to be fulfilled by the subsystems. According to Pohl [Pohl, 2010], a goal is “an intention with regard to the objectives, properties, or use of the system”. van Lamsweerde [van Lamsweerde, 2001] defines a goal as “a high-level objective the system under consideration should achieve”.
There might be different goals at different levels of abstraction. High-level goals provide the high- level strategy for the product of the company, and the requirements engineer refines these high-level goals into sub-goals which define the stakeholders’ intention in terms of the use of the system and its specific properties [Pohl, 2010]. The refinement of a goal is called “goal-decomposition”. There are AND-decomposition of a goal, i.e., all sub-goals must be satisfied to satisfy the super goal, and OR-decomposition of a goal, i.e., satisfying one of the sub-goals is sufficient to satisfy the super goal. In addition to the AND-decomposition and OR-decomposition, there are dependencies between goals [Pohl, 2010]: requires, support, obstruction, conflict and goal equivalence.
Goals and goal dependencies can be documented using unstructured, natural language. For an easy-to-understand and precise documentation of goals, several goal modelling languages, methods and tools are proposed in literature (e.g., GRL [GRL, 2009], i* [Yu, 1997], NFR [Chung et al., 1996], GDC [Kavakli, 2002], GBRAM [Anton, 1996] and KAOS [van Lamsweerde, 2009]).
2.2.3.2 Scenarios
A scenario describes a concrete example of how the system to be developed interacts with its users and third-party systems. Pohl [Pohl, 2010] defines a scenario as “a concrete example of satisfying or failing to satisfy a goal (or set of goals)”. Scenarios describe sequences of actions related to the intended application. Scenarios can be documented using various formats, such as natural language, tabular notation, or sequence diagrams. According to Pohl and Haumer [Pohl and Haumer, 1997], there are three types of scenarios:
• System Internal Scenarios: They are used to represent interactions between components of the system and subsystems. They do not consider the context in which the system to be developed is expected to run.
• Interaction Scenarios: They are used to represent interactions between the system and stake- holders and/or other third-party systems.
• Contextual Scenarios: They extend interaction scenarios by additionally representing the sys- tem context information such as business goals related to the system services, relationships between stakeholders, and organisational policies.
Use case modeling is a technique to document interaction scenarios, and first introduced in OOSE (Object-Oriented Software Engineering) [Jacobson et al., 1992]. Pohl et al. [Pohl et al., 2005] define a use case as “a description of system behaviour in terms of scenarios illustrating different ways to succeed or fail in attaining one or more goals”.
A use case represents interactions between the actors and the system to be developed. These inter- actions are described in terms of scenarios, the so-called use case scenarios. There are usually various use case scenarios representing alternatives of failure and success for the same goal. Therefore, a use case consists of multiple positive and negative use case scenarios. Besides, use cases contain pre- and post-conditions providing information about the system state before and after the execution of the use case scenarios.
Use cases of a system are documented as a use case model in which three components are nec- essary [Larman, 2002]: the template-based specification of the use cases, the proper documentation of the use case scenarios, and at least one use case diagram representing with a graphical notation an overview of the use cases. A use case template is a tabular structure that guides the textual documenta- tion of use cases [Pohl et al., 2005]. There are several use case templates in literature (e.g., [Cockburn, 2001] [Armour and Miller, 2001] [Kulak and Guiney, 2003]).
2.2.3.3 Solution-Oriented Requirements
Solution-oriented requirements specify, at the required level of detail, system properties and fea- tures [Pohl, 2010]. They describe the data, functional and behavioral perspectives on a software system. Different than goals and scenarios, they imply a conceptual solution for the system to be developed.
Conceptual or formal models are often used to document solution-oriented requirements. The re- quirements engineer can employ a data modelling language (e.g., the entity-relationship model [Chen, 1976], the enhanced entity relationship model [Elmasri and Navathe, 2015] and UML class diagrams) to document the solution-oriented requirements from the data perspective, while she employs a be- havioral modelling language (e.g., data flow diagrams [DeMarco, 1978]) and a functional modelling language (e.g., finite automata, statecharts [Harel, 1987] and UML state machine diagrams) for the behavioral and functional perspectives, respectively. We consider the use of domain models in our Product line Use case modeling Method (PUM) (see Chapter 3) as the documentation of solution- oriented requirements in UML class diagrams from the data perspective.