11

Dimensions and Types of Non-Functional Requirements NFR

Dimensiones y tipos de Requisitos No-Funcionales RNF

Michael Pierdin1, Geraldin Bulder2

University of Toronto 1 mpierdin(AT)utoronto.ca, 2 gbulder(AT)mail.utoronto.ca INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación. Historia del artículo Recibido: 20-12-2011 Correcciones: 10-04-2012 Aceptado: 12-04-2012 Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements/Specifications. General Terms Software Engineering, Requirements Engineering. Keywords Non-Functional Requirements, Software Engineering, type of system, application domain. Palabras clave Requisitos No-funcionales, Ingeniería de Software, tipos de sistemas, dominio de aplicación.

ABSTRACT In spite of Non-functional requirements-RNF-are recognized as an important component to the success of software projects, in the community of software engineering studies indicate, so far, that there is not still a general consensus with respect to its definition. This paper presents the results of an extensive and systematic analysis around three existing dimensions about the NFR: (1) definition and terminology, (2) types and (3) RNF relevant in various types of systems and application domains. It is also describe two different perspectives to examine and presents a wide range of types of catalogs, highlighting the most frequently considered in the projects. It is also presented an innovative classification based on the types of systems and application domains, which could help developers to identify which are important in a particular application domain and for which specific systems. RESUMEN A pesar de que los requisitos No-funcionales ―RNF― se reconocen como un componente importante para el éxito de los proyectos software, en la comunidad de la Ingeniería de Software los estudios indican, hasta el momento, que aún no existe un consenso general con respecto a su definición. En este trabajo se presenta el resultado de un análisis amplio y sistemático a la literatura existente alrededor de tres dimensiones de los RNF: (1) definición y terminología, (2) tipos y (3) RNF relevantes en diversos tipos de sistemas y dominios de aplicación. También se describen dos perspectivas diferentes para examinarlos y se presenta un amplio catálogo de tipos, resaltando los que con mayor frecuencia se consideran en los proyectos. También se presenta una clasificación novedosa con base en los tipos de sistemas y los dominios de aplicación, lo que podría ayudar a los desarrolladores para identificar cuáles son importantes en un dominio de aplicación particular y para cuáles sistemas específicos.

© 2012 IAI. All rights reserved.

1. INTRODUCCIÓN Los requisitos no-funcionales se reconocen como factor muy importante para alcanzar el éxito de los proyecto software [1-3]. Si los RNF no se tratan adecuadamente, puede surgir un número de problemas potenciales. Por ejemplo, software incongruente y de mala calidad, insatisfacción de clientes, usuarios finales y desarrolladores, lo que causa sobrecosto e incrementa el tiempo para encontrar los errores del producto [1]. En el ciclo de vida del desarrollo de software, los RNF se consideran como las restricciones o aptitudes de operación [4]. Los RNF imponen restricciones en el producto en desarrollo, en el proceso de desarrollo y en limitaciones externas específicas que el producto debe exhibir [5]. A menudo, los RNF son más importante que los Requisitos Funcionales (FRS) para determinar el éxito o el fracaso de un sistema [6, citado por 7, 8]. Cuando se descuidan los

RNF se origina una serie de fallos del software [3, 9-12], como el fallo sistémico en el London Ambulance System [10, 11], el fallo del sistema causado por problemas de escalabilidad y rendimiento en el New Jersey Department of Motor Vehicles Licensing System [13] y algunos otros ejemplos que se describen en [10, 13-15]. A pesar de que los RNF se reconocen ampliamente como muy importante, una revisión a la literatura demuestra que a menudo son ignorados, mal entendidos y no se consideran adecuadamente en el desarrollo de software. En el desarrollo del sistema software los usuarios se focalizan naturalmente en la especificación de sus requisitos funcionales o de comportamiento, es decir, las cosas que el producto tiene que hacer [1, 7]. Por lo tanto, los RNF se pasan por alto en el proceso de desarrollo de software [3, 16]. En varios estudios acerca de las prácticas de investigación en la industria del software reportan que los desarrolladores comúnmente no prestan suficiente

