Requisitos no funcionales explicados: ejemplos, tipos, herramientas

1. Requisitos de rendimiento

Los requisitos de rendimiento se centran en la velocidad y la eficiencia de cualquier sistema. Definen la rapidez con la que el sistema debe procesar las solicitudes de los usuarios y responder a ellas. Los usuarios suelen sentirse frustrados al utilizar sistemas de bajo rendimiento, lo que da lugar a altas tasas de rebote.

Ejemplos (sistema de IA generativa)

• El sistema debe responder a las consultas del usuario en un plazo de 1,2 segundos.
• Al escribir la consulta en el cuadro de entrada, la latencia no debe superar los 500 ms.

2. Requisitos de escalabilidad

La escalabilidad se refiere a la capacidad del sistema para crecer sin perder rendimiento. Cuando aumenta el número de usuarios del sistema o las solicitudes de procesamiento de datos, un sistema escalable sigue funcionando sin necesidad de una reconstrucción completa del sistema.

Los requisitos de escalabilidad son importantes para las empresas que prevén un crecimiento futuro o picos de tráfico estacionales. Si se ignoran estos requisitos, el sistema podría colapsar al no poder soportar la carga durante los picos de tráfico.

Ejemplos

• El sistema de mensajería debería seguir funcionando sin problemas incluso aunque el número de usuarios activos aumente de 100 000 a 5 millones.
• Durante la oferta, la tienda online debería ser capaz de gestionar un tráfico 10 veces mayor sin que el rendimiento se vea afectado.

3. Requisitos de disponibilidad

Los requisitos de disponibilidad describen el tiempo durante el cual el sistema debe estar accesible para los usuarios. La alta disponibilidad del sistema reduce considerablemente los riesgos de interrupción del servicio y mejora la confianza de los usuarios. En el caso de algunos sistemas, incluso unos pocos minutos de interrupción pueden suponer la pérdida de millones de dólares, de usuarios y de reputación.

Ejemplo

• El sistema de banca en línea debería estar disponible el 99,95 % del tiempo. Para realizar tareas de mantenimiento, el sistema puede sufrir una interrupción del servicio de 30 minutos entre las 2:00 y las 4:00 de la madrugada, hora local.

4. Requisitos de portabilidad

Los requisitos de portabilidad (NFR) se refieren a la facilidad con la que el sistema puede funcionar en distintos entornos, incluidos sistemas operativos, proveedores de servicios en la nube o dispositivos. Un sistema portátil ahorra tiempo y esfuerzo al pasar de la fase de desarrollo a la de producción o al expandirse a nuevas plataformas.

Ejemplos (plataforma de redes sociales)

• Una aplicación debería funcionar en todos los dispositivos móviles.
• Los usuarios de Android y iOS deberían disponer de las mismas funciones básicas.
• El sistema debe estar preparado para contenedores (por ejemplo, Docker) a fin de permitir una implementación rápida en distintos entornos de nube, como AWS, Azure o GCP.

5. Requisitos de compatibilidad

Los requisitos de compatibilidad definen el grado de compatibilidad del sistema con otros sistemas, software o hardware. Esto es importante en entornos en los que el sistema debe conectarse a API, bases de datos, navegadores o servicios de terceros. Una compatibilidad deficiente puede provocar fallos en las funciones, quejas de los usuarios y problemas de integración.

Ejemplos

• La opción de compartir pantalla en una aplicación de videoconferencia debería funcionar tanto en navegadores móviles como en navegadores de escritorio.
• Una herramienta de gestión de proyectos debería integrarse a la perfección con diversas plataformas, como Google Calendar, Slack, etc., sin que los usuarios tengan que configurarla manualmente.

6. Requisitos de fiabilidad

Los requisitos de fiabilidad evalúan la frecuencia con la que el sistema funciona sin fallos, incluso ante situaciones imprevistas. Esto es importante para aplicaciones como el software bancario, los sistemas sanitarios, etc., que la gente utiliza a diario.

Ejemplos (sistema de gestión de pacientes hospitalarios)

• El sistema debe funcionar sin fallos durante el 99,95 % del tiempo en cualquier periodo de 30 días.
• Si falla la conexión a la base de datos, el sistema debe intentar volver a conectarse tres veces para recuperarse automáticamente.
• Si el sistema falla, debería revertir la última implementación para recuperarse.

7. Requisitos de mantenibilidad

