Interview with Neil Maiden: Reaching the goal with goals

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

At ReConf 2017, he gave a presentation on creative thinking in agile requirements processes (view). I spoke to Neil at the conference about Goal-based system development. This is a translation of the interview, which in English on the Formal Mind Blog can be read.

How are systems developed when the starting point is high-level goals?

Our approach is based on the i* (i-star) framework for goal-based modeling. First of all, the stakeholders and actors must be identified. It is not about goals per se, but about the goals of the various stakeholders and actors. These can be the goals of an organization, an individual (with a role), or even the goals of a system. Hierarchical goals rarely work, as sooner or later actors will have conflicting goals. Of course, there are also dependencies between goals, but ultimately it is about balancing the goals against each other and satisfying as many stakeholders - and their goals - as possible.

Therefore, we usually start with the actors and build a goal-based model for each actor. In a complex system, such as an airspace surveillance system, this can be 30 to 40 actors. This includes organizations, like an airline, a human role, like a pilot, or any number of systems, like a radar system. But in our experience, you have to build the model from the bottom up, or at least "from the middle", to understand all the goals, tasks, constraints and quality requirements of each actor. Only then are the complex relationships created.

You have to build the model from the bottom up, or at least "from the middle". Only then are the complex relationships built. [tweetthis]You have to build the model from the bottom up, or at least "from the middle out."[/tweetthis]

You use i*, which is not really widespread. Can these ideas also be implemented with popular modeling languages?

Unfortunately, you don't get such models with existing methods, so I call them weak. i* is about strategic goal modeling, not about modeling every goal. So the engineer or analyst has to decide what is strategic in the first place. The challenge is to focus only on the truly strategic goals, tasks and qualities that are important for the system in order to create these models. This results in a model with 300 to 400 elements, distributed across 30 to 40 actors. But this is still at a high level of abstraction.

We work our way down from these goals and tasks by creating use cases. We experimented with the semi-automatic generation of use case models derived from the models. But we found these too descriptive, there wasn't enough room for creativity. Instead, we created a set of guidelines to break them down. You take the strategic goals, the strategic actors, and look at the tasks they have to fulfill. We use this as building blocks to create a concrete specification from use cases. We rarely use visual use case models, i.e. the potato and stick figure representation, as the semantics of these diagrams have always been weak. Instead, we use descriptive use case templates.

But the problem is simply that these sophisticated target models are simply not widespread enough. I don't think the notation is the problem. The problem is more the skill level of the analysts, and users have trouble really understanding the models if they haven't had training in modeling and abstraction. It is difficult!

We use these models internally, and sometimes we also show them to engineers or appropriately trained stakeholders. But normally we use representations derived from the internal models. For example, we have developed a series of templates with which we can generate requirement texts semi-automatically. With a simple push of a button (more or less), 200 to 300 simple requirements are generated. This seems to have increased productivity considerably.

We usually show a derived version of the model instead of the actual model. This is very effective for communicating with stakeholders. [tweetthis]We usually show a derived version of the model instead of the actual model[/tweetthis].

That sounds like a good approach to get use cases that are consistent with the goals. What happens over a longer period of time?

That's a good point. We always assumed that bi-directional traceability would be an easy change management problem to solve. But to be honest, there is indeed a problem there. Of course, you can argue that the model is only the starting point: the model is only really correct at a single point in time. Immediately after its validation, the model is potentially invalid again. We also have to be careful about how much the model can really give us. After all, it is an iterative process: by definition, we are trying to change towards a better solution. The model is just a snapshot at one point in this process. For us, the model is not the end product, but a means to an end. The model helps to ask the right questions and make the right decisions, and this can even be done without reference to the model. But the model has set the framework for finding the decisions and making them correctly. Only rarely do we make the model part of the specification. It is an internal tool that stakeholders rarely get to see.

Also, the model is dynamic, not a static diagram. Sometimes people expect that the model can be fully visualized as a static diagram. But things are constantly being switched on or off, and with changed framework conditions you also get a changed model. A model is a much more complex artifact, and also becomes part of the underlying domain model. A combined target and domain model is developed for a specific industrial sector.

Can you make a recommendation? Who should use goal-based modeling and what should be considered?

You need extremely good analytical skills to model targets well. I read research results and also see what happens in the industry. And a lot of what I see I think is wrong, often lacking a clear understanding of the semantics. But that's what decisions are based on, and that can lead to wrong decisions. So what we actually need are better analytical skills. We need people who are able to think long and hard about problems. The agile approach frees us from this somewhat, because it involves constructing something in small steps and then observing it.

But that's a long answer that can be summarized briefly: You simply need the right knowledge to be able to develop such models. You need sufficient problem analysis in advance. You need to be aware that the target model contains a domain model, which can only be developed with sufficient knowledge of the domain. And you need to know that there are always pros and cons, nothing comes for free. Without the right investment, the work will simply fall flat. These topics are difficult and complex. That's what makes them so interesting.

Picture: Neil Maiden