Modelado de Requisitos - 1ra parte 2022.pdf

Universidad Nacional del Oeste
Escuela de informática
Ingeniería de Software II
MODELADO DE REQUISITOS.
ESPECIFICACIÓN DE REQUISITOS
Ingeniería de Software II 1

Especificación de requisitos
▪ Proceso de escribir, en un Documento de Requisitos, los requerimientos y
requisitos.
▪ Idealmente los requisitos deben ser claros, sin ambigüedades, fáciles de entender,
completos y consistentes.
▪ Deben describirse los requisitos FUNCIONALES y NO FUNCIONALES.
▪ Solo se debe describir el comportamiento externo del sistema.
▪ NO es un documento de diseño, pero será imposible excluir toda la información de
diseño.
2

Formas para escribir una
especificación de requisitos.
3

Especificaciones en lenguaje natural
Es expresivo, intuitivo y universal, también vago, ambiguo y su significado depende
del lector.
Para minimizar interpretaciones erróneas, se puede:
▪ Elaborar un formato estándar: redactar el requisito en una sola oración, incluir las
razones por las que se propuso (puede agregarse quién lo propuso).
▪ Resaltar las partes claves del requisito.
▪ Evitar el lenguaje técnico de la Ingeniería de Software.
4

Especificaciones estructuradas
▪ Conserva la expresividad y comprensión del lenguaje natural pero asegurando
uniformidad en las especificaciones.
▪ Se emplean “plantillas” para especificar cada requisito.
5
Cuando sigue siendo complejo definir los requisitos
pueden incluirse modelos gráficos o tablas.

6
Escenarios
“Los escenarios describen secuencias narrativas que pueden
ser reales (reconstrucción de incidentes), deseadas (ilustración
de la aplicación satisfactoria de una política determinada) o
imaginadas pero no deseadas (ilustración de una política que
tiene que ser evitada).” (*)
(*) Anton, A., Earp, J., Potts, C., Alspaugh, T., “The Role of Policy an
Stakeholder Privacy Values in Requirements Engineering”, Proceedings of
Fifth IEEE International Symposium on Requirements Engineering, Toronto,
Canada, 2001, pp. 138-145.

7
Escenarios
“Los escenarios son casos particulares de uso del sistema”.
“Aunque los escenarios son útiles para adquirir y validar
requisitos, no son requisitos en si mismos. Describen el
comportamiento del sistema sólo en situaciones específicas.
Una especificación, en cambio, describe los que el sistema
debería hacer de una forma general.” (*)
(*) Potts, C., Takahashi, K., Antón, A. I., “Inquiry-Based Requirements
Analysis”, IEEE Software, Vol. 11, N° 2, 1994, pp. 21-32 .

8
Escenarios
“Una vez que el contexto ha sido establecido, el
próximo paso es determinar lo que se espera que el
sistema haga, y para quién y con quién lo hará. La
idea básica es especificar escenarios de uso que
cubran todos los posibles caminos a través de las
funciones del sistema.” (*)
(*) Rubin, K.S., Goldberg, J., “Object Behavior Analysis”, Communications of
the ACM, Vol. 35, N° 9, Sep. 1992.

9
Escenarios. Objetivos
ESCENARIOS: Describen situaciones específicas de la aplicación
centrando su atención en el comportamiento.
Objetivos:
▪ Capturar los requisitos.
▪ Proveer un medio de comunicación entre los stakeholders.
▪ Proveer un soporte para trazabilidad.

10
Escenarios: Componentes
▪ Título
▪ Objetivo
▪ Contexto
▪ Ubicación Geográfica
▪ Ubicación Temporal
▪ Precondiciones
▪ Recursos
▪ Actores
▪ Episodios
▪ Excepciones

