Neil Maiden is Professor of Digital Creativity in the Faculty of Management at the Cass Business School, and co-founder of the Centre for Creativity in Professional Practice at City, University of London. He initiates and leads interdisciplinary research in software engineering, creativity science and integrated health and social care.

As keynote speaker at ReConf 2017, he talked about Creative Thinking in Agile Requirements Processes (watch online). At the conference, Michael Jastram talked with Neil about goal-based systems development.

Can you summarize how you develop systems, starting from the very high level goals?

We adopt an approach that is based on the i* (i-star) framework of goal and intention modeling. The key element is to first understand who your stakeholders and actors are. It’s not about goals per se, it’s about the goals that the different stakeholders and actors have. This could be the goals of an organization, of individuals with certain roles, or even goals attributable to a system. If you try to build hierarchical goal models, you will almost always fail, because inevitably, different actors have different, conflicting goals. There are still dependencies between the goals, and ultimately it’s about finding the right trade-off, trying to satisfy as many stakeholders and their goals as possible.

So normally we start with actors and build a goal-based model for each individual actor. In a complex system, like an air traffic control system, this could be 30 to 40 different actors. This could be an organization, such as an airline, or a human role, such as a pilot, or any number of systems, like a radar system. But in our experience, you have to build bottom up, or at least “middle out”, understanding all the goals, tasks constraints and quality that each actor desires. Then you have to build up the complex dependencies between them.

You have to build bottom up, or at least middle out. Then you can build up the complex dependencies

You said that you use i*, which is not that widely used. Can you realize these ideas with today’s modeling techniques that are popular?

The problem is, you just can’t get these models through existing methods, and that’s why I consider them weak. i* is all about strategic goal modeling, it’s not about modeling every goal. So the engineer or analyst has to decide what’s strategic in the first place. If you imagine all the goals and tasks a traffic controller seeks to achieve their work, few of them will be strategic. But some of them are. The key is to focus only on the most strategic system-important goals and tasks and qualities in producing these models. Therefore you may end up with a model of 300 to 400 elements, spread across 30 or 40 actors. But that is still quite high-level.

We then drill down from those goals and tasks by creating use cases. We have experimented with a semi-automatic means of generating use case descriptions from these models, but we found that too descriptive, it did not allow for creativity or flexibility. So instead we provide a set of guidelines on how to drill down. So you take the strategic goals and strategic actors, you look at the tasks that they are seeking to achieve and use them as the building blocks to build a more concrete use case specification. We tend not to use use case models, the potato-and-stick-person diagrams, because I think the semantics has always been weak. We prefer to use the more descriptive template version of a use case specification.

But the problem is that not enough people are using these advanced goal models. I don’t think it’s a problem with the notation, I think it’s a problem with skills of analysts, and users struggle to fully understand these models, unless you are educated in modeling and abstraction. It’s hard! We use them as internal models and may show them to engineers and educated stakeholders. Instead, we use representations that are derived from these internal model. For example, we built a series of templates that produce semi-automatically generated requirements statements, for instance. So with the press of a button, more or less, you can produce 200 – 300 basic requirements statements. That seemed to have created quite a productivity gain.

We usually show a derived version, rather than the model itself. That is quite effective in communicating with stakeholders

That seems like a great approach for getting consistent use cases that are aligned with the goals. What happens to them over time?

That’s a fair point, and we always assumed that two-way-traceability is something that would be a fairly straight forward change management issue. But to be honest, I accept there is a problem. You could argue that the model is a starting point. The model is only valid one point in time. Immediately after its validation, the model is potentially invalid again. We need to be somehow circumspect on how much a model can really give you here. You are in an iterative process, by definition you are trying to change, trying to improve. The model is merely a snapshot at a point in this process.

For us, the model is not the end, but the means to something else.

The model is about asking the right questions and making the right decisions, which actually might be done without reference to the model. But the model has framed the decisions that need to be made in the right way. We don’t often present the model as part of the specification. It’s an internal tool, but not something that you usually show to the stakeholders.

Also the model is a dynamic entity. It is not a static diagram. People often think that a model has to be a static diagram that can be seen in its entirety. But you are constantly switching different things off and on, with different assumptions you get a different model. A model is a much more complex artifact, and also becomes part of the underlying domain model. What we end up building is a combined goal and domain model for a certain sector.

Can you give a recommendation? Who should use goal-based modeling, what should they watch out for?

You need to have a high level of analytic skill to model goals well. I look at academic papers and see what businesses are doing, and I think a lot of it is wrong, with no proper understanding of the semantics. But you rely on this to make your decisions, and this may lead to wrong decisions. So as a community, we need more of the right analytic skills. We need people capable and willing to think long and hard about the problems. Agile let’s you off that a little bit, as it encourages you to just think a little bit and then built something and see what happens.

This is along-winded way of saying: you need the right sets of skills associated with developing these models; you need enough up-front problem analysis; and you need to be aware that there is a domain model contained in the goal model, which requires proper domain experience. You need to be aware that there is a trade-off, nothing comes for free. Without the right investment, your effort will vaporize. This stuff is hard and complex. That’s why it is so interesting.

Image: Neil Maiden / BigStock