SciELO - Scientific Electronic Library Online

 
vol.22 número2Modelado y simulación de la insatisfacción de los clientes, impuntualidad de los trabajadores y tolerancia al retraso en las cadenas de suministro make-to-order, medido a través del rendimiento del valor de la vida en la empresa del cliente índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Articulo

Indicadores

Links relacionados

  • En proceso de indezaciónCitado por Google
  • No hay articulos similaresSimilares en SciELO
  • En proceso de indezaciónSimilares en Google

Compartir


Ingeniería y Universidad

versión impresa ISSN 0123-2126

Ing. Univ. vol.22 no.2 Bogotá jul./dic. 2018

 

Artículos de investigación científica y tecnológica

Framework to elicit multidimensional requirements1

Marco de trabajo para elicitar requisitos multidimensionales2

Edgar Serna M3  , Alexei Serna-A. 4  

3Ingeniero de Sistemas (Corporación Universitaria Remington), Ms.C. en Ingeniería (UNAL), Ph.D. en Pensamiento Complejo (Multiversidad Edgar Morin). Investigador de la Universidad Autónoma Latinoamericana, Medellín, Colombia. eserna@eserna.com

4 Ingeniero de Sistemas (Universidad Católica Luis Amigó), M.s.C. (c) ITM. Investigador del Instituto Antioqueño de Investigación, Medellín, Colombia. alexeiserna@gmail.com.

Abstract

Objective:

Propose a framework to elicit multidimensional requirements.

Materials and methods:

A review of the literature is carried out, and the elicitation proposals are analyzed in which the multidimensionality of the requirements is taken into account.

Results and discussion:

23 works were found, of which 15 were selected that met the quality conditions and inclusion criteria. These proposals are related to multidimensionality in elicitation but do not take it into account in order to construct a representative requirement specification.

Conclusion:

It is evident that there is no unanimity about the dimensions from which the requirements originate, and they have not been elicited. For this reason, and because its existence is accepted, it is necessary to unify criteria and propose frameworks to elicit multidimensional requirements.

Key words: Requirements elicitation; software engineering; software requirements; multidimensionality

Resumen

Objetivo:

Proponer un marco para elicitar requisitos multidimensionales.

Materiales y métodos:

Se realiza una revisión de la literatura y se analizan las propuestas de elicitación en las que se tiene en cuenta la multidimensionalidad de los requisitos.

Resultados y discusión:

Se encontraron 23 trabajos, de los cuales se seleccionaron 15 que cumplieron con las condiciones de calidad y los criterios de inclusión. Estas propuestas relacionan la multidimensionalidad en la elicitación, pero no la tienen en cuenta para construir una especificación de requisitos representativa.

Conclusión:

Es evidente que no existe unanimidad acerca de las dimensiones desde las que se originan los requisitos y tampoco se gestionan para elicitarlos. Por eso y debido a que se acepta su existencia, se necesita unificar criterios y proponer marcos para elicitar los requisitos multidimensionales.

Palabras-clave: Elicitación de requisitos; ingeniería del software; ingeniería de requisitos; multidimensionalidad

1. Introduction

In software engineering, the term requirements refers to the set of needs that the product in development must satisfy. Requirements, in general terms, are derived from people, the architecture of technology and other systems, the national and international political and administrative contexts, social and ethical-ecological responsibility, etc. Although the majority of models and methodologies tend to treat these needs as the original sources of requirements, in reality, they should be considered dimensions because they are structured as facts, actions, and norms categorized with the goal of serving as predictors for analysts.

In the case of software development, the concept of dimension should not be confused with the concept as used in applied physics, mathematics, or philosophy but should rather be understood as a type of database that contains information related to the type of problem to be solved. In other words, dimensions are a collection of reference information about various measurable events, such as software requirements. Each dimension categorizes and describes events, actions, and rules about the data it contains so that the data can be consulted iteratively to explore, discuss, clarify, define, and agree on what the final product must satisfy.

An important issue that must be considered in the elicitation is the impossibility of assuming that the set of requirements is final and complete. Requirements, in fact, change as the solution progresses during project development or as part of the normal evolution of the context of the problem [1]. For that reason, and because of the challenge of adjusting a software project to budgetary and time constraints while fully satisfying the requirements, stakeholders must work together and discuss their needs from each dimension involved to increase the possibility of approaching the expected product. In this way, they can achieve a shared vision based on the analysis of the consulted information because they discuss and interpret the perspectives and needs of each dimension.

