Especificación de

Requerimientos
Semana: 10
Sesión: 1
Propósito de la sesión:
• Al final de la sesión, el estudiante será capaz de
especificar los requerimientos de un software.
• Inicio:
El docente expondrá el propósito de aprendizaje.
• Desarrollo:
Presenta el tema usando diapositivas e interactuando con
diálogo-preguntas.
• Cierre:
Realiza una síntesis y resuelve dudas.
 Fases de la Ingeniería de Requerimientos
• ELICITACIÓN:
Entender el problema
– Tomar requerimientos, Elicitación
comprenderlos, etc.
• ESPECIFICACIÓN:
Formalmente describir el problema
– Especificar, modelar, etc. Especificación
• VALIDACIÓN:
Confrontar el problema con la
realidad Validación
– Validar, solucionar conflictos,
negociar
– Administrar los requerimientos
(Loucopoulos et al.,1995)
 Especificación de Requerimientos

• Es una descripción completa de

un requerimiento de sistema.

• Incluye un análisis detallado de

los “casos de uso” que describen
todas las interacciones que
tendrán los usuarios con el
sistema.
 Casos de Uso
• Los casos de uso
representan
requerimientos de
sistema
• Describen requerimientos
funcionales de software
• Describen como el
sistema debe
comportarse desde el
punto de vista del usuario
(Grässle et al.,2005).
 Requerimiento a Caso de Uso

«El sistema permitirá registrar un proveedor»

Registrar Proveedor

Figura 1. Requerimiento a Caso de Uso. Archivo Propio.

Casos de Uso en la Jerarquía

Figura 2. Casos de Uso en la Jerarquía. (Zielczynski, 2007).

 Actores
• Entidad externa que interactúa con el
sistema (persona identificada por un rol
o sistema externo)
• Sus objetivos son cumplidos al realizar Actor
el caso de uso
• Los actores son externos al sistema que
vamos a desarrollar <<actor>>
• Al identificar actores estamos Sistema
delimitando el sistema
• Usuario: es un actor, que usa el sistema
(Grässle et al.,2005).
 Casos de Uso
• Conjunto de “usos” posibles que
puede encarar un actor (o
varios) con el sistema para el
logro de cierto objetivo
• “Un resultado observable de
valor”, se basa en entregar Caso de Uso
sistemas que hagan lo que las
personas realmente necesitan
(Grässle et al.,2005).
 Inclusión
• Son actividades
comunes a más de un
caso de uso
• El caso de uso incluido
representa
comportamiento
encapsulado que
puede ser reusado en
varios Casos de Uso
(Grässle et al.,2005).
 Extensión
• Es un fragmento de un caso
de uso, que se agrega a otro
caso de uso.
• Se usan para explicar
escenarios que sería
complejo presentar como
flujo alternativo
• Representan una parte de la
funcionalidad del caso que
no siempre ocurre
(condicional). (Grässle et al.,2005).
 Generalización o Herencia
• Se puede crear un caso de
uso abstracto, que sea el
«padre» y relacionarlo con
casos de uso «hijo»
• El caso de uso «hijo» hereda
los escenarios, puntos de
extensión y relaciones
definidos en el Caso de Uso
«padre». (Grässle et al.,2005).
 Escenarios de Caso de Uso
• Secuencia de acciones e
interacciones entre los
actores y el sistema, dando
un resultado de valor
observable para un actor
particular.
• También se conoce como
instancia de un caso de uso.
• Es una forma particular de
usar el sistema, un camino a
través de un caso de uso.
(Grässle et al.,2005).
Escenarios en la Jerarquía

Figura 3. Escenarios en la Jerarquía. (Zielczynski, 2007).

Escenario de Caso de Uso

Figura 4. Caso de Uso. Archivo Propio.

Escenario de Caso de Uso

Figura 5. Escenario.
Archivo Propio.
 Escenarios de Caso de Uso

Figura 6. Escenarios de Casos de Uso. Archivo Propio.

Metacognición
• Los casos de uso de software, representan requerimientos de
sistema, útiles para el posterior diseño del software.
Referencia bibliográfica y de imágenes
Loucopoulos, P., Karakosas, V. (1995). Systems Requeriments Engineering. E.E.U.U.,
Manchester: McGraw Hill

Grässle, P., Baumann, H., Baumann, P. (2005). UML 2.0 in Action. UK, Birmingham:
Packt Publishing Ltd.

Zielczynski, P. (2007). Requirements Management Using IBM® Rational®

RequisitePro®. E.E.U.U., Boston: IBM Press
CREA IMPACTO POSITIVO Y TRASCIENDE