Requirement elicitation is a very critical step in software development. In order to develop adequate software which answers to user's needs, it is essential to understand the real-world environment, the users themselves, goals, constraints, and risks and its possible solutions. Unable to describe correct requirements can lead to a massive software development failure. This paper aims to propose an integrated framework for requirement elicitation which combines the characteristics of goal-based requirement engineering methods, Problem Frame (PF), and Message Sequence Chart (MSC). The proposed framework uses i* framework to describe the dependency relationships between actors, PF to analyze the constraints that exist in the real world, KAOS' to analyze obstacles, and MSC to show the dynamic behavior of the system.
Requirements engineering (RE) is an engineering activity that ties up the development
activities with the real-world problems. It represents a series of engineering decisions
that lead from recognition of a problem to be solved to a detailed specification of that
problem [
There are several methods in analyzing requirements, but currently they differ from
one to another. Each method has its own characteristics and fundamentals. In the
requirement analysis community, goal-based modeling approaches have gained
considerable attention. These approaches aim at capturing the rationale for the software
system development [
This research aims to develop a framework that can analyze the actors and goals in a system, while analyzing scenarios that can explain which tasks go first and which go later along with the constraints exist in the environment. The framework combines i* approach to describe the relations between actors in the system along with their tasks and goals, with Message Sequence Chart (MSC) and Problem Frame method to explain the scenarios of the system, the process sequences and constraints in the system. Moreover, it also imports the obstacle analysis from KAOS to analyze risks in the software development and their possible solutions.
We understand that integration needs a good communication line between methods, and there will be intersection points in some methods that can be complicated and difficult to understand. To answer those problems, the next step of this research is to develop a support tool for the integrated framework. 2 2.1
A goal is a prescriptive statement of intent that the system should satisfy through the
cooperation of its agents [
KAOS is a goal-driven, model-based approach for elaborating a complete,
adequate, consistent, and well-structured set of measurable software requirements and
environment assumptions [
Problem Frame [
Message sequence chart describes the scenario in the system. It shows the flow of
data and the actor responsible for sending, and receiving messages in the system.
Message Sequence Charts (MSCs) are a technique to describe patterns of interaction
between the components of interactive distributed systems by specific diagrams [
This paper uses a problem about meeting scheduler software in order to explain the
integrated framework. The problem example used in this paper is taken from a
version found in [
In order to elicit requirements, first, it is necessary to elicit who the actors involved in the system are because each actor has different goals, tasks, and resources. Actors can depend on other actors for some goals, resources, or tasks to be completed. In the meeting scheduler problem, initially there are two actors, meeting initiator and meeting participants. I*’s model shows how those two actors depend on each other. For example, meeting initiator depends on participants for goal “meeting is fully attended”. Moreover, each actor’s own goals and tasks decompositions are also described inside each actor in a hierarchical system.
By describing these relations in i* model, we can get the big idea of the environment, actors involved, and their relations. In addition, not only the outside relations of actors, the goal and task decomposition inside each actor can also be understood. These are considered essential in order to elicit software requirements. 3.3
Although the i* model has already described the relations between actors, goals and tasks decompositions, and the idea of the system, it lacks in describing the dynamic behavior of the system. By looking at i* diagram only, we cannot understand which task goes first and which goes later, nor we can know which resource is needed first before the other. Thus, this paper integrates the Message Sequence Chart (MSC) into the framework, to describe the scenarios exist in the system. However, unlike UML’s sequence diagram, MSC supports the characteristics of i* model which separates the requirement analysis process and the software design process by not going too deep into the development processes. MSC shows the flow of the resources between actors and its orders which represent scenarios in the system, not computer methods nor classes. In this integrated framework, the actors in MSC are actors from i* model, and the messages in MSC are the resources from i*. 3.4
After the system’s environments are understood by doing the earlier steps, now it is necessary to describe how the environment will work if we add a new machine actor, which is the software that will be developed, the meeting scheduler system, into the i* model and reconnect the relations between actors, as shown in figure 1, except the requirement circle as it will be explained in the next step. Problem Frame is used to describe the requirement constraints which exist in the real world to help software developers to realize and understands the outside circumstances. We already analyzed the relations between actors and their tasks and goals. The behavior of the system is also already drawn in the earlier steps. However, there are constraints in the environment that has not been elicited yet in the above steps. By analyzing the system from a problem frame view (figure 2), we can find that there are constraints that is not elicited yet, so we need to find and add them into the integrated diagram.
The requirement constraints are written in a, b, c, and d as symbols and the
descriptions are written separately to save space in figure 1. By analyzing the requirement
constraints that exist in the system, we can enhance the behavior analysis by inserting
constraints into the chart, as shown in figure 3.
Then after the whole diagram is done, using KAOS method [
This research proposes a new integrated framework in software requirement analysis, taking advantages from existing methods like i*, Message Sequence Chart, KAOS, and Problem Frame, which are currently used separately even though they all used for the same purpose which is to elicit requirements. By combining the advantages of those methods, this research is expected to be able to cover each methods’ disadvantages, and by doing so, requirements can be described suitably and clearly. This paper explains the early result of our research, which is the integrated framework. We also show the applicability of our framework by implementing it on the meeting scheduler problem.
In order to integrate several methods into one framework, there are some setbacks in our framework. The framework consists of several methods in its implementation which can cause the diagrams to be complicated and difficult to understand. Moreover, there are some intersection points between each approach in the framework, for example, actors in the i* model and MSC, or tasks in the i* model and KAOS’ obstacle analysis, which draw the possibility of inconsistency and redundancy if they are manually drawn. Thus, for future work, our research aims to develop a support tool to assist user in implementing the integrated framework that can auto-generate diagrams from known variables in order to mitigate redundant drawings, consistency checks, and to provide simple views of each diagram if the users feel the need to check diagrams individually, not as a whole which can be complicated. By using this support tool, it would be easier for users to analyze requirement while adapting to the fastchanging environments which software are built in. 5