IREB Certified Professional for Requirements Engineering

ion levels are a powerful thinking tool in requirements elicitation [GoWo2005], [Laue2014]. They are often used as a kind of process model to structure the elicitation work, i.e. first elicit requirements only on the highest level and continue with further levels. It can be further used to structure requirements information obtained, to identify gaps in requirements or unnecessary requirements and to focus the elicitation activities to a certain abstraction level. For example, in a workshop with users, it is advisable to focus on the system context since the users are the experts for the system context. Talking about the data structures of a system may not be appropriate since the users do not care about the internal data structures. Thinking in terms of problems and goals (K2) A requirement is “a condition or capability needed by a user to solve a problem or achieve an objective” (a goal), see CPRE Glossary [Glin2017]. Thinking in terms of problems and goals thus is a core competence for the Requirements Engineer. A problem is the state of a certain aspect in the context of a stakeholder, that is experienced as negative. A problem can exist in the present (an actual problem). A goal is the state of a certain aspect in the context of a stakeholder that is expected to be positive. A goal exists in the future only. Problems and goals do not exist in real world: they are mental constructs of stakeholders. The same topic can be conceived as a problem by one stakeholder and serve as a goal for another. Problems and goals can only be known by communicating with the pertaining stakeholders. Problem and goal are interconnected by another mental construct: The solution is a roadmap for a certain intervention in the context of the stakeholder. Usually, more than one solution may solve the problem and reach the goal (to a certain extent). For more information, see [LoLS2017]. IREB Certified Professional for Requirements Engineering ‐ Elicitation, Advanced Level Syllabus IREB Certified Professional for Requirements Engineering Advanced Level Elicitation – Version 2.0. 1 Page 28 / 44 Thinking in terms of problems and goals enables the Requirements Engineer to analyze and uncover the complete network of problems, solutions and goals. In literature, there are several approaches that focus on problems, e.g., Problem Frames [Jack2001], or goals, e.g., KAOS [Lams2009]. Avoidance of transformation effects (K2) In the CPRE Foundation Level syllabus [FreA2017], transformational effects are discussed in the context of the output of Requirements Engineering, being the documentation. Requirements engineers should also be aware of these (and other) transformational effects in their input, as they frequently occur during elicitation activities in communication with stakeholders or when reading documents. Encountering this kind of effects is a trigger for additional elicitation efforts that will probably reveal additional or detailed requirements. Thinking in terms of models (K2) The CPRE Foundation Level syllabus [FreA2017] introduces several types of models (e.g. data flow diagrams, activity diagrams) for documenting requirements. Models allow focus on a specific perspective of a system: data, function, behavior. Models can also serve as a thinking tool if the Requirements Engineer wants to focus on a specific perspective during a particular elicitation activity, e.g., discuss an activity diagram in a stakeholder interview or develop a data flow diagram in a workshop with stakeholders. However, the Requirements Engineer should keep in mind that models are only useful if the modelling language is understood by all involved stakeholders.