Notes on structure of requirements modeling languages

In relation to some research in progress in July 2013, a friend and colleague asked if I see a Requirements Modeling Language (RML) as the tuple (Ontology, Language, Entailment relation). Below is my response.

I do not see an RML as the tuple (Ontology, Language, Entailment relation), at least for the following reasons:

1) I prefer Formal Ontology than Ontology.

By Formal Ontology, I mean an Ontology specified as a set of FOL axioms. Like Guarino specified DOLCE – see pages 26 and later in:

2) I think Ontology in an RML is MORE than a set of concept and relations like in KAOS or RE10 Techne.

In RE10 Techne, we had an ontology with these concepts and relations:

– Goal;
– Softgoal;
– Quality Constraint;
– Task;
– Domain Assupmtion;

and these relations:

– Implication;
– Conflict.

What we were missing are:

– Statuses, which we use to mark when goal instances are achieved, task instances are executed, etc.

– Rules that say how goals, tasks, and assumptions (and maybe other things) need to be related, for us to say that some goal is achieved, some task executed, etc.

BEFORE this Techne Framework draft I sent, we equated achievement with derivability: If I had a requirements KB such that KB |- x, and x was a goal instance, I would say “goal x is achieved”. And the whole Zave & Jackson Req. Problem rests on this idea.

BUT, whether it was correct of me to conclude achievement BECAUSE of derivability (or satisfability with |=) is not very clear.

One of the main reasons that we talked so much about paraconsistency in the first place was that in SOME cases (namely if we use the consequence relation from classical logic and our KB is classically inconsistent) we could DERIVE goals, BUT it was clear to us that these goals should NOT be considered as achieved.

The way Zave & Jackson dealt with these exceptions is that they said “K and S have to be consistent”, and they used the classical consequence relation in K, S |- R. But we argued in RE08 that this works ONLY if K and S describe ONE solution, while a requirements KB which we placed on the left-hand side of |- may include more than one solution, and therefore need NOT always be consistent. So it makes no sense to assume K and S are always consistent, and their problem statement falls apart.

So what I want is that, if someone proposes an RML, they CANNOT ONLY say “I have these concepts and these relations”, but also what are the desirable statuses / values of these concepts as a function of the relations.

Moreover, I want them to say what the problem they are solving is, and what is a solution to that problem.

In the end, I am also asking for an Ontology, but I am also saying this:

– This ontology should NOT equate derivability or satisfiability with goal achievement, task execution, and assumption maintenance (among others). Hence the need for statuses and rules;

– This ontology should define the problem and solution concepts;

– This ontology should define rules / axioms that the KB must satisfy at all times, when using the RML.

3) Once we separate goal achievement from derivability / satisfiability, we can also separate the language for the representation of the world, from the language for reasoning about goals, tasks, assumptions.

That fits my own intuition: I can be in a particular situation, and know things about that situation. Which actions I then do in that situation depends on what problems (undesirable things) I observe in it, and what problem-solving knowledge I can apply in that situation to solve these problems. In other words, there are TWO kinds of knowledge – knowledge of the situation / domain, and problem-solving knowledge.

The language for the representation of the world is what I call the Domain language.

For example, in KAOS, the Domain language is linear temporal logic (LTL).

LTL is independent from any requirements ontology and problem. Sometimes it may be good enough to represent the world in terms of a propositional logic, sometimes with LTL, sometimes with CTL, etc. – but our knowledge of what requirements are, what specifications are, what domain assumptions are, how they can relate, etc., are independent from the way we represent the world. I can read a proposition “if incident reported, dispatch ambulance” as a natural language sentence, or as an LTL expression “reported(incident) => dispatch(ambulance)”, or in some other logic, but in all these cases, whichever the logic, I know that is a requirement, and I know I have to refine it, for example.

So I need TWO KBs – one for what I know about the world, and another for how I organize and think of what I know about the world, when I apply to it my problem-solving knowledge. In that view of things, an RML is not (Ontology, Language, Entailment relation).

Published by

Ivan Jureta

I hold the Senior Researcher (Chercheur qualifié) position with the Belgian national research fund (Fonds de la Recherche Scientifique – FNRS, Brussels) and am Associate Professor with the Department of Business Administration, University of Namur. My principal research interest is in method engineering and method automation, focusing on the elicitation, modeling and analysis of knowledge that human experts apply in problem solving and decision making, the engineering of ontologies and processes capturing that knowledge, and the automation of the said processes. This interest falls within the various research fields concerned with the transfer, preservation and automation of knowledge. I am the author of “Analysis and Design of Advice” (Springer, 2011) and have published over 50 research papers on these topics within the fields of requirements engineering, business analysis, and conceptual modeling of information systems. I organize and chair the series of International Workshops on Modeling and Reasoning for Business Intelligence (MORE-BI), held in Brussels in 2011 and Florence in 2012. I serve on scientific committees of the IEEE International Requirements Engineering Conference (RE), the International Conference on Advanced Information Systems Engineering (CAiSE), and the International Conference on Conceptual Modeling (ER). In parallel, I am / have been involved with several startups at CxO level and have held lead roles in Product Design for web and digital services that today serve more than 500.000 people every day.