The literature on elicitation makes clear that the work of the analyst at this stage is like that of a farmer looking for and picking ripe fruit in a garden. In practice, this process is not so simple [2]. The analyst has to develop the skills and tenacity of a detective because discovering and understanding requirements is a complex task. The task is not simply to look for unique sources of origin, which would be like trying to find the fruit on a single tree. Instead, we must search for and identify these sources in dimensions because they are embedded in documents, artifacts, experiences, images, interpretations, and thoughts that are generally not direct in origin and because they have complex dependencies and interrelationships with other dimensions and disciplines.

Therefore, we contend that requirements should not be elicited by looking for them only at one source; rather, we must first identify the dimensions that may exist and then define and discuss their relevance to the project. In each dimension, there may be multiple relationships and dependencies in addition to direct and indirect sources, which are often not explicit. Resolving these difficulties is detective work, and the analyst must know these dimensions to identify and document requirements. In addition, analysts should work with a transdisciplinary team to discover the tacit and explicit information required to enable the team to analyze the structure and propose a solution to the problem.

2. Methodology

According to Kitchenham [3,4], a literature review has three primary phases: 1) planning the review, 2) conducting the review, and 3) documenting the results. These phases and other necessary processes are summarized in Table 1.

Table 1 Research methodology 

Source: Author’s own creation

3. Results

Some authors have focused on the dimensionality of requirements in their work, including Klaus Pohl [3], who proposes a framework in which the specification is a process that originates in vague ideas in natural language. His proposal is characterized by framing the process of requirements engineering in three dimensions: 1) specification, which stipulates the methods used and the viewpoints for understanding the needs of the system, 2) representation, which organizes the requirements using some form of notation, and 3) compliance, which addresses how to reach a common understanding about the requirements and the fundamental objectives of the system.

For Duran [4], the term requirement involves a large number of qualifiers that reflect dimensional aspects but are generally considered in isolation. The author identifies three dimensions from the requirements: 1) setting, the component where the project must be carried out; 2) feature, the system features that are desired in the specification; and 3) audience, specific actors who can understand the requirements. For Sawyer and Kotonya [5], there is a strong overlap between the classification and attributes of requirements because their origin can be classified into the following dimensions: 1) level of compliance, whether functional or nonfunctional; 2) level of emergence, whether they are derivatives or emergent; 3) degree of demand, whether they are from the product or process; 4) priority, whether their importance is high, medium, or low; 5) scope, whether they affect the system or a component; and 6) volatility/stability, the number of changes they undergo in development.

Silva et al. [6] state that the multidimensionality [7] inherent in applications presents a new challenge for the analysis of software requirements because the information in the applications is a matter of exploitation and integration of data that requires a high level of knowledge. For these authors, elicitation is similar to managing a data warehouse, in which dimensions are individual perspectives that determine the level of detail to be adopted for their representation as requirements. According to Tuunanen [8], the literature contains a gap regarding how to elicit requirements from different dimensions, and he presents an analysis based on two of these dimensions: communication and outreach. The author concludes that the literature does not explain how to overcome the barriers related to the scope of the requirements nor how to make communication smooth, in a common language, and oriented to the audience.

To Nurmuliani and colleagues [9], the management of changing requirements is a multifaceted problem that could be solved by adopting a multidimensional approach to elicitation. That is, one must take into account the nature of the changes, the characteristics of the participants, and the design context because they are important factors for achieving proper management. Meanwhile, Coleman [10] states that elicitation methods generate independent perspectives on the requirements, although many of their activities, or dimensions, overlap in the context of a project. She concludes that eliciting requirements dimensionally generates opportunities for team collaboration, improves knowledge management at this stage, and boosts product quality.

In this same sense, Moreira et al. [11] argue that an effective requirement engineering approach must reconcile the need for separating interpretations with that of satisfying the general requirements and restrictions. However, traditional methods do not offer such support for this phase of the life cycle because most methods only have a two-dimensional perspective: functional and nonfunctional. These authors propose that the requirements should be elicited uniformly from all dimensions of origin, regardless of their nature. Annoni and colleagues [12] maintain that recent research on requirements engineering has focused on the design of multidimensional conceptual models, but only a few studies are aimed at developing models and tools to analyze them. Their work aims to fill this gap, and they demonstrate how to systematically derive a conceptual scheme of multidimensional requirements.

