ANALISIS Y DISEÑO DE

SISTEMAS

SESION 11

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com 1
 Objetivos de la clase
 Definir el modelamiento de
requisitos.
 Entender la fase parte 1 de análisis
(ejemplo de requisitos)

2
 Contenidos

1. Modelamiento de Requisitos
2. Resumen de la fase de requisitos

3
Modelado de Requisitos

4
 Artefacto
 Pieza de información utilizada o producida por un
proceso de desarrollo de software
Artefactos implicados durante la captura de
requisitos

 Modelo de Casos de Uso

 Actor
n

 Glosario

 Caso de Uso

 Prototipo de Interfaz de Usuario

 Descripción de la Arquitectura 5
 Work Flow de Requisitos

Encontrar Actores Estructurar el Modelo

y Casos de Uso de Casos de Uso
Analista de Sistemas

Arquitecto Priorizar
los Casos de Uso

Detallar
Especificador CU los Casos de Uso

Diseñador de Interfaz
de usuario Prototipar
la Interfaz de Usuario6
Modelado de Requisitos

Objetivo:
Establecer los requisitos funcionales y no
funcionales del sistema.

A partir del modelo del negocio (si se hace)

se construye el modelo de casos de uso y
el modelo conceptual.

7
 Qué es un Requerimiento ?
RAE (Real Academia de la Lengua Española)
Requerimiento
 Acción y efecto de requerir.

Requisito
 Circunstancia o condición necesaria para
algo.

8
 Qué es un Requerimiento ?
 Un requerimiento es una condición o capacidad
a la que el sistema (siendo construido) debe
conformar [ Rational Software Corp.].

 Un requerimiento de software puede ser

definido como :
 Una capacidad del software necesaria por el usuario
para resolver un problema o alcanzar un objetivo.
 Una capacidad del software que debe ser reunida o
poseída por un sistema o componente del sistema para
satisfacer un contrato, especificación, estándar, u otra
documentación formal. [Somerville]
9
 Interpretaciones acerca de los
Requerimientos
 El consultor Brian Lawrence sugiere que un
requerimiento es “cualquier cosa que impulsa un diseño
de calidad”. Muchos tipos de información caen en esta
categoría.
 El glosario estándar IEEE de Terminología de Ingeniería
de Software define un requerimiento como:
1. Una condición o capacidad necesaria por un usuario para resolver un
problema o lograr un objetivo.
2. Una condición o capacidad que debe ser cumplida o poseída por un
sistema o componente del sistema para satisfacer un contrato,
estándar, especificación u otros documentos formalmente impuestos.
3. Una representación documentada de una condición o capacidad como
en las especificaciones 1 o 2.

10
Qué representan y muestran los
Requerimientos ?
 Los requerimientos de usuario representan
el conjunto completo de resultados a ser
obtenidos utilizando el sistema.
 Los requerimientos de sistemas deben
mostrar todo lo que el sistema debe hacer
mas todas las restricciones sobre la
funcionalidad.
 Los requerimientos forman un modelo
completo, representando el sistema total a
algún nivel de abstracción.
11
 Rol de Requerimientos
 Si un producto no es lo que el cliente o los usuarios
quieren, entonces la calidad de la construcción es
irrelevante.
 El rol clave de los requerimientos es mostrar a los
desarrolladores y usuarios que se necesita de un
sistema.
 Proveer los requerimientos forma parte de un
lenguaje que todos comprenden, ya que todos están
involucrados, incluyendo los clientes.
 El primer y básico rol de los requerimientos es por lo
tanto la comunicación.

12
 Cómo identificamos los
Requerimientos ?
 Los Requerimientos toman vida desde que
realizamos nuestro primer encuentro de
interlocución con usuarios o clientes.
 Este puede desarrollarse utilizando cualquiera
de una variedad de técnicas como entrevistas
para intercambiar opiniones, brainstorming,
prototipeo, cuestionarios, etc.
 Cuando los requerimientos se logran redactar
a un significativo nivel de detalle, tendremos
listo el documento denominado “Especificación
de Requerimientos”.
13
 Buena Especificación de
Requerimientos
 Un resultado primario es la Especificación de
Requerimientos, la cual define y documenta
en forma completa el comportamiento
externo del sistema a ser construido.
Caracterizándose por :
 Definidos sin ambigüedad
 Son completos
 Tienen consistencia
 Especifica el origen
 Evita detalles de diseño
 Están enumerados

