Marco de requisitos no funcionales

Los NFR ( requisitos no funcionales ) necesitan un marco para su compactación. El análisis comienza con objetivos blandos que representan los NFR con los que están de acuerdo las partes interesadas. Los objetivos blandos son objetivos que son difíciles de expresar, pero que tienden a ser cualidades globales de un sistema de software. Estos pueden ser usabilidad, rendimiento, seguridad y flexibilidad en un sistema determinado. Si el equipo comienza a recopilarlos, a menudo encuentra una gran cantidad de ellos. Para reducir el número a una cantidad manejable, la estructuración es un enfoque valioso. Hay varios marcos disponibles que son útiles como estructura.

Los siguientes marcos son útiles para servir como estructura para los NFR:

1. Modelado de objetivos Los objetivos blandos finalizados se suelen descomponer y refinar para descubrir una estructura de árbol de objetivos y subobjetivos, por ejemplo, el objetivo blando de flexibilidad. Una vez que se descubren las estructuras de árbol, es inevitable encontrar objetivos blandos que interfieren en diferentes árboles, por ejemplo, los objetivos de seguridad generalmente interfieren con la usabilidad. Estos árboles de objetivos blandos forman ahora una estructura de gráfico de objetivos blandos. El paso final de este análisis es elegir algunos objetivos blandos de hoja en particular, de modo que se satisfagan todos los objetivos blandos raíz.[1]

2. IVENA ^[1] - Enfoque integrado para la adquisición de NFR El método ha integrado un árbol de requisitos. [2]

3. Contexto de una organización Existen varios modelos para describir el contexto de una organización como Business Model Canvas , OrgManle [3], u otros [4]. Esos modelos también son un buen marco para asignar NFR.

SNAP es el proceso de evaluación no funcional del software. Mientras que los puntos de función miden los requisitos funcionales mediante el dimensionamiento del flujo de datos a través de una aplicación de software, el SNAP de IFPUG mide los requisitos no funcionales.

El modelo SNAP consta de cuatro categorías y catorce subcategorías para medir los requisitos no funcionales. Los requisitos no funcionales se asignan a las subcategorías pertinentes. Cada subcategoría tiene un tamaño, y el tamaño de un requisito es la suma de los tamaños de sus subcategorías.

El proceso de dimensionamiento de SNAP es muy similar al proceso de dimensionamiento de puntos de función. Dentro de los límites de la aplicación, los requisitos no funcionales se asocian con categorías relevantes y sus subcategorías. Utilizando un conjunto estandarizado de criterios básicos, cada una de las subcategorías se dimensiona según su tipo y complejidad; el tamaño de dicho requisito es la suma de los tamaños de sus subcategorías. Estos tamaños se suman luego para obtener la medida del tamaño no funcional de la aplicación de software.

Las pruebas beta del modelo muestran que el tamaño de SNAP tiene una fuerte correlación con el esfuerzo de trabajo requerido para desarrollar la parte no funcional de la aplicación de software.

• Puntos SNAP

[1] Mylopoulos, Chung y Yu: “Del análisis de requisitos orientado a objetos al análisis de requisitos orientado a objetivos" Comunicaciones de la ACM, enero de 1999 [CACM.f.doc [1] [2] Götz, Rolf; Scharnweber, Heiko: " IVENA: Integriertes Vorgehen zur Erhebung nichtfunktionaler Anforderungen". https://www.pst.ifi.lmu.de/Lehre/WS0102/architektur/VL1/Ivena.pdf [3] Teich, Irene: Tutorial PlanMan. Documento de trabajo Postbauer-Heng, Alemania 2005. Disponible bajo demanda. ] Teich, Irene: Contexto de la organización-Modelos Documento de trabajo Meschede, Alemania 2020. Disponible bajo demanda.