Due to the complexity of current systems, it is necessary to explore and analyze the variability of the requirements at a higher level of abstraction, but the difficulty in understanding the origin of requirements influences the interpretations of analysts [13]. This issue makes it difficult to understand and manage the variability because the traditional process does not take into account the particular dimensions that define the origin of the requirements. These authors propose that variability is addressed based on dimensions to model and generate reasonable representations, while the level of variation is used to elicit specific terms from each dimension. Dufresne [14] modifies the Kano Model [15] using the theory of attractive quality and applies it to requirements engineering. According to him, the low level of acceptance of software products is due largely to the fact that requirements are elicited one- dimensionally, making it impossible to determine their interrelationships and dependencies in other dimensions.

Pa and Zin [16] state that one of the problems of requirements elicitation is the poor quality of communication between team members. For them, this practice is more than just expressing something because it requires sharing the values of language, experience, and culture. Therefore, they recommend using the dimensions from which the (physical, social, psychological, and temporal) requirements originate to understand and break down communication barriers that may arise. Meanwhile, Tran and Anvari [17] propose a framework for the elicitation of requirements based on five dimensions: management of change, user characteristics, knowledge, the cognitive process, and evaluation. Their proposal is inspired by different techniques adopted from various disciplines with the aim of helping analysts. For them, analyzing the source requirements from a single dimension does not permit a stable or durable specification because the requirements must be modified when their dimensional relationships are discovered.

As shown in this literature review, the authors recount the multidimensionality of elicitation or of requirements engineering, but their contributions are more oriented to analysis and representation than to management in order to build a representative specification of multidimensional requirements. Also evident is the lack of unanimity about the dimensions that are the source of the requirements, which is appropriate because each problem presents a unique context and domain. We should consider that there are dimensions specific to human interaction that have an impact on software solutions, such as sociocultural, political, institutional, administrative, technological, and disciplinary dimensions, embedded in any problem that can be solved with these products in which their requirements arise.

Because this literature review could not find a concrete framework to elicit multidimensional requirements, the researchers decided to structure and propose, based on their experience and the results of the research on which this work is supported, a framework to elicit multidimensional requirements. It is a theoretical proposal of how to carry out this process amid the complex developments in which software professionals are currently involved. As a framework, it was adopted as an experiment by the Instituto Nacional de Tecnología Industrial INTI of Argentina to validate it in its Software Engineering processes. It is expected that, by the end of October of this year, they will present the results achieved in the application of the framework. Next, the traditional process of eliciting requirements is described and, subsequently, the proposal of the framework to elicit multidimensional requirements is presented.

4. Traditional Elicitation

Currently, the elicitation of requirements is carried out by attending to general processes and methodologies that are tailored to each project and by drawing upon processes and methodologies from different areas of knowledge. That is, this activity is a combination of what has worked for others and what is believed to work to solve each particular problem. However, this way of working is difficult to articulate in complex contexts today because it is generally oriented to meet the needs of stakeholders in order to document and resolve those needs in the development of a product, while the complexity of the software requires a different vision for managing these requirements. In practice, elicitation is generally a process of interaction in which one or more methods is applied [18,33]: 1) verbal, 2) observational, 3) analytical, or 4) synthetic.

  • Verbal methods are techniques of communication and social interaction, such as interviews, workshops, focus groups, and brainstorming, through which analysts elicit explicit requirements [19]. Applying these methods is demanding because it is tedious to organize meetings and collect information as well as replay and analyze the transcription.

  • Observational methods consist of sessions of the observation of human activities, through which analysts can discover requirements that are difficult to verbalize, i.e., implicit requirements [20]. These methods are appropriate when the parties do not express themselves well verbally or when analysts want to understand the context in which the system will be used [21]. Because they usually require longitudinal studies and application takes time, observational methods are not often an option.

  • Analytical methods explore the documentation or the existing knowledge about a problem to elicit requirements through the deduction of analysts. These methods also allow information to be collected from the domain of the system, the workflow, and the software features. Although considered non-vital in elicitation, analytical methods can be complementary when inherited or related information is available [22].

  • Synthetic methods are also known as composite techniques because they combine individual methods to make a systematic composition of the above methods. Thus, these methods exploit the fact that, in elicitation, all parties communicate and interpret information in different ways and aim to find a common understanding of product requirements [23]. By combining various communication channels, they provide models that can demonstrate the characteristics and interactions of a system, but it is difficult to find trained analysts to apply them.