Los requisitos no funcionales (NFR) de mantenibilidad definen la facilidad y rapidez con la que se puede actualizar o reparar el sistema. Abarcan el tiempo y los recursos necesarios para mantener el sistema. La mantenibilidad es siempre importante en proyectos a gran escala o en productos sujetos a mejoras constantes.

Ejemplos (sistema CRM para equipos de ventas)

• Cualquier error debe solucionarse en un plazo de 30 minutos.
• Los desarrolladores deben poder implementar la nueva versión o las actualizaciones sin que ello afecte a las sesiones de usuario activas.

8. Requisitos de seguridad

Los requisitos de seguridad no funcionales definen cómo debe el sistema proteger y salvaguardar los datos confidenciales de los usuarios frente al acceso no autorizado, las brechas de seguridad y los ciberataques. Esto incluye, principalmente, la implementación de mecanismos de autenticación y cifrado para proteger los datos.

Ejemplos (aplicación de negociación bursátil)

• Los datos del usuario deben cifrarse al realizar una solicitud de API entre el front-end y el back-end del sistema para actualizar los datos.
• Los usuarios deben iniciar sesión mediante la autenticación de dos factores (2FA) para realizar cualquier operación financiera.
• El sistema debería bloquear una cuenta tras cinco intentos fallidos de inicio de sesión y avisar al usuario por correo electrónico.

9. Requisitos de usabilidad

La usabilidad se centra en la facilidad con la que los usuarios pueden interactuar con el sistema. Un producto con una alta usabilidad mejora la experiencia del usuario y permite que los nuevos usuarios lo adopten con una formación mínima. Una usabilidad deficiente genera frustración y aumenta los costes de asistencia técnica.

Ejemplo

• En la aplicación de reparto de comida a domicilio, todas las acciones principales (añadir al carrito, aplicar un cupón, volver a pedir) deben estar disponibles con dos toques o menos en el móvil.

Por qué son importantes los requisitos no funcionales: fallos reales y lecciones aprendidas

Los equipos de desarrollo de productos se centran principalmente en los requisitos funcionales, pero no prestan atención a los requisitos no funcionales. Los equipos piensan que, si la función funciona, el trabajo está hecho. Sin embargo, no tienen en cuenta el rendimiento, la fiabilidad, la seguridad y otros requisitos no funcionales.

A continuación se explica cómo el hecho de pasar por alto los requisitos no funcionales provocó fallos graves en sistemas reales.

Amazon: Fallo técnico durante el Prime Day (2018)

En 2018, Amazon sufrió una importante interrupción del servicio durante el evento Prime Day. El número de usuarios del sitio web aumentó de forma inesperada y el sistema no pudo hacer frente a la demanda. A causa de ello, la página web de Amazon dejó de funcionar y los compradores recibían mensajes de error. Amazon perdió entre 90 y 100 millones de dólares durante esta interrupción, que duró una hora.

Esta interrupción se debió a una gestión deficiente de la escalabilidad. Por lo tanto, el sistema debe estar siempre preparado para adaptarse a cualquier situación y debe estar disponible la mayor parte del tiempo.

Knight Capital: Fallo del sistema de negociación (2012)

En 2012, Knight Capital lanzó el software de negociación sin haberlo sometido a las pruebas adecuadas. A los 45 minutos de su puesta en marcha, el sistema comenzó a realizar operaciones erróneas que provocaron a la empresa unas pérdidas de 440 millones de dólares.

Este fallo del sistema se produjo porque no se comprobó adecuadamente la fiabilidad del software y no existían controles de seguridad para impedir las acciones defectuosas.

TSB Bank: Desastre en la migración de sistemas informáticos (2018)

El banco TSB del Reino Unido se vio envuelto en graves problemas en 2018 tras trasladar los datos de sus clientes a un nuevo sistema. La migración de datos de la plataforma antigua a la nueva se llevó a cabo con éxito. Sin embargo, a partir de ese momento, muchos clientes no pudieron iniciar sesión, algunos observaron datos incorrectos en su perfil y unos pocos usuarios pudieron ver los datos privados de otras personas. Al final, el banco pagó alrededor de 330 millones de libras esterlinas para solucionar todo y perdió la confianza de sus clientes.

Las causas de este fallo fueron la escasa fiabilidad del sistema y las deficientes medidas de seguridad.