RACCIS, 2(1), 11-17, 2012.

Revista Antioqueña de las

Ciencias Computacionales y la Ingeniería de Software

ISSN: 2248-7441

www.fundacioniai.org/raccis/index.htm

raccis@fundacioniai.org

12

atención a los RNF [3, 16-18], que no se elicitan al mismo tiempo y con el mismo nivel de detalle que los FR y que a menudo son mal articulados en el documento de requisitos [17, 18]. Además, estas investigaciones demuestran que el trato negligente a los RNF en el desarrollo de un sistema software está fuertemente influenciado por sus características: que son subjetivos, relativos y que interactúan [1], que son abstractos [10, 19] y que no presentan una naturaleza uniforme [2]. Estas características hacen los RNF sean difíciles de tratar, modelar, verificar, probar y de comparar con los FR [1, 8, 20, 21]. Asimismo, que es difícil capturarlos, especificarlos y gestionarlos porque la mayoría de desarrolladores no tienen un conocimiento adecuado de ellos y a que en la literatura existe poca ayuda disponible [22]. La mayoría de las investigaciones en Ingeniería de Software, particularmente en la Ingeniería de Requisitos, se orienta a los requisitos funcionales, es decir, se trata de asegurar que se entregue la funcionalidad necesaria del sistema al usuario [23]. El término requisitos no-funcionales se ha utilizado por casi tres décadas, sin embargo, los estudios realizados hasta la fecha indican que actualmente aún no existe un consenso general en la comunidad de la Ingeniería de Software con respecto a su noción [1, 7, 24, 25]. Glinz [24, 25], incluso argumenta que es necesario replantear la noción de RNF debido a que no se encuentra un concepto claro acerca de lo que realmente son. La revisión a la literatura también demostró que no se conoce bien una serie de aspectos esenciales relacionados con los RNF, como una variedad de perspectivas para considerarlos y su relevancia en diversos tipos de sistemas y dominios de aplicación. Estos hechos motivaron este trabajo en el que se describe una investigación exhaustiva y sistemática de la noción de RNF en la literatura de la Ingeniería de Software con el objetivo de mejorar los niveles de comprensión acerca de este complejo y multifacético fenómeno. Este estudio abarca tres dimensiones esenciales de los requisitos no-funcionales: (1) definición y terminología, (2) tipos y (3) RNF relevantes en diversos tipos de sistemas y dominios de aplicación. De estos tres parámetros se ha derivado una serie de preguntas de investigación: 1. ¿Qué perspectivas existen en la comunidad de la

Ingeniería de Software al considerar los RNF? 2. ¿Cuál es la tipología de los RNF? 3. ¿Qué tipos de RNF se consideran o discuten

comúnmente en la literatura? 4. ¿Qué tipos de RNF son motivo de preocupación en los

diferentes tipos de sistemas? 5. ¿Qué tipos de RNF son motivo de preocupación en los

diferentes dominios de aplicación? Las principales contribución de este trabajo es una clasificación novedosa de RNF con base en la tipología, la definición, los tipos de sistemas y los dominios de aplicación. Esta contribución beneficiará de muchas maneras a la comunidad de la Ingeniería de Software ―es

decir, a investigadores y profesionales―. La correspondencia entre los RNF y los tipos de sistemas y entre los RNF y los dominios de aplicación se desarrolla mediante la realización de un análisis a las referencias cruzadas de la literatura. Este artículo está organizado en cuatro secciones: en la primera se presenta la introducción en la que se describe la importancia de los RNF en el desarrollo de software; en la segunda se describe el enfoque de la investigación y la fuente de información; los resultados de la investigación se describen en la sección tres y la sección 4 contiene las conclusiones, la discusión y los futuros trabajos, poniendo de relieve algunas cuestiones abiertas que surgen a partir de esta investigación. 2. METODOLOGÍA APLICADA La investigación se llevó a cabo a partir de 182 fuentes de información publicadas en las últimas tres décadas. La mayoría son artículos académicos relacionados con la disciplina de la Ingeniería de Software en general y con la Ingeniería de Requisitos en particular ―por ejemplo, artículos de revistas, ponencias en conferencias y estándares IEEE/ISO―, y unos pocos son reportes de la industria ―por ejemplo, reportes técnicos y white papers―. Todas estas fuentes cubren diferentes temas de RNF, como se ilustra en la Figura 1. El punto de partida para seleccionar los documentos a revisar fue el estudio de Chung et al. [1]. La composición detallada de la literatura de Ingeniería de Software investigada se presenta en la Tabla 1.

