Ir b c

INGENIERÍA DE
REQUERIMIENTOS
ACTIVIDADES DE LA ING DE REQUERIMIENTOS – B y C

ingeniería de requerimientos
2 / 88
Ing. Williams A. Muñoz Robles
UNDAC – Escuela de sistemas y Computación
Ingeniería de Sistemas y Computacion
PROGRAMACION DE SISTEMAS
priorizar casos de uso
priorización de casos de uso
determinar cuáles son necesarios
para el desarrollo en las primeras
iteraciones y cuáles pueden
dejarse para posteriores
iteraciones
cuestiones a tener en cuenta:
casos de uso con dificultad de
desarrollo
casos de uso imprescindibles
para la puesta en marcha del
sistema
organización del desarrollo
incremental
disponibilidad de equipo de
desarrollo
se revisa la priorización con el jefe
de proyecto y se utiliza como
entrada para la planificación de
cada iteración del proyecto
Encontrar actores y
casos de uso
Estructurar el modelo
de caso de uso
Priorizar los
casos de uso
Detallar un caso
de uso
Prototipar la interfaz
de usuario
: Diseñador de interfaces de usuario: Especificador de casos de uso: Arquitecto: Analista de sistemas

3 / 88
detallar los casos de uso
objetivo principal: describir su
flujo de sucesos en detalle
cómo comienza
cómo termina
cómo interactúan con los actores
se detalla paso a paso la
secuencia de acciones del caso de
uso
se trabaja estrechamente con los
usuarios reales de los casos de
uso
resultado: descripción detallada
mediante
texto
diagramas
Encontrar actores y
casos de uso
Estructurar el modelo
de caso de uso
Priorizar los
casos de uso
Detallar un caso
de uso
Prototipar la interfaz
de usuario
: Diseñador de interfaces de usuario: Especificador de casos de uso: Arquitecto: Analista de sistemas

4 / 88
secciones de la descripción del caso de uso (1)
actor principal: actor que recurre a los servicios del sistema para
cumplir un objetivo
personal involucrado y lista de intereses
el caso de uso captura todo y sólo el comportamiento relacionado con la
satisfacción de los intereses del personal involucrado
ejemplo:
Cajero: quiere entradas precisas, rápidas y sin errores de pago, ya que las pérdidas se
deducen de su salario.
Vendedor: quiere que las comisiones de ventas estén actualizadas
precondiciones:
establecen lo que siempre debe cumplirse antes de comenzar un escenario en el
caso de uso.
no se prueban en el caso de uso, sino que son condiciones que se asumen que
son ciertas.
normalmente una precondición implica un escenario de otro caso de uso que se
ha completado con éxito, como “inicio de sesión”, o “validación de usuario”.
ejemplo: el cajero se identifica y el sistema lo autentifica.
postcondiciones:
establecen qué debe cumplirse cuando el caso de uso se completa con éxito
(bien el escenario principal de éxito o algún camino alternativo)
ejemplo: se registra la venta. El impuesto se calcula de manera correcta. Se
actualizan la Contabilidad y el Inventario. Se registran las comisiones. Se genera
el recibo.

5 / 88
escenario principal de éxito (o flujo básico)
describe el camino de éxito típico que satisface los intereses del
personal involucrado
no suele incluir condiciones o bifurcaciones
recoge los pasos, que pueden ser de tres tipos:
una interacción entre actores
una validación (normalmente a cargo del sistema)
un cambio de estado realizado por el sistema (por ejemplo, registrando
una venta o modificando un registro de la base de datos)
el primer paso indica el evento que desencadena el comienzo del
escenario
ejemplo:
1. El Cliente llega a un terminal PDV con mercancías para comprar
2. El Cajero comienza una nueva venta.
3. El Cajero introduce el identificador del artículo.
4. ...
El Cajero repite los pasos 3-4 hasta que se indique
5. ...

6 / 88
extensiones (o flujos alternativos)
indican todos los otros escenarios o bifurcaciones, tanto de éxito
como de fracaso.
la combinación del escenario principal y los escenarios de extensión
deberían satisfacer casi todos los intereses del personal involucrado
(algunos intereses se documentan como requisitos no funcionales)
ejemplos:
3a. Identificador no válido
1. El Sistema señala el error y rechaza la entrada
3b. Hay muchos artículos de la misma categoría y tener en cuenta una única
identidad del artículo no es importante (por ejemplo, 6 cajas de leche de
la misma marca).
1. El Cajero puede introducir el identificador de la categoría del artículo y la cantidad
un flujo alternativo tiene dos partes:
condición: algo que puede ser detectado por el sistema o el actor (el
Sistema detecta un fallo de comunicación con el sistema de actualización
de inventario)
manejo: se puede resumir en un paso o bien incluir una secuencia:
3-6a. El Cliente le pide al Cajero que elimine un artículo de la compra:
1. El Cajero introduce el identificador del artículo para eliminarlo de la compra
2. El Sistema muestra la suma parcial actualizada
si una extensión es muy compleja, se puede expresar como un caso de uso
aparte
pueden incluirse condiciones de extensión que se pueden dar durante cualquiera
de los pasos (por ejemplo, el sistema falla, o el Cliente cancela la compra)

