2.8 Requisitos de software

Panorama y motivación

Un requisito de software es una declaración de una capacidad o condición que un sistema debe ofrecer, cumplir o poseer para resultar aceptable ante sus partes interesadas. La ingeniería de requisitos, el trabajo riguroso de obtener, analizar, especificar, validar y gestionar esas declaraciones, se sitúa en el mismo origen de la cadena de valor. Todo lo que viene después (desde la arquitectura hasta el código y las pruebas de aceptación) es un intento de satisfacer esos requisitos. Por eso, cuando los requisitos son erróneos, incompletos o ambiguos, todo el esfuerzo invertido en construir con perfección la cosa equivocada se convierte en un desperdicio puro, y es el más costoso que existe, pues es el que se descubre a última hora. El Cuerpo de Conocimiento de la Ingeniería de Software (SWEBOK), en su área de conocimiento de Requisitos de Software, trata este campo como una disciplina de ingeniería de pleno derecho, no como un trámite burocrático previo al verdadero trabajo.

En equipos grandes, los requisitos son el entendimiento compartido que permite a muchas personas construir un solo sistema coherente. Un desarrollador solitario puede sostener la intención en su mente; cientos de personas repartidas entre muchos equipos, no. Los requisitos se convierten en el pacto entre quienes necesitan una capacidad y quienes la construyen, en la base para distribuir el trabajo entre equipos y en el criterio para juzgar cuándo algo está realmente terminado. Se conectan con la fase de exploración (capítulo 11.1), donde afloran los problemas y las oportunidades; con los fundamentos de la experiencia de usuario (capítulo 5.1), donde se comprenden las necesidades reales; con el diseño de interfaces y APIs (capítulo 2.3), donde se fijan las obligaciones de interfaz; con la arquitectura y los atributos de calidad (capítulo 3.1), donde los requisitos no funcionales determinan la estructura; y con la gestión de proyectos (capítulo 10.6), donde el alcance, el presupuesto y el plazo se planifican en torno a ellos.

En entornos empresariales y de la administración pública, los requisitos tienen peso legal, contractual y de seguridad. Un sistema regulado debe demostrar que cada obligación impuesta (accesibilidad, privacidad, seguridad, conservación de registros, control financiero) está recogida como requisito, implementada y verificada con pruebas documentales. Las licitaciones públicas se construyen a menudo en torno a una especificación de requisitos, y el pago, la auditoría y la certificación dependen de que cada uno de ellos pueda rastrearse hasta la evidencia de su cumplimiento. En ese contexto, los requisitos son más que una buena práctica: son la columna vertebral de la rendición de cuentas.

Principios fundamentales

Un requisito expresa una necesidad o una restricción, no una solución; dice qué y por qué, no cómo.
Cada requisito debe ser necesario, inequívoco, verificable, factible y trazable.
Los requisitos se descubren y negocian con las partes interesadas, no se inventan en soledad.
Los requisitos no funcionales y las restricciones condicionan la arquitectura tanto como la funcionalidad.
Los requisitos evolucionan: hay que gestionar el cambio de forma deliberada, ni congelándolos ni ignorándolo.
La trazabilidad, desde la necesidad hasta el requisito, el diseño, la prueba y la evidencia, es el tejido conectivo de la responsabilidad.
El nivel de formalidad adecuado depende del riesgo, la escala y el contexto regulatorio, no del hábito.

Recomendaciones

Definir y clasificar los requisitos con claridad

Denomínense las categorías con intención. Los requisitos funcionales declaran qué debe hacer el sistema: los comportamientos, transformaciones y servicios que ofrece. Los requisitos no funcionales (atributos de calidad) declaran con qué nivel de excelencia debe hacerlo: rendimiento, disponibilidad, seguridad, usabilidad, accesibilidad, mantenibilidad, entre otros; estos están ligados de forma estrecha a la arquitectura (capítulo 3.1). Las restricciones son los límites inmodificables de la solución: tecnologías impuestas, estándares, presupuestos, normas legales o interfaces con sistemas existentes. Y separen los requisitos de negocio (por qué la organización necesita el sistema) de los requisitos de usuario (qué necesitan las personas para lograr) y de los requisitos de sistema (qué debe hacer el software en consecuencia). Si se mezclan estos niveles, la confusión en el alcance no tarda en aparecer.