Figura 1. Temáticas de investigación en RNF

Tabla 1 Fuentes de información

Tipo Cantidad Revista 78 Ponencia 70 Libro 16 Otros 18

Cada artículo fue analizado sistemático utilizando la técnica de análisis de contenido [26, 27]. Se seleccionó el análisis de contenido porque les permite a los investigadores identificar tendencias y patrones en la literatura a través de la frecuencia de palabras clave y mediante la codificación y la categorización de los datos en un grupo de palabras con significado o connotaciones similares [27, 28]. Esta técnica también es aplicable a todos los contextos de dominio [26, 29]. Se definieron tres dimensiones esenciales como línea base de investigación: (1) definición y terminología, (2) tipos y

13

(3) RNF relevantes en diversos tipos de sistemas y dominios de aplicación. Para la primera dimensión se catalogaron cada una de las definiciones y las terminologías que se encontraron en la literatura y posteriormente se analizaron los aspectos de similitud y de diferencia entre ellos. A partir de este proceso fue posible visualizar las diferentes perspectivas de cómo la comunidad de la Ingeniería de Software considera los RNF y las terminologías introducidas para representarlos cada perspectiva. Para la segunda dimensión se recolectaron todos los tipos desde catálogo de tipos de RNF y se registró su definición y atributo ―el término atributo se considera aquí como el componente principal de cada tipo de RNF; en la literatura, atributo también se conoce como un sub-factor de calidad [32-34] o sub-tipo de RNF [1]. Posteriormente, se llevó a cabo el análisis de frecuencia para cada tipo con el fin de identificar los RNF comúnmente considerados, es decir, los que frecuentemente figuran en los catálogos de tipos de RNF. Para la dimensión tres se realizó un mapeo entre los tipos de sistemas y los dominios de aplicación y los tipos de RNF considerados en cada tipo de sistema o dominio de aplicación. En este estudio se identificaron cinco diferentes tipos de sistemas con sus RNF relevantes, mientras que para el dominio de aplicación se adoptó la Digital’s Industry Taxonomy [30, 31]. 3. RESULTADOS Con respecto a las preguntas de investigación los hallazgos de esta investigación se clasifican en: 3.1 Definición y terminología de los RNF La Figura 2 muestra los resultados acerca de la definición y la terminología de los RNF en la literatura. Se puede observar que, generalmente, el término RNF se considera para dos perspectivas diferentes: (1) como los requisitos que describen las propiedades, características o limitaciones que un sistema software debe exhibir y (2) como los requisitos que describen los atributos de calidad que el producto software debe tener. En la primera perspectiva, los RNF consisten de varios aspectos, como las restricciones de desarrollo, las reglas de negocio, las interfaces externas, los atributos de calidad y cualquier otro requisito que no describa la funcionalidad del sistema. Para representar los RNF en

esta perspectiva también se utilizan términos como restricciones, requisitos sin comportamiento, preocupaciones, objetivos y requisitos extra-funcionales. La segunda perspectiva toma el enfoque limitado de RNF para considerar sólo los atributos de calidad; por lo tanto, esta perspectiva es un sub-conjunto de la primera. Los términos requisitos de calidad, atributos del sistema software y atributos de calidad, también se utilizan para representar RNF.

Figura 2. Definición y terminología de RNF

