Post on 30-Apr-2020
Clase 11 Requerimientos para los Datos y para los reportes
Sonia Rueda
Req del Negocio
Req no Funcionales
Req del Usuario
Req Funcionales
Req para los datos
Captura Análisis Especificación Validación
Los primeros encuentros con los clientes se enfocan a capturar los requerimientos de alto nivel.
Sin embargo, ya en esas primeras sesiones de trabajo aparecen referencias, más o menos explícitas, a los datos.
Requerimientos del Negocio
Requerimientos No Funcionales
Una buena práctica es registrar estas referencias para retomarlas más adelante, sin perder en ese momento el objetivo de concentrarse en los objetivos del negocio, la visión del producto y el alcance del proyecto.
Documento de Visión y Alcance
Requerimientos del Negocio
Requerimientos No Funcionales
El diagrama de conceptos y el diagrama de contexto, especificados en el Documento de Visión y Alcance y acordados con el cliente en las primeras iteraciones, serán más adelante un buen punto de partida para comenzar a concentrarse en los requerimientos para los datos.
Requerimientos del Negocio
Documento de Visión y Alcance
Requerimientos No Funcionales
Requerimientos tácitos
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Requerimientos del Usuario
Requerimientos No Funcionales
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Requerimientos del Usuario
Requerimientos No Funcionales
Modelo de CU
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Modelo de CU
Requerimientos del Usuario
Requerimientos para los Datos
Requerimientos Funcionales
Requerimientos No Funcionales
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Modelo de CU
Requerimientos del Usuario
Requerimientos para los Datos
Requerimientos Funcionales
Requerimientos No Funcionales
SRS
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Modelo de CU
Requerimientos del Usuario
Requerimientos para los Datos
Requerimientos Funcionales
Requerimientos No Funcionales
SRS
Enfoque centrado en el usuario
Requerimientos del Negocio
Documento de Visión y Alcance
Modelo de CU
Requerimientos del Usuario
Requerimientos para los Datos
Requerimientos Funcionales
Requerimientos No Funcionales
SRS
Modelo de Casos de Uso
Documento de Visión y Alcance
Es fundamental lograr la consistencia entre las distintas especificaciones que conforman un modelo.
Un modelo de datos especifica los datos que van a ser almacenados por el sistema en forma más o menos permanente y sus relaciones.
En muchas aplicaciones el modelo de datos tiene un rol protagónico, la mayoría de los requerimientos funcionales se refieren a como procesar y consultar datos.
En otras aplicaciones él rol principal lo tienen los requerimientos funcionales, aunque hay datos de entrada y de salida, las necesidades del usuario están más bien vinculadas al comportamiento.
Un modelo de datos puede especificarse con
diferentes niveles de abstracción.
El primer nivel queda definido durante el
desarrollo de requerimientos.
El modelo se refina luego durante la etapa de
diseño.
Modelo Lógico
Modelo Conceptual
Modelo Físico
Desarrollo de Requerimientos
Diseño
Implementación
Un modelo lógico de datos es una representación
abstracta, no considera restricciones de
implementación.
Un mismo problema puede modelarse de
diferentes maneras y utilizando diferentes
técnicas.
Los modelos lógicos no van a variar demasiado
dependiendo de la técnica.
El Diagrama de Conceptos, el Diagrama de
Contexto y el Diagrama de Casos de Uso
brindan información útil para comenzar a
modelar los datos.
Los sistemas con los cuales el nuevo producto va a interactuar probablemente también brinden información relevante respecto a los datos.
En algunos casos esta situación puede representar una limitación, ya que el nuevo sistema queda condicionado por restricciones de los sistemas con los que interactúa.
La construcción del modelo de datos comenzará representando la estructura estática de los datos compartidos con otros sistemas.
Las sesiones de captura basadas en el análisis
de documentos son una valiosa oportunidad
para identificar requerimientos de datos.
En particular son fuente de requerimientos:
Formularios y Reportes
Capturas de pantallas
Manuales del usuario
Registrar Devolución
Socio
Registrar Nuevo Socio
Actualizar Catálogo
Bibliotecario
Comprobar Estado
Consultar
Suspender Socio
Registrar Préstamo
Renovar Préstamo
Iniciar Sesión
Notificar retrasos
Dar de Baja Socio
Director
Taller Mecánico
Asignar
Vehículos
Completar
Formulario
del servicio
Capataz
Mecánico
Ingresar
Vehículo
Iniciar
Formulario
Autorizar
Salida
Registrar
Vehículo
Cajero
Registrar
Factura
Notificar
OK
Registrar
Cta Cte
Consultar
Gestión de Servicios del
Taller Mecánico
Sistema de Cobro
Capataz
Mecánico
Cajero
Con la visión del producto propuesta en este ejemplo, no es relevante representar al capataz o al cajero, salvo que se requiera identificación. Sí hay que representar a los mecánicos porque se les asignan vehículos. También surgirán datos de la interacción con el Sistema de Cobros.
Nuestro conocimiento del dominio en general va a ser una ayuda pero en ocasiones puede resultar un obstáculo.
Es fundamental considerar la necesidad del usuario.
Un modelo de datos adecuado para modelar el estado actual, por ejemplo, puede dejar de serlo si se desea que el nuevo sistema mantenga también información histórica.
Diagramas de Clases
Diagrama de Entidad-Relación
Diccionario de Datos
Los diagramas permiten construir
representaciones fáciles de interpretar, de
modo que puedan ser compartidas con el
usuario durante la validación.
El diagrama de clases y el diagrama ER son
alternativos.
El diccionario de datos es complementario a
las otras técnicas
Un diagrama de clases muestra la estructura estática de los elementos relevantes del sistema y sus relaciones, sin considerar el tiempo.
Aunque se llama diagrama de clases, las relaciones entre las clases son tan importantes para el modelo como las clases mismas.
Las relaciones son de asociación, agregación-composición y herencia.
El analista especifica los primeros niveles, que van a refinarse luego durante el diseño.
Una clase modela los atributos y el comportamiento de un conjunto de objetos relevantes del problema.
Nombre de la Clase
Nombre de la Clase
Atributos
Nombre de la Clase
Atributos
Servicios
Desarrollo de Requerimientos
Profesor
float salario()
legajo nombre fechaIngreso cargo
Profesor
int legajo String nombre Date fechaIngreso DP datosPostales String cargo
Profesor
boolean antes() Date diaAnterior()
Date
int dia, mes, año
Desarrollo de Requerimientos
La visibilidad es un elemento opcional en
el modelo y especifica si cada atributo o
servicio de la clase es visible fuera de la
clase o queda encapsulado.
Normalmente no se especifica en el
modelo lógico.
Cada atributo puede asociarse a un tipo y a un conjunto de restricciones sobre los valores. El tipo puede ser elemental o una clase.
En los LOO puros no existe el concepto de tipo. Cada atributo es un objeto de una clase.
En los modelos lógicos por lo general no se incluye el tipo.
La asociación es una relación estructural, estática entre clases.
Las asociaciones se explicitan en el diagrama de clase estableciendo un arco entre las clases relacionadas.
La asociación puede tener un nombre y opcionalmente una flecha que permite navegar entre las clases, es decir, nos indica la dirección para leer el nombre.
A
r1
E
r3
B
D
C
r2
Plan de Estudios
Materia
tiene
Materia
requiere
La multiplicidad es un elemento opcional e indica cuántas instancias de una clase estarán vinculadas a una instancia de la clase asociada.
La cantidad puede ser:
1
1 o más (1..*)
0 o 1 (0..1) (opcional)
0 o más (0..*) (opcional)
Un rango específico (m..n)
Director
Carrera
1 dirige 1
Una Carrera tiene un único Director y cada Director solo puede dirigir una Carrera. desea modelar información histórica. A lo largo del tiempo una Carrera va tener diferentes Directores y un mismo Director puede dirigir diferentes carreras.
Carrera
Plan de Estudios
1 tiene 1..*
Una Carrera puede estar asociada a uno o más Planes de Estudio, pero un Plan de Estudios corresponde a una única carrera.
Plan de Estudios
Materia
0..* tiene
20..45
Si el rango de valores no es estricto es preferible no establecerlo.
Plan de Estudios
Materia
* tiene
20..45
1 0..3 ofrece
Curso
Una materia se crea antes de dictarse por primera vez, puede existir la materia y no estar asociada a un Curso.
Plan de Estudios
Materia
* tiene
20..45
Curso 1 0..3 ofrece
Profesor
1..3 dicta
0..2
De acuerdo a este modelo no es posible crear un Curso sin asociarlo a un Profesor y a una materia.
Una clase asociación es una clase que modela la asociación entre otras clases y tiene atributos propios.
Por lo general se presenta en las relaciones con multiplicidad muchos a muchos.
A B
r 0..* 0..*
C
Materia Alumno
rinde 0..* 0..*
La clase Examen, que surge de la asociación entre Materia y Alumno (muchos a muchos), puede tener atributos, como fecha y nota.
Otra alternativa es que el analista identifique a Examen directamente como una clase, relacionada con las clases Materia y Alumno.
Examen
Materia Curso Aula
Profesor
La asociación entre Profesor, Materia y Aula se
modela con la clase Curso que tendrá atributos
propios.
Las relaciones de agregación y composición permiten modelar la dependencia entre clases que forman parte de un todo.
La agregación es una relación más fuerte que la asociación porque el comportamiento de una instancia de una clase depende del comportamiento de la instancia relacionada.
La composición es una relación aun más fuerte que la agregación porque la existencia de una instancia de una clase depende de la existencia de la instancia de la clase relacionada.
Director
Carrera
1 dirige 1
Cuando la multiplicidad es 1 existe una dependencia fuerte entre las clases.
Acta
ItemActa
Un acta contiene entre uno y más ítems. No existen
ítems que no estén asociados a un acta. Tampoco
actas sin ítems.
1 contiene
1..n
La herencia es un mecanismo que establece una relación de generalización-especialización entre clases.
D C
Profesor Director
Carrera
1 dirige 1
El Director de una Carrera debe ser un Profesor.
Una clase abstracta es aquella que no modela a ningún objeto del problema.
D E
*C
Por lo general se especifican durante el diseño.
Grado Posgrado
*Alumno
Plan de Estudios
Materia
0..* tiene
20..45
Curso 1 0..3 ofrece
Profesor
1..3 dicta
0..2
Alumno 0..* 0..* rinde
1 0..* inscripto
Cada plan de estudios tiene entre 20 y 45 materias inclusive Toda materia puede estar asociada a cualquier número de planes de estudio. Un curso se asocia exactamente una materia y al menos a un profesor y como máximo tres Un profesor puede no estar vinculado a ningún curso Todo alumno está ligado a exactamente un plan de estudios, puede no haberse inscripto en ningún curso.
La validación puede realizarse mediante una matriz en la que se “cruzan” casos de uso y clase y se registran diferentes tipos de operaciones.
Por ejemplo “C” crear, “L” leer, “M” modificar y “B” borrar”.
La generación y validación de la tabla permite detectar ausencias e inconsistencias entre casos de uso y conjuntos de entidades en el diagrama de clases.
Vehículo Mecánico Formulario Cuenta Corriente
Iniciar reparación
L L C
Registrar Factura
L C
…
En un sistema de mediana o gran escala es imposible incluir el conjunto completo de clases en un diagrama.
Un paquete es el recurso provisto por UML para organizar el conjunto de clases en forma jerárquica.
El DC va a ser refinado durante la etapa de
diseño agregando funcionalidad,
responsabilidades y nuevas clases asociadas.
El analista se concentra en el problema, el nivel
de abstracción es alto. No identificamos clases
como Fecha o String.
En esta etapa tampoco se decide como se van a
organizar las colecciones de datos.
Vehículo Patente NroChasis
Formulario Fecha Hora Inicial Hora Final
Propietario Nombre
Factura Nro Fecha Monto
Mecanico Nombre
Tipo Servicio Nombre
0..* 1..*
1 1
1 1..*
1
0..* 0..*
1
0..*
1
CtaCte Fecha Monto
1
0..*
Se registra el movimiento en cuente corriente pero no el cobro. La cobranza se realiza desde otros sistema, vinculado a través de la cuenta corriente. La factura no está imputada directamente a la cuenta corriente.
Vehículo Patente NroChasis
Formulario Fecha Hora Inicial Hora Final
Propietario Nombre
Factura Nro Fecha Monto
Mecanico Nombre
Tipo Servicio Nombre
0..* 1..*
1 1
1 1..*
1
0..* 0..*
1
0..*
1
CtaCte Fecha Monto
0..1 1
Una factura puede quedar pendiente imputada a un movimiento de la cuenta corriente. La vinculación del movimiento con el cliente es indirecta, a través de la factura.
Vehículo Patente NroChasis
Formulario Fecha Hora Inicial Hora Final
Propietario Nombre
Factura Nro Fecha Monto
Mecanico Nombre
Tipo Servicio Nombre
0..* 1..*
0 1
1 1..*
1
0..* 0..*
1
0..*
1 1
0..*
CtaCte Fecha Monto
Un diagrama entidad-relación es una representación visual que modela las entidades relevantes de un sistema, sus relaciones y atributos.
La técnica proviene del área de Bases de Datos pero se generalizó y se ha usado para modelar datos de cualquier tipo de sistema.
Aunque en la actualidad es más frecuente elaborar DC, el modelo de datos de los sistemas desarrollados hace algunos años suele estar especificado usando DER.
Una entidad es un objeto o cosa del mundo real que tiene una identidad propia, es decir, se distingue de otros objetos o cosas.
Libro Socio Editorial
Una entidad puede ser concreta o abstracta.
Plan de Estudios
Materia Carrera
Un atributo es una propiedad relevante para caracterizar a una entidad.
Libro Editorial
ISBN
Título Nombre
Contacto
Género
Socio
Código
Nombre
FNac
Nro
Tipo Doc
CantPag
Cada atributo toma un valor dentro de un dominio de valores.
Dos entidades que comparten los mismos atributos forman parte de una misma colección de entidades.
Dos entidades de una colección pueden tener los mismos valores en algunos atributos, pero no van a tener los mismos valores en todos los atributos.
El valor de un atributo puede ser simple, compuesto o multivaluado.
Se dice que el dominio puede ser un tipo provisto por el lenguaje o un tipo definido por el programador.
Algunos atributos se derivan de otros.
Es posible establecer restricciones sobre los valores e indicar si el dominio incluye un valor nulo.
Estas características no se especifican en el DER sino que se documentan por separado.
Socio
Código
Nombre
Fecha_Nac
Nro
Tipo_Doc
Código, Tipo_Doc y Nro tomarán valores simples
Nombre y FNac toman valores compuestos.
En ambos casos el dominio de valores puede estar provisto por el lenguaje.
Socio
Código
Nombre
Fecha_Nac
Tipo_Nro
Datos_ Postales
En este caso
Tipo_Nro
Datos_Postales
Toman valores compuestos, el dominio es un tipo definido por el programador
Este concepto no aparece en los LOO.
Una relación establece una asociación entre dos o más entidades.
Libro Socio Editorial publica retira
ISBN
Título
Código
Nombre
Nombre
Contacto
Género Fecha_Nac
Nro
Tipo_Doc
CantPag
Aunque las relaciones binarias son las más frecuentes, una relación puede asociar a tres o más entidades.
Artículo publica Autor
Revista
Una relación puede tener atributos
Libro Editorial publica retira
ISBN
Título Nombre
Contacto
Género FDev
FPres
Socio
Código
Nombre
FNac
Nro
Tipo_Doc
CantPag
Una participación total exige que cada entidad esté relacionada con al menos otra entidad
Artículo tiene Revista
Por lo general no se usa esta notación sino que se establece la cardinalidad.
Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada.
Uno a Uno
Uno a Muchos
Muchos a Muchos
Uno a Uno: (1:1) Una entidad de A se relaciona únicamente con una entidad en B y viceversa
Aunque la técnica nombra 1:1 a esta cardinalidad, incluye en esta categoría la posibilidad de que haya entidades sin relacionar.
Carrera
Director
dirige
1
1
El arco rotulado especifica explícitamente si se trata de una relación Total (toda entidad debe estar relacionada) o Parcial.
Uno a Muchos: (1:N)Una entidad en A se relaciona con 1o muchas entidades en B.
Nuevamente los rótulos permiten indicar si la participación de cada entidad es total o parcial.
Plan de Estudios
tiene Carrera 1 1..n
Cada carrera tiene al menos un Plan de Estudios.
Cada Plan de Estudios está relacionado siempre con una única carrera.
Muchos a Muchos: (N:M) Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa
Materias
tiene
Plan de Estudios
0..n
1..m
Una materia puede estar relacionada a un plan de estudios, varios o ninguno.
Una clave es un subconjunto de atributos, que permite identificar a una entidad o relación unívocamente.
Una superclave un subconjunto de atributos que permite distinguir unívocamente cada una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el resultado seguirá siendo una superclave.
Socio
Código Nro
Tipo Doc
Una clave candidata es un atributo o conjunto mínimo de atributos que identifica unívocamente a una entidad.
Si una superclave deja de serlo quitando uno de los atributos que la componen, entonces es una clave candidata.
Socio
Nro
Tipo Doc
Socio
Código
Una clave primaria es una clave candidata elegida para identificar unívocamente las entidades en un conjunto de entidades.
Socio
Código
El análisis de un conjunto de entidades no es suficiente para asegurar qué atributos conforman una clave primaria.
Si una relación no tiene atributos la clave primaria de la relación es la unión de las claves primarias de las entidades asociadas por la relación.
Si una relación tiene atributos la clave primaria es la unión de las claves primarias de las entidades asociadas por la relación, junto con los atributos de la relación.
Libro Socio Editorial publica retira
ISBN
Título
CantPag Código
Nombre Nombre
Contacto
Género Fecha de
Devolución
FPres
FNac
Un mismo problema puede modelarse de maneras diferentes.
Cada género podría modelarse como una entidad.
Cada préstamo de un libro podría modelarse como una entidad intangible.
En este caso la entidad Préstamos estaría relacionada con Libro y con Socio, ninguna de estas relaciones tendría atributos.
La técnica ha sido extendida para incorporar:
Distinción entre entidades débiles y fuertes
Atributos agrupados en un rectángulo
Herencia
Agregación
Una entidad débil no tiene clave primaria.
Una entidad débil no puede existir sin participar en la relación, es decir, no puede ser unívocamente identificada solamente por sus atributos.
Una entidad fuerte o regular tiene una clave primaria.
La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos.
La relación de herencia jerárquica se representa mediante un triángulo interconectado por líneas a las entidades.
La entidad conectada por el vértice superior del triángulo es la entidad "padre".
La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más alto.
Se utiliza para expresar relaciones entre relaciones.
Se representa englobando las relaciones y las entidades que participan en ella en un rectángulo.
El DER va a ser refinado durante la etapa de
diseño para transformar el modelo conceptual
en un modelo lógico.
El analista se concentra en el problema, el nivel
de abstracción es alto.
Por lo general el analista elabora un DER
cuando se decide que la especificación va a
evolucionar durante el diseño para producir un
modelo de base de datos relacional.
El diccionario de datos es una descripción textual de los datos, con una estructura basada en una plantilla.
Aunque no es un modelo formal, si es importante elaborarlo aplicando una metodología rigurosa.
Es un complemento de las representaciones visuales y debe ser consistente con ellas, como así también con el Glosario.
Describe tanto los datos almacenados como la entrada y salida.
Cada entidad del MER o cada clase de un DC va a estar asociada a una descripción en el DD, aunque no es necesario completar la plantilla para cada entidad o clase.
De cada atributo se incluye al menos el nombre y el tipo.
Se puede especificar de forma opcional las reglas de validación, las fórmulas de cálculo y los valores por omisión.
Nombre de la Clase
Nombre del Atributo
Tipo Rango Valor por omisión
Regla de Validación
Responsabilidades de la clase
Requisitos de la clase
Nombre del Flujo de Entrada de Dato
E o S Tipo Rango Valor por omisión
Regla de Validación
Nombre del Flujo de Salida de Dato
E o S Tipo Rango Valor por omisión
Las reglas de validación modelan restricciones y garantizan cierto nivel de integridad en los datos.
Las reglas de validación y las fórmulas pueden involucrar a varios atributos.
El análisis de las reglas del negocio permite identificar muchas de las reglas de validación y fórmulas.
Las siguientes reglas del negocio referidas a un Acta de Examen debe transformarse en reglas de validación para los datos:
El tipo de examen debe ser Regular o Libre.
La fecha de creación de un acta debe ser anterior a la fecha de examen
La nota debe ser entre 0 y 10
La cantidad de alumnos debe coincidir con la cantidad de renglones del cuerpo del acta.
El diccionario de datos mantiene un nivel de detalle que solo es posible alcanzar con lenguaje natural.
Son particularmente útiles para describir casos complejos.
En los diagramas es difícil especificar casos especiales o excepciones.
La principal desventaja de los DD es que tienden a crecer desmesuradamente y son difíciles de validar.
Para evitarlo no deberían describirse casos triviales.
El mayor riesgo es la inconsistencia, sobre todo cuando participan diferentes analistas.
En algunos proyectos el analista solo elabora el diccionario de datos y el diseñador genera las representaciones visuales.
En este caso el diccionario de datos no es un complemento de los requerimientos, sino que los requerimientos se especifican exclusivamente en el diccionario de datos.
Diagrama de
Contexto
Diagrama de
CU
Descripción
de CU
Diagrama de
Concep. Neg.
Diagrama de
Clases
La mayor parte de las aplicaciones generan reportes.
En general tienen un formato rígido, pueden incluir texto y gráficos.
El propósito y contenido se define durante el desarrollo de requerimientos y muchas veces impacta sobre la derivación de requerimientos de datos.
El diagramado puede establecerlo el usuario, el diseñador o puede estar impuesto por el contexto de la organización.
¿Qué reportes se generan actualmente?
¿Cuáles se agregan?
¿Cuáles deben ser modificados?
¿Quiénes son sus usuarios? ¿Para qué los usan?¿Qué decisiones se toman a partir de la información de cada reporte?
¿Con qué frecuencia se usa cada uno? ¿Depende de un evento?
¿Cuántas hojas puede demandar como máximo?
¿Cuál es el soporte? Se visualiza por pantalla, se imprime, se envía por mail, se exporta a una planilla de cálculo o a algún otro formato.
¿Hay restricciones de seguridad o privacidad que limiten el acceso a individuos específicos o clases de usuarios?
¿Qué fuentes de datos tiene el reporte?
¿Qué parámetros puede establecer el usuario?
¿Qué procesamiento se requiere? ¿Subtotales? ¿Contadores? ¿Ordenamiento?
¿Cuál es el contenido del reporte si no hay datos para mostrar?
¿Puede usarse una misma plantilla para distintos reportes?
Verificar que el sistema mantenga la información requerida por cada reporte o pueda computarla a partir de los datos almacenados.
Por ejemplo para poder generar un reporte que muestre una cuenta corriente imputada es necesario que el sistema haya registrado previamente que facturas fueron canceladas con cada recibo.
Anticipar el crecimiento
Un formato que es adecuado inicialmente puede no serlo cuando el volumen de información aumenta.
Un diagramado tabular puede ser adecuado para una cantidad reducida de items pero puede no ser adecuado cuando la cantidad aumenta.
Validar el glosario considerando los términos que aparecen en los reportes.
Identificar patrones
Varios usuarios pueden requerir reportes similares, definir formato común y parametrizar los aspectos que son diferentes.
Por ejemplo un certificado de alumno regular puede contener o no el promedio, con o sin aplazos, los exámenes pueden estar ordenados alfabéticamente o cronológicamente, puede incluir las materias cursadas o solo los finales.
Considerar si tienen que modificarse dinámicamente
Los reportes estáticos muestran la información que corresponde al instante en que se generó el reporte.
Los reportes dinámicos se actualizan automáticamente a medida que la información cambia.
Por ejemplo un tablero de control.
Decidir si se generan prototipos
Permiten que el usuario visualice el diagramado y decida qué características le agradan y cuáles no.
Código
Título Nombre, posición y datos fijos y variables del título
Propósito Breve descripción de la necesidad que satisface el reporte
Usuarios Clases de Usuarios interesados en el reporte
Privilegios Privilegios requeridos para generar cada reporte
Decisiones Decisiones que cada clase de usuario puede tomar a partir del reporte
Prioridad Prioridad respecto a otros reportes
Latencia Tiempo de entrega del reporte al usuario que lo requiere Actualidad de los datos incluidos en el reporte
Diagramado Tamaño de papel, orientación, márgenes
Gráficos e Imágenes
Tipos de gráficos e imágenes, tamaño
Encabezamiento y pie
Texto fijo y variable, Fecha Número de página, nombre del usuario que lo solicita, nivel de confidencialidad
Cuerpo Criterio de selección de dato, atributos Criterio de ordenamiento, fórmulas Criterio de paginado
Un tablero de control es un reporte que aparece en pantalla o impreso y permite visualizar información relevante y consolidada referida a la organización o un proceso.
Por lo general incluye algunos valores numéricos, probablemente organizados como una tabla, gráficos u otro tipo de imágenes que muestran algunos indicadores claves. Puede ofrecer también un texto breve.
En un tablero dinámico la información se modifica en tiempo real a medida que el estado interno de los datos se modifica.
La información debe permitir detectar situaciones que requieren tomar decisiones rápidas.
El usuario puede explicitar que necesita un tablero de control o puede proponerlo el analista luego de capturar los requerimientos para los reportes.
Es probable que la interpretación de un tablero requiera de algún entrenamiento.
En todos los reportes, pero más aun en los
tableros de control, el contenido es muy
importante, pero el diagramado también tiene
relevancia.
Tanto el contenido como el diagramado puede
parametrizarse, en cuyo caso se requiere un
usuario aun más entrenado.
Como en el caso de los reportes es necesario capturar restricciones, privilegios, prioridades y fundamentalmente analizar si con los datos almacenados es posible ofrecer los indicadores incluidos en el tablero.
Los prototipos son un excelente recurso para asegurar que el estilo y diagramado satisface las necesidades del usuario.
En proyectos en gran escala o en empresas dedicadas al desarrollo de sistemas se suele asignar un especialista para el diseño de interfaces de usuario.
En este caso será el responsable de diseñar los prototipos de todos los reportes, en particular el tablero de control, pero debe trabajar con usuarios representativos para conocer convenciones propias del dominio, con el analista para asegurar que la información pueda obtenerse a partir de los datos almacenados y con los implementadores para analizar el tiempo y los recursos que demanda.