Obtener requisitos de fuentes reales, no de suposiciones

La obtención es un acto de descubrimiento activo. Extraiga los requisitos de las partes interesadas mediante entrevistas, talleres, observación, prototipos y el análisis de sistemas y documentos existentes. Persiga a cada parte interesada relevante, incluida aquella que suele pasarse por alto: los operadores, los auditores, el personal de soporte y las personas afectadas por el sistema que nunca lo utilizan directamente. Vincule la obtención a la fase de exploración (capítulo 11.1) y a la investigación de experiencia de usuario (capítulo 5.1), para que los deseos declarados se rastreen hasta las necesidades que los originan. Registre el origen y la justificación de cada requisito, porque saber por qué un requisito existe es precisamente lo que permite modificarlo con seguridad más adelante.

Analizar, negociar y priorizar

Las necesidades obtenidas a partir de la obtención entran en conflicto, se solapan y suman mucho más de lo que es viable. El análisis es el medio de reconciliarlas: clasificar requisitos, detectar contradicciones, ponderar la factibilidad y el riesgo, y negociar prioridades con las partes interesadas. Priorice con transparencia, por ejemplo mediante distinciones entre debe, debería y podría, o mediante una ponderación de valor frente a coste, de modo que, cuando se acabe el tiempo, se recorte el alcance correcto. Y modele los requisitos allí donde un modelo aporte claridad: flujos de proceso, diagramas de estado, modelos de datos y definiciones de interfaz revelan vacíos que el texto en prosa oculta.

Especificar con el grado de formalidad adecuado

Redacte los requisitos en una forma que se ajuste al riesgo y al público destinatario. Un sistema gubernamental de alta confianza puede requerir una especificación formal estructurada según un estándar como el IEEE 29148; un equipo de producto ágil puede capturar los requisitos como historias de usuario con criterios de aceptación en un backlog. En cualquier caso, cada requisito debe ser atómico, verificable y libre de términos ambigüos como «rápido», «amigable para el usuario» o «etcétera». Adjunte los criterios de aceptación, de modo que se defina cómo se verifica un requisito en el mismo instante en que se redacta. Y mantenga una única fuente autorizada, en lugar de dejar que los requisitos se dispersen entre correos, tickets y diapositivas.

Validar antes de construir

La validación confirma que los requisitos especificados son los correctos y que encajan entre sí. Revíselos con las partes interesadas, recorra escenarios y, siempre que sea posible, utilice prototipos para convertir declaraciones abstractas en algo tangible. Validar es más barato que cualquier corrección posterior: un defecto detectado en una revisión de requisitos cuesta una fracción de lo que cuesta el mismo defecto detectado en producción.

Gestionar los requisitos y mantener la trazabilidad

Los requisitos cambian. La labor es controlar ese cambio, no resistirlo. Establezca un proceso de gestión del cambio: evalúe cada modificación propuesta por su impacto, su coste y su efecto en cascada antes de aprobarla. Baselinee los requisitos en hitos acordados y vérselos. Mantenga una trazabilidad bidireccional que enlace cada requisito hacia delante con el diseño, el código y las pruebas, y hacia atrás con la necesidad que lo originó. La trazabilidad responde a las dos preguntas que guían a los equipos grandes: si esta necesidad cambia, ¿qué se ve afectado?; y para esta funcionalidad entregada, ¿qué necesidad la justificó? En contextos regulados, prolongue el rastreo hasta la evidencia de aceptación (resultados de pruebas, registros de auditoría, firmas de conformidad) para poder demostrar el cumplimiento, no limitarse a afirmarlo.

Adaptar a los contextos ágiles y planificados