3.2 Tipos de RNF En esta investigación se identificaron en la literatura 252 tipos de RNF. Generalmente, consisten de atributos de calidad ―mantenimiento, rendimiento y fiabilidad―, restricciones de desarrollo ―tiempo, costo y equipo de desarrollo―, requisitos de interfaces externas ―interfaz de usuario y factores humanos, apariencia y sensación e interfaz del sistema―, reglas de negocio ―producción en el ciclo de vida― y otros ―culturales, políticos y ambientales―. Entre estos 252 tipos, 114 corresponden a las definiciones de RNF que se han discutido específicamente en relación con "calidad". La lista de estos 114 tipos se presenta en la Tabla 2. En esta lista se muestra que 23 tipos de RNF (20,18%) tienen definición y atributos, que 30 (26,32%) sólo tienen definición y que los demás 61 tipos (53,50%) fueron introducidos sin definición o atributos. La lista de detalles de esta clasificación se ilustra en la Tabla 3.

Tabla 2 Tipos de RNF

Agilidad Durabilidad Facilidad de recuperación Nivel de madurez Ajustabilidad Efectividad Facilidad de reemplazo Nivel de medición Asequibilidad Eficiencia Facilidad de repetición Nivel de permanencia Atomicidad Escalabilidad Facilidad de revisión Nivel de resumen Atractividad Estabilidad Facilidad de transferencia Nivel de simpatía Auto-descripción Exhaustividad Facilidad de verificación Nomadismo Calidad de servicio Expresividad Facilidad operativa Operatividad Capacidad de adaptación Extensibilidad Factibilidad Portabilidad Capacidad de ampliación Facilidad de acceso Flexibilidad Precisión Capacidad de anonimato Facilidad de análisis Formalidad Privacidad Capacidad de aprendizaje Facilidad de cambios Funcionalidad Probabilidad Capacidad de comunicación Facilidad de comprensión Grado de supervivencia Rendimiento Capacidad de estructuración Facilidad de confección Idoneidad Replicabilidad Capacidad de formación Facilidad de configuración Inmunidad Responsabilidad

14

Capacidad de incremento Facilidad de control Integridad Reusabilidad Capacidad de integración Facilidad de demostración Inter-operatividad Robustez Capacidad de soporte Facilidad de descomposición Legibilidad Seguridad Capacidad evolutiva Facilidad de estandarización Mejorabilidad Simplicidad Capacidad sumativa Facilidad de expansión Movilidad Sostenibilidad Compatibilidad Facilidad de instalación Nivel de certeza Susceptibilidad Complejidad Facilidad de intercambio Nivel de completitud Tolerancia a fallos y errores Composición Facilidad de juicio Nivel de comprensión Trazabilidad Confiabilidad Facilidad de localización Nivel de confianza Uniformidad Confidencialidad Facilidad de mantenimiento Nivel de conformidad Usabilidad Consistencia Facilidad de observación Nivel de correctitud Variabilidad Control de seguridad Facilidad de personalización Nivel de defensa Versatilidad Dependencias Facilidad de predicción Nivel de depuración Viabilidad Disponibilidad Facilidad de prueba Nivel de generalización Visibilidad Distribución Facilidad de reconfiguración

Tabla 3 Definición y atributos de los RNF

Con definición y atributos Con definición Sin definición ni atributos Capacidad de adaptación Capacidad de integración Confiabilidad Control de seguridad Disponibilidad Eficiencia Escalabilidad Facilidad de acceso Facilidad de cambios Facilidad de comprensión Facilidad de mantenimiento Facilidad de prueba Funcionalidad Integridad Legibilidad Portabilidad Privacidad Rendimiento Reusabilidad Robustez Seguridad Tolerancia a fallos y errores Usabilidad

Atractividad Calidad de servicio Capacidad de aprendizaje Capacidad de comunicación Capacidad evolutiva Complejidad Composición Confidencialidad Consistencia Dependencias Estabilidad Facilidad de análisis Facilidad de expansión Facilidad de instalación Facilidad de localización Facilidad de recuperación Facilidad de reemplazo Flexibilidad Idoneidad Inmunidad Inter-operatividad Nivel de completitud Nivel de correctitud Nivel de defensa Nivel de madurez Nivel de permanencia Nivel de simpatía Operatividad Precisión

