19. Análisis de documentos, sistemas existentes y normativa

19.1 Introducción

La elicitación de requerimientos no depende solo de conversar con personas. También se puede obtener información valiosa analizando documentos, sistemas existentes y normativa.

Estos elementos muestran cómo trabaja la organización, qué reglas aplica, qué datos usa, qué reportes necesita, qué problemas existen y qué restricciones deben respetarse.

Analizar estas fuentes permite llegar mejor preparado a entrevistas y talleres, además de validar o contrastar lo que dicen los interesados.

19.2 ¿Por qué analizar documentos?

Los documentos existentes pueden contener información que los usuarios no recuerdan mencionar o que consideran obvia. También permiten conocer lenguaje, reglas, formatos y procesos de la organización.

El análisis documental ayuda a descubrir:

  • Datos usados por el negocio.
  • Reglas y procedimientos.
  • Estados de procesos.
  • Roles y responsabilidades.
  • Restricciones legales o internas.
  • Reportes y salidas esperadas.
  • Excepciones documentadas.
  • Información duplicada o inconsistente.

19.3 Tipos de documentos útiles

Distintos documentos pueden aportar distintos tipos de información.

Documento Información que puede aportar
Formularios Datos requeridos, campos obligatorios, validaciones y flujos de aprobación.
Reportes Indicadores, filtros, agrupaciones, datos calculados y necesidades de decisión.
Procedimientos Pasos, responsables, reglas, entradas, salidas y controles.
Manuales de usuario Funciones actuales, términos del dominio y formas de operación.
Contratos Obligaciones, plazos, niveles de servicio y responsabilidades.
Normas internas Políticas, permisos, auditoría y restricciones organizacionales.
Incidentes o reclamos Problemas frecuentes, fallas del sistema actual y oportunidades de mejora.

19.4 Análisis de formularios

Los formularios muestran qué datos se solicitan y cómo se estructuran las operaciones actuales. Pueden ser formularios en papel, planillas, pantallas de sistemas o archivos digitales.

Al revisar un formulario conviene observar:

  • Campos solicitados.
  • Campos obligatorios y opcionales.
  • Formato de los datos.
  • Firmas o aprobaciones requeridas.
  • Secciones que se completan en distintos momentos.
  • Notas, aclaraciones o instrucciones.
  • Datos que se repiten en otros formularios.

Un formulario no debe copiarse automáticamente al nuevo sistema, pero puede revelar información necesaria.

19.5 Análisis de reportes

Los reportes muestran qué información necesita la organización para controlar, decidir o cumplir obligaciones.

Al analizar reportes conviene preguntar:

  • ¿Quién usa el reporte?
  • ¿Para qué decisión o control se usa?
  • ¿Con qué frecuencia se genera?
  • ¿Qué filtros necesita?
  • ¿Qué datos y cálculos contiene?
  • ¿De dónde provienen esos datos?
  • ¿Qué problemas tiene el reporte actual?

Los reportes también ayudan a descubrir datos que deben capturarse desde el inicio del proceso.

19.6 Análisis de procedimientos

Los procedimientos describen cómo debería realizarse una actividad. Pueden incluir pasos, responsables, controles y excepciones.

Al revisarlos conviene identificar:

  • Inicio y fin del proceso.
  • Roles participantes.
  • Datos de entrada y salida.
  • Decisiones y condiciones.
  • Reglas de negocio.
  • Controles y aprobaciones.
  • Excepciones documentadas.

Es importante recordar que el procedimiento escrito puede diferir de la práctica real, por lo que debe validarse con usuarios y observación.

19.7 Sistemas existentes

Cuando ya existe un sistema, su análisis puede revelar funciones, datos, integraciones, reglas y problemas. No se trata de copiarlo sin pensar, sino de aprender de él.

Un sistema existente puede mostrar:

  • Funciones usadas actualmente.
  • Datos almacenados.
  • Flujos de trabajo.
  • Permisos y perfiles.
  • Reportes.
  • Integraciones con otros sistemas.
  • Limitaciones y errores frecuentes.
  • Funcionalidades que ya no se usan.

19.8 Sistemas legados

