Goal-oriented Requirements Analysis for Clarifying the Meaning and Value of Information Technology

1. Introduction

In requirements engineering, a goal-oriented requirements analysis has been actively discussed in recent years. The i* framework [1] is said to be one of the best-known goal-oriented requirements analysis methods [2]. The strategic dependency (SD) model in the i* framework expresses the requirements dependency among the actors in a business. However, a practical method, which could help stakeholders check whether or not the requirements in the SD model are comprehensive, has not been proposed.

In this article, we describe a method of defining and analyzing requirements from the viewpoint of the relationships among actors by using a two-dimensional matrix, which we call the Actor Relationship Matrix (ARM). We also discuss the effectiveness of this method. Section 2 introduces an example of the SD model and its issues that occur when the i* framework is applied to actual problems. Section 3 presents ARM, which we designed to tackle these issues. Section 4 discusses how ARM delivers three types of reviews to address these issues. Section 5 introduces future issues in a goal-oriented requirements analysis. Section 6 summarizes the main points and mentions future work.

2. SD model and its issues

Here, we consider a product sales management service as an example for the SD model. The requirements of this service can be described as follows:

R1: The customer shall place an order with the system for a product.

R2: The system shall check with the warehouse staff to see if the product is in stock.

R3: The ordering staff shall instruct the system to restock when the inventory is low.

R4: The system shall instruct the warehouse staff to ship the product from the warehouse.

R5: The warehouse staff shall confirm that the product has been shipped.

R6: The warehouse staff shall update the product inventory.

R7: The delivery staff shall send an invoice to the customer.

R8: The delivery staff shall send a shipping list to the customer.

R9: The customer shall pay the fee to the cashier.

R1–R4 and R7–R9 describe relationships between actors. The SD model based on these requirements is shown in Fig. 1. Since R5 and R6 describe only the actor's own objectives, these two requirements are not shown in the SD model.

Fig. 1. SD model.

When the i* framework is applied to actual problems, the number of actors to consider is very large and the relationships among actors are complex. For that reason, it is difficult for stakeholders in the business to check efficiently whether or not the requirements have been comprehensively described in the SD model.

3. Actor relationship matrix (ARM)

ARM is a two-dimensional matrix that defines the relationship among actors. The above requirements are listed in Table 1 using ARM. The element at Row i, Column j of the table (i≠j) describes the requirement that the beneficiary (actor i) expects of the provider (actor j). For example, in the earlier SD model, the system requires the warehouse staff to check the inventory. So this requirement is written in the cell in the table where the system row and the warehouse staff column intersect.

Table 1. ARM.

The diagonal elements (where i=j) give the actor's own objectives. This applies to R5 and R6. Thus, the warehouse staff has two objectives: confirm shipment status and update product inventory are entered in the cell corresponding to the row and column of the warehouse staff. ARM can be used to organize the requirements among all actors in the business. So ARM makes it possible to perform a comprehensive review of requirements.

4. Discussion

ARM helps stakeholders to review the requirement descriptions. For our example of ARM (Table 1), ARM can provide the following three types of reviews.

Type 1: Review of requirements expected of actor

Nothing is written in the cashier column of ARM. This means that the other actors do not have any requirements of the cashier. ARM shows that after the cashier has collected the fee from the customer, there is no requirements description of how he or she should manage the fee. In response to this case, a new requirement by the system could be added, namely, “confirm the deposit of money” for the cashier. The new requirement would be written in the cell where the system row and cashier column intersect.

Type 2: Review of requirements expected by actor

Nothing is written in the delivery staff row of ARM. This means that the delivery staff does not have any requirements of the other actors. In this service the delivery staff shall send the shipping list and invoice. Normally, such actions would happen because another actor has instructed the delivery staff to send them. In other words, the delivery staff needs instructions that take into account the timing of the delivery. However, the current requirements descriptions are missing these instructions. To handle this case, a new requirement expected by the delivery staff could be added, namely “Instruct the warehouse staff to deliver the product”. The new requirement would be written in the cell where the delivery staff row and the warehouse staff column intersect.

Type 3: Review of the actor's own objectives

Nothing is written in the diagonal cells of ARM for any actor except the warehouse staff. This means that the objectives to be achieved by the actors' activities are missing. It is necessary to reconsider the significance of the actors themselves; that is, to reconsider why each actor is necessary.

5. Future issues

In this section, we introduce future issues concerning a goal-oriented requirements analysis.

(1) Requirements changes

In actual business situations, existing requirements that have been created need to be revised according to changes in the business environment. However, in goal-oriented requirements analysis, there has been insufficient research into how to manage such changes in requirements. Therefore, the importance of a methodology for proper requirements management will increase in response to changes in the environment [3].

(2) Vague expressions

When high-level requirements, namely soft goals, are described by a stakeholder, they are very often expressed vaguely. Even when the intention is the same, the expression may be different. For example, three soft goals customer satisfaction increases, customers are satisfied, and we satisfy customers correspond to the same intention. However, the expressions of these soft goals are different. Therefore, it is necessary to have unified expressions in order to evaluate such requirements. In an actual analysis, it often takes a lot of time to deal with such problems. It is important to prepare a methodology to unify the expression of soft goals and make the understanding of their meanings consistent [4].

(3) Requirements interviews

It is likely that a large number of interviews with stakeholders will be required in order to apply a goal-oriented requirements analysis. However, it is usually very difficult to elicit clear requirements from stakeholders in the early stages of interviews. ARM could be an effective interview tool, but a practical methodology for conducting efficient requirements interviews is necessary to enable an analyst to use a goal-oriented requirements analysis.

6. Conclusion

In this article, we described ARM, which supports the review of requirements descriptions. ARM defines the relationships among actors in a business and addresses issues related to the application of the i* framework. It provides three types of reviews. This contributes to a comprehensive review of requirements descriptions. We also introduced future issues concerning a goal-oriented requirements analysis.

ARM should be easy for anyone to implement because it uses a familiar two-dimensional matrix, so it is a powerful technique for beginners. In future, we will investigate practical implications from case studies in order to demonstrate the benefits of ARM.

References

[1]	i* : http://www.cs.toronto.edu/km/istar/
[2]	Proc. of International Working Conference on Requirements Engineering (Refsq2007), Trondheim, Norway, June 11–12, 2007.
[3]	S. Saito and S. Yamamoto, “An Attribute-based Goal Selection Analysis Method,” Journal of the Japan Society for Management Information, Vol. 15, No. 3, pp. 37–50, 2006 (in Japanese).
[4]	K. Ibe, Y. Sato, and S. Yamamoto, “Experimental evaluation of i* framework development method based on actor relationship matrix,” SIGSS 2007, Technical Report of the Institute of Electronics, Information and Communication Engineers, Vol. 107, No. 392, pp. 7–12, 2007 (in Japanese).

↑ TOP