Requirements Engineering Methods:
A Classification Framework and Research Challenges

The Requirements Problem concept defines the undesirable properties of the situation at the start of re, which the rem should help solve. The Solution concept defines desirable properties of the result that the requirements engineer aims to make with the rem.

• •

  Define the purpose of rem.

• •

  Define the desired result of applying the rem.

• •

  Force the rem designer to clearly state what her rem is intended to do within re, thereby forcing her to state the scope and depth at which she views the problem that the rem should help solve.

• •

  Compare rems, in that the Problem and Solution statements help us evaluate if an rem is focusing on the same problem as another, if it focuses on a more specific, or a more general problem.

• •

  Justify design choices in the rem: Decisions to include some concepts and relations in the Ontology, support specific rules of reasoning in the Formalism, and include processes in the Guidelines can be justified through their relevance to the description of the Requirements Problem, and finding and description of Solution instances.

• •

  Implicit Definition: No explicit statement of the Requirements Problem and Solution concepts is given, but can be inferred from other Components of the rem.

• •

  Informal Definition: Component Property is satisfied if the Requirements Problem and Solution concepts are defined in natural language.

• •

  Formal Definition: The Requirements Problem and Solution are defined as expressions in a Formalism.

As there are no explicit definitions of Requirements Problem and Solution statements, all rems cited up to this point, except for Techne have Implicit Definitions. For example, it is clear in Tropos and kaos that the aim is to find operationalizations of high-level goals, but the explicit statement of this problem, such as the one given by Zave & Jackson, is absent. Techne is an example where both Informal and Formal Definition are used.

X is intended to solve the Zave & Jackson statement of the Requirements Problem, and this problem has both an Informal and a Formal Definition, given in the Case Study. The Solution concept is implicit in the definition of the Requirements Problem, as it is a specification $S$ which is consistent with $K$ and $R$ (otherwise it cannot be that $K,S\vdash R$), and which together with domain assumptions is enough to derive requirements, i.e., $K,S\vdash R$.

An Ontology in an rem is an explicit specification of concepts and relations, whose instances are input, used and output by the rem.

• •

  Scoping: By including some and excluding other concepts and relations, the Ontology identifies the categories of information judged relevant to achieve the purpose of the rem.

• •

  Communication: Concepts and relations of the Ontology give the starting stable set of terms to use in communication about requirements.

• •

  Documentation: Categories of information in the Ontology should be captured by artifacts that document requirements. Ontology helps structure these artifacts.

• •

  Focusing: For the engineer/user of the rem, the Ontology acts as a checklist information to focus on when applying the rem.

• •

  Implicit Definition: Concepts and relations are not explicitly defined, but can be inferred from other Components of the rem. In such cases, it appears as if there is no Ontology; it can, however, be determined by looking at the kinds of information used by other Components.

• •

  Informal Definition: Informal interpretation for concepts and relations is given via definitions in natural language, the choice of concepts and relations is justified with regards to the purpose of the rem, and a discussion given of the ontological commitments, i.e., the assumptions for choosing particular concepts and relations rather than others, and for defining them exactly as proposed.

• •

  Structured Definition: Concepts and relations are represented as a graph, where concepts are nodes and relations are edges of the graph. This is the case when, e.g., an Entity-Relationship model is used to describe the Ontology of the rem.

• •

  Formal Definition: Concepts and relations are defined using expressions of a formal logic.

In kaos, the conceptual meta-model provides the Structured Definition of the Ontology. Informal definitions are given in intensional form, listing properties of concepts (e.g., properties of the goal concept) and properties of relations (e.g., minimality and consistency for the goal refinement relation). Similar combination is applied in Tropos, Formal Tropos, i*. To the best of my knowledge, there are no rems with Formal Definitions for their complete Ontology. The Core Ontology for Requirements, subsequently used in Techne, accomplishes this only in part and indirectly, by mapping its concepts to a foundational ontology which has a Formal Definition (see Appendix B of [15]). For illustration of Formal Definition of Ontology, but unrelated to re, see dolce [17]. carl is a case of Informal Definition. Implicit Definition occurs in the original presentation of both Viewpoints and Labeled Quasi Classical Logic. In both cases, concepts and relations are implicit in the Formalisms and Guidelines, but explicit and separate definitions are not given.

