Checklist - Definición Funcional de Detalle Hecho N/A

Pantallas (nuevas o modificaciones)

Brindar Maqueta o Screenshot
Prestar especial atención en el diseño si la pantalla no es para escritorio (por ejemplo, para Handheld o celular).
Nombrar la pantalla, definir su Acceso desde el menú
Explicitar Controles Especiales de Acceso que deban hacerse (por fuera del módulo de perfiles y usuarios que ya tenga el sistema)
Si tiene Filtros
Valores DEFAULT apenas entra el usuario
Aclarar filtros opcionales y obligatorios
Si hay combos de selección: Definir cómo se cargan los posibles valores del combo ¿Se cargan “en cascada”?
Si hay selectores de fecha: ¿Hay límites en el DESDE, en el HASTA o en el RANGO?
Definir si el dato de cada filtro, debería también estar en la grilla
Si tiene Grillas
Definir los títulos de las columnas
Considerar el ancho de la grilla según los datos que irán adentro. ¿Se debe forzar el ancho de alguna columna?
Pensar el tipo de dato de cada columna (por ejemplo: decimales, formatos de fechas, formatos de moneas, etc.)
Definir cuándo se carga la grilla (apenas se entra a la pantalla o luego de apretar un botón? ¿Aplica el refresco automático?)
Si tiene Acciones in grid
Definir el nombre de la acción (a poner en un tooltip por ejemplo)
Definir en dónde van en la grilla (entre qué columnas)
Íconos: entregar los íconos junto con el desarrollo. Crear los íconos con el equipo de diseño.
¿Las acciones están siempre disponibles o dependen de alguna condición del registro de la grilla? (se "grisan")
¿Se debe poner un "Tildar todos"?
¿Tendrá paginado o será de continuo?
¿Tendrá abajo una sección de totales?
Tener en cuenta el nivel de volumen que cargará la grilla en ambiente operativo. Afectar al diseño en base a ello.
Si tiene Formularios
Definir auto-explicativo el título de cada dato solicitado
Si hay combos de selección: Definir cómo se cargan los posibles valores del combo ¿Se cargan “en cascada”?
Definir validaciones o controles que haya que hacerle a cada campo (Tipos de dato, fechas con restricciones, etc)
Definir qué validaciones se hacen “al final” con el botón de aceptar
Definir qué validaciones se hacen “en el lugar” apenas completado el campo

Definir el mensaje de error debe dar la validación (solo para aquellas que consideres funcionalmente importantes)
¿Hay datos que puedan ocultarse/deshabilitarse en función de lo que se elige en otros o por Configuraciones?
(ejemplo, en un viaje aparece el campo de “segunda patente” si el vehículo es un tractor con semi, caso contrario no se muestra.)
Si tiene Botones de Accion (sean in grid o no)
Definir con claridad el proceso que se debe disparar
Definir qué debe pasar cuando la acción es exitosa (mensaje al usuario, limpieza de la pantalla, re-direccionamiento a otra pantalla, etc.)
Definir si vale la pena pedir confirmación del usuario (procesos irreversibles o complejos de revertir)
Si hay Validaciones que hacer
Chequeo de que ciertos datos en la BBDD sigan siendo iguales a cuando se cargó la pantalla (controles de simultaneidad), o sigan estando en
condiciones válidas.
Chequeo de que los valores de formularios sean válidos.
Chequeo de que los registros tildados de una grilla cumplan las condiciones necesarias.

Definir el mensaje de error debe dar la validación (solo para aquellas que consideres funcionalmente importantes)
Si hay Grabaciones que hacer
Definir qué tablas se graban, con qué datos en cada campo.
¿Qué pasa si alguna grabación falla? (por ejemplo, por primary key repetida)

Reportes (PDF, Excel, archivos de Texto)

Brindar un layout del reporte (maqueta o ejemplo excel)
Definir los nombres de las columnas (en excel puede ser más significativo)
Definir el formato especiales de los datos (fechas, numeros, decimales, etc.)
Definir el nombre del archivo a generar (por ejeplo, AAAA-MM-DD-USUARIO-ReporteX)
Estructura de Datos (tablas nuevas o modificaciones)
Brindar la Grilla de Definición de cada Tabla
Aclarar si hay datos “relacionados” (por ejemplo, el campo de artículo tiene que ser un código de artículo del maestro de artículos)
¿Está claro el uso de esta nueva tabla?
¿Cuándo se graba?
¿Cuándo se modifica?
¿Cuándo se borra?
¿Cuándo se consulta? (para tablas de alto volumen ver índices con Desarrollo en la reunión de definición)
 Además de usarla este nuevo desarrollo, ¿No habría que adaptar desarrollos pre-existentes?
¿Cuántos registros se insertarán por día?
¿Requerirá un vuelco a histórico por el volumen? ¿Con qué condiciones se hace éste vuelco?

Casos de Uso Sugeridos

Definir casos con casuísticas específicas del cliente que solicita el desarrollo
Definir casos de volumen realista, acordes al cliente que solicita el desarrollo
Brindar alguna facilidad para que las pruebas sean más certeras (de ser posible)
Base de datos con escenarios específicos ya creados
Coordinar pruebas en conjunto con el desarrollador antes de la entrega (UAT, user acceptance testing, o “demo pre-entrega”)

Para el caso de Interfaces

Definir claramente el INPUT que va a recibir la interfaz
Archivo, lectura de tablas, consumo de WS
Definir claramente el OUTPUT que va a recibir la interfaz
Archivo, lectura de tablas, consumo de WS
Definir claramente el MAPEO de los datos (relación entre el input y el output)
Si se está interactuando vía Web Service: Proveer documentación y accesos de TEST para el WS en cuestión.
Definir configuraciones necesarias en el archivo .config
Por ejemplo Listado que definan qué procesar (códigos de cliente, de empresas, de CD, tipos de documento).
Definir VALIDACIONES
Condiciones que debe cumplir el input para poder procesarse
Condiciones que debe cumplir el output para poder procesarse
Mensaje de LOG que debe dar en cada caso y su severidad (o grupo destinatario)
Definir aquí el grupo destinatario o severidad (NOVEDADES, USUARIO 1, USUARIO 2, SOPORTE 1, SOPORTE 2).

Para el caso de Tercerizar el desarrollo con un proveedor exerno

Asegurarse de incluír TODOS los Casos de Uso que vas a exigirle aprobar al proveedor para darle el OK del desarrollo.
Asegurate de que reciba como base de desarrollo la versión correcta/última del sistema (fuentes y de base de datos).
Agrega el Anexo técnico acorde a la tecnología del proyecto (ASP.NET, Android, GeneXus).
Darle lineamientos claros y explícitos al desarrollador sobre Aspectos Estéticos del desarrollo solicitado.
Pasarle los íconos a utilizar
Establecer colores o pantallas ya existentes del sistema como referencia para tomar la estética.
Si se está utilizando una suite (DevExpress, K2B Tools): Especificar cuáles componentes debe utilizar
Analizar si vale la pena separar el entregable en “partes” o Sprints intermedios. Aclarar que parte será cada Sprint.