How Can Goal Modelling Be Used in Requirements Engineering?

...

The only valid test of a practical method is in its use on real projects [5]. Therefore, the author tests the approach of GBRAM based on the case study of CTTS. And from that, the author also gains the ‘lessons’ for both himself or practitioners.

It is really helpful for readers to understand further the elements or terms when the author gives some small examples to explain them. It is also more reliable that the author specifically demonstrates and explains the GBRAM based on the CTTS case study. This article sheds some light on the goal-based requirements, but for sure there still a lot for us to explore.

2.4 Towards modelling and reasoning support for early-phase requirements engineering [6]

This article proposes a concept of dividing the whole process of RE into two stages: early phrase and late phrase. The early stage is to understand the organization context and rationale, so requirement engineers will understand better how the system can be more suitable. In author’s opinion, compare to the early stage, the late stage is traditionally about the completeness, consistency, and automated verification of requirements [6]. And the author concludes that most modelling supports are focusing on the late stage although the early stage is very important, so more attentions and efforts are needed to develop the early stage of RE.

The author found that the i*framework (The i* framework was developed for modelling and reasoning about organizational environments and their information systems [7].) gives a closer step to explore the early phrase. And a meeting schedule example is given in this article to demonstrate and explain the i*framework. There are two components of i*framework: the Strategic Dependency(SD) model and the Strategic Rationale (SR) model. The first mentioned of two shows the dependency relationships among different actors within a specific context and the latter is used to describe stakeholder interests and concerns, and how they might be addressed by various configurations of systems and environments [7].

i*framework is one of the modeling languages covering the GM and focusing more on the actor relationships. It should be totally agreed that the early phrase is like a foundation of a building, and paying more attentions and efforts of the early stage will give more chances to avoid failures of information systems from the beginning. So i*framework should be applied in the early stage of the RE process while creating goals.

This paper gives several figures of the meeting schedule example, this helps readers to understand the paper but it is short of the explanation of the elements and terms of i*framework such as depender, denpendee and dependum since it is really confusing sometimes.

2.5 Goal-Directed Requirements Acquisition [8]

At the beginning of this paper, the author addresses requirements analysis is a highly critical step in the software lifecycle [8] and mainly includes requirements acquisition. And to support the requirement analysis, the requirements model is developed which is not supported by the existing specification languages (Goal-Oriented languages, Agent-oriented languages, etc.) but can be acquired as the instances of a conceptual model [8]. The author points two existing problems of requirements acquisition: the scope problem and the acquisition problem. The reason for the former is because most specification languages only focus on the functional requirements but non-functional requirements. The reason for the latter is because the experts (stakeholders) of a specific domain cannot provide concrete and clear requirements and the requirement engineers have limited knowledge about the specific domain.

According to the problems, this paper offers a solution to requirements the acquisition which is using the KAOS meta-model together with one specific acquisition strategy and this solution is presented through an example of a university library system.

KAOS stands for Knowledge Acquisition in automated Specification [9] and has three components: the conceptual model, acquisition strategies and the acquisition assistant. The driving forces of this method are the reuse of domain knowledge and the application of two machine learning technologies [8, 10] (learning-by-instruction [11,12], learning-by-analogy [13]). KAOS is used to capture the initials goals here.

To understand the strategy better and identify all components, it is necessary to ask three questions: What tasks are done during the step? Why are those tasks necessary? How are the tasks carried out? [8] The learning-by-instruction strategy contributes to conduct the requirement acquisition process and it follows the steps below:

- Find goal structure and main objectives.

- Find relative agents and responsibilities.

- Find constraints of goal operationalization [8].

- Refine objectives and agents.

- Ensure constrains.

- Find alternative responsibilities.

- Assign actions to agents.

This solution starts from system-level and organizational objectives and focuses on goals especially high-level goals. Goals are crucial to this solution for some reasons:

- Contribute to incorporate requirements components.

- Explain the existence of requirements components.

- Distribute responsibilities to different agents.

- Contribute to handle conflicts.

This solution also reuses both meta-level and domain level knowledges. The more domain- independent knowledge the meta-model provides, the more guidance the acquisition strategy can provide [8].

This solution is different from most traditional approaches of requirements specification, because it focuses on the system-level goals and pays actions through constrains. For sure, there also some problems of this solution, which is the reason we should explore more. For practitioners, this solution is a more complicated one and it needs more knowledges to support. This paper illustrates the whole solution based on the university library case study which makes the solution more likely feasible. But some of the knowledges about KAOS are not complete so more details would be better.

2.6 Using Goals, Rules and Methods to Support Reasoning in Business Process Reengineering [14]

This paper also