The Ontology for X should include the Requirement, Domain assumption, and Specification concepts. Assume for simplicity that all are top-level concepts. The consequence relation $\vdash$, since it is from classical logic, tells us the Ontology should include a Satisfaction relation from the Domain assumption and Specification concepts to the Requirements concept. Note that $\vdash$ is about derivability, not satisfaction, but classical logic is sound and complete so we can talk about Satisfaction as it fits the intuition that requirements are there to be satisfied.

Informal Definition in X consists of giving (at least) natural language definitions for the K, S, R concepts and all relations, then justifying why there are the three concepts and not more or less, and why they are top-level (i.e., one is not a specialization of another). An Informal Definition of the Requirement concept is that it is an optative statement about the environment of, and/or about the system-to-be. A Structured Definition for X can be an Entity-Relationship diagram, showing the three concepts as nodes, and relations as links. A Formal Definition can consist of defining the concepts using predicates of a more abstract ontology, such as writing that $\textit{Optative}(\phi)\rightarrow\textit{Requirement}(\phi)$, to say that $\phi$ is a requirement if it is optative, whereby the predicate Optative would be defined in the more abstract ontology.

A Formalism serves for the representation of, and reasoning about instances of concepts and relations of the Ontology. A Formalism in rem defines (i) symbols, (ii) rules for combining symbols into expressions, whereby the expressions refer to instances of the concepts and relations of the Ontology, (iii) semantic domain and semantic mapping function, to assign values within a domain of interest to expressions, and (iv) rules and algorithms for making deductions from, and/or checking properties of, expressions.

• •

  Representation/Modeling: Expressions written in the Formalism are models of information elicited for, and used in rem. Modeling helps reflection on requirements and helps highlight the relationships between requirements.

• •

  Communication and Learning: Models facilitate communication between stakeholders and help new project participants to learn about the requirements of the system-to-be.

• •

  Analysis: If the Formalism has the necessary features, models can automatically be checked for properties of interest, such as consistency, completeness, presence of solutions to the requirements problem that the model defines.

• •

  Prediction: If the Formalism has the necessary features, simulations can be performed on models, to evaluate, e.g., the probability of failure of a requirement, given a particular way to operationalize it.

• •

  Traceability: Provided that the Formalism allows the distinction of model versions and for capturing the rationale for version changes, the Formalism can help document traces and aid traceability.

• •

  Multi-Formalism: rem uses more than one Formalism.

• •

  Syntax Properties: Properties of alphabet and of grammar (i.e., rules for combining symbols in the rem):

  • –

    Symbolic Syntax: Models are well formed formulas as in a formal logic; it is relevant then to look into properties such as the presence of labels on formulas (to indicate sorts, or to keep track of formulas in deductions, as in labeled deduction), of predicates, quantifiers, and so on.

  • –

    Graphical Syntax: Models are drawn as diagrams; it is relevant then to look into the properties of graphs that these diagrams define, how the diagrams evaluate on cognitive effectiveness criteria [18], etc.

  • –

    Syntax Maps: Presence of rules to map expressions written in one syntax to expressions written in another syntax, in order to indicate that the expressions refer to the same (or aspects of the same) instances of concepts and relation (i.e., that the expressions aim to state the same information). This Component Property applies to rems which include two or more ways to represent the same information (e.g., symbolic and graphical syntax)

• •

  Deductive System Properties: Properties of the set of rules capturing correct inferences from a given set of expressions; properties of interest include:

  • –

    Classicality: How the Deductive System in the rem relates to that of classical logic; this can be established by verifying which of Gabbay’s [8] 13 properties the rem’s Deductive System satisfies.

  • –

    Paraconsistency: Whether the Deduction System allows deriving any formula from an inconsistent set of formulas; property relevant for inconsistency handling, as a Paraconsistent Deductive System allows drawing useful conclusions from an inconsistent set of formulas.

• •

  Model Theory Properties: Presence of a semantic domain and a function mapping expressions to elements of the semantic domain; properties of interest include:

  • –

    Truth Valuation System: The number of, and relationships between truth values (e.g., four truth values with two order relations, as in Belnap’s four valued logic [1]).

  • –

    Inconsistency Valuation: If an expression can be evaluated as both true and false, and what aggregate truth value such expressions obtain.

  • –

    Incompleteness Valuation: If the truth value of an expression can be undetermined, and what truth value such expressions then obtain.

  • –

    Utility Valuation: If the truth, falsity, or another valuation of an expression is interpreted as being (and how) valuable with regards to a purpose; e.g., truth of a requirement can be informally interpreted, in an rem, as that the requirement will be satisfied by the system-to-be if it is designed according to the Solution of the rem, so we see some truth values are being more desirable than others in the resolution of the Requirements Problem.

