En la primera parte de esta serie, describíamos una definición de requerimientos no funcionales y porque son importantes.
Los requerimientos no funcionales definen las características o cualidades generales que se esperan de un sistema y establecen restricciones sobre el producto, el proceso de desarrollo de software y establecen restricciones externas que el software debe lograr.
Para poder identificar estas características durante la ingeniería de requisitos que realizan los Analistas de sistemas e Ingenieros de software en todo proyecto de desarrollo, es útil contar con una clasificación que nos establezca un marco de los tipos de requerimientos no funcionales con que nos podemos encontrar.
Los requerimientos no funcionales definen las características o cualidades generales que se esperan de un sistema y establecen restricciones sobre el producto, el proceso de desarrollo de software y establecen restricciones externas que el software debe lograr.
Para poder identificar estas características durante la ingeniería de requisitos que realizan los Analistas de sistemas e Ingenieros de software en todo proyecto de desarrollo, es útil contar con una clasificación que nos establezca un marco de los tipos de requerimientos no funcionales con que nos podemos encontrar.
PMOinformatica presenta una clasificación de los requerimientos no funcionales a continuación.
¿Que son los requerimientos no funcionales?
Si buscas más información sobre el concepto de requerimientos no funcionales, te recomendamos la primera parte de esta serie:
> Requerimientos no funcionales: Porque son importantes
Para ver algunos ejemplos de requerimientos no funcionales consulta los siguientes artículos:
> Requerimientos no funcionales: Ejemplos
> 10 Tipos de pruebas no funcionales de software
Cuando se realizan las fases de levantamiento y análisis de requerimientos, los requisitos no funcionales se pueden registrar en un documento de requerimientos de software. A continuación te compartimos una plantilla:
Clasificaciones varias de requerimientos no funcionales
Existen diversas fuentes o marcos de referencia para clasificar los requerimientos no funcionales, de hecho, existe un estándar de la IEEE, Std 830 – 1993 que establece 13 tipos de requerimientos no funcionales que deberían incluirse en toda especificación de software.
Otro modelo es el propuesto por Jacobson (1999) en el cuales e propone para el Unified Process.
Uno de los modelos más difundidos es el establecido por Somerville, que presentaremos más adelante en el artículo.
La clasificación de requerimientos no funcionales de Somerville
La figura presenta la clasificación de requerimientos no funcionales definida por Somerville.
Somerville divide los requerimientos no funcionales en tres grandes tipos: Requerimientos de producto, requerimientos organizacionales y requerimientos externos.
Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual establece límites y restricciones sobre lo que los diseñadores (arquitectos de software) e ingenieros de software pueden hacer.
Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el desempeño y la confiabilidad, pero otros son más difíciles como por ejemplo usabilidad y adaptabilidad.
Los requerimientos de producto pueden clasificarse en (Sommerville):
Una herramienta útil para comprobar la eficiencia de un sistema es SoapUI, que permite hacer pruebas de carga o estrés sobre webservices. Aquí te compartimos artículos sobre el tema:
Requerimientos no funcionales de producto
Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual establece límites y restricciones sobre lo que los diseñadores (arquitectos de software) e ingenieros de software pueden hacer.
Algunos de estos requerimientos pueden ser fáciles de cuantificar, por ejemplo el desempeño y la confiabilidad, pero otros son más difíciles como por ejemplo usabilidad y adaptabilidad.
Los requerimientos de producto pueden clasificarse en (Sommerville):
- Requerimientos de usabilidad: La usabilidad se define como el esfuerzo que necesita hacer un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de un software de aplicación. En tiempos recientes, la usabilidad ha adquirido mucha importancia, en especial ante la demanda de desarrollo de software para móviles y tabletas.
- Requerimientos de eficiencia: Relacionado con desempeño en cuanto a tiempo de respuesta, número de operaciones por segundo, entre otras mediciones, así como consumo de recursos de memoria, procesador, espacio en disco o red.
- Requerimientos de dependibilidad: Engloba varios atributos
- Disponibilidad: Disposición del sistema para prestar servicio correctamente.
- Confiabilidad: Continuidad del servicio prestado por el sistema.
- Seguridad industrial: Ausencia de consecuencias catastróficas para el usuario o el ambiente.
- Integridad: Ausencia de alteraciones inadecuadas al sistema.
- Mantenibilidad: Posibilidad de realizar modificaciones o reparaciones a un proceso sin afectar la continuidad del servicio.
- Requerimientos de seguridad: Capacidades funcionales o no funcionales que debe tener un sistema para cumplir atributos en el área de seguridad de tecnología de información, seguridad de datos, seguridad lógica, control de acceso a información (restricciones de acceso), autenticidad de la información, privacidad, redes privadas virtuales (VPN), entre otros aspectos.
Considerar los requerimientos de producto es vital para lograr la integración continua de aplicaciones y el desarrollo de cambios que sean rápidos pero sostenibles en el tiempo.
Este nuevo paradigma es necesario para implementar las nuevas tecnología de información y aplicaciones de software como la movilidad, internet de las cosas, analítica avanzada de datos (Big Data), evolución de los sistemas a la nube y tecnología de información escalable.
Requerimientos no funcionales organizacionales
Se derivan de las políticas y procedimientos de la organización como por ejemplo estándares de procesos o requerimientos de implementación.
Pueden incluir metodologías de desarrollo de software, estándares de programación (codificación) y herramientas de soporte al desarrollo de software (por ej. Herramientas CASE) que deben usarse (siguiendo las políticas de la organización), también reportes a la gerencia que deben proveerse, entre otros.
Las herramientas para la gestión de desarrollo de software que conocemos, se definen como requerimientos no funcionales organizacionales.
Los requerimientos organizacionales pueden clasificarse en (Sommerville):
- Requerimientos de entorno: Describen el ambiente operativo en el que se debe desenvolver el sistema.
- Requerimientos operacionales: Procedimientos operativos que describen como será usado el sistema dentro del contexto de la organización.
- Requerimientos de desarrollo: Lenguaje de programación a usar, estándares de codificación, patrones (y antipatrones) de diseño y programación, herramientas para gestionar el desarrollo de software, entorno de desarrollo de software (ambiente de desarrollo), entorno de pruebas de software (ambiente de pruebas), entre otros aspectos.
Uno de los aspectos que se documentan como requerimientos funcionales organizacionales son los entorno, específicamente los procedimientos de mantenimiento y administración del ambiente de desarrollo de software.
Esta administración también incluye los procedimientos para gestionar los ambientes de pruebas integrales.
Requerimientos no funcionales externos
Estos derivan del entorno organizacional (no entorno técnico) en el cual se desarrolla el sistema y pueden hacerse tanto sobre el producto (el software desarrollado) o también sobre el proceso de desarrollo de software.
Este tipo de requerimientos incluyen limitaciones de índole económica, interacción o necesidad del sistema de inter-operar con otros sistemas, requerimientos regulatorios en el área de salud, seguridad industrial o protección de datos, requerimientos legales concernientes con licencias, regulaciones o certificaciones que necesita el producto según la industria en el que se desempeñe, entre otros.
Somerville a su vez clasifica estos requerimientos en:
- Requerimientos regulatorios: Leyes y reglamentos que establecen que debe hacer el sistema y como debe hacerlo para cumplirlas. El foco de un sistema o nueva funcionalidad puede ser exclusivamente para cumplir una regulación.
- Requerimientos éticos: Requerimientos que aseguran que el sistema será aceptable para el usuario, público en general y se adapta a las costumbres de la sociedad en la que se desenvuelve o a la que presta servicios.
- Requerimientos legislativos: Características que debe cumplir el sistema para cumplir con la ley, por ejemplo en el área de contabilidad (normas contables y estándares financieros), requerimientos de seguridad industrial (para sistemas críticos), entre otros aspectos.
Importancia de clasificar los requerimientos no funcionales
El especificar requerimientos no funcionales de forma incompleta o inexacta puede ocasionar el fracaso de tu proyecto de ingeniería de software.
De hecho no gestionar los requerimientos no funcionales es uno de los errores clásicos en la gestión de desarrollo de software definida por Steve McConnell.
Lograr clasificar adecuadamente cada requerimiento no funcional identificado es muy importante para garantizar este proceso.
¿Y qué opinas tú?
¿Cómo clasificas en tu organización o proyectos los requisitos no funcionales?, ¿Consideras que se les pone suficiente atención al levantamiento de estos requisitos en los proyectos?, ¿Cuál es el tipo de requisito no funcional que te solicitan con mayor frecuencia?
< Artículo anterior: Requerimientos no funcionales: Porque son importantes
¿Buscas más información de gerencia informática?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Artículos similares
> Documento de requerimientos de software
> Alojamiento web: Definición, ventajas y desventajas
> 8 Técnicas de análisis de requisitos
> 10 Tipos de pruebas no funcionales de software
> Modelo de curriculum vitae para Analista Programador
> Plantilla de Casos de uso
Referencia
Bochman, G. Non-Functional Requirements. University of Ottawa.
Clasificación de RQs no funcionales, ejemplos y preguntas para identificarlos
Computer Science, Central Connecticut University. Requirements Engineering. CS 410/530 - Software Engineering.
Wikipedia. Dependability
Referencia
Bochman, G. Non-Functional Requirements. University of Ottawa.
Clasificación de RQs no funcionales, ejemplos y preguntas para identificarlos
Computer Science, Central Connecticut University. Requirements Engineering. CS 410/530 - Software Engineering.
Wikipedia. Dependability
No hay comentarios :
Publicar un comentario