11
Ejemplo de Escenario
Título: Entrega de pasaporte en el Box de Reválidas
Telefónicas
Objetivo: Entregar al solicitante el pasaporte solicitado
Contexto: Se efectúa en el Box de ReválidasTelefónicas
El solicitante debe haber iniciado el trámite telefónicamente
Se entrega el pasaporte dentro de las 24 horas desde que el
solicitante se lleva el talón
Actores: Solicitante
Empleado del Box de Reválidas Telefónicas
Recursos: Pasaporte
Talón
Episodios:
1. El solicitante llega al Box de Reválidas Telefónicas una vez
cumplido el plazo y entrega el talón
2. El empleado verifica que el pasaporte esté listo
3. El empleado entrega el pasaporte al solicitante
Excepciones:
SI el pasaporte tiene alguna observación ENTONCES
DERIVACIÓN DE PASAPORTES OBSERVADOS

12
Jerarquía de Escenarios
ESCENARIOS INTEGRADORES
ESCENARIOS
SUBESCENARIOS

¿Qué son los casos de uso?
• Técnica para especificar el comportamiento de un sistema.
• Secuencia de interacciones entre un sistema y alguien o algo (otro sistema o una máquina)
que usa alguno de sus servicios.
• Son una excelente forma de especificar el comportamiento externo del sistema.
• Su notación fue incorporada al lenguaje estándar de modelado UML (Lenguaje Unificado
de Modelado)
Como ejemplo:
En un sistema de ventas se debe ofrecer la posibilidad de ingresar un nuevo pedido
de un cliente. Cuando un usuario accede a ese servicio se está ejecutando el caso
de uso “Ingresando pedido”
13

▪ Los casos de uso, a pesar de ser considerados una técnica de Análisis
Orientado a Objetos, son independientes del método de diseño que
se utilice, y por lo tanto del método de programación.
▪ Es probable esperar que en el futuro los métodos de análisis y
diseño que prevalezcan adopten las principales ventajas de todos los
métodos disponibles actualmente
14
¿Qué son los casos de uso?

Tiene principalmente dos objetivos:
• Encontrar los verdaderos requisitos, los que “agreguen” el valor
esperado por los usuarios.
• Representar los requisitos de un modo adecuado (comprensible)
por usuarios y desarrolladores.
15
Captura de requisitos con
casos de uso

• Proporcionan un medio sistemático e intuitivo de capturar requisitos
funcionales, centrándose en el usuario.
• Dirigen todo el proceso de
desarrollo: todas las etapas pueden
plantearse en términos de
casos de uso.
16
¿Por qué casos de uso?

• Tomando la perspectiva de cada tipo de usuario, se pueden capturar los requisitos
que necesitan para realizar su trabajo.
• La pregunta clave: ¿Qué se quiere que haga el sistema para cada usuario?
• Los usuarios y clientes pueden participar del proceso junto a los desarrolladores.
• Permite conseguir un acuerdo con usuarios y clientes sobre que debería hacer el
sistema
17
Captura de REQUISITOS
con valor añadido
Puede utilizarse
como parte del
contrato con el cliente
Permiten delimitar
el sistema

• ACTORES
• CASOS DE USO
• ALTERNATIVAS
• RELACIONES DE EXTENSIÓN
• RELACIONES DE USO
18
DEFINICIONES BÁSICAS

• Es una agrupación uniforme de personas, sistemas o máquinas que
interactúan con el sistema.
• Los actores son externos al sistema: permiten comenzar a definir
límites y alcances
• UN ACTOR ES UNA CLASE DE ROL, UN USUARIO ES UNA
PERSONA QUE CUANDO USA EL SISTEMA ASUME ESE ROL
19
Actores

• Se representan con “stick man” (Hombres de palo)
20
Actores
Sistema de Ventas
Empleado
de ventas
En UML siempre se representan a los actores con “hombres de palo” pero a
veces es más útil representar a otros sistemas con un dibujo más claro (ej. una
computadora)
Sistema de
producción

• Las flechas indican el flujo de información entre el actor y el sistema.
(no se utilizan en UML)
• Identificar a los actores es el primer paso para utilizar casos de uso.
• Generalmente los actores coinciden con área de la empresa o
jerarquías dentro de la organización.
21
Actores