kaos, Formal Tropos and Techne are Multi-Formalism rems, as each includes a Symbolic and a Graphic Syntax: linear-temporal logic and goal trees in kaos, linear temporal logic and i* diagrams in Formal Tropos, a custom symbolic syntax with a deductive system and corresponding graphs in Techne. Viewpoints can be a Multi-formalism rem if different Viewpoints use different Formalisms. Techne has Syntax Maps which ensure that all represented in Symbolic Syntax can be translated into Grphical Syntax, and back. This is not the case in kaos and Formal Tropos: e.g., temporal relations that can be captured in linear temporal logic have no corresponding representation in Graphical Syntax in either of these rems. Neither kaos nor Formal Tropos have a Deductive System, while Techne does. In contrast, Techne has no Model Theory, while both kaos and Formal Tropos do. Deductive Systems of both Labeled Quasi-Classical Logic and Techne fail Classicality, both being Paraconsistent; however, they are not Paraconsistent in the same way, meaning that they would not derive the same conclusions given a same set of inconsistent formulas. i* has Graphical Syntax, no Deductive System and no Model Theory. Truth Valuation System in kaos and Formal Tropos is that of linear temporal logic, so it can be understood as involving two truth values (if we say “true” for a formula which is satisfied, false otherwise), so that there are no interesting Inconsistency and Incompleteness Valuations. Utility Valuation in kaos and Formal Tropos is not developed beyond the idea that if a formula representing a requirement is true/satisfied, then this is seen as beneficial.

Since $\vdash$ in the Requirements Problem is the consequence relation of classical logic, the Formalism of X must be either classical logic, or another formalism which ensures that we can check derivability or satisfaction (e.g., linear temporal logic will work) and has a notion of inconsistency, so that we can check if some given set $R$, $K$, and/or $S$ is consistent (as the formulation $K,S\vdash R$ requires that $K\cup S\cup R$ is consistent). If we add a Graphical Syntax, then X will be a Multi-Formalism. If so, then Syntax Maps define how formulas from the Symbolic Syntax map to (combinations of) primitives in Graphical Syntax. If we keep classical logic as one of the two Formalisms, then it will fail Paraconsistency. The Truth Valuation System properties in that case are also straightforward. Note that there is no Incompleteness and Utility Valuation.

Organization Mechanisms are intended to facilitate the creation and manipulation of expressions written in the Formalism of the rem. An Organization Mechanism will include rules enabling, e.g., to reuse and combine model fragments, to highlight relations between model fragments that the Formalism cannot or is not intended to show.

• •

  Modularity: A model can be split into pieces and each piece presented individually, perhaps accompanied with comments helping the reader of the model.

• •

  Problem decomposition: Different pieces of the model can focus on different aspects of functionality of the system-to-be. The Organization Mechanism can allow an aspect to be considered while hiding others, and showing only its relationships with others. This can help distribute work among those involved in modeling.

• •

  Reuse: A piece of a model may represent requirements that need to be satisfied by different features of the system-to-be. The Organization Mechanism can allow inclusion of pieces by referencing them, thus avoiding repetition and enabling reuse.

• •

  Reference: Presence of tools to reference, without reproducing, pieces of a model.

• •

  Structure: Presence of part-of and is-a relations between model pieces, to capture, respectively, (i) that a piece is an aggregate of other pieces, that the latter are parts of the former, and (ii) that a piece is a generalization of other pieces, i.e., that the latter are specializations of the former.

• •

  Interface: Presence of tools to describe how a model piece depends on another model piece, without describing the internals of either, and thus, how model pieces depend on contents of other model pieces, or of operations defined in other model pieces.

• •

  View: Presence of tools to group pieces of a model according to interests of different stakeholder groups, such as clients or suppliers, managers or engineers, etc.

• •

  Constraint: Ability to define constraints on relationships between pieces of models, such as conditions which should be satisfied for a set of pieces to be parts of another piece, or that some pieces together are a refinement of another piece, etc.

• •

  Verification: availability of algorithms to automatically verify whether constraints on relationships between pieces of models are satisfied.

