Requerimientos No Funcionales: Accesibilidad y su Importancia en el Desarrollo de Software

Al describir una aplicación o software, es común centrarse en los "requisitos funcionales", es decir, lo que el producto debe hacer. Sin embargo, existen numerosos aspectos de los productos en los que se confía que no tienen que ver específicamente con la funcionalidad. Estos son los requisitos no funcionales (NFR), que describen las propiedades generales de un sistema que limitan y dan forma a su estructura.

Los NFR incluyen todas las propiedades estandarizadas y fundamentales de un sistema, tales como la disponibilidad, la facilidad de uso, el rendimiento, la seguridad, la escalabilidad, la portabilidad y, de manera crucial, la accesibilidad. Aunque no siempre se piense en ellos al usar un producto, las personas tienen preferencias y necesidades innatas respecto a su experiencia de usuario.

A menudo, los NFR se pasan por alto, se infravaloran y se subestiman sistemáticamente, en detrimento del proyecto en su conjunto. Si se infravaloran, pueden implementarse incorrectamente, causando una serie de problemas inmediatos y posteriores.

¿Qué son los Requerimientos No Funcionales (NFR)?

Los NFR especifican criterios que definen cómo debe comportarse un sistema en lugar de describir sus funciones específicas. Estos se centran en aspectos como la seguridad, la usabilidad, el rendimiento, la escalabilidad y la disponibilidad del sistema. Por ejemplo, un requerimiento no funcional puede especificar que un sitio web debe cargar en menos de tres segundos para garantizar una experiencia de usuario óptima.

Son cruciales para el éxito de un proyecto, ya que ayudan a establecer expectativas claras sobre el rendimiento y la calidad del software. Al definir adecuadamente estos requerimientos, los equipos de desarrollo pueden anticiparse a problemas potenciales y garantizar que el software no solo cumpla con las especificaciones funcionales, sino que también sea eficiente y confiable en su uso diario.

Definición de "No Funcional"

"No funcional" se refiere a los aspectos de un sistema que no están relacionados directamente con sus funciones específicas, sino más bien con cómo esas funciones deben ser implementadas y operadas. Mientras que los requisitos funcionales describen lo que un sistema debe hacer, los requisitos no funcionales definen criterios relacionados con la calidad y el comportamiento del sistema.

Por ejemplo, un NFR podría indicar que una aplicación debe ser capaz de soportar 1000 usuarios simultáneos sin degradar el rendimiento. Este tipo de requerimiento es esencial para garantizar que la aplicación no solo funcione correctamente, sino que también ofrezca una experiencia satisfactoria bajo condiciones específicas.

Diferencias entre Funcional y No Funcional

Lo funcional se refiere a las acciones específicas que un sistema debe realizar, como procesar transacciones o permitir la autenticación de usuarios. Lo no funcional aborda aspectos como el rendimiento, la seguridad y la usabilidad. Por ejemplo, un requisito funcional podría especificar que un usuario debe iniciar sesión con su correo electrónico y contraseña, mientras que un requisito no funcional indicaría que el sistema debe estar disponible el 99.9% del tiempo. Esta distinción es clave en el desarrollo de software, ya que ambas categorías deben considerarse para garantizar un producto que satisfaga las expectativas del usuario.

Importancia de los NFR en el Desarrollo de Software

Los NFR desempeñan un papel crucial al proporcionar un punto de referencia para la calidad del sistema y la experiencia del usuario. Sin ellos, incluso un software con muchas funciones puede no cumplir con las expectativas si carece de velocidad, escalabilidad o facilidad de uso. Los NFR también afectan la arquitectura y el diseño, ya que garantizan que el sistema esté preparado para satisfacer demandas como el máximo rendimiento o una seguridad rigurosa.

Son fundamentales para ofrecer una experiencia de usuario fluida, una estabilidad sólida del sistema y un software escalable. Los requisitos de rendimiento de red, por ejemplo, determinan la forma en que los usuarios perciben un sistema. Una interfaz con capacidad de respuesta y una navegación intuitiva mejoran enormemente la satisfacción del usuario. Los requisitos de rendimiento de red relacionados con la estabilidad, como la confiabilidad y la tolerancia a fallas, reducen el tiempo de inactividad y evitan fallas frustrantes.