14
 Beneficios de una Buena Gestión
de Requerimientos

 Mejor control de proyectos complejos.

 Mejora en la calidad del software y en la
satisfacción del cliente.
 Reducción en los retrasos y en los costos
del proyecto.
 Mejora en la comunicación del equipo.
 Facilita la conformidad con estándares y
regulaciones.

15
 Los Problemas de la Gestión de
Requerimientos
 No son siempre obvios y tienen muchas fuentes.
 No son siempre fáciles de expresar en palabras.
 Hay muchos tipos diferentes a distintos niveles de
detalle.
 El número puede llegar a ser inmanejable.
 Están relacionados a otros en una variedad de
formas.
 Hay muchos interesados y partes responsables.
 Cambian.
 Pueden ser sensibles al tiempo.

16
 El Alto Costo de Errores en los
Requerimientos
 Hay fuertes evidencias que una efectiva
administración de requerimientos conducen a
los ahorros del proyecto integral.
 Las tres razones primarias para esto son :
 Costos de reparar errores en los requerimientos
superan en mas de 10 veces a otros errores.
 Errores de requerimientos comprenden encima del
40% de todos los errores de un proyecto de
software.
 Pequeños reducciones en el número de errores de
requerimientos rinden grandes dividendos al evitar
costos de re-trabajo y días de retraso.
17
 NIVELES DE LOS REQUERIMIENTOS

Los óvalos representan tipos de requerimientos de información y los

rectángulos indican contenedores o recipientes (documentos, diagramas o
bases de datos) en la cual almacenamos esta información. 18
 Requerimientos del Dominio
 Se derivan del dominio del sistema más que de
las necesidades específicas de los usuarios.
Pueden ser requerimientos funcionales nuevos,
restringir los existentes o establecer cómo se
deben ejecutar cálculos particulares.
 Los requerimientos del dominio son importantes
debido que a menudo reflejan los fundamentos
del dominio de aplicación.
 Si estos requerimientos no se satisfacen, es
imposible hacer que el sistema trabaje de forma
satisfactoria.
19
 Requerimientos de Usuario
 Describen las metas del usuario o las tareas
que los usuarios deben ser capaces de
ejecutar con el producto.
 Formas valiosas para representar los
requerimientos de usuario incluyen a los
casos de uso, descripciones de escenarios, y
tablas de respuesta a eventos.
 Los requerimientos de usuario sin embargo
describen lo que el usuario será capaz de
hacer con el sistema.

20
 Requerimientos del Sistema
 Establecen con detalle los servicios y
restricciones del sistema.
 El documento de requerimientos del sistema,
algunas veces denominado especificación
funcional, debe ser preciso.
 Éste sirve como parte del contrato entre el
negocio y el desarrollador de software.

21
Ej. Definición de
Requerimientos de Usuario

1.El software debe proveer un medio

para representar y acceder a archivos
externos creados por otras
herramientas.

22
 Ej. Especificación de
Requerimientos del sistema

1.1 Al usuario se le proveerá con los recursos para definir

el tipo de archivos externos.
1.2 Cada tipo de archivo externo tendrá una herramienta
asociada que será aplicada al archivo.
1.3 Cada tipo de archivo externo se representará como un
icono especifico sobre la pantalla del usuario.
1.4 Se proveerán recursos para que el usuario defina el
icono que representa un tipo de archivo externo.
1.5 Cuando un usuario selecciona un icono que representa
un archivo externo, el efecto de esa selección es
aplicar la herramienta asociada con este tipo de
archivo al archivo representado por el icono
seleccionado. 23
 Tipos de Requisitos
 Funcionales
 Que tienen que ver con la funcionalidad del sistema
 Describen lo que el Sistema debe hacer

 No Funcionales
 Usabilidad
 Fiabilidad
 Rendimiento
 Adaptabilidad, Mantenimiento, Configurable
 Implementación: lenguajes, herramientas,..
 GUI
 Legales 24
 Requerimientos Funcionales
 Describen la funcionalidad o los servicios que se
espera proveerá el sistema.
 Estos dependen del tipo de software y del
sistema que se desarrolle y de los posibles
usuarios del software.
 Cuando se expresan como requerimientos del
