The first paper on goal-driven requirements acquisition was published in 1993. Since then, it has been followed by a very large number of research papers, a comprehensive book, and a growing number of industrial applications, but goal modelling is still something that is mostly done in universities and not so much elsewhere. In industry, current practices are based on use cases, process modelling, and user stories; you will rarely meet a requirements engineer or business analyst who knows about goal modelling. This is despite a broad agreement that existing requirements engineering practices don’t work so well, precisely because they focus too much on the processes and the software (the how) and not enough on the goals (the why). So how can we fix this? How can we make goal modelling more broadly used? Ian Alexander, one of the early adopters, says we’ll know we’ve been successful when we’ll regularly hear analysts saying things like “this use case relates to this goal that contributes to this other goal and relies on this domain assumption.” To achieve this, we’ll need to simplify and communicate better the most essential ideas contained in our technical research papers.
With this in mind, I was captivated by Vic Stenning’s talk “Pelorus: a Tool for Business Change” at a meeting of the BCS Business Change Specialist Group last Thursday. The talk consisted purely of discussions about goals, how to elaborate goal models by asking WHY and HOW questions, how to avoid confusing goals and activities, how to identify stakeholders by asking WHO questions, how to define goals with measurable factors and targets, and how to anchor risks analysis on specific goals instead of doing it in a vacuum. Every concept had an almost direct relation to some of our research papers: goal-driven elaboration process, goal refinements, measures of partial goal satisfaction, obstacle analysis. The only ideas I could see missing from the discussions were conflict analysis and reasoning about alternatives.
And Pelorus even brings something new and exciting to goal modelling. It is a lightweight tool for collaborative modelling. The target domain for Pelorus is the domain of business change initiatives. Studies show that about 50% of all such initiatives fail. There are many reasons for this, but one of the main factors is a failure to engage key stakeholders early enough in the design of the changes. Vic quoted Rosabeth Kanter: “Change is disturbing when done to us, and exhilarating when done by us“—a view I agree with entirely. The focus in Pelorus is on providing a platform that allows large groups of stakeholders to collectively define and manage their goals for a change project. Unlike other goal modelling tools such as Objectiver or jUCM-Nav, it is not meant to be used for a detailed goal-oriented elaboration of complete software requirements specifications.
Pelorus is a web-based tool with a deliberate minimalistic design. The main concept is that of goal, a goal can support other goals, goals must be well-defined and measurable, and—apart from a few of other things such as the goal-based risk analysis— that’s it. This is goal modelling stripped to its bare minimum! Keeping it simple is essential to allow a diverse group of stakeholders to contribute directly to its elaboration, but it also ensures that everyone focuses on the goals and noting else. This minimalistic design is reflected in a clean and simple user interface that you can see in their videos. Oh, maybe it’s a detail, but in Pelorus goal models are not called models, they are maps. This is a term that was also used by another company selling goal-oriented techniques, so there might be something here.
Once the goal map has been defined, Stakeholders continue to use Pelorus to supervise the delivery and harvesting of the changes. This transforms the goal model in a form of “living” business case that, unlike traditional business cases that are written once and then forgotten, can evolve throughout the change delivery. This is another interesting idea that resonates with my current research interests on system evolution.
Pelorus could be a good example of how research ideas transfer to practice, except that Vic Stenning had never heard about goal-oriented requirements engineering. The main influence behind Pelorus, he says, is critical systems thinking –although, as far as I know, critical systems thinking doesn’t include the kind of goal modelling approach present in Pelorus. Sure enough, the concepts of goals, goal decomposition, measurable objectives, and perhaps even obstacles are so common that one doesn’t need to have read or heard about goal modelling to come up with the same ideas. Yet, during the talk, the resemblances with the research papers and tutorial on goal-oriented requirements engineering was striking. One person in the audience observed that these ideas are very much in the air at the moment. As a researcher who sometimes has to justify the public money spent on his research by showing it has an impact, I like to believe that we have played at least a small role in putting these ideas in the air. I hope Pelorus and other similar tools will continue to push these ideas forward.