Agilidad Ajustabilidad Asequibilidad Atomicidad Auto-descripción Capacidad de ampliación Capacidad de anonimato Capacidad de estructuración Capacidad de formación Capacidad de incremento Capacidad de soporte Capacidad sumativa Compatibilidad Distribución Durabilidad Efectividad Exhaustividad Expresividad Extensibilidad Facilidad de confección Facilidad de configuración Facilidad de control Facilidad de demostración Facilidad de descomposición Facilidad de estandarización Facilidad de intercambio Facilidad de juicio Facilidad de observación Facilidad de personalización Facilidad de predicción Facilidad de reconfiguración Facilidad de repetición Facilidad de revisión Facilidad de transferencia Facilidad de verificación Facilidad operativa Factibilidad Formalidad Grado de supervivencia Mejorabilidad Movilidad Nivel de certeza Nivel de comprensión Nivel de confianza Nivel de conformidad Nivel de depuración Nivel de generalización Nivel de medición Nivel de resumen

15

Nomadismo Probabilidad Replicabilidad Responsabilidad Simplicidad Sostenibilidad Susceptibilidad Trazabilidad Uniformidad Variabilidad Versatilidad Viabilidad Visibilidad

Por otra parte, el resultado del análisis de frecuencias indica que el rendimiento (88,68%), la confiabilidad (67,92%), la usabilidad (62,26%), la seguridad (60,38%) y la facilidad de mantenimiento (54,72%) son los tipos más frecuentes de RNF que aparece en el catálogo. Los detalles de la definición y los atributos de estos requisitos no-funcionales se presentan en la Tabla 4. Estas definiciones y atributos se descomponen mediante la integración de algunas definiciones y atributos con base

en la descripción general complementaria que se encuentra en la literatura académica. Igualmente, los resultados demuestran que algunos tipos de RNF también se reconocen como atributos de otros RNF. Por ejemplo, la integridad, la disponibilidad y la confidencialidad son RNF que también se convierten en atributos de seguridad. Por lo tanto, en un lugar son considerados como RNF, mientras que en otro se consideran como atributos de otros RNF.

Tabla 4 Tipos de RNF considerados más frecuentemente

RNF Definición Atributos

Rendimiento

Requisitos que especifican la capacidad del producto software para proporcionar un rendimiento apropiado con respecto a la cantidad de recursos necesarios para llevar a cabo la funcionalidad completa bajo las condiciones indicadas.

Tiempo de respuesta, espacio, capacidad, latencia, rendimiento, cálculo, velocidad de ejecución, retardo de tránsito, carga de trabajo, utilización de recursos, uso de memoria, exactitud, eficiencia de cumplimiento, modos, demoras, tasas de pérdida, datos perdidos, procesamiento de transacciones concurrentes.

Confiabilidad

Requisitos que especifican la capacidad del producto software para operar sin fallas y de mantener un nivel especificado de rendimiento cuando se utiliza bajo determinadas condiciones normales durante un período de tiempo determinado.

Integridad, ocurrencia, consistencia, disponibilidad, integridad, correctitud, madurez, tolerancia a fallos, capacidad de recuperación, fiabilidad, cumplimiento, tasa de errores críticos.

Usabilidad

Requisitos que se especifican interacciones de usuarios finales con el sistema y los esfuerzos necesarios para aprender, operar, preparar entradas e interpretar las salidas del sistema.

Capacidad de aprendizaje, comprensión, operatividad, atractividad, cumplimiento de la usabilidad, facilidad de uso, ergonomía, familiaridad de uso, memorabilidad, eficiencia, productividad del usuario, utilidad, simpatía, tiempo de reacción del usuario.

Seguridad Requisitos cuyo objetivo es prevenir el acceso no autorizado al sistema, los programas y los datos.

