Embed Size (px)
Citation preview
IDAT
Ing: Carlos Díaz Sánchez
Capítulo 4:
Requisitos
Temas:
1. Disciplina RUP de Requisitos
2. Modelado de Casos de Uso
IDAT
Requisitos
1. Disciplina RUP de Requisitos
IDAT
REQUISITOS
1. Disciplina RUP de Requisitos
1.1 Introducción
1.2 RUP. Workflow del proceso
1.3 Actividades del Workflow
IDAT
1.1. INTRODUCCIÓN
Un requerimiento es considerado una condición o capacidad a la que se debe
ajustar el sistema que se está desarrollando
IDAT
1.1. INTRODUCCIÓN
Finalidad:
Establecer y mantener un acuerdo con los clientes y otros
interesados, acerca de lo que debe hacer el sistema.
Proporcionar desarrolladores de sistema con un buen
conocimiento de los requisitos del sistema.
Definir los límites del sistema (delimitarlo).
Proporcionar una base para planificar el contenido técnico
de las iteraciones.
Proporcionar una base para la estimación del coste y del
tiempo en que desarrollar el sistema.
Definir una interfaz de usuario para el sistema,
centrándose en las necesidades y los objetivos de los
usuarios.
1. Disciplina RUP de Requisitos
IDAT
1.2. DISCIPLINA RUP: REQUIREMENTS
1. Disciplina RUP de Requisitos
IDAT
1.2.1. ROLES EN EL MODELADO DE
REQUISITOS
El Analista de Sistemas
El Arquitecto de software
El Especificador de Requisitos
El revisor técnico
1.2. Disciplina RUP: Requirements
IDAT
1.2.2. WORKFLOW
1.2. Disciplina RUP: Requirements
IDAT
1.2.3. PRODUCTOS DE TRABAJO / ARTEFACTOS
1.2. Disciplina RUP: Requirements
IDAT
MAPEO ENTRE MODELOS
1.2. Disciplina RUP: Requirements
IDAT
1.3. ACTIVIDADES DEL WORKFLOW
Analizar el problema.
Conocer las necesidades
de los stakeholders.
Definir el sistema.
Gestionar el ámbito del
sistema.
Perfeccionar la definición
del sistema.
Gestionar cambios de
requisitos.
1. Disciplina RUP de Requisitos
IDAT
1.3.1. IDENTIFICAR REQUERIMIENTOS
1.3. Actividades del Workflow
REQUERIMIENTOS
Business Use Case Model Business Analysis Model
Business Rules
Stakeholders Request
IDAT
1.3.1. IDENTIFICAR REQUERIMIENTOS
Técnicas de captura de
requerimientos:
Entrevistas.
Cuestionarios.
Encuestas.
Descripción de puestos.
Artefactos del Modelado de
Negocio.
Revisar los documentos
actuales.
1.3. Actividades del Workflow
IDAT
1.3.2. TIPOS DE REQUERIMIENTOS
1.3. Actividades del Workflow
REQUERIMIENTOS
FUNCIONALES NO FUNCIONALES
También están los pseudo_requerimientos, que
son aquellos requerimientos impuestos por el
cliente que restringen la implementación del
sistema.
IDAT
1.3.2. TIPOS DE REQUERIMIENTOS
Requerimientos Funcionales Son los requerimientos del usuario que el
sistema a desarrollar, debe satisfacer, indicando cuáles son las condiciones de entrada (inputs) y las condiciones de salida (outputs).
Requerimientos No Funcionales Son características que el sistema debe
tener para poder asegurar la calidad del sistema.
1.3. Actividades del Workflow
IDAT
A. REQUERIMIENTOS FUNCIONALES
Definición:
Especifican las condiciones que deben ser cumplidas por el sistema.
Se identifican desde el punto de vista del cliente.
Se redactan en lenguaje natural.
Se capturan en dos artefactos.
○ Especificación de Requerimientos de Software.
○ Modelo de Casos de Uso de Sistema.
1.3.2. Tipos de requerimientos
IDAT
A. REQUERIMIENTOS FUNCIONALES
Asociados a los casos de uso del sistema Ejemplo:
○ El sistema debe actualizar la información de los
profesores que dictan los cursos de baile.
○ El sistema permitirá registrar los horarios de
dictado de clase definidas por el administrador.
○ Se podrá Consultar la programación del rol de
los campeonatos locales y regionales.
○ El sistema debe permitir Cerrar un curso.
1.3.2. Tipos de requerimientos
IDAT
A. REQUERIMIENTOS FUNCIONALES
Asociados a otros aspectos generales.
Ejemplo:
○ El sistema debe obligar al usuario a cambiar su contraseña cada 60 días.
○ Se debe incluir un mecanismo que permita su actualización automática sin la intervención del usuario.
○ Deberá contener un registro de los errores y para cada uno, debe registrar: el código del error, una descripción del error, la fecha y la hora del error.
1.3.2. Tipos de requerimientos
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
1.3.2. Tipos de requerimientos
REQUERIMIENTOS
NO FUNCIONALES
REQUERIMIENTOS
ORGANIZACIONALES
REQUERIMIENTOS
DEL PRODUCTO
REQUERIMIENTOS
EXTERNOS
REQUERIMIENTOS
DE USABILIDAD
REQUERIMIENTOS
DE EFICIENCIA
REQUERIMIENTOS
DE FIABILIDAD
REQUERIMIENTOS
DE PORTABILIDAD
REQUERIMIENTOS
DE DESEMPEÑO
REQUERIMIENTOS
DE ESPACIO
REQUERIMIENTOS
DE ENTREGA
REQUERIMIENTOS
DE
IMPLEMENTACION
REQUERIMIENTOS
DE ESTÁNDARES
REQUERIMIENTOS DE
INTEROPERABILIDAD
REQUERIMIENTOS
LEGALES
REQUERIMIENTOS
ETICOS
REQUERIMIENTOS
DE PRIVACIDAD
REQUERIMIENTOS
DE SEGURIDAD
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
Algunas de las categorías:
Usabilidad: Fácil uso, estética y estándar de la interfaz, documentación de usuario, materiales de capacitación.
Fiabilidad: Exactitud en los cálculos del sistema, seguridad contra fallas, capacidad de recuperación y/o corrección de errores del usuario, predicción de resultado antes de ejecutar la operación.
Eficiencia: Rapidez, tiempo de espera, demora en cálculos, capacidad de memoria.
1.3.2. Tipos de requerimientos
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
Usability (Usabilidad – Facilidad de uso)
Ejemplo.
El lenguaje empleado en la interfaz gráfica del sistema
debe respetar los términos usados en el negocio.
El sistema permitirá a los usuarios realizar búsquedas sin
entrenamiento previo.
1.3.2. Tipos de Requerimientos
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
Reliability (Confiabilidad o Fiabilidad)
Ejemplo.
El sistema debe estar disponible 24x7x365 días al año.
El sistema estará disponible al 95 por ciento entre las
8:00 AM y las 6:00 PM
1.3.2. Tipos de Requerimientos
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
Performance. (Rendimiento)
Ejemplo:
El sistema debe permitir al administrador registrar una
matrícula como promedio en 30 segundos.
Durante el proceso de matrícula, el sistema permitirá el
acceso concurrente de 500 alumnos.
El sistema permitirá almacenar la información de hasta
4000 alumnos.
El 95 por ciento de las transacciones del sistema no
deben exceder los 5 segundos
1.3.2. Tipos de Requerimientos
IDAT
B. REQUERIMIENTOS NO FUNCIONALES
Supportability (Soporte)
Ejemplo.
El cliente Web del sistema debe soportar los siguientes navegadores:
○ Microsoft Internet Explorer 7.0 o superior
○ FireFox 1.5 o superior para Linux y para Windows
El sistema debe ser compatible con Windows 2003 profesional y Windows XP.
El sistema debe permitir a un usuario su instalación sin entrenamiento previo.
1.3.2. Tipos de Requerimientos
IDAT
Requisitos
2. Modelado de Casos de Uso
IDAT
REQUISITOS
2. Modelado de Casos de Uso
2.1 Elementos
2.2 Diagrama de Casos de Uso
2.3 Estructura del diagrama
2.4 Documentación de los Casos de Uso
División de Alta Tecnología - DAT
IDAT
2.1. ELEMENTOS
2. Modelado de Casos de Uso
ELEMENTO NOTACIÓN UML
Actor
Casos de Uso
IDAT
2.1.1. ACTOR
El actor representa un ROL, no
es un usuario individual del
sistema.
Un actor es cualquier cosa que
intercambia datos con el sistema.
Un actor puede ser un usuario,
hardware externo u otro sistema
2.1. Elementos
IDAT
Los actores se determinan observando:
Usuarios directos del sistema.
Trabajadores y/o Actores del Negocio.
Responsables del uso o mantenimiento del sistema.
Otros sistemas que interactúan con el sistema.
El nombre del actor describe el papel desempeñado.
2.1. Elementos
IDAT
2.1.1. ACTOR
Preguntas para ayudar a identificar mas actores:
¿Quién usará la funcionabilidad principal del sistema?
¿Quién está interesado en cierto requerimiento?
¿Quién se beneficia con el uso del sistema?
¿Quién administrará, soportará y mantendrá el sistema?
¿El sistema usa un recurso externo?
¿Alguna persona juega varios roles diferentes?
¿El sistema interactúa con otro sistema?
2.1. Elementos
IDAT
2.1.1. ACTOR
Sugerencias para identificar actores del sistema:
Son roles (humanos, software o hardware), no personas
con nombres propios.
No siempre están asociado con el nombre de un cargo en la planilla de la organización objetivo.
El nombre no debe representar áreas, departamentos o partes de una organización sino roles de ejecución.
Cada actor debe estar asociado con al menos, un caso de uso del sistema; caso contrario, debe ser eliminado del modelo.
2.1. Elementos
IDAT
2.1.2. CASO DE USO
Un caso de uso es un proceso
específico del sistema con
identidad propia que define una
secuencia de acciones que el
sistema realiza para un actor en
particular.
Los casos de uso recopilados
constituyen todos los modos
posibles de utilizar el sistema.
2.1. Elementos
IDAT
2.1.2. CASO DE USO
2.1. Elementos
Realización de Casos de Uso de Negocio
Mapeo para obtener Casos
de Uso (sistema)
IDAT
2.1.2. CASO DE USO
Cada Caso de uso debe tener un
nombre que indique lo que se ha
conseguido por medio de sus
interacciones con los actores.
Dos casos de uso no pueden tener el
mismo nombre.
Nombre: verbo + objeto afectado
2.1. Elementos
Registrar Cliente
IDAT
2.1.2. CASO DE USO
El proceso va relacionado con la identificación de
actores.
Por cada actor identificado se podrá preguntar:
¿Cuáles son las tareas automatizables del actor?
¿Qué información crea, guarda, modifica, destruye o
lee?
¿El actor debe notificar al sistema los cambios
externos?
¿El sistema debe informar al actor los cambios
internos?
2.1. Elementos
IDAT
2.1.2. CASO DE USO
Caso de Uso Vs. Requerimiento Funcional.
Existe una correspondencia directa entre
ambos. La diferencia radica en la manera en que
describen la necesidad de funcionalidad.
○ Los RF se describen desde la perspectiva del usuario o cliente del proyecto.
○ Los CUS se describen desde la perspectiva de la arquitectura del sistema.
2.1. Elementos
IDAT
2.2. DIAGRAMA DE CASOS DE USO
Los diagramas con actores, casos de uso y relaciones entre ellos se denominan diagramas de casos de uso e ilustran las relaciones en el modelo de casos de uso.
2. Modelado de Casos de Uso
IDAT
uc Atencion al publico
Cajero
Registrar Retiro
Consultar Tipo de Cambio
Registrar Deposito
2.2 DIAGRAMA DE CASOS DE USO
Representa lo que hace el sistema y su relación con el entorno, desde el punto de vista del usuario.
Son iniciados por un agente externo: El Actor.
Describen lo que hace el actor y lo que hace el sistema al interactuar.
Están limitados a una sola tarea.
Muestra gráficamente los requerimientos funcionales del sistema.
2. Modelado de Casos de Uso
IDAT
2.2 DIAGRAMA DE CASOS DE USO
Se tiene en cuenta “¿QUIÉN realiza QUÉ actividad?”
¿QUIÉN? (actor del sistema identificado).
¿QUÉ? (caso de uso identificado).
Relaciones entre ellos (asociaciones).
No constituye un Diagrama de Flujo de Datos.
2. Modelado de Casos de Uso
IDAT
2.2.2. ASOCIACIÓN
Características: Los actores se conectan a los casos de uso, a través de
una relación de asociación.
Esta relación se estereotipa como «comunicates» pero
no es necesario indicarla.
2.2 DIAGRAMA DE CASOS DE USO
Uc Casos de Uso
Actor
Caso de uso
IDAT
LABORATORIO
En este laboratorio, usted: Identificará los Requerimientos Funcionales y no
Funcionales de un proyecto.
Reconocerá el ambiente de la herramienta para
modelado de Casos de Uso.
Reconocerá los elementos del Modelo: Actor, Casos de
Uso, Relaciones.
Colocará los elementos de la versión 2.4 de UML.
División de Alta Tecnología - DAT
IDAT
2.3. ESTRUCTURA DEL DIAGRAMA
Se estructura el modelo de casos de uso para que los
requisitos sean más fáciles de entender y mantener. Esto
incluye promover la similitud entre los casos de uso y los
actores e identificar el comportamiento opcional y
excepcional.
2. Modelado de Casos de Uso
IDAT
2.3. ESTRUCTURA DEL DIAGRAMA
Objetivos:
Encontrar comportamiento similar o común
en el Modelo de Casos de Uso del Sistema.
Identificar actividades básicas o alternas
que se repitan en los casos de uso.
Identificar actores que comparten roles
ejecutados por otros.
2. Modelado de Casos de Uso
IDAT
2.3.1. RELACIÓN INCLUDE
Es una relación de dependencia entre
dos casos de uso.
2.3. Estructura del diagrama
IDAT
2.3.1. RELACIÓN INCLUDE
Características:
Se establece cuando el caso de uso base necesita incluir
obligatoriamente la secuencia de acciones descritas por
el caso de uso incluido.
Indica que el comportamiento del caso de uso incluido
está explícitamente insertado dentro del comportamiento
definido por el caso de uso base.
El caso de uso base es el que conoce la asociación entre
ambos y el caso de uso incluido, no necesita conocer
cuáles casos de uso lo incluyen.
Se utiliza el estereotipo «include» .
2.3. Estructura del diagrama
IDAT
2.3.1. RELACIÓN INCLUDE
En el proceso de abastecimiento de una empresa, se cuenta
con dos casos de uso que comparten una función común:
actualizar el stock de productos sumando o restando el
movimiento efectuado.
2.3. Estructura del diagrama
Almacenero
Registrar
recepcion de productos
Despachar productos
Actualizar Stock
«Include»
«Include»
IDAT
2.3.1. RELACIÓN INCLUDE
En la documentación: Flujo Básico
○ 1. ...
○ 2. ...
○ ...
○ 6. El sistema actualiza el stock de cada
producto. Incluir el caso de uso “Actualizar
stock” del producto.
2.3. Estructura del diagrama
IDAT
NO ES INCLUDE !!!
2.3. Estructura del diagrama
Bibliotecario
Gestionar
Biblioteca
Mantener Libros
Mantener Peticiones
Mantener Prestamos
Añadir Libro
Eliminar Libro
Añadir Peticion
Eliminar Peticion
Prestar Libro
Devolver Libro
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
IDAT
2.3.2. RELACIÓN EXTEND
Es una relación que se ejecuta bajo
ciertas condiciones.
2.3. Estructura del diagrama
Devolver ejemplar
_________________
Fecha retrasada
Aplicar Mora
«extends»
IDAT
2.3.2. RELACIÓN EXTEND
Es una relación de dependencia entre dos casos de
uso.
Se establece cuando el caso de uso extendido ocurre
excepcionalmente en el caso de uso base.
El caso de uso extendido ocurre sólo cuando ocurra el
evento respectivo dentro del caso de uso base.
Indica que el comportamiento del caso de uso
extendido puede ser insertado en el comportamiento
definido por el caso de uso base.
2.3. Estructura del diagrama
IDAT
2.3.2. RELACIÓN EXTEND - EJEMPLO
El Caso de Uso Registrar venta
en un supermercado, tiene una
función adicional si el cliente
presenta su tarjeta de
acumulación de puntos.
Las acciones para “Actualizar
puntos” sólo se presentan si el
cliente tiene la tarjeta en
mención y deben separarse en
un caso de uso independiente.
2.3. Estructura del diagrama
vendedor
Registrar Venta
_______________
Si presenta tarjeta
Actualizar puntos
«extends»
IDAT
2.3.2. RELACIÓN EXTEND
Documentación.
Flujo Alternativo.
○ 1. ...
○ 2. ...
○ .....
○ 8. Si el cliente posee Tarjeta de acumulación
de puntos, entonces se actualizan sus puntos.
Extender el caso de uso “Actualizar puntos”.
2.3. Estructura del diagrama
IDAT
2.3.3. ASOCIACIÓN DE TIPO GENERALIZACIÓN
La generalización de casos de uso se utiliza cuando tiene
uno o más casos de uso, que son realmente
especificaciones o un caso más general.
2.3. Estructura del diagrama
Validar Usuario
Validar con
passwordExaminar Retina
«inherits»«inherits»
IDAT
2.3.3. ASOCIACIÓN DE TIPO GENERALIZACIÓN
Es una relación de herencia entre casos
uso.
Los casos de uso hijos heredan la
estructura, comportamiento y
asociaciones del caso de uso padre.
El caso de uso padre es abstracto y
sólo se crean instancias de los casos de
uso hijos.
2.3. Estructura del diagrama
IDAT
EJEMPLO Registrar una orden de
pedido.
“Registrar pedido por
teléfono” y “Registrar pedido
por Internet” tienen acciones
iguales que pueden
generalizarse en “Registrar
Pedido”.
Los hijos heredan la
estructura, comportamiento y
asociaciones del padre.
2.3. Estructura del diagrama
Registrar Pedido
Operador
Registrar pedido telefonico
Cliente de Internet
Registrar Pedido por Internet
IDAT
2.3.3. ASOCIACIÓN DE TIPO GENERALIZACIÓN
¿Cuándo utilizar la generalización?
Cuando existen dos o más casos de uso
que poseen un comportamiento y estructura
muy común.
Las actividades comunes son llevadas hacia
un caso de uso padre o generalizado.
Las actividades diferentes y particulares se
quedan en los casos de uso hijos.
2.3. Estructura del diagrama
IDAT
2.3.4. GENERALIZACIÓN ENTRE ACTORES
El actor hijo hereda el rol representado
por el actor padre en la relación.
2.3. Estructura del diagrama
Hijo
Padre
«inherits»
IDAT
2.3.4. GENERALIZACIÓN ENTRE ACTORES
La asociación de tipo Generalización entre actores se da cuando:
Si existen dos o más actores que:
○ Interactúan o utilizan el sistema de la misma forma.
○ Juegan el mismo rol frente al sistema.
Entonces es posible.
○ Establecer una relación de Generalización entre ellos.
○ Simplificar el modelo de Casos de Uso.
2.3. Estructura del diagrama
IDAT
EJEMPLO
2.3. Estructura del diagrama
Comprador
Vendedor
Comprar productos
Vender productos
________________
Si tiene Tarjeta
Actualizar Stock
«include»
«include»
Actualizar Tarjeta
Bonus
«extends»
uc Comercializacion
Supervisor
Registrar
Incidencias
«inherits»
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Los casos de uso están documentados
en un artefacto llamado Use Case
Specification
2. Modelado de Casos de Uso
Anular Pedido
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Objetivo:
Describir en resumen el flujo de actividades
de cada caso de uso del sistema.
Asegurarse de que los actores del sistema
respectivos obtengan el resultado
esperado.
Se documenta a través de la Especificación
de alto nivel de casos de uso del sistema.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Elementos:
Nombre: El nombre del caso de uso.
Descripción breve: Una descripción breve
del rol y el objetivo del caso de uso.
Flujo básico: Una descripción textual de lo
que hace el sistema respecto al caso de uso
(no cómo se resuelven los problemas
específicos en el sistema). La descripción
es comprensible para el cliente.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Elementos:
Requisitos especiales: Una descripción textual
que recopila todos los requisitos, como
requisitos no funcionales, sobre el caso de uso,
que no se consideran en el modelo de casos de
uso, pero que deben cuidarse durante el diseño
o implementación.
Condiciones previas: Una descripción textual
que define una restricción en el sistema cuando
el caso de uso puede empezar.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Elementos:
Condiciones posteriores: Una descripción textual que define una restricción en el sistema cuando los casos de uso han terminado.
Puntos de extensión / ampliación: Una lista de ubicaciones dentro del flujo de sucesos del caso de uso en el que se puede insertar un comportamiento adicional utilizando la relación de ampliación.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Elementos:
Relaciones: Las relaciones, como asociaciones de
comunicación, Include, Generalización y Extend,
donde participa el caso de uso.
Diagramas de actividad: Estos diagramas ilustran
la estructura del flujo de sucesos.
Diagramas de caso de uso: Estos diagramas
muestran las relaciones que implican al caso de
uso.
Otros diagramas: Otras ilustraciones gráficas del
caso de uso.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
¿Qué se incluye en una especificación?
Definir el estado inicial.
Cómo y cuándo comienza el caso de uso.
El orden requerido en que las acciones se
ejecutarán.
Cómo y cuándo terminan los casos de uso.
Definir los posibles estados finales.
Las ejecuciones no permitidas.
Describir explícitamente lo que hace el sistema.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Ejemplo: Sistema de Ventas de Ferretería
Caso de Uso:
Registrar Pedido
Resumen:
El vendedor registra en el sistema un Pedido realizado
por el cliente
Actor:
Vendedor
2. Modelado de Casos de Uso
uc Use Case View
Vendedor
Registrar Pedido
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Pre Condiciones:
Se tienen ingresado los artículos a vender [CU: Ingresar
Productos].
Los precios de los artículos y su stock están actualizados
con cada compra realizada [CU: Actualizar Precio]
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Descripción:
(El cliente solicita un artículo.)
El caso de uso empieza cuando el vendedor registra el pedido.
El sistema muestra en pantalla la fecha y obtiene los datos necesarios.
El vendedor ingresa el código del cliente.
El sistema valida la existencia del cliente usando el caso de uso Incluido: [CU validar cliente]
El vendedor ingresa cada producto a cotizar.
El sistema muestra el precio del producto ingresado y va acumulando el importe.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Descripción:
El vendedor da por concluido el ingreso de productos y da la orden de mostrar la cotización.
El sistema muestra una cotización por pantalla.
El vendedor da la orden de emitir una orden de pedido con la cotización de la pantalla.
El sistema graba la cotización con un número de orden de Pedido nuevo.
El sistema muestra el número generado.
El sistema imprime la Orden de Pedido.
El caso de Uso termina cuando la Orden de Pedido está registrada (Posteriormente, podrá ser cancelada-pagada o Anulada).
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Puntos de Extensión:
Si el vendedor o cliente no recuerda su código, el
vendedor puede escoger la opción de consultar clientes.
El sistema llama a una interfaz para consultar los datos
del cliente. [Extender CU: Consultar Cliente]
El sistema almacena los datos del cliente.
El sistema retorna a la pantalla anterior.
2. Modelado de Casos de Uso
IDAT
2.4. DOCUMENTACIÓN DE LOS CASOS DE USO
Post Condiciones:
Una Orden de Pedido ha sido emitida.
El stock de los artículos ha sido actualizado (stock
comprometido aumentado y cambiará definitivamente
cuando cancele la orden)
Resumen de Excepciones:
El cliente decide no comprar. El vendedor cancela la
cotización y el caso de uso termina.
2. Modelado de Casos de Uso
IDAT
CONCLUSIONES
La identificación de los requerimientos funcionales llevará a
la proyección de las funciones del sistema.
La descripción de los requerimientos no funcionales
facilitarán la construcción de la plataforma del sistema.
La construcción del Modelo de Casos de Uso del Sistema
permitirá la definición de la arquitectura del sistema.
División de Alta Tecnología - DAT
IDAT