usuario, habitualmente se describen de forma
general mientras que los requerimientos
funcionales del sistema describen con detalle la
función de éste, sus entradas y salidas,
excepciones, etc.
25
Requerimientos no funcionales

26
 RNF Requerimientos del
Producto
 Éstos especifican el comportamiento del
producto.
 Algunos ejemplos son los requerimientos de
desempeño en la rapidez de ejecución del
sistema y cuánta memoria se requiere; los de
fiabilidad que fijan la tasa de fallas para que
el sistema sea aceptable; los de portabilidad y
los de usabilidad.

27
 RNF: Requerimientos
Organizacionales
 Se derivan de las políticas y procedimientos
existentes en la organización del cliente y en
la del desarrollador.
 Algunos ejemplos son los estándares en los
procesos que deben utilizarse;
 Los requerimientos de implementación como los
lenguajes de programación o el método de diseño
a utilizar, y los requerimientos de entrega que
especifican cuándo se entregará el producto y su
documentación.

28
 RNF: Requerimientos Externos
 Este gran apartado cubre todos los requerimientos
que se derivan de los factores externos al sistema y
de su proceso de desarrollo.
 Éstos incluyen los requerimientos de
interoperabilidad que definen la manera en que el
sistema interactúa con los otros sistemas de la
organización; los requerimientos legales que deben
cumplirse para operar dentro del marco de la Ley, y
los requerimientos éticos que permitan asegurar que
será aceptado por el usuario y por el público en
general.

29
 Ejemplos RNF
 Requerimiento del Producto
 El tiempo de respuesta que debe ofrecer el sistema para
una transacción en el módulo X debe oscilar entre los 3 y 6
seg.
 Requerimiento Organizacional
 El proceso de desarrollo del sistema y los documentos a
entregar deberán apegarse al proceso y a los productos a
entregar definidos en la norma Nº abc-2002.
 Requerimiento Externo
 El sistema no deberá revelar a sus operadores alguna
información personal de los clientes excepto su nombre y
número de referencia.

30
 Del modelo de negocio al
modelo de requisitos
 Extraer los casos de uso del sistema a
partir de las actividades que aparecen en
los diagramas de actividades.
 Establecer el modelo conceptual a
partir de las informaciones incluidas en los
diagramas de actividades.

31
 Del modelo de negocio al modelo
de requisitos
 De los diagramas de proceso...

rol
actor
Caso de Uso
actividad

objeto Concepto del

Dominio

32
 Introducir Pedido Analizar Produccion

Cliente
JefeTecnico

Cursar Pedido Ordenar Fabricacion

Planificar Produccion
JefeProduccion

Comercial Informar Pedido

Diagrama de Casos de Uso “Registrar Pedido”

33
 Identificación de casos de uso
 Objetivos Estrátegicos casos de uso del negocio
 Ejemplo: Evitar pérdidas
 Objetivos de Usuario  casos de uso
 Ejemplo: Realizar Venta
 Subfunciones  ¿casos de uso?
 Ejemplo: Iniciar sesión (Login)

34
 Identificación de casos de uso
 Establecer los límites del sistema
 Identificar los actores principales
 ¿Es el cliente un actor en el sistema Terminal Punto
de Venta?
 Identificar sus objetivos de usuario
 Posible uso de los eventos externos
 Definir un caso de uso por objetivo de usuario
 Excepción: casos de uso para manejar información
(crear, eliminar, modificar, consultar)
 Formato expandido y esencial
35
 Plantilla usecases.org
 Actor Principal
 Personas involucradas e Intereses
 Precondiciones
 Postcondiciones
 Escenario Principal (Flujo Básico)
 Extensiones (Flujos Alternativos)
 Requisitos especiales
 Tecnología y Lista Variaciones de datos
 Frecuencia
 Cuestiones abiertas

36
Ejemplo: Terminal Punto de Venta

Realizar Venta

Cajero Cliente

Registrar Productos

Casos de Uso
Inicia
Gerente

Gestion Usuarios
Administrador
Sistema

37
 Caso de uso “Realizar Venta”

Resumen: Un cliente llega al TPV con un conjunto de artículos. El