Un sistema legado es un sistema existente que sigue siendo importante para la organización, aunque pueda tener tecnología antigua, documentación insuficiente o limitaciones de mantenimiento.

Al analizar sistemas legados conviene prestar atención a:

  • Datos que deben migrarse.
  • Reglas ocultas en el comportamiento del sistema.
  • Procesos que dependen de funciones antiguas.
  • Integraciones no documentadas.
  • Usuarios que conocen atajos o excepciones.
  • Limitaciones que el nuevo sistema debe superar.

Muchas reglas importantes están "dentro" del sistema legado y no en documentos formales.

19.9 Revisión de pantallas existentes

Las pantallas de un sistema actual pueden ayudar a identificar datos, acciones y flujos. Sin embargo, no deben asumirse como el diseño ideal para el nuevo sistema.

Al revisar pantallas conviene anotar:

  • Qué tareas permite realizar.
  • Qué campos usa.
  • Qué acciones están disponibles.
  • Qué validaciones muestra.
  • Qué mensajes de error aparecen.
  • Qué pasos resultan confusos para usuarios.
  • Qué información falta o sobra.

El objetivo es entender la operación actual, no replicar cada elemento visual.

19.10 Análisis de bases de datos y archivos

Cuando es posible, revisar bases de datos, archivos o planillas existentes ayuda a conocer datos reales y problemas de calidad.

Aspectos a observar:

  • Tablas o listas principales.
  • Campos disponibles.
  • Valores repetidos o inconsistentes.
  • Datos obligatorios que aparecen vacíos.
  • Códigos o estados usados.
  • Relaciones entre datos.
  • Volumen de información.
  • Datos históricos que podrían migrarse.

Este análisis debe respetar políticas de privacidad y acceso a datos.

19.11 Normativa

La normativa puede imponer restricciones y requerimientos obligatorios. Puede provenir de leyes, regulaciones sectoriales, normas técnicas, contratos, políticas internas o auditorías.

Al analizar normativa conviene identificar:

  • Obligaciones concretas.
  • Datos que deben conservarse.
  • Plazos de conservación o eliminación.
  • Requisitos de privacidad y seguridad.
  • Formatos obligatorios.
  • Reportes exigidos.
  • Responsables de cumplimiento.
  • Sanciones o riesgos por incumplimiento.

La interpretación normativa debe validarse con áreas competentes, como legal, auditoría o cumplimiento.

19.12 Contrastar fuentes

Distintas fuentes pueden contradecirse. Un procedimiento puede decir una cosa, un sistema permitir otra y los usuarios hacer una tercera.

Ejemplo:

El procedimiento indica que todo reclamo debe tener prioridad. El sistema actual permite dejar la prioridad vacía. Los usuarios explican que la completan al final porque muchas veces no pueden definirla al registrar el reclamo.

Estas diferencias son valiosas: muestran reglas ambiguas, problemas del proceso o necesidades de rediseño.

19.13 Qué extraer del análisis

Del análisis de documentos, sistemas y normativa pueden surgir distintos insumos:

  • Requerimientos funcionales candidatos.
  • Requerimientos no funcionales.
  • Reglas de negocio.
  • Datos requeridos.
  • Estados y transiciones.
  • Restricciones.
  • Interfaces externas.
  • Reportes.
  • Problemas del sistema actual.
  • Preguntas para entrevistas o talleres.

Estos insumos deben analizarse y validarse antes de convertirse en requerimientos definitivos.

19.14 Ejemplo de análisis documental

Supongamos que se analiza un formulario de solicitud de crédito. El formulario muestra:

  • Datos del solicitante.
  • Ingresos declarados.
  • Monto solicitado.
  • Plazo de pago.
  • Firma del solicitante.
  • Sección de aprobación interna.
  • Observaciones del analista.

De allí pueden surgir requerimientos sobre registro de solicitudes, validación de datos, estados de aprobación, documentos adjuntos, roles autorizados y trazabilidad de decisiones.

19.15 Ejemplo de análisis de sistema existente

Al revisar un sistema de pedidos existente, se descubre que:

  • Hay estados de pedido que no aparecen en la documentación.
  • Los vendedores usan un campo de observaciones para indicar condiciones especiales.
  • Algunos productos se cargan con códigos antiguos.
  • El sistema no valida stock en tiempo real.
  • Los reportes se exportan a planillas para corregir datos manualmente.

