Estructurar requisitos no funcionales

En esta categoría se describen las propuestas que proponen una notación para representar RNF y las relaciones entre ellos. A continuación se exponen cada una de las propuestas:

En (J. Tsai et al., 1994) se busca extender el lenguaje formal de especificación de requisitos (FRORL por sus siglas en inglés) (J. J. P. Tsai & Weigert, 1993) (J. J. P. Tsai, Weigert, & Jang, 1992) para representar los requisitos no funcionales y establecer relaciones entre los modelos de requisitos funcionales y no funcionales. Por tal motivo, propone un método para representar la relación entre requisitos no funcionales y funcionales pero la propuesta no establece como lograr esa relación. Un ejemplo del modelado de RNF y RF se presenta en la figura 4, donde los RF están representados en los objetos: cantidad y cuenta y la actividad: deposito; los RNF son representados en otro árbol que tiene el objeto exactitud como raíz, y los objetos: preciso, menos preciso,

validado y auditado como hojas; la línea de flecha sólida indica que el objeto cuenta tiene la

propiedad preciso, las líneas discontinuas muestran que la actividad depósito utiliza dos objetos monto y cuenta; para lograr el objetivo de precisión en la actividad depósito, la actividad utiliza un objeto que tiene una propiedad de exactitud.

Figura. 1 Ilustración del modelado de RNF y RF, tomado de [40] Figura 4: Ilustración del modelado de RNF y RF, tomado de [40].

En (Marques et al., 2014) es propuesto un enfoque para modelar y especificar requisitos funcionales y no funcionales en el dominio de software integrado17, basándose en: la notación estándar UML; el perfil MARTE (El Object Management Group® (OMG®), 2016) el cual define los fundamentos para la descripción basada en modelos de los sistemas embebidos en tiempo real desde la especificación hasta el diseño detallado; y SysML (El Object Management Group® (OMG®), 2016) como lenguaje para la especificación de requisitos y la trazabilidad con los artefactos de diseño. Este enfoque parte con una lista de requisitos creada en la actividad de licitación, posteriormente durante las actividades de análisis y especificación el único RNF que aborda es el tiempo utilizando estereotipos para representar aspectos de tiempo. Algunos estereotipos representados son los siguientes: << ClockType >>, << timedConstraint >> y << rtFeature >> para representan un reloj, un retraso, y un objeto activo con restricción en tiempo real, respectivamente.

En (Thonse, 2005) se propone un marco que utiliza casos de uso para la especificación de requisitos funcionales y no funcionales, el cual tiene como objetivo proporcionar descripciones formales pero fácilmente comprensibles. Este marco mejora la especificación incorporando nuevos conceptos, tales como: (i) flujos de tareas que utilizan anotaciones de flujos de trabajo propuestas por BPMN para definir los eventos o escenarios, (ii) notación de tarea, para clasificar las tareas en interactivas18 y del sistema19; estas tareas ayudan a representar las interacciones del sistema y del usuario para un escenario determinado y (iii) extensiones que facilitan la captura de requisitos no funcionales.

En (T. Shah & Patel, 2016) se propone un Esquema de Descripción del Requisito (RDS), basado en XML para la representación estructural de los requisitos funcionales y no funcionales. El esquema RDS es una integración de 3 esquemas diferentes, los cuales son: (i) esquema de

17_{Software integrado: software que está ya instalado en un sistema hardware. Este tipo de software normalmente está} diseñado para realizar una función específica, en una misma pieza de hardware. Ejemplo, tableros con circuitos y chips (WebFinance, 2018).

18 _{Tarea interactiva: tarea donde el usuario está involucrado en la interacción con el sistema (Thonse, 2005) .}

requisitos funcionales, donde se describen las características clave deseadas de un sistema y se representan de forma modular, (ii) esquema de requisitos no funcionales, enfocado en la definición de requisitos relacionados con la seguridad, privacidad, fiabilidad y rendimiento, (iii) esquema de artefactos de requisitos, que reutiliza artefactos de requisitos existentes logrando que la tarea de especificación de requisitos sea más prescriptiva y sistemática. Para la validación de la propuesta plantean que se realizó un estudio de caso de un sistema de examen en línea, pero no se describen los diferentes elementos de la planeación del estudio ni muestran los resultados obtenidos.

En (U. S. Shah et al., 2016) se propone un enfoque denominado Especificador NFR, tiene como objetivo generar especificaciones precisas a partir de requisitos informales; este enfoque está constituido por los siguientes 5 módulos: (i) Pre-procesamiento, utiliza como entrada los requisitos en un lenguaje natural y produce requisitos normalizados; el módulo realiza tres tareas: división de oraciones, etiquetado y normalización, además se realiza la reconstrucción sintáctica para dividir una oración compleja en oraciones simples y así extraer toda la información posible del documento de requisitos; (ii) resolución de ambigüedad, utiliza como entrada un requisito normalizado y produce requisitos inequívocos; el módulo identifica los requisitos ambiguos y sugiere la solución más adecuada para resolver la ambigüedad; (iii) formación de ontología de especificación de requisitos de software, ayuda a identificar los requisitos de la aplicación; (iv) generación de diagrama UML, extrae los términos orientados a objetos (clase, objeto, método, etc.) y se genera semiautomáticamente el diagrama UML; (v) clasificación de NRF, identifica los NFR usando Ontología de Calidad y luego los refina.

En (Jackson et al., 2009) utilizan la programación lógica como base para la especificación de RNF como restricciones de los sistemas en el espacio de los modelos. Plantean que los programas lógicos que representan los RNF se reducen a restricciones de sistemas definibles por fórmulas de primer orden sobre términos algebraicos.