i* allows Structuring via actor boundaries, to indicate that some model pieces belong to the same actor (stakeholder, user, or otherwise). Tropos and Formal Tropos inherit this mechanism. Formal Tropos includes templates, each template being associated to an instance of the ontology in i*. This means that i* models act as-if they are the Organizing Mechanism for a specification in linear temporal logic. In other words, goals, tasks, and other notions in i* models play the same role as schemas and schema relations play in the Z notation: they are used to organize pieces of a model. This idea is in kaos, which uses the goal concept and goal trees as an Organization Mechanism for formulas in linear temporal logic. Some relations in kaos are defined in a way which allows Verification: e.g., goal refinement is defined via properties between formulas of linear temporal logic in the goals participating in the refinement (consistency of the goals in refinement, minimality of the refining goal set, etc.) so that Verification of such properties is feasible. Labeled Quasi-Classical Logic and Techne have no Organization Mechanism. Viewpoints themselves are an Organization Mechanism of model pieces. carl uses its Ontology as an Organizing Mechanism, taking sets of formulas to be extensions of concepts in its Ontology. These examples raise the issue of what interplay there can be between Ontology, Formalism, and Organization Mechanisms in an rem (see, §III-E).

For example, to have views in X, we can adopt the ideas from Viewpoints. In this case, we can define meta-level rules for, e.g., solving inconsistencies between viewpoints, including a viewpoint into another viewpoint, and for referencing viewpoints in one another. We can thus use Viewpoints to satisfy Component Properties such as Reference, Structure, View, and Constraint. If meta-level rules are themselves defined in a logic, and there are means for, say, model checking for that logic, X can satisfy Verification.

Guidelines include all recommendations given on how to instantiate the concepts and relations of the Ontology, make models using the Formalism and manage models using Organization Mechanisms in an rem.

Guidelines suggest how to use the components of an rem to accomplish activities in re, such as elicitation, modeling, analysis, negotiation, validation, or otherwise.

• •

  Design Guidelines: Presence of rules and steps in which to apply rules to structure the problem space. Design Guidelines are present if it is explained how to refine and operationalize requirements, and identify/define alternative refinements and operationalizations. A refinement relates requirements at different levels of detail; operationalization relates a requirement to resources and processes to use and apply to satisfy the requirement.

• •

  Decision Making Guidelines: Presence of rules and steps for defining criteria for ranking alternative refinements and operationalizations of requirements, and select the refinements and operationalizations ranking highest according to most important criteria.

• •

  Inconsistency Handling Guidelines: Presence of rules and steps for knowing what model pieces are inconsistent and what to do about them, such as whether to tolerate or resolve the inconsistencies, which of them to resolve when (as soon as detected, or later), etc.

• •

  Tool Support: availability of software designed to facilitate the modeling or other applications of the rem.

Any rem that includes the refinement (or decomposition) and operationalization (or means-ends) relations allows the structuring of the requirements problem and solution space, which includes all rems being able to formalize such relations. This does not mean that they all include Design Guidelines. kaos, i*, Tropos, Formal Tropos include guidelines on how to refine/decompose and operationalize requirements. Viewpoints comes with instructions on how to relate and combine viewpoints, and in this sense also provide Design Guidelines. Techne, Labeled Quasi-Classical Logic and carl have the necessary concepts and relations, but are not explicit on steps to follow. Decision Making Guidelines are less common. Notions such as quality criteria and nonfunctional requirements are present in Tropos, i*, Techne, but methods on how to rank alternatives are explicit only in nfr and in kaos in relation to uncertainty [16]. Labeled Quasi-Classical Logic, carl and Viewpoints do not include the necessary concepts, relations, and guidelines. Inconsistency Handling Guidelines are given in Viewpoints, nfr, kaos, Tropos (as in nfr). Techne is paraconsistent, but does not provide explicit Guidelines on what to do, when inconsistency is deduced. kaos, i*, nfr, Tropos, Viewpoints, carl all have software tools to support Guidelines.

To make X into a Design Method, we need at least to ensure that it has the refinement relation. To have Decision Making Guidelines in X, we need to add at least one preference relation, rules for aggregating preferences, and a decision rule to rank alternatives. An alternative can amount to a consistent specification $S$, which also satisfies the condition that $K,S\vdash R$. Preference relations would indicate relative desirability of each specification. The rule for aggregating preferences and for ranking alternatives should let us define a total order over all specifications. The idea is then, that we would select the highest-ranking specification. If the Formalism is classical logic and Viewpoints are used as the Organization Mechanism, then Inconsistency Handling Method can be defined using meta-level rules. Finally, Tool Support will be satisfied if there is software that helps make and do reasoning on models made with X.