Confidencialidad, integridad, disponibilidad, control de acceso, autenticación.

Facilidad de mantenimiento

Requisitos que describen la capacidad del producto software para ser modificado, que pueden incluir la corrección de un defecto o hacer una mejora o cambio en el software.

Facilidad de prueba, comprensibilidad, modificabilidad, analizabilidad, cambiabilidad, estabilidad, cumplimiento de la facilidad de mantenimiento.

3.3 Tipos de sistemas y dominios de aplicación de los

RNF En esta sección se presenta un mapeo entre cada tipo de sistema y sus RNF pertinentes, así como entre cada dominio de aplicación y sus RNF. Tipos de sistemas y RNF. En esta investigación se

identificaron cinco tipos de sistemas con sus RNF pertinentes. Estos son: sistemas de tiempo real, sistemas de seguridad crítica, sistemas web, sistemas de información y sistemas de proceso controlado. El mapeo entre cada tipo de sistema y sus RNF pertinentes se ilustra en la Figura 3.

Como se muestra en Figura 3, los tipos de RNF: rendimiento, seguridad y usabilidad se consideran en los cinco tipos de sistemas, mientras que la fiabilidad se considera en los sistemas de tiempo real, de seguridad crítica, de información y controlados por procesos. Esto indica que los tres primeros RNF son los más comunes en cada tipo de software a desarrollar.

16

Figura 3. Tipos de sistemas y RNF relevantes

RNFS y dominios de aplicación. Al adoptar una

taxonomía de dominio de aplicación del software bien conocida, como Digital’s Industry Taxonomy [30, 31], se consideraron ocho dominios de aplicación diferentes: banca y finanzas, educación, recursos energéticos, gobierno y militar, seguros, asistencia médica/salud, telecomunicaciones y transporte. La correspondencia entre estos dominios de aplicación y sus RNF relevantes se presenta en la Tabla 5.

Un análisis a los datos de la Tabla 5 muestra que los requisitos de rendimiento y de usabilidad se consideran en siete de los ocho dominios de aplicación, el de seguridad se considera en seis dominios, el de confidencialidad en cinco dominios y el de precisión y el de fiabilidad se considera en cuatro. Por lo tanto, y de acuerdo con los resultados hasta el m omento, el rendimiento y la usabilidad son los RNF más comúnmente considerados en los tipos de sistemas y los dominios de aplicación.

Tabla 5 Dominios de aplicación y RNF relevantes

Dominio de aplicación RNF relevantes Banca y finanzas Precisión, confidencialidad, rendimiento, seguridad, usabilidad. Educación Inter-operatividad, rendimiento, seguridad, usabilidad, confiabilidad, escalabilidad, Recursos energéticos Disponibilidad, rendimiento, confiabilidad, seguridad, usabilidad.

Gobierno y militar Precisión, confidencialidad, rendimiento, privacidad, probabilidad, reusabilidad, protección, estandarización, usabilidad, nivel de verificación, viabilidad.

Seguros Precisión, confidencialidad, integridad, usabilidad, inter-operatividad, seguridad,

Asistencia médica/salud Capacidad de comunicación, protección, seguridad, trazabilidad, confidencialidad, integridad, rendimiento, nivel de privacidad, confiabilidad, usabilidad.

Telecomunicaciones Compatibilidad, conformidad, dependencia, usabilidad, Nivel de instalación, rendimiento, portabilidad, confiabilidad, mantenimiento.

Transporte Precisión, disponibilidad, compatibilidad, completitud, confidencialidad, dependencia, integridad, rendimiento, protección, seguridad. Nivel de verificación.