Los NFR suelen dictar las opciones de arquitectura y tecnología, orientando a los desarrolladores en la selección de la estructura, la optimización de la base de datos y la configuración del servidor. La planificación de recursos en torno a los NFR ayuda a asignar el presupuesto y el personal para cumplir con los estándares de alto rendimiento o seguridad de manera eficaz, evitando así rediseños o modernizaciones costosas en el futuro.

Consecuencias de No Considerar los NFR

No tener en cuenta los requisitos no funcionales puede provocar costosas fallas. Por ejemplo, si una plataforma de comercio electrónico no cumple con los requisitos de escalabilidad, puede colapsar durante eventos de alto tráfico, lo que provocaría una pérdida de ventas y dañaría la reputación de la marca. De manera similar, los requisitos de seguridad deficientes pueden dejar a los sistemas vulnerables a las violaciones de datos, lo que comprometería la información confidencial.

El incumplimiento de los objetivos de rendimiento puede generar frustración en los usuarios, abandono de transacciones y disminución de la retención de clientes. Una falla en la confiabilidad podría resultar en fallas o mal funcionamiento del sistema durante momentos críticos. Si el sistema no cumple con los estándares de rendimiento, podría generar reacciones tardías con consecuencias significativas. El incumplimiento de los requisitos de seguridad podría dar lugar a filtraciones de datos, pérdidas financieras y un importante daño a la reputación.

Tipos Clave de Requerimientos No Funcionales

Los requerimientos no funcionales abarcan diversos atributos de calidad que determinan el rendimiento de un sistema de software en diferentes condiciones. Aquí se presenta una lista de comprobación de NFR esenciales:

1. Rendimiento

• Definición y significado: Los requisitos de rendimiento definen la capacidad de respuesta y de manejo de cargas del sistema de manera eficaz. La velocidad a la que un sistema realiza determinadas tareas es fundamental para enriquecer la experiencia del usuario. Si los usuarios tienen que esperar a que se carguen las páginas o se actualicen los datos, su flujo de trabajo puede descarrilar.
• Ejemplos y puntos de referencia: Las métricas como el tiempo de respuesta (p. ej., <2 segundos para la carga de la página), el rendimiento (solicitudes por segundo) y el uso de recursos (CPU, memoria) son comunes.

2. Usabilidad

• Noticias: Los requisitos de usabilidad se centran en hacer que el sistema sea fácil de aprender, usar y navegar.
• Ejemplos y enfoques: Las métricas incluyen el tiempo de finalización de las tareas, la tasa de errores y las puntuaciones de satisfacción del usuario.

3. Fiabilidad (Dependibilidad)

• Ejemplos y métricas: Las métricas como el tiempo medio entre fallos (MTBF) y el tiempo medio de recuperación (MTTR) son comunes. La disponibilidad se refiere al tiempo que el sistema está activo entre trabajos de mantenimiento o interrupciones. Para cuantificar esta característica, los analistas utilizan datos como la media del tiempo transcurrido entre fallos del sistema.

4. Seguridad

• Aspectos clave: Los requisitos de seguridad implican proteger el sistema contra el acceso no autorizado y garantizar la integridad de los datos. Una de las principales preocupaciones de cualquier sistema es su capacidad para bloquear el acceso no autorizado o la modificación del comportamiento, manteniendo al mismo tiempo la facilidad de uso. Todo, desde los tiempos de espera de sesión hasta las restricciones de contraseña, debe ser considerado para todos los roles y permisos. Por ejemplo, el sistema incluirá un procedimiento de autorización de usuarios, en el cual los usuarios deben identificarse usando un nombre de usuario y contraseña.

5. Mantenibilidad

• Ejemplos y objetivos: Los objetivos incluyen la modularidad, la documentación del código y el uso de prácticas de código limpio.

6. Escalabilidad

• Ejemplos: Los ejemplos incluyen el escalamiento horizontal (agregar más servidores) o vertical (mejorar la potencia del servidor) para satisfacer una mayor demanda. La escalabilidad no solo se refiere al tamaño de un sistema, sino a su capacidad para adaptarse al crecimiento y al cambio en el futuro, a menudo en circunstancias diferentes. Estas consideraciones deben tenerse en cuenta en la arquitectura y el diseño desde el principio.

7. Portabilidad