En programas planificados y regulados, se especifican y baseliningan los requisitos con antelación, con un control formal de cambios. En contextos ágiles, los requisitos viven como un backlog priorizado y en evolución, que se elabora justo antes de la implementación y se valida de forma continua mediante software funcional. Las actividades subyacentes son las mismas en ambos casos; solo varían el momento, la formalidad y los artefactos. Las grandes organizaciones suelen combinar ambos enfoques: especifican y rastrean formalmente las obligaciones estables y de alta confianza, mientras elaboran el comportamiento del producto de forma iterativa. Elija el equilibrio según el riesgo, no según una ideología.

Compensaciones: ventajas e inconvenientes

Enfoque	Ideal para	Ventajas	Inconvenientes
Especificación formal anticipada	Alta confianza, entornos regulados, contratos de alcance fijo	Trazabilidad sólida; base clara de aceptación; auditabilidad	Lento ante el cambio; riesgo de sobre-especificar antes de aprender
Backlog ágil	Productos en evolución con partes interesadas comprometidas	Retroalimentación rápida; capacidad de adaptación; menos desperdicio en alcance no construido	Trazabilidad de largo alcance más débil; más difícil de auditar y contractualizar
Híbrido (restricciones formales + comportamiento ágil)	Empresas con obligaciones mixtas	Rigor donde importa, flexibilidad en el resto	Requiere criterio para distinguir qué va en cada lado

La tensión central es entre estabilidad y aprendizaje. Fijar los requisitos con antelación compra una base de aceptación sólida y auditabilidad, pero a costa de la capacidad de adaptarse a lo que se aprende durante la construcción. Posponerlos compra adaptabilidad, pero a costa de la trazabilidad de largo alcance y la claridad contractual. Invertir más en ingeniería de requisitos también cambia la velocidad a corto plazo por menos rework a largo plazo: una compensación que se rentabiliza a medida que crecen la escala, la longevidad y el coste del fallo de un sistema. Los proyectos más grandes y los más regulados se sitúan sin duda en el lado de la mayor inversión. Una herramienta interna de bajo riesgo no.

Puntos para debatir en equipo