Cajero registra los artículos y se genera un ticket. El cliente paga en
efectivo y recoge los artículos.
Actor Principal: Cajero
Personal Involucrado e Intereses:
 Cajero: quiere entradas precisas, rápida y sin errores de pago
 Compañía: quiere registrar transacciones y satisfacer clientes.
 ...
 Precondición: El cajero se identifica y autentica
 Postcondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza contabilidad e inventario...

38
 Caso de uso “Realizar Venta”

Flujo Básico:
1. A: El cliente llega al TPV con los artículos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artículo.
4. S: El sistema registra la línea de venta y presenta descripción del
artículo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo

39
 Caso de uso “Realizar Venta”

Extensiones (Flujos Alternativos):

3a. Identificador no válido
1. El Sistema señala el error y rechaza la entrada
3-6a. El Cliente pide eliminar un artículo de la compra
1. El Cajero introduce identificador a eliminar
2. El sistema actualiza la suma
...
7a. Pago en efectivo
1. El Cajero introduce cantidad entregada por el cliente
2. El Sistema muestra cantidad a devolver
...
....

40
 Caso de uso “Realizar Venta”
Requisitos especiales:
- Interfaz de usuario con pantalla táctil en un monitor de pantalla
plana. El texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorización de crédito de 30 sg. El 90%
de las veces
...
Lista de Tecnología y Variaciones de Datos:
- El identificador podría ser cualquier esquema de código UPC, EAN,..
- La entrada de información de la tarjeta se realiza mediante un lector
de tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios remotos
- ¿Qué adaptaciones son necesarias para diferentes negocios?
41
Diagramas de estado de casos
de uso
introducirArticulo

Esperando crearNuevaVenta Introduciendo

Venta Articulos

finalizarVenta

EsperandoPago

realizarPagoEnEfectivo

Autorizando
Pago
realizarPagoACredito
Procesar Venta

realizarPagoConCheque

42
 Elaboración de casos de uso
 ¿Cuándo?
 Al principio de la iteración en formato extendido y
esencial, se refinan a lo largo de las iteraciones
 ¿Dónde?
 En talleres de captura de requisitos
 ¿Quién?
 Usuarios finales, clientes, desarrolladores
 ¿Cómo? (Herramientas)
 Herramientas de requisitos web-enabled integradas
con un procesador de texto (texto cdu) y
herramientas CASE UML (diagramas de cdu)

43
 Recomendaciones sobre casos
de uso
 Define bien los límites del sistema.
 Los actores interaccionan con el sistema.
 Pregunta qué quieren los actores del sistema:
Objetivos.
 Distingue el flujo normal de los flujos alternativos.
 Lo importante es escribir la descripción del caso
de uso, no dibujar diagramas de casos de uso.
 Uso limitado de las relaciones include y extend

44
 Recomendaciones sobre casos
de uso
 Usa include para factorizar parte de un flujo que
aparece en varios casos de uso.
 Las extensiones pueden incluirse dentro del caso
de uso base como flujos alternativos en vez de
incluir casos de uso aparte.
 El propio sistema puede disparar casos de uso.
 No incluir casos de uso CRUD; casos de uso Crear
y Consulta si son relevantes.
 No especificar casos de uso que incluyan detalles
de diseño de interfaces de usuario.
45
Modelo Conceptual (o Dominio)
 Representa el vocabulario del dominio:
ideas, conceptos, objetos
 No son modelos de elementos software
 Clases conceptuales
 Clases no incluyen operaciones, sólo
atributos
 Atributos: números o texto
 Asociaciones entre clases

46
 Identificar Clases Conceptuales
 Si se hace modelado del negocio:
“Los objetos información, entrada y salida de las
actividades de los diagrama de proceso, representan
entidades y conceptos del dominio”.
 Una clase conceptual para cada información
relevante.
 De la especificación del diccionario se extraen:
 atributos, asociaciones, restricciones
 Se refina a lo largo de las iteraciones
 “Más vale que sobren clases que falten”

47
 Del Modelo del Negocio al
Modelo Conceptual
Objeto información “Pedido” (modelo del negocio)

Atributos: codigo, importe, estado, fechaTopeEntrega,..

Asociaciones: Pedido-Cliente y Pedido-Producto,..
Restricciones: fechaTopeEntrega > fechaRecepcion, ..

 También es posible identificar objetos que pasan por

varios estados (diagrama de estados preliminar)