7 / 88
requisitos especiales
se recoge cuando un requisito no funcional, atributo de calidad o
restricción se relaciona de manera específica con un caso de uso
incluye cualidades como rendimiento, fiabilidad y facilidad de uso, y
restricciones de diseño (a menudo en dispositivos de entrada/salida)
que son obligados o se consideran probables.
ejemplo:
interfaz de usuario con pantalla táctil en un gran monitor de pantalla
plana. El texto debe ser visible a un metro de distancia
tiempo de respuesta para la autorización de crédito de 30 segundos al
menos en el 90% de los casos
en ocasiones resulta conveniente reunir al final todos los requisitos
no funcionales en una especificación complementaria

8 / 88
descripción del caso de uso
Nombre del caso de
uso: Pagar Factura
Actores participantes: Comprador (inicia)
Vendedor
Sistema de cuentas bancarias
Precondición: el comprador ha recibido los bienes y servicios y al menos una factura del sistema. El comprador ahora planifica el pago de
las facturas
Flujo de eventos:
Camino básico
1. El comprador invoca al caso de uso para comenzar a hojear las facturas recibidas del sistema. El sistema verifica
que el contenido de cada factura es consistente con las confirmaciones de pedido recibidas anteriormente (como
parte del caso de uso Confirmar Pedido) y así indicárselo al comprador. La confirmación de pedido describe qué
elementos serán enviados, cuándo, dónde y a qué precio.
2. El comprador decide planificar una factura para pagarla por banco, y el sistema genera una petición e pago para
transferir el dinero a la cuenta del vendedor. Hay que tener en cuenta que un comprador no puede planificar el
pago de la misma factura dos veces [A2].
3. Más tarde, si hay suficiente dinero en la cuenta del comprador, se hace un pago mediante transacción en la
fecha planificada. Durante la transacción, el dinero se transfiere de la cuenta del comprador a la del vendedor,
como se describe en el caso de uso abstracto Realizar Transacción (que es utilizado por Pagar Factura). Tanto
el comprador como el vendedor tienen notificación del resultado de la transacción. El banco recoge unos cargos
por la transacción, que se retiran de la cuenta del comprador [A3].
4. La instancia del caso de uso finaliza.
Caminos alternativos
[A2] En el paso 2, el comprador puede, en cambio, pedir al sistema que devuelva un rechazo de factura al
vendedor.
[A3] En el paso 3, si no hay suficiente dinero en la cuenta, el caso de uso cancelará el pago y se lo notificará al
comprador.
Postcondición: la instancia del caso de uso termina cuando la factura ha sido pagada o cuando el pago de la factura ha sido cancelado y
no se ha hecho ninguna transferencia.
Nombre del caso de
uso: Pagar Factura
Actores participantes: Comprador (inicia)
Vendedor
Sistema de cuentas bancarias
Precondición: el comprador ha recibido los bienes y servicios y al menos una factura del sistema. El comprador ahora planifica el pago de
las facturas
Flujo de eventos:
Camino básico
1. El comprador invoca al caso de uso para comenzar a hojear las facturas recibidas del sistema. El sistema verifica
que el contenido de cada factura es consistente con las confirmaciones de pedido recibidas anteriormente (como
parte del caso de uso Confirmar Pedido) y así indicárselo al comprador. La confirmación de pedido describe qué
elementos serán enviados, cuándo, dónde y a qué precio.
2. El comprador decide planificar una factura para pagarla por banco, y el sistema genera una petición e pago para
transferir el dinero a la cuenta del vendedor. Hay que tener en cuenta que un comprador no puede planificar el
pago de la misma factura dos veces [A2].
3. Más tarde, si hay suficiente dinero en la cuenta del comprador, se hace un pago mediante transacción en la
fecha planificada. Durante la transacción, el dinero se transfiere de la cuenta del comprador a la del vendedor,
como se describe en el caso de uso abstracto Realizar Transacción (que es utilizado por Pagar Factura). Tanto
el comprador como el vendedor tienen notificación del resultado de la transacción. El banco recoge unos cargos
por la transacción, que se retiran de la cuenta del comprador [A3].
4. La instancia del caso de uso finaliza.
Caminos alternativos
[A2] En el paso 2, el comprador puede, en cambio, pedir al sistema que devuelva un rechazo de factura al
vendedor.
[A3] En el paso 3, si no hay suficiente dinero en la cuenta, el caso de uso cancelará el pago y se lo notificará al
comprador.
Postcondición: la instancia del caso de uso termina cuando la factura ha sido pagada o cuando el pago de la factura ha sido cancelado y
no se ha hecho ninguna transferencia.