¿Quién cuenta como parte interesada del sistema de mayor riesgo, y cuáles siguen ausentes hasta la aceptación? En un programa de gran envergadura, las personas que se pasan por alto rara vez son las usuarias evidentes: son los operadores que lo gestionan a las tres de la madrugada, los auditores que deben certificarlo, el personal de soporte que gestiona los fallos y las personas afectadas que nunca inician sesión, pero cuyos datos se custodian. Omitirlas y se descubrirán sus requisitos en el momento más costoso: durante la aceptación o tras la pregunta de un regulador. Lleve al encuentro un mapa concreto de partes interesadas y sométalo a estrés: para cada obligación impuesta (accesibilidad, privacidad, conservación de registros, seguridad), nombre a la persona que la posee y al requisito que la recoge. Si no puede nombrar un responsable, ha hallado un vacío, y la solución es incorporar a esa parte interesada a la obtención ahora, no forzar sus necesidades en una arquitectura ya cerrada.
Cuando un requisito cambia, ¿podemos responder qué se ve afectado antes de aprobar el cambio? Esta es la prueba práctica de si la trazabilidad bidireccional es real o decorativa. En un sistema grande o regulado, un único cambio de norma puede propagarse por el diseño, el código, las pruebas y la evidencia de aceptación, y aprobarlo a ciegas es la forma más habitual de entregar un sistema con aspecto de cumplir que, en realidad, vulnera en silencio una regla que antes satisfacía. Lleve una solicitud de cambio reciente y trátela de rastrear hacia delante en la reunión: si requiere una tarde de arqueología, la trazabilidad no está cumpliendo su función. La respuesta debe redefinir el proceso de cambio, de modo que la evaluación de impacto sea una consulta rápida sobre un rastreo vivo, no una búsqueda manual, y que los baselines y la versión ofrezcan un punto estable sobre el que cambiar.
¿Dónde reside la fuente autorizada de nuestros requisitos y cuánta verdad circula fuera de ella? La dispersión de requisitos (la especificación real repartida entre correos, tickets, diapositivas y la memoria de alguien) es una de las falencias más frecuentes en equipos grandes, y en sistemas auditados es letal, porque hay que demostrar qué se acordó. Decida, en voz alta, cuál es el sistema de registro canónico y trate todo lo que se declare en otro lugar como borrador hasta que se incorpore allí, con su origen y su justificación. Aporte evidencia: cuente cuántas disputas de alcance recientes se resolvieron con dos personas citando distintas versiones «finales». Si el resultado es mayor que cero, la acción es consolidar en una única fuente y escribir la justificación de cada requisito, porque saber por qué un requisito existe es, de nuevo, lo que permite modificarlo o retirarlo con seguridad.
¿Se capturan los requisitos no funcionales con suficiente antelación para impulsar la arquitectura, o seguimos descubriéndolos cuando la estructura ya está fijada? El rendimiento, la disponibilidad, la seguridad y la accesibilidad condicionan la arquitectura más que la mayoría de las funcionalidades, y en un programa grande son los requisitos que con más frecuencia afloran demasiado tarde, cuando la estructura que habría de satisfacerlos ya está vertida en hormigón. La tensión contraria es real: el comportamiento funcional es lo que las partes interesadas piden en voz alta y lo que mejor se demuestra en una presentación, mientras que un requisito de «respuesta en menos de un segundo bajo carga máxima» o «conformidad con WCAG» es invisible hasta que se viola. Aporte la lista actual de requisitos no funcionales del sistema de mayor riesgo, el momento de la línea temporal en que cada uno se escribió y si la arquitectura (capítulo 3.1) los recibió como conductores explícitos o los infirió. En entornos empresariales y de la administración pública, añadan las obligaciones de calidad impuestas (cifrado, conservación de registros, legislación de accesibilidad) y verifiquen que cada una sea un requisito escrito, medible y transmitido al diseño como tal, no una suposición, porque retrofitear un atributo de calidad tras la aceptación es donde presupuestos y plazos mueren en silencio.
¿Qué grado de formalidad corresponde a cada sistema que gestionamos, y se elige por riesgo o por costumbre? Una gran organización suele operar un abanico de sistemas, desde una herramienta interna desechable hasta una plataforma regulada que afecta a vidas, y aplicar un mismo ceremonial a todos ellos o sepulta el trabajo de bajo riesgo en papeleo o deja el de alto riesgo insuficientemente especificado. La tensión es entre la auditabilidad y la base de aceptación firme de la especificación formal anticipada y la retroalimentación rápida y la reducción de desperdicio de un backlog en evolución, y la respuesta honesta para la mayoría de las empresas es una combinación deliberada: formalizar y trazar las obligaciones estables y de alta confianza, mientras se elabora el comportamiento del producto de forma iterativa. Aporte un breve inventario de los sistemas ordenado por consecuencia del fallo, exposición regulatoria y ritmo de cambio, y para cada uno nombre la formalidad que se emplea en realidad frente a la que el riesgo exige. Para un programa gubernamental anclado en un pliego de condiciones y en un estándar como el IEEE 29148, la formalidad está en parte dictada por el contrato, de modo que la discusión se centra en dónde es posible superponer la elaboración ágil sin romper la trazabilidad de la que depende la auditoría.
¿Puede verificarse cada requisito del sistema de mayor riesgo, y lleva cada uno sus criterios de aceptación redactados en el momento de su creación? Un requisito que no puede verificarse no es un requisito, es un deseo, y términos vagos como «rápido», «seguro» o «intuitivo» pasan la revisión precisamente porque nadie puede demostrar que no se cumplen. Para un equipo grande esto se paga dos veces: los requisitos no verificables generan disputas de alcance en la aceptación y hacen imposible saber cuándo una funcionalidad está verdaderamente terminada. La consideración contraria es la velocidad, pues adjuntar un criterio medible y un método de verificación a cada requisito es más lento al principio que redactar prosa, pero es la defensa más barata frente al rework más caro a última hora. Aporte una muestra de requisitos recientes y sométalos a una prueba sencilla: ¿es atómico, es medible y nombra cómo se verificará? En contextos regulados y de la administración pública, amplíe la prueba a la evidencia: un requisito sin evidencia de aceptación trazada y superada no se considera entregado, por mucho que el software parezca cumplirlo, de modo que los criterios de aceptación son el germen del registro de cumplimiento que habrá que producir eventualmente.

