Filed under: Requirements Engineering

Thoughts on "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering – Eric S. K. Yu"

The original paper: http://dl.acm.org/citation.cfm?id=827807

My thoughts on the papaer:

This paper discusses the earliest phase of requirements engineering, where the reason for an intended system, or the “why” of the system are the primary focus. The author argues that this is different from the later phases of requirements engineering when the purpose is to understand what the system does and how it should be doing it. The author states that this is as important, if not more, as asking 'what' the system should do or 'how' it should do it. The author then argues about the importance of tool support in this early, yet critical, phase; especially to help us maintain the knowledge that will be gathered at this point, which will guide key future decisions and track the origins of change in the system, among other things. Also, he shows how there isn't enough such support for this early and critical phase in requirements engineering. This is when he introduces the idea of using a tool called i*, which is used for modelling organizational environments, in this early phase.

The central idea in i* is to model the stakeholders' interests, concerns and constraints and how these factors between multiple stakeholders interact with each other. It has the strategic dependency modelling where the actors' dependencies on each other are inspected. And there is the strategic rationale model, where an actor's internal goals, beliefs, tasks and abilities are looked at. One question that I had was regarding the aggregation of these various attributes for a particular kind of actor. It would be interesting to model how these attributes vary between people who the same actor type. For instance, an organization might have many people employed in the role of a coder. The distribution of the coders' goals, beliefs, tasks and abilities across the whole group might provide insight about priorities and importance of certain goals and tasks.

The biggest problem in modelling the intentionality of a stakeholder, which is the central focus of i*, is to get the stakeholders to list out the intentions to begin with. How easy or difficult is that? Finding the intentions behind any system in effect allows the requirements engineer to help stakeholders find the solutions to their own problems. This itself might be easier said than done. In many cases, the stakeholders might arrive at a set of possible alternatives and then simply not know which of them is the optimum choice. Thus at this point, understanding the why's behind an intended system might not be enough. Choosing the right option among various alternatives then simply becomes a matter of trying out a selective few of them after doing some analysis. So my question is that, is the goal of this phase to possibly find the right alternative based on the reasons alone? Or just identifying the reasons enough? Or should we force ourselves to stop at the reasons, leaving more than one alternative solution for later analysis?

The paper raises the importance of forcing the stakeholder to figure out a substantial chunk of the problem, instead of the requirements engineer doing most of the gathering process. While it might not be completely effective, but it might result in higher levels of stability in the requirements and thus eventually the system itself when it is finally built.

How or when do you know to shift over to the later phase of requirements engineering? Or is there a clear shift at all? In other words, is it an iterative process, where you understand some of the reasons, then figure out some of the details of how and what to do with a maximum possible degree of completeness and precision, and then return back to finding the answers to the why questions if they arise, or if they were left unanswered? Might this be done to keep a constant check on if we are doing things for the right reasons?

On a final note, is this kind of analysis not the second half of a goal tree, where the why's and the how's are recognized?

 

 

Goal based RE!

This is a recent paper i read on RE; Requirements Engineering in the Year 00: A Research Perspective (http://dl.acm.org/citation.cfm?id=337184).

And this was my response:

Overall while reading this paper, one could feel a sense of pity that we (software folk) allowed programming paradigms to drive the paradigms of RE. I am talking of Object Oriented techniques here. When clearly, it should have been the other way around. Goal based approaches including responsibility assignment and goal dependencies seem to be a far more natural way of doing things rather than relying on scenarios. And when grounded in formal methods such as AND/OR relationships they form the bridge to the implementation landscape thus driving software architectures and eventually programing.