SciELO - Scientific Electronic Library Online

vol.81 número186Kinetic modelling of drying of three varieties of yucca industrialImpact estimates of the actions for the rehabilitation of energy efficiency in residential building índice de autoresíndice de assuntospesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados



Links relacionados

  • Em processo de indexaçãoCitado por Google
  • Não possue artigos similaresSimilares em SciELO
  • Em processo de indexaçãoSimilares em Google



versão impressa ISSN 0012-7353

Dyna rev.fac.nac.minas vol.81 no.186 Medellín jul./ago. 2014

Specification of problems from the business goals in the context of early software requirements elicitation

Especificación de problemas a partir de objetivos de negocios en el contexto de la educción temprana de requisitos de software


Carlos Mario Zapata-J. a & Fabio Alberto Vargas-Agudelo b


a Facultad de Minas, Universidad Nacional de Colombia, Colombia.
b Tecnológico de Antioquia, Institución Universitaria, Colombia.


Received: September 16th, 2013. Received in revised form: June 18th, 2014. Accepted: July 7th, 2014.


One of the main activities of the early elicitation of software requirements is the recognition and specification of organizational problems. Such activity is intended to allow for an initial requirements definition and the fulfillment of the stakeholder needs. Such problems can be directly traced to the organizational goals for achieving contextualized software applications and alignment with the organizational raison d'etre. In current elicitation methods based on goals and problems, the relationships are detected by the analyst and the stakeholder by using his/her experience and knowledge. However, traceability among goals and problems is still not achieved. In this paper we propose a method for specifying problems based on business goals. This method is composed by a set of semantic and syntactic rules used by the analyst for expressing the problem from the goal statements. Also, we present a laboratory example based on a KAOS goal diagram

Keywords: Business goals; problems; semantic rules; syntactic rules.

Una de las principales actividades de la educción temprana de requisitos de software es el reconocimiento y especificación de los problemas de la organización. Esta actividad tiene por objeto la definición de los requisitos iniciales y la satisfacción de las necesidades de los interesados. Estos problemas deben tener relación con los objetivos de la organización para lograr una aplicación de software contextualizada y alineada con la razón de ser de la organización. En los métodos de educción actuales basados en objetivos y problemas, las relaciones se detectan con la ayuda de la experiencia y conocimiento del analista y el interesado. Sin embargo aún no se logra trazabilidad entre objetivos y problemas. En este artículo se propone un método para la especificación de problemas a partir de objetivos organizacionales. Este método se compone de un conjunto de reglas sintácticas y semánticas que el analista usa para expresar los problemas a partir de las declaraciones de los objetivos. También, se presenta un ejemplo de laboratorio basado en el diagrama de objetivos de KAOS.

Palabras clave: Objetivos organizacionales; problemas; reglas semánticas; reglas sintácticas.


1.  Introduction

The definition of problems during the early requirements elicitation process is one of the main activities the analyst and the stakeholder should perform in order to complete an initial set of requirements. Such problems should be aligned with the organizational goals, as a basis for developing a software application. So, the problems linked to the system should reveal organizational deficiencies related to high-level goals [1].

Rebollar et al. [2] acknowledge the importance of early requirements engineering techniques, known as organizational modeling techniques. Requirements engineering is a vital stage in high-quality software development because it provides answers to the needs and expectations of the stakeholders. Likewise, the organizational goals should be considered for ensuring an in-context relevant software application [2]. Note that the context can influence-at any given point-the stakeholder concerns and consequently, the way to accomplish the goals [2]. Collecting requirements is a manual process completed by the analyst based on their experience and skills. At this stage, problems to be solved-and their relationships with the organizational goals-are defined by avoiding previous guidelines which can ensure consistency. Often, problems arise in the software development life cycle [3]. Some authors try to establish consistency relations among goals and problems, but they still fall short, since they only establish the relations based on the total negation of the goals, in order to solve the problems [4].

Current methodologies for the early elicitation of software requirements are based on business goals as the most important input (TROPOS [2], KAOS [5], I* [6], UNC-METHOD [7]). In such methodologies, the specification of goals, needs, problems, and requirements and their possible relation with each other is manually established by the analyst and the stakeholder. Traceability of the goals-among other elements-is needed in the initial stages of the requirements elicitation, but this task is difficult when you have to manually relate such elements.