Perspectiva por sector

Startup. Con un equipo diminuto y poca holgura de tiempo, mantenga los requisitos lo más ligeros que la situación permita: historias de usuario con criterios de aceptación en un backlog compartido, no un documento de especificación. La disciplina que rinde frutos incluso a esta escala es hablar con usuarios reales antes de construir y registrar el origen y la justificación de cada historia, de modo que la semana que se habría perdido construyendo la funcionalidad equivocada sea la semana que se salva. Omítase la trazabilidad formal, pero nunca la conversación que revela cuál es la necesidad real.

Pyme. Es probable que no exista un analista de negocio ni un especialista en requisitos, así que la labor recae en quien está más cerca del cliente, y la pregunta comprar o desarrollar domina. Formule los requisitos como una lista breve y priorizada de los resultados que se necesitan, y úsela para evaluar herramientas de mercado en lugar de especificar un desarrollo a medida. Sea estricto al separar la necesidad subyacente de la lista de funciones de un proveedor, porque un requisito redactado como «necesitamos el producto X» clausura de antemano opciones más baratas que habrían satisfecho la necesidad real.

Empresa grande. La escala convierte los requisitos en el contrato que permite a muchos equipos construir un solo sistema coherente, de modo que la prioridad es un proceso estándar aplicado de forma consistente: categorías definidas, trazabilidad bidireccional de la necesidad a la prueba, una única fuente autorizada y gestión del cambio controlada con baselines. Separe explícitamente los requisitos de negocio, de usuario y de sistema, y transmita los requisitos no funcionales a la arquitectura como conductores, para que el alcance y las obligaciones de calidad no se dispersen entre equipos. Combine la especificación formal de las obligaciones estables y de alta confianza con la elaboración ágil del comportamiento del producto, y gobierne ese equilibrio por el riesgo, no por la preferencia de un solo equipo.

Administración pública. Las normas de contratación pública a menudo construyen el contrato completo en torno a una especificación de requisitos, con frecuencia estructurada según un estándar como el IEEE 29148, de modo que la precisión y la completitud son contractuales, no opcionales. Mantenga una matriz de trazabilidad de requisitos que enlace cada requisito con elementos de diseño, casos de prueba y evidencia de aceptación, porque el pago al proveedor, la auditoría y la autorización de operación (la aprobación formal para poner el sistema en producción) dependen de la cobertura demostrada. La transparencia y la responsabilidad pública elevan la barra aún más: las obligaciones impuestas de accesibilidad, privacidad y conservación de registros deben aparecer cada una como un requisito explícito y verificable, y un requisito sin evidencia de aceptación trazada y superada simplemente no se considera entregado, por mucho que el software parezca cumplirlo.

Ejemplos

Startup. Una startup de cuatro personas que desarrolla una aplicación de programación captura los requisitos como historias de usuario con criterios de aceptación en un backlog compartido, no como una especificación formal. Antes de escribir la funcionalidad de sincronización de calendarios, la fundadora dedica una tarde a conversar con cinco clientes potenciales y descubre que la necesidad real es evitar dobles reservas entre dos herramientas, no la sincronización que habían supuesto. Esa única conversación reencuadra la historia y ahorra una semana de trabajo en lo equivocado. Incluso a esta escala, registran el origen y la justificación de cada historia, de modo que, cuando las prioridades cambien, puedan descartar o reestructurar el alcance sin volver a litigar por qué existía.

