Requirements artifacts – Goals Requirements Engineering

Framework Overview Framework introduced by Klaus Pohl [1]

Definition Purpose of goals is to make requirements engineers understand the stakeholders intentions with regard to the system to be developed. A goal is intention with regard to the objectives, properties, or use of the system. [1] Goals abstract from system usage as well as from the realization of the system. System vision is actually refined by the goals. There are usually many different alternatives for satisfying a goal.

Brief Example Goals for the car navigation system. [1] G1: The system shall guide the driver to a desired destination automatically. G2: The response times of the system shall be 20% lower compared with the predecessor system.

Motivation Better understanding of the system. Requirements elicitation. Identification and evaluation of alternative realizations. Detection of irrelevant requirements. Justification of requirements. Completeness of requirements specifications. Identification and resolution of conflicts. Stability of goals.

AND/OR Goal Decomposition Goals can form a decomposition graph in which child nodes refine parent node. Root node of that graph is actually system vision, that can be considered as top-level goal. There are two kinds of goal decomposition: AND-decomposition – The decomposition of a super-goal G into a set of sub-goals G1, … , Gn with n ≥ 2 is an AND-decomposition if and only if all sub-goals G1, … , Gn must be satisfied in order to satisfy the super-goal G. OR-decomposition – The decomposition of a super-goal G into a set of sub-goals G1, … , Gn with n ≥ 2 is an OR-decomposition if and only if satisfying one of the sub-goals G1, … , Gn is sufficient for satisfying the super-goal G.

AND/OR Goal Decomposition - Example AND-decomposition of the goal “Navigation system must provide comfortable and fast navigation to the destination” [1]: G1: Easy entry of the destination. G2: Automatic routing according to user-specific parameters. G3: Displaying of traffic jams and automatic re-routing to avoid traffic jams. OR-decomposition of the goal “Navigation system must have ability to localize the position of the car” [1]: G1: Localization of the car via cell phone. G2: Localization of the car via GPS.

Goal Dependencies Goals can have following types of dependencies between each other: Requires – A goal G1 requires a goal G2 if the satisfaction of a goal G2 is a prerequisite for satisfying a goal G1. Support – A goal G1 supports a goal G2 if the satisfaction of G1 contributes positively to satisfying G2. Obstruction – A goal G1 obstructs a goal G2 if satisfying G1 hinders the satisfaction of G2. (Opposite of support dependency.) Conflict – A conflict exists between a goal G1 and goal G2 if satisfying G1 excludes the satisfaction of G2 and vice versa. Equivalence – Two goals G1 and G2 are equivalent if satisfying the goal G1 leads to the satisfaction of the goal G2 and vice versa.

Documenting Goals It is very important to document goals properly. The effort required to document goals in requirements engineering is, compared with the advantages gained, rather low. Goals can be documented in two ways: Using natural language. Using dedicated goal modeling language. Both approaches have it’s positive and negative sides.

Documenting Goals Using Natural Language Documenting goals using natural language can be done in two ways: by using unstructured or by using structured approach. Unstructured approach implies specifying goals one after the other in free text, without any specific rules. Structured approach is actually template-base documentation, which means that each goal have to fit given template. Template-based documentation of goals offers significant advantages.

Template for documenting goals No. Section Content/Explanation 1 Identifier Unique identifier of the goal 2 Name Unique name for the goal 3 Authors Names of the authors who have documented the goal 4 Version Current version number of the documentation of the goal 5 Change history List of the changes applied to the documentation of the goal 6 Priority Importance of the documented goal 7 Criticality Criticality of the goal, e.g. for the overall success of the system 8 Source Name of the source from which the goal originates 9 Responsible stakeholder Name of the stakeholder who is responsible for the goal 10 Using stakeholders Stakeholders who benefit from the satisfaction of the goal 11 Goal level Identifier for the abstraction level at which the goal is defined 12 Goal description Description of the goal 13 Super-goal Reference to the super-goal including the type of decomposition 14 Sub-goals References to the sub-goals including the type of decomposition 15 Other goal dependencies Further dependencies with other goals such as requires, conflict, etc. 16 Associated scenarios References to scenarios that describe the (dis)satisfaction of the goal 17 Supplementary information Additional information about this goal

Rules for Documenting Goals Document goals concisely. Document goals as concisely as possible. Avoid unnecessary phrases, fillers, and repetition. Use the active voice. Avoid using the passive voice. Using the active voice enhances understandability and clearly names the actor. Document the stakeholder’s intention precisely. It should be possible to check objectively whether the implemented system satisfies the goal or not. Decompose high-level goals into more concrete sub-goals. The decomposition enables the stakeholders to check whether the system satisfies the sub-goals defined during the requirement engineering process.

