gestion de requisitos no funcionales en proyectos

Requisitos no funcionales

1. Gestión de Requisitos No Funcionales
en Proyectos Ágiles: Un Análisis de la
Teoría y la Práctica
1. Introducción: El Desafío de los NFRs en el Mundo
Ágil
El desarrollo ágil de software (ASD) ha transformado la industria de TI al priorizar la entrega
rápida e incremental de valor al cliente. Sin embargo, este enfoque, centrado en la
funcionalidad tangible, crea una tensión inherente con la gestión de los Requisitos No
Funcionales (NFRs). A diferencia de las funcionalidades, que pueden desarrollarse de forma
aislada, los NFRs —como la seguridad, el rendimiento o la mantenibilidad— son a menudo
propiedades transversales que afectan a todo el sistema. Su naturaleza sistémica choca
con el modelo de desarrollo iterativo, lo que ha llevado a que la literatura académica reporte
con frecuencia que los NFRs son un desafío problemático en los proyectos ágiles.
Contrario a la narrativa académica, los profesionales en el campo no han quedado
paralizados por estos desafíos. Han forjado un conjunto de prácticas pragmáticas para
integrar y gestionar los NFRs en sus flujos de trabajo. Lejos de ignorar estos requisitos
críticos, han encontrado formas efectivas de abordarlos para garantizar la calidad y el éxito
a largo plazo del software.
El objetivo de este informe es sintetizar y analizar los hallazgos de una investigación dual,
que combina una revisión sistemática de literatura (SLR) con entrevistas a expertos del
sector. A través de este análisis, se busca ofrecer una visión consolidada sobre cuándo,
cómo y dónde se gestionan los Requisitos No Funcionales en proyectos ágiles reales,
cerrando la brecha entre la teoría académica y la práctica industrial. A continuación, se
detalla la metodología empleada para recopilar y contrastar estas dos perspectivas.
2. Metodología de Investigación: Un Enfoque Dual
Para obtener una visión completa y matizada sobre la gestión de NFRs, es fundamental
emplear un método de investigación robusto que vaya más allá de una sola fuente de
información. Por ello, este estudio adoptó un enfoque cualitativo dual, diseñado
específicamente para contrastar la teoría académica con la experiencia práctica y el
conocimiento tácito de los profesionales de la industria. Esta combinación permite no solo
identificar las prácticas propuestas, sino también comprender cuáles se aplican en el mundo
real y por qué.
El primer componente del estudio fue una Revisión Sistemática de Literatura (SLR). Su
propósito principal fue identificar, registrar y categorizar las diversas prácticas y técnicas

2. descritas en la literatura académica para la gestión de NFRs en contextos ágiles. El proceso
partió de una búsqueda exhaustiva que arrojó 159 artículos, los cuales fueron sometidos a
un riguroso proceso de filtrado basado en criterios de inclusión y exclusión. Finalmente, se
seleccionaron 31 fuentes calificadas que constituyeron la base para el análisis teórico.
El segundo componente consistió en una serie de Entrevistas Semi-estructuradas con
profesionales experimentados. Se llevaron a cabo 10 entrevistas en profundidad con
expertos de diversos sectores (banca, automotriz, servicios públicos), cada uno con un
mínimo de siete años de experiencia en proyectos de desarrollo ágil. Este método permitió
obtener una comprensión profunda de las prácticas industriales, los desafíos cotidianos y
las estrategias pragmáticas que los equipos utilizan para manejar los NFRs, proporcionando
un valioso contrapunto a los hallazgos de la literatura. Con esta sólida base metodológica, el estudio procedió a analizar los hallazgos,
comenzando por una de las decisiones más críticas en la gestión de NFRs: el momento de
su identificación.
3. El Momento Estratégico: ¿Cuándo se Identifican los
NFRs?
La decisión sobre cuándo identificar los Requisitos No Funcionales es de una importancia
estratégica fundamental. Un NFR crítico, como un requisito de seguridad o rendimiento,
identificado tardíamente puede invalidar decisiones arquitectónicas tempranas, generando
retrabajo costoso y poniendo en riesgo el cronograma del proyecto. Por lo tanto, el
momento elegido para abordar los NFRs impacta directamente en la arquitectura del
sistema y en la gestión de riesgos del proyecto.
3.1. Perspectivas de la Literatura Académica
La revisión sistemática de literatura revela un panorama diverso de enfoques propuestos
para la identificación de NFRs, sin un consenso claro sobre una única "mejor práctica". Los
principales enfoques identificados son:
●​Enfoque Iterativo: La práctica más comúnmente citada. Los NFRs se identifican y
refinan de manera continua en cada iteración del desarrollo, en paralelo con los
requisitos funcionales.
●​Enfoque Temprano Híbrido: Se identifican los NFRs de más alto nivel en una
iteración inicial (a menudo llamada "Iteración Cero"), sentando las bases
arquitectónicas. Estos NFRs se detallan y refinan en iteraciones posteriores.
●​Enfoque de "Cascada": Algunos autores proponen una identificación exhaustiva de
todos los NFRs al inicio del proyecto, de manera similar a un enfoque tradicional en
cascada, antes de que comience el desarrollo iterativo de funcionalidades.
●​La literatura también advierte que la identificación tardía de NFRs es una causa
común de problemas significativos, incluyendo deuda técnica y la necesidad de
rediseños costosos.
3.2. La Práctica Industrial: Un Consenso hacia la Anticipación