Empresa grande. Una banca multinacional sustituye su plataforma de concesión de préstamos. El equipo de requisitos separa los requisitos de negocio (reducir el tiempo de aprobación, cumplir la normativa de préstamos), los requisitos de usuario (los oficiales de crédito necesitan comparar ofertas en una sola vista) y los requisitos de sistema (la plataforma debe integrarse con tres sistemas de núcleo). Los requisitos no funcionales (respuesta en menos de un segundo para consultas frecuentes, disponibilidad del 99,95 %, cifrado de datos personales) se recogen de forma explícita y se transmiten a la arquitectura (capítulo 3.1) como conductores. Cada requisito se traza a través del backlog hasta las pruebas de aceptación automatizadas. Así, cuando un regulador pregunta cómo se aplica una norma concreta de concesión de préstamos, el equipo solo tiene que seguir la trazabilidad desde la norma hasta la prueba que la verifica.

Administración pública. Un organismo nacional adjudica un sistema de elegibilidad de prestaciones mediante una licitación formal. El contrato se ancla en una especificación de requisitos estructurada según el IEEE 29148, que abarca las reglas funcionales de elegibilidad, la conformidad obligatoria de accesibilidad, las restricciones de privacidad y conservación de registros, y los controles de seguridad. Una matriz de trazabilidad de requisitos vincula cada requisito con elementos de diseño, casos de prueba y evidencia de aceptación. El pago al proveedor y la autorización de operación dependen de la cobertura demostrada. Un requisito sin evidencia de aceptación trazada y superada no se considera entregado, por mucho que el software parezca cumplirlo.

Argumento de negocio: motivaciones, rentabilidad y coste total

El argumento económico de la ingeniería de requisitos se apoya en el coste de corregir defectos a última hora. Los estudios del sector constatan de forma consistente que los defectos de requisitos figuran entre las causas más frecuentes y más costosas del fracaso de un proyecto, y que el coste de reparar un defecto se multiplica en órdenes de magnitud desde la fase de requisitos hasta la producción. Así, el dinero invertido en aclarar y validar requisitos es, en realidad, palanca: una inversión modesta al principio evita construir, probar y operar lo equivocado.

El coste total de propiedad de los requisitos incluye el esfuerzo continuo de obtención, especificación, herramienta y gestión del cambio a lo largo de toda la vida del sistema; no es un coste de una sola vez. Frente a él se opone el coste de unos requisitos deficientes: rework, disputas de alcance, desbordamiento de plazos, fracasos en la aceptación, penalizaciones contractuales y, en entornos regulados, multas o pérdida de autorización. Para la dirección, enmarque la madurez en requisitos como reducción de riesgo y predictibilidad. Trazable la volatilidad de requisitos, el origen de los defectos y la proporción de trabajo entregado trazable a una necesidad validada, y vincúlelos con la previsión de la gestión de proyectos (capítulo 10.6). El retorno no se manifiesta como una funcionalidad. Se manifiesta como los fallos y el rework que nunca llegaron a ocurrir.

Antipatrrones y errores frecuentes

Soluciones disfrazadas de requisitos: especificar una tecnología elegida o una disposición de pantalla en lugar de la necesidad subyacente, cerrando la puerta a mejores opciones.
Lenguaje ambiguo: «rápido», «seguro», «intuitivo» sin criterio medible, lo que hace que el requisito sea in verificable.
Sobrediseño: capturar requisitos que ninguna parte interesada necesita realmente, inflando el alcance y el coste.
Requisitos no funcionales ausentes: descubrir obligaciones de rendimiento, seguridad o accesibilidad solo después de que la arquitectura ya está fijada.
Dispersión de requisitos: la verdad repartida entre correos, tickets y diapositivas, sin fuente autorizada.
Cambio congelado o descontrolado: o bien rechazar todo cambio o bien aceptar cada uno sin evaluar su impacto.
Ausencia de trazabilidad: incapacidad de responder a qué afecta un cambio o por qué existe una funcionalidad, letal en sistemas auditados.
Parálisis por análisis: una especificación interminable que retrasa el aprendizaje del software funcional.
Partes interesadas ignoradas: operadores, auditores y personas afectadas no usuarias excluidas hasta la aceptación.