9 / 88
Nombre del caso de
uso: InformarEmergencia
Actores participantes: OficialCampo (inicia)
Controlador
Condición inicial: El OficialCampo activa la función Informar
Emergencia en su PDA
Flujo de eventos:
1. El sistema EMERGENCIAS responde presentando
un formulario al OficialCampo
2. El OficialCampo cubre el formulario, seleccionando
el nivel de emergencia, tipo, ubicación, y una breve
descripción de la situación. También describe
respuestas posibles a la situación de emergencia.
Una vez cubierto el formulario, el OficialCampo lo
envía y en ese momento se notifica al Controlador.
3. El Controlador revisa la información recibida y crea
un Incidente en la base de datos llamando al caso
de uso AbrirIncidente. El Controlador selecciona
una respuesta y da un acuse de recibo del informe
de emergencia.
4. El OficialCampo recibe el acuse de recibo y la
respuesta seleccionada.
Requerimientos
especiales: Se da acuse de recibo del informe del
OficialCampo en menos de 30 segundos. La
respuesta seleccionada llega en menos de 30 segundos
desde que la envía el Controlador.
Nombre del caso de
uso: InformarEmergencia
Actores participantes: OficialCampo (inicia)
Controlador
Condición inicial: El OficialCampo activa la función Informar
Emergencia en su PDA
Flujo de eventos:
un formulario al OficialCampo
2. El OficialCampo cubre el formulario, seleccionando
el nivel de emergencia, tipo, ubicación, y una breve
descripción de la situación. También describe
respuestas posibles a la situación de emergencia.
Una vez cubierto el formulario, el OficialCampo lo
envía y en ese momento se notifica al Controlador.
3. El Controlador revisa la información recibida y crea
un Incidente en la base de datos llamando al caso
de uso AbrirIncidente. El Controlador selecciona
una respuesta y da un acuse de recibo del informe
de emergencia.
Requerimientos
especiales: Se da acuse de recibo del informe del
OficialCampo en menos de 30 segundos. La
respuesta seleccionada llega en menos de 30 segundos
desde que la envía el Controlador.

10 / 88
refinamiento
se incorporan detalles al
caso de uso
se describe el flujo de
eventos en mayor detalle
se mejora la descripción
de las interacciones
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar
Emergencia en su PDA.
un formulario al OficialCampo. El formulario
incluye un menú de tipos de emergencia (incendio,
accidente, disturbios,...) y campos para introducir
la ubicación, descripción del incidente, petición de
recursos,...
3. El OficialCampo cubre el formulario, y puede
también describir respuestas posibles a la
situación de emergencia y solicitar recursos
específicos. Una vez que ha llenado el formulario,
el OficialCampo lo envía oprimiendo el botón
“Enviar Informe” y en ese momento se le notifica al
Controlador
4. Al Controlador se le notifica un nuevo informe de
incidente mediante un cuadro de diálogo
desplegable. El Controlador revisa la información
recibida y crea un Incidente en la base de datos
llamando al caso de uso AbrirIncidente. Toda la
información contenida en el formulario del
OficialCampo se incluye automáticamente en el
Incidente. El Controlador selecciona una respuesta
asignando recursos al incidente (con el caso de
uso AsignarRecursos) y da un acuse de recibo al
informe de emergencia enviando un mensaje
breve al OficialCampo.
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar
Emergencia en su PDA.
un formulario al OficialCampo. El formulario
incluye un menú de tipos de emergencia (incendio,
accidente, disturbios,...) y campos para introducir
la ubicación, descripción del incidente, petición de
recursos,...
3. El OficialCampo cubre el formulario, y puede
también describir respuestas posibles a la
situación de emergencia y solicitar recursos
específicos. Una vez que ha llenado el formulario,
el OficialCampo lo envía oprimiendo el botón
“Enviar Informe” y en ese momento se le notifica al
Controlador
4. Al Controlador se le notifica un nuevo informe de
incidente mediante un cuadro de diálogo
desplegable. El Controlador revisa la información
recibida y crea un Incidente en la base de datos
llamando al caso de uso AbrirIncidente. Toda la
información contenida en el formulario del
OficialCampo se incluye automáticamente en el
Incidente. El Controlador selecciona una respuesta
asignando recursos al incidente (con el caso de
uso AsignarRecursos) y da un acuse de recibo al
informe de emergencia enviando un mensaje
breve al OficialCampo.
Estación
OficialCampo
Estación
Controlador
Estación
OficialCampo

Ir b c

Más contenido relacionado

Destacado

Similar a Ir b c

Último

Ir b c