48
 Identificar Clases Conceptuales

 Si no se hace modelado del negocio:

 Usar una lista de categorías de clases
 Identificar nombres de las frases
 Categorías de clases
 Objetos físicos
 Especificaciones o descripciones de cosas
 Lugares
 Transacciones
 Líneas de una transacción

49
 Identificar Clases Conceptuales

 Categorías de clases (continua)

 Contenedores de cosas
 Cosas en un contenedor
 Dispositivos externos al sistema
 Conceptos abstractos
 Eventos
 Procesos
 Reglas y Políticas
 Catálogos
 Contratos, documentos legales
 Instrumentos y servicios financieros
 Manuales, documentos, trabajos, libros
50
Modelo Conceptual Registra venta de

Descrita por Contiene

Catalogo Productos Producto
1 1..n
1
Usado-por Describe
0..1
0..n
0..n
Tienda Almacena 1
Item
Lineas Venta direccion
cantidad nombre 1 0..n
0..n
1..n 1
Contenidas en
1 1..n
capturada en Iniciado por
Venta TPV Gerente
1 1 1 1
1 1
1
iniciada por Registra Ventas
pagado por
1
1
1
Cliente Cajero
Pago

51
 EspecificaciónTarea
Cliente Pedido
1 1..n 1
1

1
Modelo Plantilla 1..n Tarea Puesto Producción
1 1 1..n 1
1 1

Propio EnCatalogo 1
OrdenTarea
0..n

LineaMaterial

Material

Modelo conceptual inicial 52

 Identificar Asociaciones
 Se incluyen aquellas:
 para la que el conocimiento de la relación debe
mantenerse algún tiempo
 derivadas de la Lista de Asociaciones
 Lista de Asociaciones
 A es parte física de B
 A es parte lógica de B
 A está físicamente contenida en B
 A está lógicamente contenida en B
 A es una descripción de B

53
Identificar Asociaciones
 Lista de Asociaciones (continua)
 A es una línea de una transacción o informe B
 A es conocido/registrado/informado/capturado en B
 A es miembro de B
 A es una subunidad organizacional de B
 A usa o maneja a B
 A comunica con B
 A está relacionado a una transacción B
 A es el siguiente a B
 A es apropiado por B
 A es un evento relacionado con B

54
Identificar Asociaciones
“Encontrar clases conceptuales es más importante
que encontrar asociaciones. Se debe dedicar más
tiempo a encontrar clases conceptuales que
asociaciones”

 Centrarse en las asociaciones “necesita-conocer”

 Muchas asociaciones dificultan la comprensión de los
diagramas
 Evitar asociaciones redundantes
 En la implementación se notará que falta o sobra
alguna asociación

55
Asociaciones en TPV
 A es parte física de B
 TPV-Caja
 A es parte lógica de B
 LineaVenta-Venta
 A está físicamente contenida en B
 Item-Tienda, TPV-Tienda
 A está lógicamente contenida en B
 EspecificacionProducto-CatalogoProductos
 A es una descripción de B
 EspecificacionProducto-Item

56
 Asociaciones en TPV
 A es una línea de una transacción o informe B
 LineaVenta-Venta
 A es conocido/registrado/informado/capturado en B
 Venta-TPV
 A es miembro de B
 Cajero-Tienda
 A usa o maneja a B
 Cajero-TPV, Gerente-TPV
 A comunica con B
 Cliente-Cajero
 A está relacionado a una transacción B
 Cliente-Pago, Cajero-Pago
 A es el siguiente a B
 LineaVenta-LineaVenta
 A es apropiado por B
 TPV-Tienda

57
 Atributos
 Son valores de tipos de datos: Identidad no tiene sentido
 Tipos Primitivos: Boolean, Date, Numero, Time, String
 Tipos no primitivos: Direcciones, Colores, Número Tlfno,
Número Seguridad Social, DNI, Código de Producto
Universal, Código Postal,..
 Tipos no primitivos se deben modelar como clases si:
 Están formados por varias partes
 Son aplicables las operaciones
 Tiene otros atributos
 Es una cantidad con una unidad
 No utilizar atributos como claves ajenas

58
 Documentos de Análisis Requisitos
 Casos de Uso
 Especificación Complementaria
 Captura otros requisitos
 Glosario
 Captura términos y definiciones
 Visión
 Define visión del producto de las personas