Modelo de madurez

Nivel 1, Iniciar. Los requisitos son implícitos o verbales, capturados de forma inconsistente y reactiva. Las disputas de alcance y el rework son habituales; no hay trazabilidad, no hay criterios de aceptación y no hay proceso definido.
Nivel 2, Desarrollar. Algunos equipos documentan y siguen los requisitos por proyecto, con una priorización básica y una gestión de cambios ad hoc. Las prácticas existen pero varían según el equipo y la persona, de modo que las categorías, la formalidad y la calidad son inconsistentes en toda la organización.
Nivel 3, Estandarizar. Un proceso estándar de requisitos está documentado y se aplica en toda la organización: categorías definidas, prácticas de obtención y validación, criterios de aceptación adjuntos en el momento de la redacción, una única fuente autorizada y trazabilidad bidireccional de la necesidad a la prueba, adaptada de forma consistente al contexto ágil o planificado.
Nivel 4, Gestionar. El proceso se mide y controla con datos. La volatilidad de requisitos, el origen de los defectos, la cobertura de trazabilidad y la proporción de trabajo entregado trazable a una necesidad validada se siguen en función de baselines; la trazabilidad se extiende a la evidencia de aceptación y al cumplimiento; y las métricas de requisitos alimentan la previsión de la gestión de proyectos (capítulo 10.6), de modo que las decisiones sobre cambios y calidad se sustentan en evidencia, no en opinión.
Nivel 5, Orquestar. La práctica de requisitos mejora de forma continua y se integra en toda la organización. La formalidad se ajusta de forma adaptativa según el riesgo y el resultado, la herramienta de obtención y trazabilidad se conecta con la exploración, la arquitectura y la entrega, y la organización emplea su propio historial de mediciones para prevenir defectos de requisitos recurrentes antes de que alcancen el código.

Ideas para la reflexión

¿Cómo distinguir un requisito genuino de una solución prematura cuando una parte interesada senior lo enuncia como solución?
¿Qué grado de formalidad en requisitos corresponde al sistema de mayor riesgo frente al de menor riesgo, y quién lo decide?
¿Cómo mantener la trazabilidad bidireccional al día en un backlog ágil en rápida evolución sin que se convierta en un lastre burocrático?
¿Qué requisitos no funcionales se descubren con más retraso en su organización y por qué?
En un programa regulado, ¿qué constituye una evidencia de aceptación suficiente de que un requisito se ha cumplido?
¿Cómo deberían cambiar las herramientas de obtención y especificación asistidas por IA su práctica de requisitos, y qué nuevos riesgos introducen?

Puntos clave

Los requisitos declaran necesidades y restricciones, no soluciones; deben ser necesarios, inequívocos, verificables y trazables.
Separen los requisitos funcionales, no funcionales y de restricción, y los niveles de negocio, usuario y sistema.
Obténgalos de partes interesadas reales, analícelos y priorícelos, especifíquenlos con la formalidad adecuada, valídelos antes de construir y gestionen el cambio.
La trazabilidad bidireccional, de la necesidad a la evidencia de aceptación, es la columna vertebral de la rendición de cuentas, sobre todo en entornos regulados.
Los contextos ágiles y planificados comparten las mismas actividades; difieren en el momento, la formalidad y los artefactos, de modo que elige según el riesgo.
El coste de unos requisitos deficientes se paga a última hora y multiplicado; invertir al principio es palanca contra el rework y el fracaso en la aceptación.

Referencias y lecturas complementarias

IEEE y ISO/IEC, Guía del Cuerpo de Conocimiento de la Ingeniería de Software (SWEBOK), área de conocimiento de Requisitos de Software
Karl Wiegers y Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Ingeniería de sistemas y de software: Procesos del ciclo de vida: Ingeniería de requisitos
Suzanne Robertson y James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (capítulos sobre ingeniería de requisitos)