With these ideas in mind, in this paper we propose a method for specifying problems from business goals-represented in the KAOS goals diagram-within the context of the early elicitation of software requirements. Pre-conceptual schemas are used to semantically link certain domain concepts, so that business problems can be identified based on high-level goals of the business.

The paper is organized as follows: In Section II, we describe some methodologies for specifying goals and problems in the requirements elicitation process. Furthermore, we present some work showing the generation of semantic and syntactic structures to represent goals and problems. In Section III, we describe the proposal for specifying problems from the goals outlined in the KAOS goal diagram. In Section IV, we provide a laboratory example of application of the proposal related to a KAOS goal diagram, described in the state of the art. Finally we present some conclusions and future work.


2.  Background

Some methodologies for early software requirements-like KAOS [5], TROPOS [2], I* [6], and UNC-Method [7]-are based on goals. The elicited information constitutes the essential input for specifying the organizational problems and needs. Such specification is manually carried out by the analyst and the stakeholder based on their experience and the previous knowledge of the stakeholder domain by the analyst. However, traceability among goals, problems, and requirements is still not achieved [8].

At the organizational level, some methodologies for project management-such as the Logical Framework [9] and the Kepner-Tregoe method [10]-use the relationships among problems and goals as strategies for structuring project proposals. In the Logical Framework the goal tree and the problem tree are used for creating proposals and provide an approach to the problem-goal relationship, in which the problems are formulated as the opposite of the goals. The process is manually carried out.

Vargas [11] proposes a set of grammatical structures for relating goals and problems in the context of organizational analysis and the software development process. In order to achieve this goal, the author proposes one structure for specifying problems and another one for specifying goals. The relation proposed by Vargas still falls short, because it only takes into account the syntactic relations, but not the semantic ones relevant to the organizational context and to facilitate traceability below the initial software requirements. In Table 1 we specify an example of the grammatical structures for formulating problems. In Table 2 we specify an example of the grammatical structures for enunciating goals. We use the following abbreviations: S is a sentence; V, V1, and V2 are verbs; Ad is an adjective; NP is a noun phrase; Adv is an adverb; N is a noun.

Eriksson and Penker [12] structure a Goal/Problem model specifying the goals and sub-goals of the organization, and indicate the problems to be solved in order to achieve such goals. This model is based on an extension of the UML object diagram. In this model, they do not specify structures to represent goals, problems, and strategies to relate them. All these tasks are performed by the analyst, based on his/her experience and knowledge.

Anton [13] presents a set of verbs to be used in the specification of goals within the processes of early elicitation of software requirements as a way to support the analyst and the stakeholder in their processes of collective construction.

In a summary of the state-of-the-art review (see Table 3), we specify some of the most important issues:

  1. Syntactic structure to represent goals
  2. Syntactic structure to represent problems
  3. Semantic structure to represent goals
  4. Semantic structure to represent problems
  5. Schemas representing domain problems
  6. Schemas representing goals
  7. Consistency validation among business goals and domains problems.


3.  A proposal for specifying problems from goals

During the early elicitation of software requirements, the specification of the problems to be solved by the software application is crucial. The analyst and the stakeholder are directly involved in this task, and they complete it based on their experience and organizational knowledge. In some of the methodologies for eliciting requirements, a diagram is used to display the business goals and identify the relation with the problems. The method we propose in this Section for the problem specification from organizational goals is based on the KAOS goal diagram. Also, we use pre-conceptual schemas for graphically representing contextual information. We use these schemas due to their proximity to the natural language of the stakeholder and the technical language of the analyst. It should be noted that the description with pre-conceptual schemas could also be made with class diagrams, entity relationship diagrams, domain models, semantic rules, ontologies, and so on. The basic syntax of the pre-conceptual schemas [14] is shown in Fig. 1.

Figure 1. Basic Syntax of Pre-conceptual Schemas.

The stages of the method for specifying problems from the organizational goals are described in Tables 4 to 7.

For example, Fig. 2 shows a KAOS goal diagram including the proposed structure [9] and Fig. 3 shows a domain representation by using a pre-conceptual schema [14]. Elements in gray come from the information provided by the modified goal diagram. The rest of the elements are taken from the interview with the stakeholder.