• Ejemplos y configuraciones: Las métricas incluyen la facilidad de transferencia del sistema a diferentes entornos de SO o hardware.

8. Accesibilidad

• Descripción: La tecnología nos conecta, y algunas personas tienen capacidades diferentes que afectan a sus prácticas de uso. Por ello, los NFR que tienen que ver con facilitar el acceso al mayor número posible de personas son extremadamente importantes. Estos requisitos deben tenerse en cuenta al inicio de los proyectos para evitar tener que rehacer el trabajo más adelante.

9. Localización

• Importancia: La localización es otro NFR esencial a tener en cuenta desde el principio, sobre todo si el producto se va a utilizar a escala internacional. Básicamente, estos requisitos facilitan el uso en diferentes entornos culturales, lingüísticos y geográficos. Incluso algo tan específico como las zonas horarias puede resultar desastroso si no se formatea correctamente.

10. Compatibilidad con Dispositivos y Navegadores

• Consideraciones: Nuestro mundo está lleno de dispositivos y es esencial determinar qué dispositivos pueden utilizar sus usuarios finales para acceder a sus productos y servicios. Se debe considerar el tipo de hardware, la inclusión de móviles, cuántas resoluciones se admitirán y cuántos navegadores.

11. Conformidad Legal y Regulatoria

• Regulaciones: A medida que nuestras vidas se desarrollan en línea o se entrelazan con la tecnología, más leyes y normativas entran en juego sobre cómo se produce y debe comportarse nuestra tecnología. Hay distintos niveles, desde el local al estatal, pasando por el nacional y el internacional. El compromiso depende, en su mayor parte, del público objetivo.

Definición y Documentación de los NFR

La definición y documentación de los requerimientos no funcionales es fundamental para garantizar que los sistemas de software cumplan con los estándares de calidad deseados. Es recomendable acompañar su definición con criterios de aceptación que se puedan medir, dado que su conformidad o no conformidad podría ser sujeto de libre interpretación. Comprender los tipos e identidades de los NFR es una habilidad esencial porque los clientes no suelen entender o apreciar su complejidad e importancia.

Una buena forma de pensar en los NFR y su documentación es asegurarse de que cada uno de ellos tenga las siguientes cualidades: deben estar acotados (restringidos por un límite cuantificado), ser independientes (tener su propio conjunto de criterios de evaluación) y ser negociables (como características intrínsecas del sistema que afectarán a la totalidad o a la mayor parte del trabajo que se realice).

Enfoques y Estándares

Existen varios enfoques y estándares que se utilizan para capturar, comunicar y gestionar eficazmente los NFR durante todo el proceso de desarrollo:

• ISO/IEC 25010: Esta norma define un conjunto de características de calidad de los productos de software, entre las que se incluyen la eficiencia del rendimiento, la seguridad, la facilidad de mantenimiento y la facilidad de uso. Proporciona un marco integral para categorizar y evaluar los NFR, lo que garantiza que el sistema cumpla con los parámetros de calidad reconocidos.
• IEEE 830: Si bien se centra principalmente en los requisitos funcionales, la norma IEEE 830 también incluye una guía para documentar los requisitos no funcionales. Sugiere un formato estructurado para especificar los NFR, lo que facilita que los desarrolladores y las partes interesadas los comprendan y verifiquen.
• Talleres sobre Atributos de Calidad (QAW): Son sesiones colaborativas en las que participan las partes interesadas clave (desarrolladores, propietarios de productos, usuarios) para identificar y priorizar los NFR. Los QAW se estructuran en torno a la comprensión del contexto del sistema, los casos de uso y las cargas de trabajo previstas.
• Escenarios de Atributos de Calidad (QAS): Los métodos basados en escenarios son una forma eficaz de definir los NFR al describir cómo debería comportarse un sistema en condiciones específicas. Por ejemplo, un sistema de control de calidad para el desempeño podría indicar: “El sistema debería manejar 1000 transacciones por segundo con un tiempo de respuesta de menos de 2 segundos durante el tráfico pico”.
• Herramientas de Modelado y Simulación: Permiten a los desarrolladores probar y evaluar los NFR antes de implementarlos, ayudando a identificar posibles cuellos de botella, vulnerabilidades de seguridad o problemas de escalabilidad en las primeras fases de diseño.
• Evaluación Comparativa y Pruebas de Rendimiento: Son fundamentales para garantizar que el sistema cumpla con los requisitos de rendimiento nominal definidos durante la etapa de planificación. Se utilizan herramientas como pruebas de carga, pruebas de estrés y pruebas de resistencia para evaluar el rendimiento del sistema en comparación con parámetros de referencia definidos.
• Herramientas de Gestión de Requisitos: Ayudan a realizar un seguimiento de la trazabilidad de los NFR a lo largo del ciclo de vida del desarrollo. Permiten a los equipos asegurarse de que se aborden y verifiquen todos los aspectos no funcionales del sistema.