Most analysts select one or more of these methods for different factors related to the system to be developed: 1) level of abstraction, for abstracting the problem and setting its limits [24] using the generic knowledge of problem analysis and specific knowledge of product description; 2) sources, to ensure effective use in terms of available data and processes to build knowledge; 3) communication, because there are barriers to exchanging data and information through the interaction of different actors and analysts [25]; and 4) familiarity, because the level of certainty about the context and the domain of the problem reflects a relatively mature problematic situation that is easy to understand and structure, resulting in a clear expression of the vision and scope of the product.

In requirements engineering, the selection and application of these methods are based on the implicit assumption that stakeholders have formed a cooperative and sincere working team with members who are willing to share their knowledge and analysts who are carefully prepared for each elicitation session. The reality is that these situations are rarely achieved, partly because the teams are formed around a dominant discipline, and the implicit knowledge possessed by actors is not properly shared. This makes it necessary to experiment until a method is found that offers the best results in the search for requirements, which entails reworking, time delays, and cost overruns.

In this regard, the Standish Group conducted several studies between 1994 and 2008 on the successes, challenges, and failures in software projects due to inadequate elicitation [26]. According to these reports, more than half of cost overruns and failures are due to errors at the requirements engineering stage, an assertion that is supported by various studies from the same time period [27-31]. The analysis of these reports yields an extensive list of identified problems that highlight the shortcomings of traditional elicitation. Although the authors report cases along with their possible solutions, the variety and scope of the deficiencies are so extensive that trying to solve them is a complex and difficult task.

The scope of this paper does not encompass an analysis of all the problems in the elicitation of requirements and is therefore centered on the issue of source management. Source management is featured in all current methods and appears in the lists reported by the Standish Group and other analysts, who see it as a cause of deficiencies at this stage. To assume that requirements emerge from or can be discovered in some particular and unique source is to restrict the chance of finding their interrelationships and dimensional dependencies.

Moreover, in elicitation, human aspects that are difficult to locate in a single source of origin are intermingled: natural language is not always suitable for technological expression, thus requiring translation; the problems that the system must solve can change at any time and from any direction; customers describe their needs as if from a single paradigm, when those needs are actually related in ways that cannot be identified from a single source; and because requirements engineering is not deterministic, elicitation is not either. For these reasons, innovating and leveraging contributions from other areas of knowledge is needed to improve elicitation.

5. Framework to Elicit Multidimensional Requirements

Requirements elicitation is a process in which a team seeks, reveals, understands, and documents the needs to be met by the system, which, depending on their impact and influence on the solution, are traditionally classified into functional and nonfunctional requirements. When requirements are elicited as if their origin were a single source, problems of understanding and interpretation develop because the disciplinary perspective used to form the team tends to bias the search in one direction. This does not allow for discovering and charting the multiple interrelationships that the requirements have between and from those sources. For this reason, in elicitation, the analyst should approach the search for and understanding of requirements with a multidimensional perspective. In this way, the team can determine the scope and necessity of a solution before documenting needs through requirement specification.

In a software-dependent society where the complexity and size of problems that can be solved with technological products are ever increasing, traditional methods of eliciting requirements appear to be of little help to analysts. This context requires a change in practice, entailing a will to change and a different perspective. The lack of foresight in industry and academia regarding the management and administration of software degrades the reliability of the process and the final product. We must accept that elicitation is more than a process of communication and observation: it requires the team and stakeholders to share characteristics as language, experience, cultural values, interests, and knowledge.

In reality, the requirements engineering stage is carried out in a particular context and develops in several dimensions: organizational, physical, social, psychological, cultural, disciplinary, cognitive, and temporal, among others. These dimensions are, in turn, immersed in others with greater reach: global, legal, economic, and transdisciplinary, among others. In this context, multidimensional requirements interrelate and depend on multiple links; they often do not arise from or terminate in a single event, and much less are they exclusively contained in a sole source. However, traditional requirements engineering has focused on three objectives (capture, analyze, and manage requirements information) to generate document specification.