3. En marcado contraste con la diversidad de la literatura, las entrevistas con profesionales
revelaron un consenso abrumador: nueve de los diez expertos insistieron en la necesidad
de una identificación temprana de los NFRs. Consideran que posponer esta tarea es un
riesgo inaceptable. En la práctica, utilizan cuatro enfoques principales para lograr esta
anticipación:
1.​Identificación Inicial y Refinamiento Posterior: Es el enfoque más común. Se
realiza un esfuerzo inicial para esbozar los NFRs clave al comienzo del proyecto,
asegurando que la arquitectura pueda soportarlos. Los detalles específicos se
elaboran y refinan a medida que avanza el desarrollo en iteraciones futuras. 2.​Exploración Exhaustiva Inicial: Similar al enfoque de cascada, algunos equipos
dedican una fase inicial del proyecto a explorar y definir los NFRs de la manera más
completa posible. Aunque los requisitos funcionales se gestionan de forma iterativa,
los NFRs se tratan con un enfoque más planificado desde el principio. 3.​Análisis Pre-Proyecto: En contextos de alto riesgo, algunas organizaciones llevan
la anticipación un paso más allá. Identifican y evalúan la viabilidad de los NFRs más
críticos antes de firmar el contrato con el cliente. Si el riesgo de no cumplir con un
NFR esencial es demasiado alto, el proyecto puede no llevarse a cabo. 4.​Gestión Proactiva de la Sobreespecificacíón: En una táctica de gestión de
riesgos avanzada, algunas organizaciones identifican los NFRs de forma temprana
internamente, pero al mismo tiempo desalientan a los representantes del cliente a
expresarlos explícitamente en las fases iniciales (por ejemplo, evitando el tema en
las reuniones). Esto permite controlar la sobreespecificación y gestionar las
expectativas, aunque pueda parecer contrario al principio de transparencia total.
3.3. Análisis Comparativo y Conclusión Táctica
Al contrastar ambos conjuntos de hallazgos, emerge una conclusión clara. Mientras que la
literatura académica presenta un menú de opciones teóricas, la práctica industrial se
decanta casi unánimemente por la identificación temprana. Esta elección no es una mera
preferencia, sino un imperativo estratégico impulsado por una motivación singular y
poderosa: la mitigación de riesgos. Los profesionales, curtidos por la experiencia, no ven
la anticipación como una desviación del agilismo, sino como una adaptación pragmática
necesaria para prevenir costosos retrabajos arquitectónicos y asegurar la viabilidad del
producto.
Definir el "cuándo" es solo la primera mitad de la ecuación estratégica. La eficacia real
depende del "cómo": las técnicas empleadas para extraer estos requisitos críticos de las
partes interesadas.
4. Técnicas de Elicitación: ¿Cómo se Obtienen los
NFRs?
Una vez definido el momento estratégico para abordar los NFRs, el siguiente paso crucial
es su elicitación o levantamiento efectivo. La calidad de este proceso determina
directamente la claridad, la viabilidad y la relevancia de los requisitos que guiarán el