Los requerimientos no funcionales se pueden registrar en un documento de requerimientos de software. En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo, los requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y legislativos.

La Accesibilidad como NFR Crítico

La accesibilidad, como requisito no funcional, es de suma importancia. Las pruebas de accesibilidad ayudan a detectar los errores y barreras que pueden existir en el software, pero que no son fácilmente detectables si no se realizan pruebas específicas para encontrarlas. El objetivo es verificar si el software es inclusivo y si cualquier usuario, incluidas las personas con discapacidad o aquellos que se enfrentan a una discapacidad situacional, puede acceder a él fácilmente para mejorar la facilidad de uso y la satisfacción del usuario.

Norma EN 17210: Accesibilidad en el Entorno Construido

La nueva Norma EN 17210 es el primer estándar europeo de accesibilidad del entorno construido. Esta norma describe los requisitos funcionales básicos para asegurar que un entorno construido es accesible, siguiendo los principios de diseño para todos. La accesibilidad se reconoce una vez más como una condición intrínseca del entorno construido con la aprobación de la Norma EN 17210 Accesibilidad y usabilidad del entorno construido.

Esta es la primera norma europea sobre accesibilidad del entorno construido, aprobada y publicada por los organismos europeos de Normalización CEN y CENELEC en cumplimiento del mandato M/420 de la Comisión Europea (CE). El objetivo principal de la EN 17210 es contribuir a la implementación de la Convención de las Naciones Unidas sobre los Derechos de las Personas con Discapacidad (UNCRPD) en el ámbito del entorno construido. Esta norma ofrece la oportunidad de incorporar soluciones técnicas distintas, mediadas por circunstancias culturales, climáticas, geográficas o de uso.

La EN 17210 es un documento de aplicación en el diseño y construcción del entorno construido. El Mandato M/420 se basaba en la oportunidad que brinda la legislación europea de contratación pública de “compra accesible” y exigía la inclusión de requisitos de accesibilidad en el pliego de condiciones. A finales de 2020 se ha aprobado la norma europea por la que se establecen los requerimientos funcionales sobre accesibilidad y usabilidad en el entorno construido, siendo de gran utilidad para aquellos responsables de Administraciones Públicas que tengan que realizar compras e inversiones en entorno construido, como edificios o planificación urbanística.

Desafíos en la Gestión de Requisitos No Funcionales

La gestión de requisitos no funcionales presenta desafíos como definiciones imprecisas, recursos limitados y alcances de proyecto cambiantes. Los NFR afectan el trabajo a lo largo del calendario del proyecto y a veces durante todo su ciclo de vida. Si el NFR requiere una implementación incidental, como cambios de conformidad, el equipo debe organizar el trabajo para la fecha límite. Otros requisitos requieren cambios a lo largo del tiempo y pueden introducirse mejoras sobre la marcha.

Soluciones y Buenas Prácticas

• Claridad y Mensurabilidad: Garantizar la claridad mediante el uso de criterios específicos y mensurables (por ejemplo, tiempo de respuesta inferior a 2 segundos, tiempo de actividad del 99.9 %). Utilizar marcos estándar como ISO/IEC 25010 para ayudar a definir y categorizar los NFR de manera uniforme.
• Priorización: Priorizar las NFR en función de las evaluaciones de riesgo, los objetivos comerciales y la disponibilidad de recursos. Considerar implementarlas en fases, comenzando con las NFR críticas, y escalar con el tiempo.
• Flexibilidad y Trazabilidad: Mantener la flexibilidad mediante el uso de métodos ágiles para revisar y ajustar los NFR en cada iteración. Mantener los NFR rastreables y documentados en un sistema de gestión de requisitos para garantizar que las actualizaciones se controlen adecuadamente.
• Colaboración de Partes Interesadas: Involucrar a todas las partes interesadas relevantes desde el comienzo del proceso a través de talleres o sesiones colaborativas. Utilizar métodos basados en escenarios o talleres de atributos de calidad (QAW) para identificar y alinear los atributos de calidad clave.
• Pruebas Continuas: Implementar prácticas de prueba continua, incluidas pruebas de rendimiento, carga y seguridad. Utilizar herramientas de simulación y pruebas automatizadas para validar los NFR en las primeras etapas del desarrollo.