Multidimensionality is a principle of complex thought [32] that offers the possibility of ending determinism and reductionism. Elicitation can embrace this principle through the inclusion of source dimensions that do not exhaust, but rather increase, the chances of finding the requirements. Its goal is to understand the world (in this case, the problem), and therefore, it is imperative to reach unified knowledge about the system requirements. This means going beyond single sources and personal interpretations to achieve true integration. In addition, the data-information-knowledge chain does not come from one source or a single dimension, but rather from a variety of sources that are combined randomly and seemingly without a practical sense. Considering and analyzing each requirement from its original dimension(s) aids analysts in forming a single definition of the requirement and integrating it into elicitation documentation.

Moreover, in multidimensional elicitation, one must bear in mind that the explicit and tacit requirements may exist in dimensions that are either internal or external to the problem. This is evident in the relationships that individuals and organizations create formally or informally with suppliers, customers, or users and involves some aspects related to the problem. The detective work of analysts is to find these relationships and examine them to identify the requirements, but they must be cautious because many of these relationships are based on trust and attempting to examine them may raise issues of confidentiality. Therefore, the analyst is recommended to adopt practices that expose what each individual knows about the problem without violating their relationships or decisions. For example, requesting a formal document in technical language written in which the important aspects of their work are described could provide sufficient data/information/knowledge to discover the embedded requirements. Figure 1 details the process of the multidimensional elicitation of requirements.

Source: Author’s own creation

Figure 1 Framework to elicit multidimensional requirements 

This process is developed jointly by all team members to avoid discipline-specific interpretations of data/information/knowledge and synthesize interpretations into a single representation. To achieve this end, interpretations must involve the dimensions and disciplines that are important in the context of the problem domain, as in the possible solution. That is, internal and external data/information/knowledge should be integrated to build a knowledge model of comprehensive and unified requirements, involving contributions from the relevant disciplines and dimensions. In this way, an integrated understanding of requirements is acquired that facilitates the interpretation that the team and stakeholders share.

This transdisciplinary-multidimensional integration of the requirement’s source involves people, knowledge, and technology from different domains and contexts in which the system exists or with which it relates. Therefore, one should take the following two steps. 1) Find a common language to discuss the requirements, options, routes, and content of the elicitation document. For this step, it is important to form a transdisciplinary working team because one gradually progresses in understanding each language until knowledge of the requirements is integrated and unified. 2) Design a methodology to achieve integration and unification of the requirements. Not to be confused with the attempt to establish the knowledge of the requirements as a whole, this step involves the parceling of data/information/knowledge in each dimension and discipline of origin.

For the process, a dimensional requirement is defined by an end concept and a path of properties, i.e., it represents a complex characteristic of the problem. Because the requirement also has relationships with other dimensions and disciplines, one must consider the paths from a multidimensional-transdisciplinary perspective. In this way, the relevant semantics for interpretation are added. One must, however, be cautious because these relationships can be given in n different ways, which results in n different perspectives of analysis and interpretation. In addition, the team should be aware that all these paths can potentially identify different sets of instances in the end concept. The multidimensionality of the requirements is shown in Figure 2.

Source: Author’s own creation

Figure 2 Vision of multidimensional requirements 

Specifically, within the perspective of multidimensional requirements, the requirements are not presumed to come from a single original source. Rather, they are represented as if they are located in an n-dimensional and n-disciplinary space in which it is possible to understand and easily analyze them in terms of the data/information/knowledge that is available from different dimensions and disciplines, reflecting various sources of origin. For example, the data/information/knowledge needed to understand requirement (R1) comes from discipline (a), which is immersed in dimension (D3), as exemplified in the following real problem:

  • Requirement R1: The system must allow access to 40 users simultaneously

  • Data/Information/Knowledge: bandwidth, network traffic, priority subsystems, security system, etc.

  • Dimension D3: Technological Dimension (Interrelation: Administrative Dimension)

  • Discipline a: Telecommunications (Interrelation: Data Networks)

This paradigm offers a simple visualization of requirements that is easy to understand and intuitive for the team. Importantly, in real life, problems have this type of relationship and are therefore disposed to be analyzed from a multidimensional perspective so that they may be understood and solved. Figure 2 refers to the placement of data/information/knowledge in a multidimensional-transdisciplinary space. Therefore, it can be interpreted as a mathematical function. Currently, these multidimensional spaces are also commonly referred to as data cubes. However, keep in mind that in elicitation, this multidimensional- transdisciplinary location of the data-information-knowledge chain is only used to find the multidimensional source of requirements.