4. desarrollo. Una elicitación deficiente puede llevar a NFRs ambiguos, inalcanzables o, peor
aún, a la omisión de necesidades de calidad críticas para el usuario final.
4.1. Técnicas Propuestas en la Literatura
La revisión de literatura identificó varias técnicas que los autores proponen para la
elicitación de NFRs en contextos ágiles. Estas técnicas van desde métodos de
comunicación directa hasta el uso de recursos estructurados.
Técnica Descripción Breve
Entrevistas y reuniones
con stakeholders
Conversaciones directas con las partes interesadas para
indagar sobre sus expectativas de calidad.
Talleres y sesiones de
brainstorming
Sesiones de trabajo en grupo para identificar y definir
NFRs de manera colaborativa.
Uso de catálogos de
patrones de NFRs
Utilización de listas predefinidas de NFRs comunes para
guiar a los stakeholders y evitar omisiones.
Análisis de modelos de
procesos de negocio
Derivación de NFRs a partir del análisis de los flujos de
trabajo y las necesidades operativas del negocio.
Circulación de
documentos
Uso de borradores y documentos para que los
stakeholders los revisen y proporcionen retroalimentación.
Sesiones de formación Educar a los stakeholders sobre diferentes categorías de
NFRs para que puedan articular mejor sus necesidades.
4.2. El Pragmatismo en la Práctica: Comunicación y Expertise
Los profesionales entrevistados revelaron un enfoque más pragmático y centrado en las
personas que en las herramientas. Aunque las técnicas que utilizan son consistentes con
las de la literatura, su efectividad depende en gran medida de la organización del equipo y
la proactividad de sus miembros.

5. ●​Rol del Analista: Seis de los diez entrevistados destacaron que la presencia de
un analista de negocio o de sistemas en el equipo ágil es una práctica común y
valiosa. Este rol no espera pasivamente los requisitos, sino que facilita
proactivamente la elicitación de NFRs, utilizando su experiencia para preguntar
sobre aspectos de calidad que los stakeholders podrían pasar por alto.
●​Fuentes Diversas: Los profesionales enfatizan que el Product Owner no es la única
fuente de NFRs. Obtienen información de múltiples stakeholders, incluyendo
expertos técnicos (para seguridad o rendimiento) y usuarios finales (para usabilidad).
Crucialmente, consideran a los propios desarrolladores un motor de refinamiento,
ya que sus preguntas y propuestas técnicas a menudo conducen a la clarificación y
mejora de los NFRs.
●​Esfuerzo y Proactividad: Existe un consenso en que la elicitación de NFRs es una
tarea que requiere un esfuerzo significativo y un enfoque activo. Los stakeholders a
menudo no son conscientes de sus propias necesidades de calidad o las expresan
de forma genérica ("el sistema debe ser rápido"). El equipo debe guiar la
conversación para transformar estas declaraciones ambiguas en requisitos
medibles.
●​Técnicas Universales: El hallazgo más revelador es que los profesionales no
utilizan técnicas de elicitación dedicadas exclusivamente a los NFRs. En cambio,
confían en métodos de comunicación directa de propósito general, como entrevistas
y talleres, para obtener tanto los requisitos funcionales como los no funcionales. La
única excepción notable, que confirma la regla, fue el uso de pruebas de usabilidad,
una técnica inherentemente ligada a un NFR específico.
4.3. Implicaciones para el Equipo de Proyecto
El análisis comparativo revela una brecha clave: la teoría propone técnicas especializadas,
mientras que la práctica industrial se apoya en la comunicación universal. La implicación es
clara: para la elicitación de NFRs, los factores humanos y la cultura de equipo triunfan
sobre las metodologías específicas. La eficacia no parece depender de la adopción de
herramientas complejas, sino de la experiencia del equipo, una cultura de comunicación
directa y un enfoque proactivo liderado por roles de análisis cualificados. Esto sugiere que
las técnicas especializadas propuestas por la academia podrían ofrecer rendimientos
decrecientes en comparación con la inversión en analistas competentes.
Habiendo cubierto el "cuándo" y el "cómo" de la obtención de NFRs, el siguiente paso lógico
es examinar cómo se documentan estos requisitos para que sean claros, compartidos y
accionables.
5. Estrategias de Documentación: ¿Cómo se Plasman
los NFRs?
La documentación de los NFRs presenta una aparente contradicción en el mundo ágil. Por
un lado, el Manifiesto Ágil valora el "software funcionando sobre documentación extensiva".
Por otro, los NFRs, para ser útiles, deben ser claros, específicos y, sobre todo, medibles.
Dejar un NFR en la ambigüedad es una receta para el fracaso. Por lo tanto, los equipos

