Todo sistema de software trabaja con datos. Los registra, consulta, modifica, valida, calcula, transforma, muestra, envía o conserva. Por eso, además de definir funciones, es necesario identificar qué datos requiere el sistema.
Un requerimiento funcional como "registrar cliente" está incompleto si no se sabe qué datos del cliente deben registrarse, cuáles son obligatorios, qué formato deben tener, quién puede modificarlos y cómo se protegen.
En este tema estudiaremos cómo analizar los datos necesarios para el sistema y cómo documentarlos dentro del trabajo de requerimientos.
Los datos requeridos son la información que el sistema necesita para cumplir sus funciones, aplicar reglas de negocio, generar salidas, integrarse con otros sistemas y sostener la operación.
Ejemplos de datos requeridos:
Los datos están directamente relacionados con los requerimientos funcionales. Cada función suele necesitar datos de entrada, producir datos de salida o modificar datos existentes.
| Función | Datos necesarios | Resultado |
|---|---|---|
| Registrar cliente | Nombre, documento, correo, teléfono, domicilio. | Cliente creado con identificador único. |
| Confirmar pedido | Cliente, productos, cantidades, forma de pago, stock. | Pedido confirmado y stock reservado. |
| Generar reporte | Período, ventas, vendedores, importes, estados. | Reporte de ventas filtrado y totalizado. |
| Enviar notificación | Destinatario, canal, asunto, mensaje, evento disparador. | Notificación enviada o error registrado. |
Una forma inicial de organizar datos es identificar entidades y atributos. Una entidad representa algo importante del dominio; un atributo describe una característica de esa entidad.
Ejemplos:
| Entidad | Atributos posibles |
|---|---|
| Cliente | Nombre, documento, correo, teléfono, estado, domicilio. |
| Producto | Código, nombre, categoría, precio, stock, estado. |
| Pedido | Número, fecha, cliente, estado, total, vendedor. |
| Reclamo | Número, cliente, motivo, descripción, prioridad, estado, responsable. |
Esta organización ayuda a detectar información faltante, duplicada o ambigua.
No todos los datos tienen la misma importancia. Algunos son obligatorios para que una operación sea válida; otros pueden ser opcionales.
Ejemplo para registrar un cliente:
Definir obligatoriedad evita formularios incompletos y ayuda a diseñar validaciones. También evita pedir datos innecesarios que aumentan esfuerzo de carga y riesgos de privacidad.
Los datos deben tener formato y reglas de validación cuando corresponda. Esto mejora la calidad de información y evita errores posteriores.
| Dato | Validación posible |
|---|---|
| Correo electrónico | Debe tener formato válido y no superar la longitud máxima definida. |
| Fecha de inicio | No puede ser posterior a la fecha de finalización. |
| Cantidad | Debe ser un número entero mayor que cero. |
| Precio | Debe ser mayor o igual a cero y expresarse con dos decimales. |
| Documento | No debe repetirse para clientes activos. |
Para cada dato importante conviene conocer su origen. Un dato puede ser ingresado por un usuario, importado desde otro sistema, calculado automáticamente, recibido desde un dispositivo o definido por una configuración.
Ejemplos:
Conocer el origen ayuda a definir responsabilidades, validaciones y dependencias.
El dueño del dato es el área, sistema o responsable autorizado para definir, modificar o validar ese dato. Este concepto es importante cuando varios sistemas comparten información.
Por ejemplo, si el sistema de ventas consulta el saldo de un cliente, pero el saldo lo administra el sistema contable, ventas no debería modificarlo directamente. En ese caso, el sistema contable es la fuente autorizada.
Definir dueño del dato evita inconsistencias y conflictos entre sistemas o áreas.
La calidad de datos se refiere a qué tan correctos, completos, actualizados, consistentes y útiles son los datos para el sistema.
Problemas frecuentes de calidad de datos:
Si el sistema depende de datos de mala calidad, los requerimientos deben considerar limpieza, validación, revisión o migración.
Algunos datos no se ingresan directamente, sino que se calculan a partir de otros. Estos datos derivados deben especificarse con reglas claras.
Ejemplos:
Los datos calculados deben indicar fórmula, condiciones, redondeos, excepciones y fuente de valores usados.
Muchas entidades tienen estados que representan su situación dentro de un proceso. Definir estados es importante porque afecta permisos, reglas y acciones disponibles.
Ejemplo para un reclamo:
Además de listar estados, conviene definir quién puede cambiar de un estado a otro y bajo qué condiciones.
El ciclo de vida de un dato describe qué ocurre desde que se crea hasta que se archiva o elimina.
Preguntas útiles:
Estas decisiones pueden convertirse en requerimientos funcionales, no funcionales o restricciones.
Algunos datos requieren mayor protección: datos personales, información financiera, credenciales, datos de salud, ubicaciones, documentos o información confidencial de negocio.
Para estos datos conviene definir:
La privacidad debe formar parte del análisis de requerimientos desde el inicio.
Muchos sistemas deben generar reportes, indicadores o consultas para la toma de decisiones. Para eso, los datos deben capturarse con suficiente calidad y detalle.
Ejemplo: si se quiere reportar reclamos por canal de ingreso, el sistema debe registrar ese canal en cada reclamo. Si se quiere medir tiempo de resolución, el sistema debe guardar fechas y horas de apertura, asignación, resolución y cierre.
Por eso, los reportes esperados ayudan a descubrir datos que deben almacenarse aunque no sean visibles en una función principal.
Cuando se reemplaza o complementa un sistema existente, puede ser necesario migrar datos. La migración debe considerarse como parte de los requerimientos o restricciones del proyecto.
Aspectos a definir:
La migración suele ser más compleja de lo que parece y debe analizarse temprano.
Un diccionario de datos es un artefacto que documenta los datos importantes del sistema. Puede ser simple o detallado según el proyecto.
Puede incluir:
El diccionario de datos ayuda a reducir ambigüedades entre analistas, usuarios, desarrolladores y testers.
| Dato | Descripción | Validación | Obligatorio |
|---|---|---|---|
| Documento del cliente | Identificación oficial del cliente. | No debe repetirse para clientes activos. | Sí |
| Correo electrónico | Dirección usada para notificaciones. | Debe tener formato válido. | Sí |
| Estado del reclamo | Situación actual del reclamo. | Debe ser abierto, asignado, en análisis, resuelto, cerrado o cancelado. | Sí |
| Fecha de cierre | Fecha en que se cerró definitivamente el reclamo. | Solo puede existir si el reclamo está cerrado. | No |
Cuando el sistema intercambia datos con otros sistemas, debe existir claridad sobre formato, significado y responsabilidad de cada dato.
Por ejemplo, si un sistema externo envía "estado de pago", debe definirse qué valores posibles existen, qué significa cada uno, cuándo se actualiza y qué debe hacer nuestro sistema ante cada valor.
Las interfaces externas y los datos requeridos deben analizarse juntos para evitar inconsistencias de interpretación.
Al definir datos requeridos, suelen aparecer estos errores:
Algunas buenas prácticas son:
Los datos son una parte esencial de los requerimientos de software. No basta con definir acciones del sistema; también hay que aclarar qué información se necesita, cómo se obtiene, cómo se valida, quién la usa y cómo se protege.
Un buen análisis de datos mejora la precisión de los requerimientos funcionales, facilita integraciones, reduce errores y permite construir reportes y decisiones confiables.
En el próximo tema comenzaremos con la elicitación de requerimientos, estudiando su propósito y cómo prepararse para obtener información útil de interesados, documentos, procesos y sistemas existentes.