6. Conclusions

Under the current elicitation of requirements, analysts must use their wits to find the system requirements in the different dimensions and disciplines of origin. This detective work helps them identify a way to solve a specific problem. In traditional elicitation, the requirements are assumed to originate from a single source, but the complexity and size of problems give the needs of the customer, user, and system multiple origins, in addition to relationships and dependencies that cannot be traced from a predetermined source.

This article proposes that the elicitation of requirements must be multidimensional because reality shows that a relationship or dependency that is not taken into account can cause a requirement to be overlooked or misinterpreted. As a principle of complex thought, multidimensionality can provide analysts with a tool that allows them to innovate the way they carry out an elicitation. It can also facilitate the identification of different relational paths that generate volatility and ambiguity in the interpretation of requirements.

Another deduction from this study is that the process of the elicitation of multidimensional requirements must begin with the formation of an interdisciplinary team. Solving current problems must involve people with different views and perspectives who then coalesce into a unique interpretation of the context and the domain under consideration. This aspect is also important because, as stated above, requirements do not have a single definitive source and, to structure an elicitation document, a comprehensive analysis needs to be established that is based on a shared transdisciplinary language.

References

[1] M. Terstine. “The Progress of Requirements Engineering Research.” Revista Antioqueña de las Ciencias Computacionales y la Ingeniería de Software (RACCIS), Vol. 5, No. 1, 18-24, 2010. [ Links ]

[2] A. Alvear and G. Quintero. “Integrating software development techniques, usability, and agile methodologies.” Revista Actas de Ingeniería, Vol. 1, 94-103, 2015. [ Links ]

[3] K. Pohl. “The three dimensions of Requirements Engineering.” Information Systems, Vol. 19, No. 3, 243-258, 1994. [ Links ]

[4] A. Durán. Un entorno metodológico de Ingeniería de Requisitos para Sistemas de Información. PhD dissertation, Universidad de Sevilla, España, 2000. [ Links ]

[5] P. Sawyer and G. Kotonya. Software Requirements. Guide to the Software Engineering Body of Knowledge. USA: IEEE Computer Society Press, 2001. [ Links ]

[6] F. Silva, A. Carvalho and J. Castro. “Towards a Methodology for Requirements Analysis of Data Warehouse Systems.” In XVI Simpósio Brasileiro de Engenharia de Software, 2002, 146-161. [ Links ]

[7] A. Abelló, J. Samos and F. Saltor. “Benefits of an object oriented multidimensional data model.” Lecture Notes in Computer Science, Vol. 1944, 141-152, 2002. [ Links ]

[8] T. Tuunanen. “A new perspective on requirements elicitation methods.” Journal of Information Technology Theory and Application, Vol. 5, No. 3, 45-62, 2003. [ Links ]

[9] N. Nurmuliani, D. Zowghi and S. Williams. “Using card sorting technique to classify requirements change.” In 12th IEEE International Requirements Engineering Conference, 2004, 240-248. [ Links ]

[10] D. Coleman. “Dimensions of interactive software requirements: Synergistic opportunity.” In IEEE Southeast Conference, 2005, 397-405. [ Links ]

[11] A. Moreira, A. Rashid and J. Araújo. “Multi-Dimensional separation of concerns in Requirements Engineering.” In 13th IEEE International Conference on Requirements Engineering, 2005, 285-296. [ Links ]

[12] E. Annoni, F. Ravat, O. Teste and G. Zurfluh. “Towards multidimensional requirement design.” Lecture Notes in Computer Science, Vol. 4081, 75-84, 2006. [ Links ]

[13] S. Liaskos, L. Jiang, A. Lapouchnian, Y Wang, J. Sampaio and J. Mylopoulos. “Exploring the dimensions of variability: A Requirements Engineering perspective.” In First International Workshop on Variability Modelling of Software-Intensive Systems, 2007, 17-26. [ Links ]

[14] S. Dufresne. A Hierarchical Modeling Methodology for the Definition and Selection of Requirements. PhD dissertation. School of Aerospace Engineering, Georgia Institute of Technology, 2008. [ Links ]