6. ágiles deben encontrar un equilibrio que permita una documentación precisa sin caer en la
burocracia de los métodos tradicionales.
5.1. Catálogo de Técnicas Identificadas en la Literatura
La revisión de literatura arrojó un amplio abanico de técnicas de documentación para NFRs,
que se pueden agrupar en dos grandes categorías:
●​Uso de Artefactos Ágiles Estándar: Muchas propuestas se centran en adaptar los
artefactos existentes para que puedan contener NFRs.
○​User stories: Redactar historias de usuario enfocadas en la calidad.
○​Criterios de aceptación: Añadir criterios medibles relacionados con NFRs a
las historias de usuario funcionales.
○​Definition of Done (DoD): Incluir NFRs genéricos (ej. "toda nueva
funcionalidad debe pasar las pruebas de rendimiento") como parte de la
definición de "hecho" para todo el equipo.
●​Técnicas Adaptadas o Específicas para NFRs: Otros enfoques proponen
artefactos especializados para manejar mejor la naturaleza de los NFRs.
○​Technical stories: Historias enfocadas en tareas de arquitectura o
infraestructura necesarias para cumplir con un NFR.
○​Structured story cards: Tarjetas de historia con secciones predefinidas para
documentar NFRs de forma estructurada.
○​Extended acceptance criteria (AC+): Un formato extendido de criterios de
aceptación diseñado para ser más riguroso con los NFRs.
○​Wiki pages: Usar un wiki del proyecto para documentar NFRs transversales
que aplican a múltiples funcionalidades.
5.2. Enfoques de Documentación en la Práctica
Las entrevistas con los profesionales revelaron que, en la práctica, no existe un único
enfoque, sino tres estrategias principales que los equipos eligen y adaptan según su
contexto, la criticidad de los NFRs y la madurez del equipo.
1.​Enfoque Ligero (Confianza en la Comunicación): Este enfoque se adhiere
estrechamente al principio de mínima documentación. Los NFRs se documentan de
forma simplificada utilizando artefactos estándar como epics o user stories. La
confianza se deposita en la comunicación cara a cara y en la memoria colectiva del
equipo para aclarar los detalles. Funciona bien en equipos pequeños y altamente
cohesionados, pero puede ser riesgoso si los NFRs son complejos o el equipo
cambia.
2.​Enfoque Dual (Separación de Intereses): Este modelo separa la documentación
de los requisitos funcionales y no funcionales. El equipo mantiene un Product
Backlog ágil para los FRs, pero documenta los NFRs de forma precisa y medible en
un documento externo y estructurado, como una Especificación de Requisitos de
Software (SRS). Los desarrolladores consultan este documento cuando es
necesario, garantizando la precisión sin sobrecargar el backlog del día a día.
3.​Enfoque Híbrido (Rigor Integrado): Probablemente el más común, este enfoque
busca lo mejor de ambos mundos. Utiliza los artefactos ágiles típicos pero enriquece

7. la descripción de los NFRs con detalles, métricas cuantificables y criterios de
aceptación inequívocos directamente en la herramienta de gestión de proyectos.
Esto asegura que el requisito sea verificable sin necesidad de un documento
separado.
Tras haber explorado el cuándo, el cómo y el dónde de la gestión de NFRs, es momento de
integrar estos hallazgos en una síntesis final.
6. Síntesis y Conclusiones: Cerrando la Brecha entre
Teoría y Práctica
Esta sección final destila las conclusiones más importantes del análisis comparativo entre la
literatura académica y la práctica industrial, ofreciendo una visión integrada de la gestión de
Requisitos No Funcionales en entornos ágiles. El objetivo es ir más allá de las técnicas
individuales para comprender las estrategias subyacentes que conducen al éxito.
Una de las discrepancias más notables es que el problema de "ignorar los NFRs",
frecuentemente citado en la literatura como un fallo inherente de los métodos ágiles, no fue
confirmado por los profesionales entrevistados. Para ellos, no es un problema sin resolver,
sino un desafío gestionado activamente. Este hallazgo sugiere que las organizaciones
representadas han alcanzado una madurez en sus procesos que les permite abordar los
NFRs de manera proactiva, principalmente a través de la identificación temprana para
mitigar riesgos arquitectónicos. El análisis también subraya la importancia crítica del factor humano y la organización del
equipo. El éxito en la gestión de NFRs parece depender menos de la adopción de una
técnica de elicitación específica y más de factores organizacionales como la presencia de
analistas experimentados y el fomento de una cultura de comunicación directa. La
capacidad de un analista para hacer las preguntas correctas es, en la práctica, más
determinante que el uso de cualquier herramienta. Finalmente, el estudio revela el pragmatismo con el que los profesionales adaptan las
prácticas ágiles para acomodar las necesidades de los NFRs. Ya sea adelantando su
identificación o utilizando esquemas de documentación híbridos, los equipos demuestran
una notable flexibilidad. Esto indica que la industria no sigue los métodos ágiles de manera
dogmática, sino que los moldea de forma inteligente para equilibrar la velocidad de entrega
con la calidad y la robustez del producto final. Esta brecha entre la teoría y la realidad operativa no es meramente académica; tiene
implicaciones directas en la gestión de proyectos. A continuación, se destilan estos
hallazgos en recomendaciones prácticas para el liderazgo de equipos ágiles.
7. Recomendaciones Prácticas para Gestores y
Analistas

8. A partir de los hallazgos de este análisis, se proponen las siguientes recomendaciones
accionables para gestores de proyectos, analistas de negocio y líderes de equipo que
buscan mejorar la gestión de Requisitos No Funcionales en sus proyectos ágiles.
1.​Priorice la Identificación Temprana de NFRs. No espere a que los NFRs emerjan
en iteraciones avanzadas. Abordar los requisitos de calidad clave al inicio del
proyecto reduce drásticamente el riesgo arquitectónico y el retrabajo. Este enfoque
fue respaldado por el 90% de los expertos entrevistados, quienes lo consideran una
estrategia de mitigación de riesgos no negociable.
2.​Fomente un Rol Proactivo de Análisis. Asigne la responsabilidad de la elicitación
de NFRs a un rol con experiencia, como un analista de negocio o de sistemas. Esta
persona no debe ser un mero tomador de notas, sino un facilitador proactivo que
guíe a los stakeholders, les ayude a articular necesidades de calidad implícitas y
transforme declaraciones ambiguas en requisitos verificables.
3.​No Espere Técnicas Mágicas; Domine la Comunicación. El éxito no reside en
encontrar una herramienta especializada para NFRs. El estudio reveló que los
profesionales no emplean técnicas de elicitación dedicadas a NFRs, sino que logran
el éxito a través de la comunicación directa, un hallazgo que desmitifica la necesidad
de herramientas complejas. Domine los talleres y entrevistas con una mezcla
adecuada de stakeholders de negocio y técnicos.
4.​Seleccione una Estrategia de Documentación Consciente. No existe una única
forma correcta de documentar NFRs. Elija explícitamente una estrategia —ligera,
dual o híbrida— que se ajuste a la criticidad de los NFRs, el contexto de su proyecto
y la madurez de su equipo. La clave es tomar una decisión consciente en lugar de
aplicar un enfoque único para todo por defecto.
5.​Utilice los Criterios de Aceptación y la "Definición de Hecho" (DoD) como
Herramientas de Precisión. Incluso si documenta los NFRs dentro de una user
story, utilice los criterios de aceptación para hacerlos específicos y medibles. De
igual forma, aproveche la DoD para establecer una línea base de calidad no
funcional que todos los incrementos de producto deben cumplir, asegurando una
calidad consistente en todo el proyecto.