involucradas, en términos de sus necesidades y
características.

59
 Especificación Complementaria
 Funcionalidad
 Abarca varios casos de uso
 Ej. “Almacenar información errores”, “Cualquier uso requiere
autenticación de usuario”
 Requisitos No Funcionales (Atributos de calidad)
 Usabilidad, Mantenimiento, Adaptación, Fiabilidad, Rendimiento
 Restricciones Implementación (hardware, software, desarrollo)
 Componentes comprados y free open source
 Interfaces
 Reglas de Negocio (Ej. Reglas de descuento, Cálculo impuestos)
 Cuestiones Legales
 Cuestiones sobre el entorno físico y operacionales
 Información en dominios relacionados

60
 Visión
 Oportunidad
 Definición del problema
 Alternativas
 Descripción personal involucrado (stakeholder)
 Objetivos usuario
 Perspectiva del producto
 Beneficios del producto
 Lista de características del producto
 Coste y precio
 Otros requisitos y restricciones

61
 Lista de Características del
Sistema
 Alguna funcionalidad no puede ser asignada a un
caso de uso:
“El sistema debe hacer transacciones con sistemas
externos de inventario, contabilidad y cálculo de
impuestos”
 Para algunas aplicaciones conviene más una lista
de características que casos de uso
 Ej. Servidor de aplicación

62
 ¿Qué hacemos primero?
1. Escribir un borrador poco elaborado de la Visión
en la Etapa Inicial
2. Identificar objetivos del usuario y casos de uso
para ellos
3. Escribir algunos casos de uso y comenzar
Especificación Complementaria
4. Refinar Visión

63
 Elaboración de Requisitos y
Visión
 ¿Cuándo?
 Etapa Inicial, un poco
 Modelado de requisitos en cada iteración
 ¿Dónde?
 Inicio en talleres de requisitos, se completa después
 ¿Quién?
 Analista de sistemas, Arquitecto Software, Usuarios
 ¿Cómo?
 Herramientas de requisitos web-enabled integradas
con un procesador de texto

64
Casos de uso e iteraciones
 Asignar prioridad a casos de uso
 Escribir casos de uso en su forma expandida
 Asignar casos de uso a iteraciones.
 Varias versiones de un caso de uso complejo,
para añadir complejidad de modo incremental.
 Necesidad de comunicación con el usuario
 Al final un caso de uso esencial se transforma
en su forma concreta.

65
 Iteraciones
 Dirigidas por el riesgo
 Asociar a cada caso de uso un nivel de riesgo e
importancia para el negocio
 Comenzar pronto con la programación
 Realizar pruebas
 Rápida retroalimentación
 Se obtiene la arquitectura en las primeras
iteraciones

66
Prototipo Inicial
 Utilizar los casos de uso.
 Incluye las interfaces de usuario
 Sirve para validar los requisitos: analista y
usuarios llegan a un acuerdo sobre la
funcionalidad y vocabulario.
 Prototipo desechable
 Fácil de construir con herramientas visuales.

67
RESUMEN de requisitos

68
Fase II

Requerimientos( ASI )
 Objetivos de la Fase
 Obtener una especificación detallada
del Sistema de Información que
satisfaga las necesidades de
Información de los usuarios y sirva de
base para el diseño posterior del
sistema.

69
Fase II

Requerimientos

Actividades
 ASI 1. Requerimientos del Sistema de
Información
 ASI 2. Análisis de los Casos de Uso
 ASI 3. Análisis de Clases
 ASI 4. Análisis de Paquetes
 ASI 5. Especificación de Interfaces con otros
sistemas

70
Fase II \ Actividad 1

ASI 1. Requerimientos del Sistema

de Información
Objetivo
 Determinar el alcance del sistema y la
especificación de las interfaces entre el
sistema y el usuario.

Participantes
 Analista de sistemas (responsable de toda la
actividad)
 Equipo de Usuarios

71
Fase II \ Actividad 1

ASI 1. Requerimientos del

Sistema de informacion
Técnicas
 Diagrama de Contexto del Sistema
 Diagrama de Casos de Uso del Sistema
 Diagrama de Paquetes (Subsistemas.
Objetos)

Práctica
 Sesiones de Trabajo
 Catalogación
 Prototipeo