Esta información permite identificar problemas, reglas ocultas, datos de mala calidad e integraciones necesarias.

19.16 Documentación desactualizada

No toda documentación existente es confiable. Puede estar incompleta, desactualizada o reflejar cómo debería trabajarse, no cómo se trabaja realmente.

Señales de alerta:

  • Documentos sin fecha o responsable.
  • Procedimientos que mencionan sistemas que ya no se usan.
  • Campos que no aparecen en formularios actuales.
  • Reglas contradichas por usuarios.
  • Reportes que nadie consulta.
  • Normas internas sin aprobación reciente.

La documentación debe tratarse como evidencia, no como verdad absoluta.

19.17 Matriz de hallazgos

Una forma útil de registrar el análisis es crear una matriz de hallazgos.

Fuente Hallazgo Tipo Acción
Formulario de reclamo El campo canal de ingreso es obligatorio. Dato / regla Validar con usuarios si sigue vigente.
Sistema actual Existen estados de reclamo no documentados. Duda / regla oculta Revisar con supervisor de atención.
Normativa interna Los cambios de datos sensibles deben auditarse. Restricción / no funcional Consultar a auditoría.
Reporte mensual Se agrupan reclamos por motivo y zona. Reporte / dato Confirmar origen de zona del cliente.

19.18 Relación con entrevistas y talleres

El análisis de documentos y sistemas no reemplaza entrevistas o talleres. Los complementa.

Puede usarse para:

  • Preparar mejores preguntas.
  • Validar información recibida.
  • Detectar contradicciones.
  • Mostrar ejemplos concretos durante una reunión.
  • Identificar interesados que deben participar.
  • Encontrar datos o reglas que nadie mencionó.

La combinación de fuentes mejora la calidad del entendimiento.

19.19 Errores frecuentes

Al analizar documentos, sistemas y normativa, suelen aparecer estos errores:

  • Copiar el sistema actual sin cuestionarlo.
  • Confiar en documentación desactualizada.
  • No validar hallazgos con interesados.
  • Ignorar planillas o herramientas informales.
  • No revisar reportes existentes.
  • No consultar a legal o auditoría cuando hay normativa.
  • Confundir limitaciones del sistema actual con necesidades reales.
  • No registrar fuente de cada hallazgo.

19.20 Buenas prácticas

Algunas buenas prácticas son:

  • Revisar documentos antes de entrevistar cuando sea posible.
  • Registrar fuente, fecha y responsable de cada documento.
  • Analizar formularios, reportes, procedimientos, incidentes y sistemas actuales.
  • Distinguir evidencia, duda y conclusión.
  • Validar reglas y restricciones con personas autorizadas.
  • No asumir que el sistema actual representa la solución correcta.
  • Usar hallazgos para preparar entrevistas y talleres.
  • Respetar privacidad y permisos al acceder a datos reales.
Los documentos y sistemas existentes muestran pistas importantes, pero siempre deben interpretarse dentro del contexto real de trabajo.

19.21 Qué debes recordar de este tema

  • Los documentos, sistemas existentes y normativa son fuentes importantes de requerimientos.
  • Los formularios muestran datos y validaciones.
  • Los reportes muestran información necesaria para decisiones.
  • Los sistemas actuales revelan funciones, limitaciones, datos e integraciones.
  • La normativa puede imponer restricciones obligatorias.
  • La documentación puede estar desactualizada y debe validarse.
  • Los hallazgos deben contrastarse con entrevistas, talleres u observación.

19.22 Conclusión

El análisis de documentos, sistemas existentes y normativa permite descubrir información valiosa para los requerimientos. Estas fuentes ayudan a entender cómo trabaja la organización, qué datos utiliza, qué reglas aplica y qué restricciones debe respetar.

Sin embargo, ninguna fuente documental debe aceptarse sin análisis crítico. La información debe contrastarse, validarse y relacionarse con necesidades reales.

En el próximo tema estudiaremos prototipos, bocetos y pruebas tempranas de comprensión, técnicas que ayudan a validar ideas y aclarar requerimientos antes de construir la solución definitiva.