The rules are specified as follows:

Antecedent: We select a goal statement in which an improvement verb is used to qualify a noun phrase. Example: Increasing the ambulance service.

  • Consequent: C1. We first chose a negative connotation adjective as opposed to the positive verb proposed in the goal. The adjectives are the following: limited, poor, bad, worse, minor, modest, small, slow, low, and narrow. Then, we enunciate the problem by using the phrase "the result of the evaluation of" followed by the noun or the noun phrase described in the goal and the "is" verb followed by the adjective Example: The result of the evaluation of ambulance service is limited. (see Fig. 4).

  • Consequent: C2. Enunciating the problem by using an antonym of the verb proposed in the goal, followed by a noun or noun phrase related to the one described in the goal, which is reflected in the context of the domain expressed by the pre-conceptual schema. Example: Ambulance service is worsening. (see Fig. 5).

Antecedent: We select a requirement with an action verb and an achievement verb (e.g., ensuring the ambulance service is sent). The requirement should also have a constraint for qualifying the action verb (e.g., ambulance service is sent on time when the difference between the attention time and the reception time is lower or equal than 20 minutes).

  • Consequent: C3. Enunciating the problem by denying both the adverb and the constraint qualifying the action verb proposed in the goal. Example: the ambulance service is sent out of time (and ambulance service is sent out of time when the difference between the attention time and the reception time is greater than 20 minutes). See Fig. 6.

For example, Fig. 8 shows the pre-conceptual-schema-based domain representation including the problems detected [14].


4 Laboratory example

Ponsard et al. [15] present a goal diagram related to a train control system, as shown in Fig. 9. According to our method, the first stage is the validation of the structures related to the goals. In such a case, we need to review every goal defined against the structures provided by Vargas [9]. For example, the first goal "effective passenger transportation" does not match the proposed structure, since no achievement verb is found in the phrase. Effective is an adjective related to the improvement of the passenger transportation, so we can re-write the goal as "improving passenger transportation." The goal rapid transportation can be related to the increment of the speed of the entire transportation system, so we can rewrite "increasing transportation speed." In the case of the goal "safe transportation," we can relate the goal to the increment of the safety of the entire transportation system, so we can re-write such a goal as "improving transportation security." In the same way, we can proceed to obtain the partial goal diagram of the Fig. 10.

The next stage is related to the proposition of problems by using the structure provided by Fig. 3 and the rules belonging to stage 3. We build the pre-conceptual schema depicted in Fig. 11 with part of the information included in Fig. 10 and some other context information. It should be noted that such information in the real world is intended to be provided by the stakeholder. Some of the problems to be suggested by the analyst in order to gain stakeholder validation are included in Table 8.


5.  Conclusions

The methodologies for early elicitation of software requirements based on goals need a set of tools that provide the analyst and the stakeholder with the specification of goals and problems, as well as the relation among them.

Thus, early, relevant requirements aligned with the organization can be guaranteed. In this way, we can generate traceability among goals, problems and requirements. With these problems in mind, in this paper we proposed a method based on some rules for specifying problems based on business goals. We kept in mind that the problems should be aligned to the organizational goals and that they should justify the development of a software application. By applying this method, the analyst can help the stakeholder to determine the relevant problems related to the organizational context, since sometimes such problems are not adequately elicited.

The method proposed in this paper used the so-called pre-conceptual schemas in several ways: as a way to describe the structure of the problems, as a knowledge representation of the context information, and as a way to link the information included in the goals with the suggested organizational structure of the problems. Some other conceptual schemas can be used for this task, for example: domain models, class diagrams, entity-relationship models, semantic networks, and ontologies, among others. We used pre-conceptual schemas for several reasons: they are easy to understand by the stakeholders, they can be automatically traced to several conceptual schemas, and they exhibit a logical syntax for representing contextual information.


6.  Future work

Some research fields are expected to be developed as future work related to the specification of problems based on the organizational goals, during the early elicitation of software requirements:

  • Developing ontologies of terms connected to the problem domain, allowing for the specification of problems directly related to business goals.
  • Using the pre-conceptual schemas in order to define and structure other kinds of problems linked to organizational goals.
  • Suggesting other ways of linguistically and semantically relating problems and goals.
  • Establishing relations to improve the traceability among problems, goals, and requirements during the early requirements elicitation process.