Rules for Documenting Goals (2) State the additional value of the goal. Describe the intended additional value as precisely as possible. Document the reasons for introducing a goal. Knowing the rationale for introducing a goal facilitates discussions about the goal itself and supports the identification of additional goals. Avoid defining unnecessary restrictions. Avoid defining unnecessary restrictions which constrain potential realizations of the system. Only define restrictions if they are super-imposed by law or a contractual document.

Goal Modeling Languages Common goal modeling languages include different dialects of: AND/OR trees and graphs Goal-oriented Requirements Language (GRL). On this modeling language is based i* (i-Star). KAOS

AND/OR Trees and Graphs They document hierarchical decomposition of goals. An AND/OR goal tree consists of nodes that represent goals and directed edges that represent AND‑decomposition and OR-decomposition relationships between the goals. Each node (except the root node) is related to exactly one super-goal.

AND/OR Trees and Graphs (2) AND/OR tree is not suitable if some sub-goals contribute to the satisfaction of more than one super-goal. That is why an AND/OR graphs are introduced. An AND/OR goal graph is directed, acyclic graph with nodes that represent goals and edges that represent AND-decomposition relationships and OR-decomposition relationships between the goals.

AND/OR Trees and Graphs (3) AND/OR graphs can be extended by defining two additional types of edges representing the requires and the conflict dependencies. Requires edge directed from goal G1 to goal G2 implies that to satisfy the goal G1, the goal G2 must be satisfied. Conflict edge is undirected edge between two goals G1 and G2 that documents a conflict dependency.

i* (i-Star) It is based on the idea that an actor depends on other actors in order to achieve its goal. The modeling constructs of i* are divided into objects and relationships. Relationships are further divided into dependencies and links.

i* (i-Star) – Objects Actor – A person or a system that has a relationship to the system to be developed. Goal – Describes a certain state in the world that an actor would like to achieve. Task – Specifies a particular way of doing something. Typically a task consists of a number of steps that an actor must perform to execute the task. Resource – A entity that the actor needs to achieve a goal or perform a task. Softgoal – A condition in the world which the actor would like to achieve, but unlike the goal, the criteria for the condition being achieved is not sharply defined.

i* (i-Star) – Relationships i* differentiates between three types of links that may exists between goals, tasks, resources and softgoals: Means-end link – It documents which softgoals, tasks, and/or resources contribute to achieving a goal. Means-end links also facilitate the documentation and evaluation of alternative ways to satisfy a goal. Contribution link – Documents a positive (+) or negative (-) influence on softgoals by tasks or other softgoals. Task decomposition – Documents the essential elements of a task. It relates the task with its components, which can be any combination of sub-goals, sub-tasks, resources, or softgoals.

i* (i-Star) - Example http://istar.rwth-aachen.de/

KAOS KAOS stands for “Knowledge Acquisition in automated specification” or ”Keep All Objectives Satisfied”. KAOS modeling language is part of the KAOS framework for eliciting, specifying, and analyzing goals, requirements, scenarios, and responsibility assignments. A KAOS model comprises six complementary sub‑models: Goal model Obstacle model Object model Agent model Operation model Behavior model All this sub-models are interconnected in global model with traceability links.

KAOS – Goal Model The modeling constructs of KAOS are divided into two groups: objects and relationships.

KAOS – Objects The object types that play a central role in the KAOS framework are: Behavioral goal – Describes a set of admissible system behaviors. They can be defined in a clear-cut manner, i.e. one can verify whether the system satisfies a behavioral goal or not. Softgoal – Used to document preferences among alternative system behaviors. There is no clear-cut criterion for veryfing the satisfaction of a softgoal. Agent – Relates to users and components of software-intensive systems. It can be a human agent, a device, or a software component.

KAOS - Relationships There are four relationship types in KAOS: AND-decomposition – Relates a super-goal to a set of sub-goals. It documents that the super-goal is satisfied if all sub-goals are satisfied. Alternative decomposition – OR-decomposition of a goal is documented by assigning multiple AND-decompositions to the super-goal. Hence each alternative is represented as an AND‑decomposition. The super-goal is satisfied if one of the alternatives is satisfied. Potential conflict – Documents that satisfying one goal may prevent the satisfaction of the other goal under certain conditions. Responsibility assignment – Link between a goal and an agent means that this agent is responsible for satisfying the goal. If a goal is assigned to an individual agent it can thus not be further decomposed. A goal can be related to multiple agents, in which case alternative agents are defined.

KAOS - Example

Natural Language vs. Modeling Language When using natural language, typically, comprehensive information about a goal is documented. Natural language allows describing goal in detail. Modeling languages are well suited to provide an overview of the goals and their dependencies. In goal model, a goal is typically documented by a short label. Conclusion: natural language techniques complements model-based goal documentation. Use of both kinds of documentation is recommended.

References K. Pohl: Requirements Engineering. Fundamentals, Principles, and Techniques. Springer, 2010. V. Lamsweerde: Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley, 2009.