[15] N. Kano, N. Seraku, F. Takahashi and S. Tsjui. “Attractive quality and must-be quality.” Hinshitsu: The Journal of the Japaneses Society for Quality Control, Vol. 14, No. 2, 39-48, 1984. [ Links ]

[16] N. Pa and A. Zin. “Requirement Elicitation: Identifying the Communication Challenges between Developer and Customer.” International Journal on New Computer Architectures and Their Applications, Vol. 1, No. 2, 371-383, 2011. [ Links ]

[17] H. Tran and F. Anvari. “A five-dimensional requirements elicitation framework for e-Learning systems.” International Journal of Information and Electronics Engineering, Vol. 6, No. 3, 185-191, 2016. [ Links ]

[18] E. Sema M. “Analysis and selection to requirements elicitation techniques.” In 7th Colombian Computing Congress, 2012, 1-7. [ Links ]

[19] T. Gilb. Competitive engineering: A handbook for systems engineering, requirements engineering and software engineering management usingplanguage. Oxfor: Elsevier, 2004. [ Links ]

[20] P. Zave. “Classification of research efforts in requirements engineering.” ACM Computing Surveys, Vol. 29, No. 4, 315-321, 1997. [ Links ]

[21] S. Viller and S. Sommerville. “Social analysis in the requirements engineering process: From ethnography to method.” In 4th International Symposium on Requirements Engineering, 1999, 6-13. [ Links ]

[22] B. González, J. Sampaio and M. Laguna. “Eliciting non-functional requirements interactions using the personal construct theory.” In 14th IEEE International Requirements Engineering Conference, 2006, 340-341. [ Links ]

[23] A. Hickey, D. Dean and J. Nunamaker. “Establishing a foundation for collaborative scenario elicitation.” The DATA BASE for Advances in Information Systems, Vol. 30, No. 3-4, 92-110, 1999. [ Links ]

[24] D. Avison and G. Fitzgerald. Information systems development: Methodologies, techniques and tools. USA: McGraw-Hill, 2002. [ Links ]

[25] G. Dafoulas and L. Macaulay. “Investigating cultural differences in virtual software teams.” The Electronic Journal of Information Systems in Developing Countries, Vol. 7, No. 4, 1-14, 2001. [ Links ]

[26] J. Eveleens and C. Verhoef. “The rise and fall of the Chaos report figures.” IEEE Software, Vol. 27, No. 1, 30-36, 2010. [ Links ]

[27] A. Lamsweerde. “Requirements engineering in the year 00: A research perspective.” In 22nd International Conference on Software Engineering, 2000, 5-19. [ Links ]

[28] B. Boehm. “The art of expectations management.” Computer, Vol. 33, No. 1, 122-124, 2000. [ Links ]

[29] R. Briggs and P. Gruenbacher. “EasyWinWin: Managing complexity in requirements negotiation with GSS.” In 35th Hawaii Intern, Conference on System Sciences, 2002, 1-10. [ Links ]

[30] A. Eberlein and J. Leite. “Agile requirements definition: A view from requirements engineering.” In International Workshop on Time-Constrained Requirements Engineering, 2002, 1-5. [ Links ]

[31] K. Molokken and M. Jorgensen. “A review of software surveys on software effort estimation.” In International Symposium on Empirical Software Engineering, 2003, 223-230. [ Links ]

[32] E. Morin. “Restricted complexity, general complexity.” In Intelligence de la complexité: Épistémologie et pragmatique colloquium, 2006. [ Links ]

[33] E. Serna M. Prueba funcional del software - Un proceso de Verificación constante. Medellín: Fondo Editorial ITM, 2013. [ Links ]

[34] B. Kitchenham. Procedures for undertaking systematic literature reviews. Joint technical report. UK: Computer Science Department, Keele University. 2003. [ Links ]

1 Submitted on: February 14th, 2017. Accepted on: May 16th,2018. This investigation article is derived from “Diseño de un modelo semiformal para documentar la elicitación de requisitos” investigation project. Medellín, Colombia.

2 Fecha de recepción: 14 de febrero de 2017. Fecha de aceptación: 16 de mayo de 2018. Este artículo de investigación se deriva del proyecto de investigación “Diseño de un modelo semi-formal para documentar la elicitación de requisitos.” Medellín, Colombia.

Creative Commons License This is an open-access article distributed under the terms of the Creative Commons Attribution License