Los requisitos pierden su razón de ser durante el proyecto. Ese es el verdadero problema.
Surgen en un workshop, terminan en una lista, pasan al sistema de tickets – y, con el tiempo, nadie recuerda qué necesidad de negocio había detrás. TAOM mantiene la conexión con el Process Step, el Rol y el Sistema del que se originó el Requisito.
Refinamiento
Un Requisito no se escribe simplemente, se refina
Entre «necesitamos una validación» y un campo implementado hay ocho etapas. Los conflictos en un proyecto rara vez surgen por el contenido en sí, sino cuando no está claro quién es responsable de la siguiente etapa.
El valor
La pregunta que surge dos años después
En algún momento alguien pregunta por qué existe un determinado campo, si una validación sigue siendo necesaria o qué ocurre si se elimina una ampliación.
A qué está conectado un Requisito
Seis relaciones que se mantienen
Proceso
En qué proceso se necesita.
Actividad
En qué Process Step concreto surgió.
Rol
Quién lo necesita y quién es responsable.
Sistema
Qué Aplicación debe cumplirlo.
Objetivo de Negocio
A qué objetivo contribuye.
Contexto de Desarrollo
Qué se construye a partir de él – hasta su clasificación WRICEF.
De dónde proceden
La mayoría de los Requisitos comienzan como hallazgos de Process Discovery
Lo que se detecta durante un workshop
- 01Funcionalidades de Sistema ausentesLo que el Sistema no puede hacer y que, por tanto, requiere una solución alternativa.
- 02WorkaroundsLa hoja de cálculo junto al Sistema sin la cual el proceso no funciona.
- 03Brechas de IntegraciónDatos que deben transferirse manualmente.
- 04Obligaciones y EvidenciasLo que alguien cumple adicionalmente sin que quede formalmente documentado.
- 05Problemas de DatosCampos en los que nadie confía plenamente.
Sin ruptura de contexto
Estos hallazgos surgen durante Process Discovery – y permanecen vinculados al Process Step en el que fueron identificados.
Discovery → Hallazgo → Requisito → Delivery se convierte así en un único flujo conectado y no en una transferencia entre dos herramientas.
Qué se genera a partir de ello
Trazabilidad hasta la Aceptación
- 01Requisitos de NegocioLo que necesita el negocio, expresado en el lenguaje del negocio.
- 02Requisitos FuncionalesLo que debe proporcionar el Sistema para satisfacer esa necesidad.
- 03Objetos WRICEFWorkflow, Report, Interface, Conversion, Enhancement, Form.
- 04Especificaciones Funcionales y TécnicasComportamiento e implementación, ambos vinculados al mismo contexto de origen.
- 05User StoriesPara equipos que trabajan de esta forma – manteniendo el mismo origen.
- 06Criterios de AceptaciónLos criterios utilizados para determinar si el Requisito se ha cumplido.
Casos de uso típicos
Dónde se utiliza
- 01Iniciativas de TransformaciónCuando surgen muchos Requisitos simultáneamente y pierden rápidamente su contexto.
- 02Seguimiento de Fit-to-StandardCada Gap identificado se convierte en un Requisito con su justificación de negocio.
- 03Sustitución de Sistemas LegacyDeterminar qué particularidades existentes son realmente necesarias para el negocio y cuáles existen únicamente por razones históricas.
- 04Preparación de AuditoríasDemostrar por qué existe un Control y dónde se aplica.
- 05Transferencia a DeliveryEspecificaciones que mantienen la justificación de negocio hasta la implementación.
- 06Pruebas y AceptaciónSe valida frente a la necesidad original, no únicamente frente al documento de especificación.
Empezar
Con un Requisito que actualmente genera discusión
Tome uno para el que ya nadie pueda explicar con precisión por qué está formulado de esa manera. Conéctelo al Process Step del que surgió – y compruebe cuánto más clara se vuelve la discusión.