72
Fase II \ Actividad 1

ASI 1. Modelado de los

Requerimientos del Sistema
Tareas
 ASI1.1 Determinación del Alcance del Sistema
 ASI1.2 Obtención de Requerimientos
 ASI1.3 Obtención del Modelo de Casos de Uso del
Sistema
 ASI1.4 Especificación de formatos individuales de la
Interface de pantalla
 ASI1.5 Identificación de Perfiles y Dialogos
 ASI1.6 Especificación de Formatos de Impresión

73
Fase II \ Actividad 1 \ Tarea 1

ASI 1.1 Determinación del

Alcance del Sistema
 Se delimita el dominio del Sistema de
Información, en base a los Procesos de
Negocio Identificados.
 Se identifican las entidades externas al
sistema que aportan o reciben
información

74
Fase II \ Actividad 1 \Tarea 1

ASI 1.1 Determinación del

Alcance del Sistema
 Se puede adicionar un diagrama de
contexto, a fin de graficar el alcance del
sistema.

75
Fase II \ Actividad 1 \ Tarea 2

ASI 1.2 Obtención de Requerimientos

Número Requerimiento Descripción Prioridad
RF01 Registro de pagos Debe permitir el registro de pago de 3

 Requerimientos RF02 Registro de pacientes

manera eficiente
Debe permitir registro de los datos
del cliente y antecedentes clínicos.
4

Funcionales
RF03 Mantenimiento de Los nuevos usuarios o cambios en 2
usuarios los usuarios antiguos debe ser
administrado por el supervisor
RF04 Registrar resultados de Debe permitir realizar el registro de 5

Son los
examen clínico los resultados del examen clínico

RF05 Gestión de Historias Se debe permitir la apertura, 5
Clínicas actualización o baja de las historias

relacionados RF06 Realizar Presupuesto

clínicas.
Debe permitir la realización de
presupuesto de acuerdo al plan de
5

con los servicios

tratamiento y al paciente.
RF07 Diseño del plan de Debe permitir diseñar el plan de 5
tratamiento tratamiento de acuerdo a los

especificos del
resultados del examen clínico dental
y al criterio del odontólogo.
RF08 Mantenimiento Debe permitir el mantenimiento de 2
Generales tratamientos, pacientes

sistema a RF09 Programación de citas El sistema debe permitir una

administración adecuada
horarios de atención asignando un
de
4

implementar.
espacio para la atención del cliente.
RF10 Manejo de descuentos Debe permitir la realización de 3
descuentos por parte del odontólogo
de acuerdo a los pacientes.
RF11 Registrar resultados de El sistema debe permitir registrar 5
intervención los resultados después de cada
intervención así como las
observaciones.
RF12 Manejo de Debe permitir a los odontólogos el 5
Odontogramas manejo de odontogramas
permitiéndole modificar, guardar los
datos necesarios como los estados
de las piezas dentales.
RF13 Control de Ingresos El sistema debe permitir el calculo 3
de los ingresos percibidos durante el
mes
RF14 Registro de Gastos El sistema debe permitir el registro
de todos los gastos realizados
3
76
Fase II \ Actividad 1 \ Tarea 2

ASI 1.2 Obtención de Requerimientos

Número Requerimiento Descripción Prioridad
RNF01 Avisar de error en la Cualquier error en la ubicación de la 4
Base de Datos base de datos principal o secundaria
debe ser señalada durante el
 Requerimientos No RNF02
acceso al sistema
Copia de Seguridad del El sistema debe permitir grabar 3

Funcionales
sistema semanalmente una copia de
seguridad de la base de datos así
como su recuperación.
 Son los RNF03 Reparar base de Datos Debe permitir compactar
contenido de la base de datos
el 3

relacionados con desechando los registros eliminados

y reconstruyendo los índices.
las caractersiticas RNF04 Visualización de El sistema debe mostrar una 5
especiales del Odontograma pantalla amigable
encuentre el odontograma.
donde se

sistema a RNF05 Facilidad en el ingreso Debe permitir

