Cómo redactar requisitos no funcionales en 6 pasos
Los equipos definen los requisitos no funcionales (NFR) identificando atributos del sistema como la seguridad, la fiabilidad, el rendimiento, la facilidad de mantenimiento, la escalabilidad y la usabilidad, y luego los especifican en términos claros y cuantificables.
Esto es importante, ya que los requisitos no funcionales (NFR) son fundamentales para garantizar la eficacia, la usabilidad, la durabilidad y la satisfacción del usuario del sistema.
Por eso, este artículo explica cómo redactar los requisitos no funcionales (NFR) en seis pasos y quién se encarga de redactarlos, con ejemplos y plantillas que te servirán de guía.
Nota: Si quieres saber qué son los requisitos no funcionales, cuáles son las diferencias con los requisitos funcionales y profundizar en los distintos tipos de requisitos no funcionales, lee Explicación de los requisitos no funcionales (con ejemplos reales).
Índice
1. ¿Quién redacta los requisitos no funcionales?
Los requisitos no funcionales (NFR) suelen ser redactados por las distintas partes interesadas que participan en el proyecto. Entre ellas suelen figurar:
- Analistas de negocios: A menudo son los encargados de identificar y documentar los requisitos no funcionales, ya que suelen tratar con los clientes al tiempo que forman parte de la empresa que crea los productos. Como resultado, tienen una visión clara de las necesidades, preferencias y expectativas tanto de los clientes como de las partes interesadas internas.
- Arquitectos e ingenieros de sistemas: gracias a su profundo conocimiento de la arquitectura del sistema, sus limitaciones y sus posibilidades, su aportación en materia de requisitos no funcionales es inestimable.
- Responsables de producto: pueden ayudar a definir los requisitos no funcionales (NFR) basándose en las necesidades de los clientes, las necesidades empresariales y el conocimiento del mercado.
- Equipos de control de calidad (QA): pueden contribuir a definir los requisitos no funcionales (NFR) relacionados con los estándares de calidad, el cumplimiento normativo y los criterios de prueba.
Aprender a redactar o elaborar requisitos no funcionales es una tarea que requiere la colaboración de todos. Por eso, una comunicación eficaz entre todas las partes es fundamental para definirlos e implementarlos con precisión.
2. ¿Cómo redactar requisitos no funcionales en seis pasos?
Paso 1: Identificar el alcance y el objetivo
El alcance de un proyecto determina qué recursos o entregables se pueden añadir o eliminar a medida que avanza el proyecto, en función de las necesidades identificadas de las partes interesadas. También determina qué requisitos no funcionales (NFR) elabora el equipo. Un alcance inadecuado de los proyectos y los requisitos no funcionales (NFR) pueden dar lugar a problemas graves, como sobrecostes, retrasos, insatisfacción de las partes interesadas e incluso problemas legales.
Los estudios revelan que el 85 % de los proyectos de construcción en los que se produce una ampliación del alcance superan su presupuesto, con un sobrecoste medio del 27 %.
Por ejemplo, si un sistema es una aplicación de transmisión de vídeo en tiempo real, los requisitos no funcionales relacionados con el rendimiento (como la calidad del vídeo y el tiempo de inactividad) serían de gran importancia.
Paso 2: Recabar opiniones de las partes interesadas
La mejor manera de garantizar que un sistema satisfaga las necesidades de la empresa, los clientes y el mercado es recabar la opinión de las partes interesadas. Además, esto evita problemas graves, como sobrecostes y riesgos legales. Para recabar la opinión de las partes interesadas, basta con seguir dos pasos:
- Implicación de las partes interesadas
Es fundamental identificar quiénes son las partes interesadas al inicio de un proyecto. Las partes interesadas pueden clasificarse en grupos primarios, secundarios y terciarios, en función de su impacto directo y su influencia en el proyecto.
Una vez identificadas las partes interesadas, tanto internas como externas, los equipos pueden pasar a recopilar los requisitos, incluidos los requisitos no funcionales.
- Recopilación de requisitos
La recopilación de requisitos es el proceso mediante el cual los equipos recaban información de las partes interesadas para definir los requisitos del proyecto, incluidos los requisitos no funcionales.
Las técnicas de recopilación de requisitosincluyen diversos métodos cualitativos y cuantitativos, como entrevistas, sesiones de lluvia de ideas, grupos focales y encuestas. La elección de la técnica depende del alcance del proyecto, los recursos asignados y la disponibilidad de las partes interesadas.
Las mejores herramientas de gestión de proyectos también permiten a los equipos recopilar requisitos de otras fuentes, como correos electrónicos, notas, preguntas frecuentes y documentos de Word subidos.
Los equipos han empezado a utilizar herramientas de IA de última generación para automatizar la recopilación de requisitos, lo que la hace más eficiente y exhaustiva.
Paso 3: Clasificar los requisitos no funcionales (NFR)
La clasificación de los requisitos no funcionales (NFR) orienta el diseño del producto o servicio e influye en su rendimiento, seguridad y satisfacción del usuario. Una clasificación inadecuada de los NFR puede dar lugar a proyectos que no satisfagan las necesidades de las partes interesadas. A continuación se presentan dos formas de clasificar los NFR:
- Ordenar por tipo Los requisitos no funcionales (NFR) se pueden clasificar en tres categorías principales:
- Aspectos operativos: se centran en la eficacia y la seguridad del sistema en condiciones normales. Por ejemplo, el sistema debería poder dar servicio a 10 000 usuarios activos simultáneamente sin que se produzca una disminución significativa de la calidad de la transmisión.
- Aspectos de revisabilidad: Estos garantizan que el sistema pueda adaptarse a los cambios con el mínimo esfuerzo. Por ejemplo, el sistema debería poder ampliarse para dar cabida a hasta 15 000 usuarios sin que se produzcan fallos graves.
- Aspectos de transición: se refieren a la capacidad del sistema para realizar transiciones fluidas, como la integración con otros sistemas o la adaptación a los cambios. Por ejemplo, el sistema debería funcionar en todos los principales sistemas operativos (Windows, macOS, Linux) y en todos los formatos (móvil, PC, ordenador de sobremesa, tableta) sin necesidad de modificaciones significativas.
Estas categorías ayudan a comprender y gestionar los NFR durante el desarrollo de un producto, un sistema o un proceso.
- Clasificación por prioridad: Una vez que sepas qué tipo de requisitos estás redactando, es el momento de priorizarlos. El método que utilices dependerá de las necesidades de tu proyecto. Algunas técnicas habituales son MoSCoW, RICE, la matriz de prioridades y otras.
- Ordenar por tipo Los requisitos no funcionales (NFR) se pueden clasificar en tres categorías principales:
Puedes priorizar los NFR según diversos aspectos del negocio y del proyecto, entre los que se incluyen:
- Valor empresarial: Prioriza los requisitos no funcionales (NFR) en función de su impacto en el valor empresarial del sistema. Los NFR que mejoren significativamente el valor del sistema deben recibir una mayor prioridad. Por ejemplo, en el caso de un coche urbano pequeño, un NFR que describa la eficiencia en el consumo de combustible tiene más valor empresarial que uno que determine el confort de los amortiguadores.
- Evaluación de riesgos: Se debe dar prioridad a los requisitos no funcionales (NFR) asociados a mayores riesgos. Por ejemplo, en un sistema bancario se podría dar mayor prioridad a los NFR relacionados con la seguridad. Los NFR que describen la conformidad del vehículo con las calificaciones de seguridad de Euro NCAP en caso de colisiones laterales contribuyen a proteger a los pasajeros de posibles daños.
- Aportaciones de las partes interesadas: Tenga en cuenta las aportaciones de las partes interesadas. Es posible que algunas de ellas concedan mayor importancia a determinados requisitos no funcionales.
- Coste y tiempo: Los requisitos funcionales no funcionales (NFR) cuya implementación requiera una cantidad significativa de recursos o tiempo podrían recibir una prioridad menor, a menos que sean fundamentales para el funcionamiento del sistema o para el valor empresarial. Por ejemplo, un sistema de infoentretenimiento de última generación tendría una prioridad menor si su implementación resultara demasiado costosa.
Cumplimiento legal y normativo: Las NFR relacionadas con el cumplimiento legal o normativo suelen tener una alta prioridad debido a las posibles consecuencias del incumplimiento. En un famoso caso reciente, el fabricante de automóviles Volkswagen instaló «dispositivos de desactivación» en sus vehículos diésel para falsear las pruebas de emisiones, lo que supuso una infracción de la normativa sobre emisiones. El escándalo le costó a la empresa 30 000 millones de dólares.
Paso 4: Definir indicadores y métricas
Los requisitos no funcionales pueden resultar amplios y difíciles de comprender para algunas personas, pero son tan fundamentales para el éxito de un proyecto como los requisitos funcionales. La forma en que estructuramos un requisito no funcional debe reflejar algunos aspectos importantes, como:
- ¿Qué estás midiendo?
- ¿Es una aplicación, un sistema, un proyecto o un proceso?
- ¿Qué atributos estás midiendo?
- ¿Se trata de la escalabilidad, la facilidad de mantenimiento, la seguridad o algo más?
- ¿Cuál es tu objetivo?
- ¿Qué indicadores utilizas para medir el éxito?
Estas respuestas se pueden resumir en una sola frase: «El [insertar respuesta a A] debería ser [insertar respuesta a B] para que [insertar respuesta a C]».
En el caso de un requisito no funcional relacionado con la escalabilidad, esta frase podría ser:
- «El sistema debería poder ampliarse hasta alcanzar los 10 000 usuarios en los próximos dos años».
- «La aplicación debe ser escalable para gestionar 10 000 inicios de sesión simultáneos por minuto».
Siempre que sea posible, un NFR debe incluir tanto una métrica como una medida.
Por ejemplo, si quisieras definir un requisito no funcional utilizando un atributo operativo como la fiabilidad, podrías plantear las siguientes preguntas (y respuestas):
Preguntas |
|---|
¿Qué estás midiendo? |
¿Qué parámetro(s) estás midiendo? |
¿Cuál es el objetivo? |
¿Qué indicadores y métricas utilizas para evaluar el éxito de los objetivos? |
Respuestas |
|---|
Estamos midiendo un sistema. |
Medimos la fiabilidad. |
Queremos un tiempo de actividad del 100 % durante el primer año. |
Nuestro objetivo es un tiempo de actividad del 100 %, nuestro indicador es el tiempo de actividad |
Puedes resumir estas respuestas en una sola frase:
- «El sistema debe estar operativo de tal manera que alcancemos un tiempo de actividad del 100 % durante el primer año de funcionamiento, con el fin de cumplir nuestra garantía de rendimiento de un año».
Se puede añadir más información sobre por qué este NFR cumple los criterios mencionados anteriormente.
Como puedes ver, es posible crear requisitos no funcionales utilizando plantillas. Si te interesa aprender a crear requisitos no funcionales con plantillas, lee el artículo «Creación de plantillas de requisitos no funcionales».
A pesar de la plantilla, siempre es posible olvidarse de añadir requisitos no funcionales. En ese caso, debes tener el debido cuidado.
Paso 5: Documenta tus requisitos no funcionales
La documentación sirve para informar y garantizar la rendición de cuentas, actuando como una lista de verificación de los requisitos acordados y como herramienta para comprobar el trabajo realizado. Permite a los equipos supervisar la evolución y el alcance de los requisitos a lo largo de todo el ciclo de vida del proyecto, lo que ayuda a identificar cualquier desviación respecto al alcance original. Aunque no existe un documento estandarizado para los requisitos no funcionales, a continuación abordaremos los tres tipos principales de documentos:
- Documento de requisitos funcionales (FRD): Se trata de una descripción formal de los requisitos funcionales de una aplicación, que suele elaborar un analista de negocios bajo la supervisión del director del proyecto. Sirve como contrato entre el desarrollador y el cliente, en el que se detalla lo que debe hacer la aplicación.
- Documento de requisitos del producto (PRD): Normalmente redactado por el director del proyecto, el PRD comunica a los equipos de pruebas y desarrollo las funcionalidades necesarias para el lanzamiento de un producto. En él se definen el objetivo, las características y el comportamiento del producto, y sirve de guía para el trabajo de los equipos de producto.
- Especificaciones de requisitos del sistema (SRS): Este documento, redactado normalmente por arquitectos de sistemas o responsables de producto, describe las características y el comportamiento de un software o un sistema. Sirve de base para el desarrollo, proporciona una referencia para la estimación de costes y la planificación, y contiene información fundamental relacionada con el desarrollo, el control de calidad, las operaciones y el mantenimiento.
Herramientas para la documentación de requisitos no funcionales
Los equipos necesitan buenas herramientas de documentación que sean fáciles de editar, compartir e integrar en su flujo de trabajo, como:
- Smart Docs: Esta herramienta permite a los usuarios elaborar documentos de requisitos, realizar un seguimiento de los cambios mediante la gestión de versiones e iniciar revisiones críticas de los elementos de trabajo, incluidos los requisitos no funcionales.
Además, aborda las cuestiones de estandarización al permitir la creación de plantillas de documentos reutilizables con una estructura personalizable, lo que fomenta la coherencia y la eficiencia en el proceso de documentación.
Sistema de gestión documental: está diseñado para gestionar documentos a lo largo de toda la duración del proyecto, realizando tareas de carga, estructuración y control de versiones de documentos y carpetas.
Estas y muchas otras herramientas para ampliar la gestión de requisitos en Azure DevOps están disponibles con Modern Requirements4DevOps.
Paso 6: Revisar y corregir
Con el paso del tiempo, los equipos, las empresas y las partes interesadas se darán cuenta de que su lista de requisitos no funcionales irá creciendo y cambiando. Esto es de esperar, ya que las necesidades de una organización se adaptan y cambian. Se trata de un paso fundamental en la gestión de los requisitos no funcionales (NFR).
Por ejemplo, una aplicación sanitaria puede generar archivos de registro que recogen la actividad de los pacientes o las transacciones del sistema. La eliminación periódica de estos archivos de registro es fundamental para recuperar espacio en disco y mantener el rendimiento de la aplicación.
Con el paso del tiempo, los equipos, las empresas y las partes interesadas se darán cuenta de que su lista de requisitos no funcionales irá creciendo y cambiando. Esto es de esperar, ya que las necesidades de una organización se adaptan y cambian. Se trata de un paso fundamental en la gestión de los requisitos no funcionales (NFR).
Por ejemplo, una aplicación sanitaria puede generar archivos de registro que recogen la actividad de los pacientes o las transacciones del sistema. La eliminación periódica de estos archivos de registro es fundamental para recuperar espacio en disco y mantener el rendimiento de la aplicación.
3. ¿Cómo contribuyen los requisitos no funcionales a la estandarización?
Los requisitos no funcionales (NFR) desempeñan un papel crucial en la normalización, especialmente en sectores en los que las cuestiones normativas y de cumplimiento son fundamentales. Por ejemplo, en el sector de los productos sanitarios, que está muy regulado, los atributos operativos como la confidencialidad revisten una importancia capital.
La Organización Internacional de Normalización (ISO) ha definido una serie de requisitos no normativos (NFR) específicos que deben cumplirse estrictamente durante el desarrollo de cualquier producto sanitario. Estos requisitos se clasifican en diversas normas ISO, tales como:
ASPICE – Requisitos de desarrollo de software para fabricantes de automóviles
- Garantizar la eficiencia en tiempo real durante los picos de demanda.
- Cumplir con las normas de seguridad del sector automovilístico.
- Protéjase contra el acceso no autorizado y las filtraciones de datos.
- Interfaz intuitiva para conductores y técnicos.
- Rendimiento constante en condiciones variadas y situaciones de estrés.
ISO 13485: Sistemas de gestión de la calidad para productos sanitarios
- Controles de gestión
- Planificación de productos
- Evaluación de los procesos de calidad
- Control de recursos
- Control por retroalimentación
ISO 14971:2007 – Aplicación de la gestión de riesgos a los productos sanitarios
- Responsabilidades de gestión
- Proceso de análisis de riesgos
- Control de riesgos
- Proceso de gestión de riesgos
- Informe sobre gestión de riesgos
4. Dominio de los requisitos no funcionales
Saber redactar, definir y documentar los requisitos no funcionales (NFR) es fundamental para el éxito de un proyecto. Unos NFR bien definidos influyen en la gestión del tiempo, la satisfacción de los usuarios y el cumplimiento normativo. Los equipos deben centrarse en atributos del sistema claros y cuantificables, como la seguridad, la fiabilidad, el rendimiento y la escalabilidad. Comprender y gestionar los NFR mejora la eficacia, la usabilidad y la durabilidad del sistema, lo que, en última instancia, impulsa el éxito del proyecto.
Sin embargo, los requisitos no funcionales son solo una parte del éxito de un producto o proyecto. Por lo general, necesitarás una solución de gestión de requisitos que cuente con varias características, como:
- Smart Docs: Creación, formato y vinculación de documentos en Azure DevOps.
- Copilot4DevOps Plus: Una herramienta de gestión de requisitos basada en IA que supone un cambio revolucionario.
- Informes inteligentes: Generación y uso compartido de informes de instantáneas de proyectos con un solo clic en Azure DevOps.
- Trazabilidad: Trazabilidad de elementos de trabajo en Azure DevOps con matrices de trazabilidad horizontales e interseccionales disponibles.
Modern Requirements4DevOps es una herramienta galardonada que amplía Azure DevOps para convertirlo en una única fuente de información fiable.
5. Otras preguntas que nos hacen sobre los requisitos no funcionales
-
- ¿Cuáles son algunas estrategias organizativas para garantizar una NFR eficaz?
A continuación se presentan otras estrategias organizativas que pueden ayudarte a maximizar su impacto. - Priorizar: planificar y definir los requisitos no funcionales con el mismo cuidado que el resto de requisitos
- Puntos de referencia: Utiliza los puntos de referencia del sector a la hora de determinar la eficacia de un requisito no funcional. Por ejemplo, el estándar del sector para el tiempo de carga de un sitio web es de 2 segundos. Los equipos deben utilizar herramientas como GTMetrix y Google Page Speed Insights para comparar su sitio web.
- Perspectiva a largo plazo: en el contexto de DevOps, un equipo debe pensar a largo plazo. Es importante seleccionar adecuadamente los requisitos no funcionales.
- Colaboración: Fomenta la colaboración y la comunicación entre los miembros del equipo para garantizar que todos comprendan los NFR y trabajen para cumplirlos.
- Formación: Impartir formación a los desarrolladores sobre la importancia de los requisitos no funcionales y sobre cómo aplicarlos de manera eficaz en su trabajo. Esto puede contribuir a garantizar que los requisitos no funcionales no se pasen por alto durante el proceso de desarrollo.
- ¿Cuáles son algunas estrategias organizativas para garantizar una NFR eficaz?
- ¿Quién redacta los requisitos no funcionales en Agile? Los arquitectos de sistemas y soluciones, junto con el equipo de gestión de productos y soluciones, elaboran los requisitos no funcionales en Agile de forma colaborativa.
- ¿Se redactan los requisitos no funcionales en forma de historias de usuario? Sí, a veces se pueden redactarlos requisitos no funcionales en forma de historiasde usuario. Por ejemplo, se puede redactar un requisito no funcional de seguridad de la siguiente manera: «Como usuario, quiero que mis datos personales estén cifrados, para que mi información esté protegida contra el acceso no autorizado».