• El nombre de un caso de uso se expresa con un verbo en gerundio (también en
infinitivo), seguido por un objeto.
• Se representan con un óvalo con el nombre del caso en su interior.
• Se expresan SIEMPRE desde el punto de vista del actor y no del sistema.
• Se documentan con texto informal.
• Representan una determinada funcionalidad,claramente definida del sistema.
22
CASOS DE USO
Es una secuencia de acciones que el sistema lleva a cabo para
para ofrecer algún resultado de valor para el usuario

Descripción de CASOS DE USO
▪ Los casos de uso se documentan a través de una lista numerada de pasos en texto
informal
23
Caso de uso: Ingresando Pedido
Actor: Empleado de ventas
1- El cliente se comunica con la oficina de ventas, informa su número de cliente
2- El oficial de ventas ingresa el nº de cliente en el sistema
3- El sistema obtiene la información básica del cliente
4- El cliente informa el producto que quiere comprar e indica cantidad
5- El sistema obtiene la información sobre el producto, confirma su disponibilidad
6- Se repite paso 4- hasta que el cliente no informa más productos
7-….

Limitaciones de los CASOS
DE USO
24
• Los casos de uso son limitados cuando se realiza una gran cantidad de
cálculos con los datos ingresados. UML propone en estos casos utilizar
un “Diagrama de actividad” (similar a un diagrama de flujo)
• No hay una sintaxis clara para indicar decisiones o iteraciones. Se
utilizan frases como “Se repite el paso ….” “Si ocurre X ….” Debe
hacerse de forma consistente. En caso de ser muy complejo debe
recurrirse a los mencionados diagramas de actividad.

ALTERNATIVAS
• Son errores o excepciones que “desvían” el curso normal de un caso
de uso.
• No tienen sentido en si mismas.
• Pueden documentarse al final del caso de uso o dentro del caso de
uso en dos columnas.
25

• Consisten en interrumpir un caso de uso y pasar a ejecutar otro pero solo en
determinadas ocasiones.
• Se representan con una línea de trazos desde el caso que “extiende a”
(secundario) al caso que “es extendido” (principal).
26
RELACIONES DE EXTENSIÓN
Son una parte del
caso de uso, que no
siempre ocurre
Son un caso de uso
en si mismo
No provienen
necesariamente de un
error o excepción

RELACIONES DE USO
• Es una funcionalidad común accedida desde varios casos de uso.
• Puede asociarse al concepto de subrutina o subprograma.
• Son casos de uso en sí mismos.
• Se usa SIEMPRE que el caso que lo usa es ejecutando.
27

TIPOS DE CASOS DE USO
28
TEMPORALES:
Su inicio es provocado por el paso del tiempo (sin actor)
Ej.“Recibiendo estadística mensual de ventas”
Para diferenciarlos pueden ser representados con un óvalo pero de bordes
de línea punteada.

Proceso de análisis de
requisitos con CASOS DE USO
• Identificar a los actores. Identificar los principales casos de uso de cada actor.
• Identificar nuevos casos a partir de los existentes:
MÉTODOS: * Variaciones significativas
* Opuestos
* Preceden a casos existentes
* Suceden a casos existentes
• Enumerar casos de uso a nivel de nombres.
• Definir prioridades (imprescindibles-importantes-deseables) y seleccionar casos para la primera iteración.
• Realizar las descripciones de los casos de uso.
29

Ejemplos…
30

Links: documentación
casos de uso
⚫ Especificación de casos de uso – (RUP)
• Especificación de casos de uso –(Basado en EA)
⚫ Diagramas de actividades para describir casos de uso
31

Modelado de Requisitos - 1ra parte 2022.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a Modelado de Requisitos - 1ra parte 2022.pdf

Similar a Modelado de Requisitos - 1ra parte 2022.pdf (20)

Modelado de Requisitos - 1ra parte 2022.pdf