4. DISCUSIÓN Y CONCLUSIONES Este artículo presenta los resultados de una investigación sistémica acerca de las tres dimensiones esenciales de los RNF: (1) definición y terminología, (2) tipos y (3) RNF relevantes en diversos tipos de sistemas y dominios de aplicación. Se identificaron dos puntos de vista diferentes acerca de cómo la comunidad de la Ingeniería de Software considera la noción de los RNF y se discutieron otros términos similares para representar los RNF en cada punto de vista. Luego de una extensa revisión bibliográfica a 252 tipos de RNF, se identificaron 114 que se discutieron específicamente en relación con la calidad del sistema. Entre ellos, el rendimiento, la fiabilidad, la usabilidad, la seguridad y el mantenimiento son los que figuran más frecuentemente en este listado. Como un aporte original de la esta investigación se presenta el análisis a la correspondencia entre los RNF y los tipos de sistemas y los dominios de aplicación. A partir de este

estudio, el rendimiento, la seguridad y usabilidad son los RNF más comunes en los cinco tipos de sistemas, mientras que el rendimiento y la usabilidad son los más considerados en los siete dominios de aplicación. Se espera que los hallazgos presentados contribuyan a la comunidad de tres maneras: (1) mejorar la comprensión acerca de la noción de los RNF, (2) motivar para llegar a un consenso sobre varias dimensiones de los RNF, como en definición, alcance, terminología, tipos, nivel de granularidad, atributos, y taxonomía y (3) generar estudios para profundizar acerca de los RNF más considerados en los trabajos analizados: rendimiento, fiabilidad, usabilidad, seguridad y mantenimiento. Por otro lado, estos resultados también pueden ser útiles para los desarrolladores en tres formas: (1) la lista de la Tabla 2 les permitirá conocer qué tipos de RNF están disponibles para el sistema que desarrollan, (2) la matriz

17

de la Tabla 5 les ayudará a identificar los RNF más importantes para el desarrollo de un sistema en particular; de esta manera, serían capaces de descubrir qué tipo de RNF debería llamar su atención de acuerdo con el proyecto que desarrollan, en función del tipo de sistema y/o dominio de aplicación, por lo que esta matriz puede funcionar como una lista de control que pueden utilizar para asegurarse de que la especificación del sistema es completa con respecto a la cobertura de los RNF y (3) esta matriz les puede ayudar en el proceso de elicitación para asegurarse de los diferentes actores han discutido adecuadamente los RNF. Este estudio hace parte de un proyecto a largo plazo para investigar los conflictos entre los RNF. El objetivo final es desarrollar un marco para identificar y administrar eficientemente los conflictos potenciales entre ellos. Los hallazgos en esta investigación proporcionan valiosa información acerca de los RNF más citados e investigados en la literatura. El siguiente paso en el proyecto de investigación es seleccionar aquellos RNF que se conoce que frecuentemente entran en conflicto, por lo tanto, la información obtenida a partir de los hallazgos presentados en este artículo apoyarán la selección de los RNF a indagar en futuras investigaciones.

Este estudio tiene dos limitaciones: (1) no se investigaron las potenciales superposiciones que existen entre las definiciones y los atributos de cada uno de los RNF y (2) este estudio no tiene la intención de crear una estructura jerárquica de los tipos de RNF. Estas restricciones se tendrán en cuenta para futuras investigaciones.

5. REFERENCIAS [1] Chung, L. et al. 2000. Nonfunctional requirements in

software engineering. Kluwer Academic Publishers. [2] Firesmith, D. 2003. Using quality models to engineer quality

requirements. Journal of Object Technology, 2(5), pp. 67-75. [3] Ebert, C. 1998. Putting requirement management into

praxis: dealing with nonfunctional requirements. Information and Software Technology, 40(3), pp. 175-185.

[4] Peter, A. Ng. 1989. Modern software engineering, foundations and current perspectives. Van Nostrand Reinhold.

[5] Kotonya, G. & Sommerville, I. 1998. Non-functional requirements. Wiley.

[6] Charette, R. N. 1990. Applications strategies for risk analysis. McGraw-Hill.

[7] Wiegers, K. E. 2003. Software requirements. Microsoft Press. [8] Sommerville, I. 2004. Software Engineering. Addison

Wesley. [9] Barbacci, M. et al. 1995. Quality Attributes. CMU/SEI-95-TR-

021 ESC-TR-95-021. Software Engineering Institute, Carnegie Mellon University.