de información
el manejo de 4
al símbolos estándares así como el
implementar, tales odontograma uso fácil del Mouse para la
asignación de estos.
como rendimiento, RNF06 Acceso a la información Solo las personas autorizadas 3
deben tener acceso a la
seguridad, información, por tanto todas las
personas que requieren información
escalabilidad, etc del sistema deberán validarse.
RNF07 Disponibilidad de Durante los horarios fuera de oficina 3
información solo se podrá tener acceso a la
información solo para su lectura.
RNF08 Tiempo de respuesta El sistema debe responder a la 4
petición del usuario en un tiempo no
mayor a 5 segundos.
RNF09 Disponibilidad de La información de un paciente debe 5
información de paciente estar disponible para los diferentes
módulos que se utilizan durante su
atención 77
Fase II \ Actividad 1 \ Tarea 3

ASI 1.3 Obtención del Modelo de

Casos de Uso del Sistema.

 Se elabora el
Diagrama y
la
descripción
de los CU del
Sistema.

78
Fase II \ Actividad 1 \ Tarea 3

Relación entre CU Negocio y CU

Sistema

Negocio

Sistema

79
Fase II \ Actividad 1 \ Tarea 3

CU del Sistema - Descripción

Caso de Uso: Apertura de historia clínica.
Actores Principales: Asistente
Personal involucrado e intereses:
o Asistente: Quiere guardar información personal del paciente, así como antecedentes
clínicos.
o Paciente: Requiere un servicio que es suministrado por el odontólogo. Desea que sus
datos queden registrados correctamente para su debido control.
o Odontólogo: Requiere que la información del paciente sea precisa para que pueda
realizar las intervenciones adecuadamente.

Precondiciones: El paciente solicita un servicio clínico dental, autentificación del asistente.

Postcondiciones: La información quede registrada correctamente en una nueva historia

clínica.
Escenario principal de Éxito -Flujo Básico:

1. El Asistente solicita apertura de historia clínica

2. El sistema apertura una historia clínica, muestra pantalla de historia y pantalla de
paciente.
3. El asistente ingresa datos del paciente.
4. El sistema registra los datos del paciente.
5. El asistente ingresa datos de la historia.
6. El sistema registra los datos de historia

Extensiones:

a.- En cualquier momento el sistema falla:

Para dar soporte a la recuperación y registro correcto, asegura que todos los estados y
eventos significativos de una transacción puedan recuperarse desde cualquier paso del
escenario.
1. El asistente reinicia el sistema. Inicia la sesión y solicita la recuperación al estado
anterior.
2. El sistema reconstruye el estado anterior
2. a.- El sistema detecta anomalías intentando la recuperación.
1. El sistema informa del error al asistente, registra el error, y pasa a un estado

Flujo de Eventos
limpio.
2. El asistente comienza una nueva apertura de historia clínica.
1-3.a.-El paciente le pide al asistente que cancele la apertura de historia clínica.
1.- El asistente cancela la apertura de historia clínica.
4. a.- El sistema encuentra algún fallo para comunicarse con la base de datos.
1.-El sistema reinicia el servicio y continua
1. a.- El sistema detecta que el servicio no se reinicia.
1.- El sistema señala el error.
2.- El asistente cancela la apertura de historia clínica.
6. a.- El sistema encuentra algún fallo para comunicarse con la base de datos.
1.-El sistema reinicia el servicio y continua
1. a.- El sistema detecta que el servicio no se reinicia.
1.- El sistema señala el error.
2.- El asistente cancela la apertura de historia clínica.

REQUERIMIENTO ASOCIADO
RF02 Registro de pacientes
80
RF05 Gestión de historias clínicas.
Fase II \ Actividad 1 \ Tarea 4

ASI 1.4 Especificación de la

Interface de Usuario

 Se realiza un
prototipo de
las pantallas
del sistema.

81
 Fase II \ Actividad 1 \ Tarea 5

ASI 1.5 Identificación de Perfiles

y Diálogos
 Se identifican los perfiles para cada rol establecido.
 Ejemplos

1. Nombre del Perfil: Asistente

2. Opciones a las que tiene acceso
Programación de citas, apertura de historias clínicas, registro de pagos, registro
de intervención,

3. Tipo de Acceso: Lectura, Modificación, eliminación e Inserción

82
Fase II \ Actividad 1 \ Tarea 6

ASI 1.6 Especificación de

Formatos de Impresión
 Se especifica los formatos y caracteristiacs de las salidas o
entradas impresas del sistema.

83
 Analisis y Diseño de Sistemas

FIN Sesión 11

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com 84