Consejos y buenas prácticas para redactar requisitos no funcionales de forma clara

Como se ha comentado anteriormente, los requisitos no funcionales son fundamentales para el éxito de un proyecto. Sin embargo, redactarlos correctamente supone un reto. Muchos equipos cometen errores habituales que pueden provocar retrasos o un mal funcionamiento del sistema más adelante. Los equipos deben seguir las siguientes prácticas recomendadas para evitar esos errores y redactar unos buenos requisitos de software.

1. Sé concreto y evita los términos vagos: al definir los requisitos no funcionales, sé claro y evita cualquier ambigüedad. Por ejemplo, en lugar de decir «El sistema debe ser rápido», di algo como «El sistema debe cargar el panel de control en menos de 2 segundos para el 90 % de los usuarios». De esta forma, cada miembro del equipo podrá comprender el objetivo claro de los requisitos no funcionales.
2. Haz que todos los NFR sean cuantificables y verificables: establece siempre métricas o rangos para medir los criterios de éxito. Por ejemplo, en lugar de indicar que una aplicación debe tener «alta escalabilidad», di: «La aplicación debe admitir 500 usuarios simultáneos sin que ello afecte al rendimiento». Esto ayuda a los equipos a realizar un seguimiento del progreso y a garantizar que la aplicación cumple con éxito los NFR.
3. Definir los requisitos no funcionales (NFR) para los componentes del sistema: en lugar de definir un requisito no funcional concreto para todo el sistema, defínelo para el componente específico. Por ejemplo, al desarrollar una tienda de comercio electrónico, no es necesario definir requisitos de escalabilidad para el panel de administración si solo va a interactuar con él un número fijo de administradores.
4. Colabora con todas las partes interesadas clave: a la hora de definir los requisitos no funcionales, involucra a todas las partes interesadas clave, incluidos los desarrolladores, los evaluadores de control de calidad, los equipos de seguridad, los arquitectos, los responsables de producto e incluso los usuarios finales cuando sea necesario. Cada uno aporta aspectos diferentes que pueden contribuir a reforzar los requisitos no funcionales.
5. Vincula los requisitos con los objetivos empresariales: cada requisito funcional no técnico (NFR) debe tener una finalidad concreta. Si el tiempo de actividad, la velocidad o la seguridad ayudan a tu empresa a generar ingresos o a fidelizar a los clientes, esto debe reflejarse claramente en tus requisitos. Di «un tiempo de actividad del 99,9 % para cumplir con los compromisos de los pedidos en línea» en lugar de limitarte a decir «alto tiempo de actividad». De este modo, te aseguras de que el equipo comprenda por qué ese requisito es importante.
6. Agrupa los NFR en categorías: en lugar de tener una lista interminable de NFR, agrúpalos según su tipo, como rendimiento, fiabilidad, escalabilidad, etc.
7. Utiliza un formato y una terminología coherentes: asegúrate de utilizar un formato estándar para redactar los requisitos. Puedes definir el ID del requisito, la descripción, la prioridad y los criterios de evaluación para cada uno de ellos.
8. Utiliza las herramientas adecuadas para simplificar el trabajo: utiliza las herramientas adecuadas para la gestión de requisitos. Modern Requirements4DevOps, una solución de gestión de requisitos integrada de forma nativa en Azure DevOps, ofrece funciones como la trazabilidad de los requisitos, la gestión de versiones y variantes, la gestión de documentos, la gestión de revisiones, etc.

Utilizar Modern Requirements4DevOps para redactar mejores documentos de requisitos no funcionales

Documentar los requisitos no funcionales es importante para garantizar que todos los miembros del equipo y las partes interesadas compartan una visión común de los objetivos del proyecto. Con una documentación clara, los equipos pueden minimizar el riesgo de malentendidos, que pueden dar lugar a costosas repeticiones del trabajo.

A continuación, presentamos algunas de las características principales de Modern Requirements4DevOps que pueden simplificar el proceso de creación de la documentación de requisitos.

1. Smart Docs: Este módulo permite a los equipos crear y gestionar documentos de requisitos actualizados directamente en Azure DevOps. Ofrece una interfaz similar a la de Microsoft Word para crear y editar documentos. Además, permite a los equipos vincular directamente los requisitos de las listas de tareas pendientes a los documentos. De este modo, cada vez que se modifique cualquier dato de los requisitos, se reflejará al instante en el documento.