[10] Breitman, K. K.; Prado Leite, J. C. & Finkelstein, A. 1999. The world's a stage: A survey on requirements engineering using a real-life case study. Journal of the Brazilian Computer Society, 6(1), pp. 1-57.

[11] Finkelstein, A. & Dowell, J. 1996. A comedy of errors: the London ambulance service case study. Proceedings of the 8th International Workshop on Software Specification and Design, (London, UK, March 22-23), pp. 2-4.

[12] Lindstrom, D. R. 1993. Five ways to destroy a development project. IEEE Software, 10(5), pp. 55-58.

[13] Boehm, B. & In, H. 1996. Identifying quality-requirements conflict. IEEE Software, 13(2), pp. 25-35.

[14] Leveson, N. G. & Turner, C. S. 1993. An investigation of the Therac-25 accidents. IEEE Computer, 26(7), pp. 18-41.

[15] In, H. 1998. Conflict identification and resolution for software attribute requirements. In Partial Fulfillment of the Requirements for the Degree, Faculty of the Graduate School: University of Southern California.

[16] Grimshaw, D. J. & Draper, G. W. 2001. Non-functional requirements analysis: Deficiencies in structured methods. Information and Software Technology, 43(11), pp. 629-634.

[17] Loomans, L. 2003. Essential and requisites for the management of evolution - Requirements and incremental validation. Information Technology for European Advancement.

[18] Yusop, N.; Zowghi, D. & Lowe, D. 2008. The impacts of non-functional requirements in web system projects. International Journal of Value Chain Management, 2(1), pp. 18-32.

[19] Roman, G. C. 1985. A taxonomy of current issues in requirements engineering. Computer, 18(4), pp. 14-23.

[20] Cleland-Huang, J. et al. 2005. Goal-centric traceability for managing non-functional requirements. Proceedings of the 27th international conference on Software engineering, ICSE 2005. (St. Louis, USA, May 15-21), pp. 362-371.

[21] Cysneiros, L. M. & do Prado Leite, J. C. 2004. Nonfunctional requirements: from elicitation to conceptual models. IEEE Transaction on Software Engineering, 30(5), pp. 328-350.

[22] Lauesen, S. 2002. Software requirements: Styles and techniques. Addison-Wesley.

[23] PaechB. & Kerkow, D. 2004. Non-functional requirements engineering - quality is essential. Proceedings of 10th International Workshop on Requirements Engineering, Foundation for Software Quality. (Riga, Latvia, June 6-7), pp. 27-40.

[24] Glinz, M. 2005. Rethinking the notion of non-functional requirements. Proceedings of Third World Congress for Software Quality. (Munich, Germany, Sept. 26-30), pp. 55-64.

[25] Glinz, M. 2007. On non-functional requirements. Proceedings of 15th IEEE International Requirements Engineering Conference, RE '07. (Zurich, Switzerland, Oct. 15-19), pp. 21-26.

[26] Krippendorff, K. 2004. Content analysis: and introduction to its methodology. Sage Publications, Inc.

[27] Weber, R. P. 1989. Basic content analysis, Sage Publications, Inc.

[28] Stemler, S. 2001. An overview of content analysis. Practical Assessment, Research & Evaluation, 7(17).

[29] Neuendorf, K. A. 2001. The content analysis guidebook. Sage Publications, Inc.

[30] Digital Equipment Corporation. 1991. VAX VMS Software Source Book. Maynard, Mass.

[31] Glass, R. L. & Vessey, I. 1995. Contemporary application domain taxonomies. IEEE Software, 12(4), pp. 63-76.

[32] Firesmith, D. 2003. Security use cases. Journal of Object Technology, 2(3), pp. 53-64.

[33] Firesmith, D. 2004. Engineering safety requirements, safety constraints, and safety-critical requirements. Journal of Object Technology, 3(3), pp. 27-42.

[34] Firesmith, D. 2004. Specifying reusable security requirements. Journal of Object Technology, 3(1), pp. 61-75.