Plataformas como Visure Requisitos ALM ofrecen una solución robusta para la gestión de NFR, permitiendo centralizar la documentación, garantizar la trazabilidad, facilitar la colaboración, priorizar en base a riesgos, gestionar casos de prueba, ofrecer paneles personalizables y apoyar metodologías ágiles. Esto asegura que los NFR estén claramente definidos, sean rastreables y estén alineados con los objetivos empresariales.

Tipos de Pruebas No Funcionales

Las pruebas no funcionales tienen por objeto comprobar aspectos no funcionales de una aplicación, como el rendimiento, la usabilidad, la accesibilidad, la escalabilidad, etc. Su objetivo es identificar el comportamiento operativo de un sistema de acuerdo con comportamientos funcionales específicos. Cada vez más, las pruebas no funcionales adquieren mayor relevancia en el desarrollo de software.

La falta de pruebas puede dar lugar a defectos de software que dañen la reputación de una marca, generen frustración en los clientes y aumenten la tasa de pérdida de clientes. En casos extremos, un error o defecto puede afectar a sistemas interconectados o causar graves problemas operativos. Las primeras pruebas de software revelan problemas antes de que un producto llegue al mercado, permitiendo resolver errores de arquitectura, mala toma de decisiones en el proyecto, funcionalidad incorrecta o inválida, vulnerabilidades de seguridad, problemas de escalabilidad, problemas de usabilidad, diferencias en la experiencia visual y mala experiencia de usuario.

Ejemplos de Pruebas No Funcionales

• Pruebas de Carga: Simulan una determinada capacidad de carga en una aplicación para evaluar su rendimiento, ayudando a identificar la capacidad máxima de funcionamiento, posibles cuellos de botella y valles en el rendimiento.
• Pruebas de Estrés: Comprueban la estabilidad de un sistema o aplicación aplicando una carga superior a la demanda deseada para probar la capacidad operativa hasta un punto de ruptura. Esto ayuda a identificar puntos de ruptura, cargas máximas y comprender los límites seguros de una aplicación.
• Pruebas de Resistencia: Evalúan la capacidad de un sistema o una aplicación de software para soportar un uso sostenido durante un periodo de tiempo significativo.
• Pruebas de Escalabilidad: Comprueban el rendimiento de una aplicación aumentando o disminuyendo la carga (p. ej., el número de usuarios simultáneos). Se espera que los sistemas aumenten o reduzcan su capacidad y se ajusten en consecuencia a los recursos disponibles para garantizar un rendimiento adecuado y estable.
• Pruebas de Usabilidad: Su objetivo es evaluar la facilidad de uso de un sistema o aplicación para completar una tarea. Se evalúan aspectos como la comodidad de aprendizaje, la eficiencia, la asignación de memoria, la escritura de errores, la recuperación de errores y la satisfacción del usuario.
• Pruebas de Accesibilidad: Comprueban si una aplicación de software puede ser utilizada por personas con discapacidad o por cualquier usuario que se enfrente a una discapacidad situacional.
• Pruebas de Seguridad: Buscan posibles vulnerabilidades o amenazas que puedan afectar la protección, disponibilidad e integridad de los datos o la funcionalidad del sistema.
• Pruebas de Rendimiento: Analizan tanto los tiempos de respuesta como el consumo de recursos, simulando múltiples usuarios concurrentes y midiendo el uso de recursos en búsqueda de cuellos de botella.

Las fases de las pruebas no funcionales incluyen la definición del entorno de pruebas, la ejecución de los casos de prueba, la redacción de guiones, el análisis de los resultados y el envío de informes de errores. La eficacia de las pruebas se maximiza ejecutando el menor número de pruebas para encontrar el mayor número de defectos.

tags: #requerimientos #no #funcionales #accesibilidad