[1] Lapouchnian, A., Goal-oriented requirements engineering: An overview of the current research, University of Toronto, 2005, 32 P.         [ Links ]

[2] Rebollar, A. M., Esquivel, H. E. y Moreno, L. A. G., Una guía rápida de la metodología tropos. Revista Gerencia Tecnológica Informática, 7 (19), pp. 67-77, 2008.         [ Links ]

[3] Ali, R., Dalpiaz, F. and Giorgini, P., A goal-based framework for contextual requirements modeling and analysis. Requirements Engineering, 15 (4), pp. 439 - 458, 2010.         [ Links ]

[4] Martínez, A., Pastor, O., Mylopoulos, J., and Giorgini, P., From early requirements to later requirements: A Goal-Based approach, proceedings of the 8th international Bi-conference workshop on Agent-Oriented information system, 2006, pp. 5-12.         [ Links ]

[5] Dardenne, A., Van Lamsweerde, A., and Fickas, S., Goal-directed requirements acquisition. Science of Computer Programming, 20 (1), pp. 3-50, 1993        [ Links ]

[6] Yu, E., Modelling strategic relationships for process reengineering. PhD. Thesis, University of Toronto, Toronto, Canada, 1995.         [ Links ]

[7] Zapata, C. and Arango, F., The UNC-Method: A problem based software development method. Ingeniería e Investigación, 29 (1), pp. 69-75, 2009.         [ Links ]

[8] Eric, S. K., Giorgini, P. and Maiden, N., (Eds.)., Social modeling for requirements engineering. Mit Press, 2011.         [ Links ]

[9] Sánchez, N., El marco lógico. Metodología para la planificación, seguimiento, y evaluación de proyectos. Revista Visión Gerencial, 2 (6), pp. 328-343, 2006.         [ Links ]

[10] Kepner, C. and Tregoe, B., The new rational manager: An updated edition for a new world. Princeton Research Press, 1997.         [ Links ]

[11] Vargas, F., Método para establecer la consistencia de los problemas en el diagrama causa-efecto con el diagrama de objetivos de KAOS, Tesis de Maestría (Ingeniería de Sistemas). Universidad Nacional de Colombia, Medellín, Colombia, 2010.         [ Links ]

[12] Eriksson, H. E. and Penker, M., Business modeling with UML: Business patterns at work. OMG Press Advisory Board, 1999.         [ Links ]

[13] Anton, A., Goal-Based requirements analysis. Proceedings of the 2nd IEEE International Conference on Requirements Engineering, 1996, pp. 136-144.         [ Links ]

[14] Zapata, C. M., Gelbukh, A. and Arango, F., Pre-conceptual schema: A conceptual-graph-like knowledge representation for requirements elicitation. Lecture Notes in Computer Science, 4293, pp. 17-27, 2006.         [ Links ]

[15] Ponsard, C., Massonet, P., Rifaut, A., Molderez, J.F., Van Lamsweerde, A. and Tran Van, H., Early verification and validation of mission critical systems. Electronic Notes in Theoretical Computer Science, 133, pp. 237-254, 2005.         [ Links ]


C. M. Zapata-Jaramillo, currently he is Associate Professor in the Computer and Decision Sciences Department, at the Facultad de Minas, at Universidad Nacional de Colombia, Medellín Campus. He holds a degree in Civil Engineering, a Specialization in Information System Management, an MSc. in Systems Engineering, and a PhD. in Engineering (focused on Information Systems); all his titles are from the Universidad Nacional de Colombia. His research areas include: Software engineering, natural language processing, computational linguistics and pedagogical strategies for teaching engineering. ORCID:

F. A. Vargas-Agudelo, currently, he is an assistant Professor in the Facultad de Ingeniería at the Tecnológico de Antioquia. He is a System Engineer, Software Engineering Specialist,and has an MSc. in System engineering and a PhD(c) in System engineering from the Universidad Nacional de Colombia and Director of Research at the Tecnológico de Antioquia. His research areas include software engineering, requirements engineering and software quality methodologies. ORCID: