Ingeniería de Requisitos

Ingeniería de Requisitos
Guías Metodológicas
Departamento de Ciencias de la Computación
Universidad de Chile
Andrés Vignaga
Contenido
•
•
•
•
•
•
•
•
•
•
•
GM1: Identificar Stakeholders
GM2: Identificar Restricciones
GM3: Formular el Problema
GM4: Definir Características
GM5: Encontrar Actores
GM6: Encontrar Casos de Uso
GM7: Describir Interacciones entre Actores y CUs
GM8: Empaquetar Actores y Casos de Uso
GM9: Ilustrar Actores y Casos de Uso
GM10: Determinar Fuentes de Requisitos
GM11: Recolectar Información
Andrés Vignaga - DCC
Ingeniería de Requisitos
2
Contenido (2)
•
•
•
•
•
•
•
•
•
•
GM12: Realizar Workshops de Requisitos
GM13: Asignar Atributos
GM14: Establecer y Verificar Trazabilidad
GM15: Detallar el Flujo de Eventos
GM16: Estructurar el Flujo de Eventos
GM17: Ilustrar Relaciones
GM18: Definir Protocolos
GM19: Detallar los Requisitos
GM20: Identificar Requisitos Comunes
GM21: Relaciones entre Casos de Uso
Andrés Vignaga - DCC
Ingeniería de Requisitos
3
Contenido (3)
• GM22: Relaciones entre Actores
• GM23: Revisar Requisitos
Andrés Vignaga - DCC
Ingeniería de Requisitos
4
GM1: Identificar Stakeholders
• Las siguientes preguntas son de ayuda:
– ¿Quiénes son los usuarios del sistema?
– ¿Quién paga por el sistema?
– ¿Quién se verá afectado por lo que el sistema
produzca?
– ¿Quién evaluará y avalará el sistema cuando esté en
producción?
– ¿Hay otros usuarios internos o externos que haya que
atender?
– ¿Alguien más?
– Muy bien… ¿Alguien más?
• Desarrollar perfiles de los stakeholders como
sugiere el documento de Visión
Andrés Vignaga - DCC
Ingeniería de Requisitos
5
GM2: Identificar Restricciones
• Considerar las siguientes fuentes de restricciones
– Políticas: ¿Existen aspectos políticos internos o
externos que afecten las soluciones potenciales?
– Económicas: ¿Qué restricciones financieras aplican?
– Ambientales: ¿Hay restricciones regulatorias o legales
a considerar? ¿Algún estándar que seguir?
– Técnicas: ¿Se requiere el uso de alguna tecnología
particular? ¿Plataformas? ¿Alguna tecnología nueva
está prohibida?
– Factibilidad: ¿Está el programa definido? ¿Se puede
usar sólo los recursos existentes? ¿Se puede tercerizar?
¿Temporalmente?
– Sistemas: ¿La solución se debe basar en sistemas
propios? ¿Compatibilidad con sistemas existentes?
Andrés Vignaga - DCC
Ingeniería de Requisitos
6
GM3: Formular el Problema
• Trabajando en grupo completar la siguiente
plantilla que ayuda a distinguir entre
soluciones/respuestas y problemas/preguntas
El problema de resolver mal y fuera de tiempo reclamos de los clientes
afecta a nuestros clientes, ejecutivos de cuentas y personal de servicio técnico.
Su impacto es la insatisfacción de los clientes, muestra de baja calidad,
empleados descontentos y pérdidas económicas.
Una solución exitosa podría proveer a los ejecutivos acceso en tiempo
real a la base de reclamos para facilitar el despacho oportuno de técnicos a aquellos
lugares donde realmente se los necesite.
Andrés Vignaga - DCC
Ingeniería de Requisitos
7
GM4: Definir Características
• En base a
– Los beneficios encontrados en las formulaciones de
problemas
– Las necesidades de los stakeholders
elaborar una lista de características deseadas
• Describir las características en forma breve
• Definir atributos que determinen su estado y
prioridad a lo largo del proyecto
Andrés Vignaga - DCC
Ingeniería de Requisitos
8
GM5: Encontrar Actores
• Utilizar las siguientes preguntas:
–
–
–
–
–
¿Quién proveerá, usará o eliminará información?
¿Quién usará cierta funcionalidad?
¿Quién mantendrá el sistema?
¿Cuáles son los recursos externos del sistema?
¿Qué otro sistema deberá interactuar con este?
• Los actores pueden no encontrarse de inmediato
– Por no haber encontrado todos los casos de uso
• Impacto de cambios en los actores
– Frontera del sistema, interfaces y comportamiento
• Error común: incluir demasiados roles como
actores (esto modela el negocio y no el sistema)
Andrés Vignaga - DCC
Ingeniería de Requisitos
9
GM6: Encontrar Casos de Uso
• Para cada actor (humano o no) plantear las
siguientes preguntas:
– ¿Cuáles son las tareas principales que el actor quiere
que el sistema realice?
– ¿El actor creará, almacenará, cambiará, eliminará o
leerá información del sistema?
– ¿El actor necesita informar al sistema de eventos
externos?
– ¿El actor necesita ser informado de eventos dentro del
sistema?
– ¿El actor iniciará o detendrá la ejecución del sistema?
Andrés Vignaga - DCC
Ingeniería de Requisitos
10
GM6: Encontrar Casos de Uso (2)
• Las respuestas a las preguntas representan flujos
de eventos que identifican casos de uso
candidatos
• No todos representan casos de uso separados
– Algunos pueden ser variantes de un mismo caso
– Esto se puede ver mejor al detallar los flujos
• Recomendaciones
– Explotar la trazabilidad con las Características del
Sistema
– No es imprescindible (ni recomendable) detallar
completamente un caso de uso apenas es identificado
Andrés Vignaga - DCC
Ingeniería de Requisitos
11
GM7: Describir Interacciones
• Es importante mostrar cómo los actores se
relacionan con los casos de uso
– Al identificar un caso de uso establecer qué actores
interactúan con él
• Definir una relación de asociación entre los
actores y los casos de uso
– Definir una navegabilidad que explicite la dirección de
las señales entre las partes involucradas
– Las respuestas se asumen en sentido contrario a las
señales y no necesariamente se modelan
• Es posible describir la naturaleza de cada
asociación identificada
Andrés Vignaga - DCC
Ingeniería de Requisitos
12
GM8: Empaquetar Actores y Casos de Uso
• Cuando la cantidad de actores y casos de uso es
demasiado grande conviene dividirlos en
paquetes para simplificar
– La mantención del Modelo de Casos de Uso
– La comprensibilidad del modelo
– La asignación de recursos para el desarrollo
• Empaquetar casos de uso si
– Interactúan con el mismo actor
– Están relacionados entre sí
– Son todos opcionales (se ofrecen todos o ninguno)
• Puede haber otros criterios pero es necesario
definir uno y utilizarlo en forma consistente
Andrés Vignaga - DCC
Ingeniería de Requisitos
13
GM9: Ilustrar Actores y Casos de Uso
• Es posible mostrar en diagramas relaciones entre
casos de uso y actores
• Un diagrama típicamente contiene
–
–
–
–
–
–
–
Actores contenidos en un mismo paquete
Un actor y todos los casos de uso con los que interactúa
Casos de uso que manejan la misma información
Casos de uso usados por el mismo grupo de actores
Casos de uso ejecutados normalmente en secuencia
Los casos de uso más importantes
Casos de uso desarrollados juntos
• Cada diagrama debe pertenecer a un paquete
apropiado
Andrés Vignaga - DCC
Ingeniería de Requisitos
14
GM9: Ilustrar Actores y Casos de Uso (2)
• Ejemplo de diagrama de casos de uso:
Andrés Vignaga - DCC
Ingeniería de Requisitos
15
GM10: Determinar Fuentes de Requisitos
• La idea es identificar a las personas que actuarán como
stakeholders
• Estas personas completan junto a los desarrolladores el
“equipo extendido”
• Si es posible elegir, considerar
–
–
–
–
Conocimientos
Capacidad de comunicación
Disponibilidad
Importancia
• Buscar una cantidad adecuada para el equipo/proyecto
– Ni tan pocos que grupos de interés queden sin representación
– Ni tantos que no se puedan manejar y se les haga perder el
tiempo
Andrés Vignaga - DCC
Ingeniería de Requisitos
16
GM11: Recolectar Información
• Entrevistas
– Entrevistarse con un grupo de stakeholders clave es un
método muy útil para recolectar información
– Preguntas y técnicas para entrevistas está disponible
en el material del curso
– Esta plantilla se puede modificar para ajustarse mejor
a los casos específicos
– Con una preparación previa y una entrevista bien
estructurada debe ser posible recolectar información
valiosa
•
•
•
•
•
Investigar los antecedentes del stakeholder de antemano
Revisar las preguntas antes de la entrevista
Referirse al formato propuesto para recordar las preguntas
Resumir los dos o tres problemas central una vez terminado
Repetir lo aprendido para confirmar la buena comprensión
Andrés Vignaga - DCC
Ingeniería de Requisitos
17
GM11: Recolectar Información (2)
• Cuestionarios
– Temas que aparezcan repetidamente en entrevistas
pueden presentarse como preguntas con respuestas
típicas
– Las preguntas deben ser formuladas de forma de
proveer resultados realistas acerca de cuáles son las
necesidades reales de los stakeholders
– Esto permite llegar a una mayor cantidad de
stakeholders porque no es presencial
– Pero otorga un menor control sobre las respuestas
– Pueden ser una herramienta poderosa, pero no
reemplazan a las entrevistas
Andrés Vignaga - DCC
Ingeniería de Requisitos
18
GM12: Realizar Workshops de Requisitos
• Preparación del workshop:
– Un workshop consiste en reunir a todos los stakeholders con
algunos analistas durante un período predefinido de tiempo
– Los resultados deben quedar disponibles en forma inmediata para
todos los participantes
– Pueden aplicarse combinadamente otras técnicas como
storyboarding y role playing
– El moderador puede enfrentarse a lo siguiente
• Los stakeholders saben qué quieren pero no pueden expresarlo
• Los stakeholders no saben lo que quieren
• Los stakeholders creen saber lo que quieren hasta que se los
confronta contra lo que dijeron que querían
• Los analistas creen que comprenden mejor los problemas de los
usuarios mejor que los usuarios
• Todos creen que el resto tiene una motivación política
Andrés Vignaga - DCC
Ingeniería de Requisitos
19
GM12: Realizar Workshops de Requisitos (2)
• Antes del workshop:
– El moderador debe conformar el grupo que participe y
“vender” el workshop a sus integrantes
– Los participantes deben recibir material para leer con
anticipación
– El moderador es responsable de la logística (enviar
invitaciones, buscar un lugar adecuado, distribuir el
orden del día)
• Llevar a cabo la sesión
– El moderador debe liderar la sesión, lo que incluye
•
•
•
•
Racionar el uso de la palabra
Mantener el foco
Recolectar información aplicable a los atributos de requisitos
Resumir la sesión y sacar conclusiones
Andrés Vignaga - DCC
Ingeniería de Requisitos
20
GM12: Realizar Workshops de Requisitos (3)
• Consolidar los resultados:
– Al finalizar el moderador debe dedicar un tiempo a
sintetizar los hallazgos y condensar la información en
un formato presentable
– Esto puede hacerse en términos de Stakeholder
Requests o un Modelo de Casos de Uso
– Esta actividad la realiza el moderador ayudado por
otros analistas
Andrés Vignaga - DCC
Ingeniería de Requisitos
21
GM13: Asignar Atributos
• El Plan de Administración de Requisitos define los
atributos a ser mantenidos para cada tipo de
requisito
• Los atributos más importantes son
– Beneficio: determinado por el Analista en consulta
con los Stakeholders
– Esfuerzo: determinado por el Administrador en
consulta con el Arquitecto
– Riesgo: idem Esfuerzo
– Estabilidad: idem Beneficio
– Impacto arquitectónico: determinado por el
Arquitecto
Andrés Vignaga - DCC
Ingeniería de Requisitos
22
GM13: Asignar Atributos (2)
• El conjunto de atributos puede variar para cada
tipo de requisito
• Usos de los atributos
– Requisitos inestables con alto riesgo, esfuerzo o
beneficio deben analizarse con mayor profundidad
– Requisitos de bajo beneficio con alto riesgo, esfuerzo
o inestabilidad podrían ser eliminados
Andrés Vignaga - DCC
Ingeniería de Requisitos
23
GM14: Establecer y Verificar Trazabilidad
• El Plan de Administración de Requisitos define la
trazabilidad desde los requisitos hacia otros
artefactos
• El Analista debe establecer la trazabilidad
requerida y usar reportes para asegurar que es
mantenida de acuerdo al Plan
Andrés Vignaga - DCC
Ingeniería de Requisitos
24
GM14: Establecer y Verificar Trazabilidad (2)
• Ejemplo de trazabilidad concreta
Andrés Vignaga - DCC
Ingeniería de Requisitos
25
GM15: Detallar el Flujo de Eventos
• Describir los casos de uso de acuerdo a los
estándares definidos para el proyecto
• Decidir los siguientes puntos antes de comenzar
– ¿Cómo comienza?
• Describir la señal que lo activa
– ¿Cómo termina?
• Determinar claramente aquello que causa su terminación
– ¿Cómo interactúa con los actores?
• Para reducir el riesgo de malos entendido explicitar qué se
entiende dentro del sistema y qué se entiende por fuera
• Estructurar la descripción como una serie de párrafos que
representen acciones
Andrés Vignaga - DCC
Ingeniería de Requisitos
26
GM15: Detallar el Flujo de Eventos (2)
• Decidir… (cont)
– ¿Cómo intercambia datos con los actores?
• Explicitar la información intercambiada
• Puede expresarse en forma de argumentos de acciones
– ¿Cómo repite cierto comportamiento?
• Expresar esto en lenguaje natural
• En caso de ser necesario usar construcciones tipo pseudocódigo
– ¿Hay situaciones opcionales en el flujo?
• Cuando un actor tiene opciones expresarlas por separado
– ¿Cómo describirlo para que sea comprensible para los
stakeholders?
• No usar términos informáticos como “caso de uso”, “actor”,
“señal”, etc.
Andrés Vignaga - DCC
Ingeniería de Requisitos
27
GM16: Estructurar el Flujo de Eventos
• El flujo de eventos tiene dos partes principales
– El curso típico
– Alternativas
• Ambas partes deben ser estructuradas en
subflujos enfatizando en la legibilidad
• Un subflujo debe
– Tener un propósito claro
– Ser “atómico” (se realizan todas o ninguna de las
acciones descritas)
• Aclarar si el orden debe ser fijo o no
Andrés Vignaga - DCC
Ingeniería de Requisitos
28
GM16: Estructurar el Flujo de Eventos (2)
• Aclarar también
– En qué punto del flujo básico puede insertarse una
alternativa
– La condición que debe cumplirse para el
comportamiento alternativo comience
– Cómo y dónde se retoma el curso típico o cómo el caso
de uso termina
• Formas de estructurar subflujos
– Un flujo alternativo dentro del caso de uso si se trata
de una variante simple al curso típico
– Una inclusión si se trata de comportamiento a
encapsular y reusar en otros casos de uso
– Una extensión si ésta es condicional y el caso de uso
igual está completo si ella
Andrés Vignaga - DCC
Ingeniería de Requisitos
29
GM17: Ilustrar Relaciones
• Crear diagramas de casos de uso que muestren
los casos de uso y sus relaciones con los actores y
otros casos de uso
• Tal diagrama sirve como diagrama local para el
caso de uso y debe estar asociado a éste
• Este tipo de diagrama es de utilidad cuando
– El caso de uso está relacionado con otros y esas
relaciones deban ser explicadas
– Existe una complejidad inusual entre los actores
involucrados
Andrés Vignaga - DCC
Ingeniería de Requisitos
30
GM18: Definir Protocolos
• Definir los protocolos de comunicación con
aquellos actores que sean otro sistema o
hardware externo
• Si se usa algún protocolo conocido o estándar, la
descripción del caso de uso simplemente lo
nombra
• Si el protocolo es nuevo, la descripción del caso
de uso debe indicar dónde se puede encontrar la
definición (la cual será descrita en detalle
durante el desarrollo)
Andrés Vignaga - DCC
Ingeniería de Requisitos
31
GM19: Detallar los Requisitos
• Asegurarse de que todos los requisitos están especificados
al nivel de detalle necesario para pasárselos a los
diseñadores
• Ver si es necesario agregar detalle en la Especificación
Suplementaria
– Funcionalidad: chequeos de validez de las entradas, respuestas a
situaciones anormales, relación de la salida con la entrada, etc.
– Interfaces externas: cómo el software interactúa con personas,
hardware, hardware externo y otros sistemas
– Performance: velocidad, disponibilidad, tiempo de respuesta,
tiempo de recuperación, etc.
– Atributos: consideraciones de confiabilidad, portabilidad,
correctitud, mantenibilidad, seguridad, etc.
– Restricciones de diseño: estándares, lenguajes de implementación,
políticas de integridad de la BD, limitaciones de recursos, etc.
Andrés Vignaga - DCC
Ingeniería de Requisitos
32
GM20: Identificar Requisitos Comunes
• Durante las revisiones de los casos de uso es
posible detectar requisitos que son comunes a
más de un caso de uso
• Los requisitos comunes pueden ser reorganizados
para evitar redundancia
• Considerar que estos requisitos no siempre se
manejan mejor creando casos de uso nuevos
• El objetivo es volver la especificación de
requisitos más entendible y más fácil de
mantener
– No es la idea buscar una descomposición funcional que
pueda ser proyectada en el diseño del sistema
Andrés Vignaga - DCC
Ingeniería de Requisitos
33
GM21: Relaciones entre Casos de Uso
• Inclusión
– Si un caso de uso contiene un segmento del cual sólo
el resultado es de importancia para el resto del caso
de uso, entonces este segmento puede ser factorizado
en un nuevo caso de uso de inclusión
– El caso de uso original pasa a ser el caso de uso base
en una relación de inclusión con el anterior
– Esta relación significa que el caso de uso base necesita
además seguir la descripción del caso de uso incluido
para estar completo
– El nuevo caso de uso debería ser incluido por varios
casos de uso base para que valga la pena el esfuerzo
de mantener el caso de uso extra y la relación
Andrés Vignaga - DCC
Ingeniería de Requisitos
34
GM21: Relaciones entre Casos de Uso (2)
• Extensión
– Si un caso de uso contiene un segmento que es en
esencia opcional y que no aporta a la comprensión del
propósito primario del caso de uso, entonces este
segmento puede ser factorizado en un caso de uso de
extensión
– El caso de uso original pasa a ser el caso de uso base
hacia el cual el nuevo caso de uso tiene una relación
de extensión
– El caso de uso base incluye puntos de extensión
– Candidatos a ser factorizados son subflujos complejos
y comportamiento opcional
– El caso de uso base debe aún estar completo y ser
entendible después de realizada la factorización
Andrés Vignaga - DCC
Ingeniería de Requisitos
35
GM21: Relaciones entre Casos de Uso (3)
• Generalización
– Si dos o más casos de uso tienen similaridades en
estructura y comportamiento (también en intención),
estas similaridades se pueden factorizar en un caso de
uso padre
– Los casos de uso originales son casos de uso hijos del
nuevo y tienen una relación de generalización con él
– Un caso de uso hijo sigue la descripción del padre pero
atendiendo su propia descripción (que lo diferencia de
sus hermanos) para considerarse completo
– En el flujo de eventos del hijo debe indicarse cómo
este modifica el comportamiento heredado al insertar
segmentos nuevos de comportamiento
Andrés Vignaga - DCC
Ingeniería de Requisitos
36
GM21: Relaciones entre Casos de Uso (4)
• Notación UML
Caso de uso de extensión
Relación de Extensión
Caso de uso base
Caso de uso padre
Caso de uso hijo
Relación de
Generalización
Caso de uso base
Caso de uso de inclusión
Relación de Inclusión
Andrés Vignaga - DCC
Ingeniería de Requisitos
37
GM22: Relaciones entre Actores
• Los actores pueden tener características
comunes las que deben ser representadas
mediante generalizaciones entre actores
• Esto puede hacerse de mejor manera después de
haber trabajado un tiempo con el Modelo de
Casos de Uso
• Escribir una descripción de las relaciones
establecidas e incluirlas en un diagrama de casos
de uso para aportar mayor claridad
Andrés Vignaga - DCC
Ingeniería de Requisitos
38
GM22: Relaciones entre Actores (2)
• Notación UML
Relación de
Generalización
Andrés Vignaga - DCC
Ingeniería de Requisitos
39
GM23: Revisar Requisitos
• Realizar las revisiones en formato “reunión”
• Participantes sugeridos
–
–
–
–
Revisor de requisitos
Analista del sistema
Especificador de requisitos
Stakeholders
• Dividir una revisión en las siguientes reuniones:
A. Una revisión de solicitudes de cambio que impacten
en el conjunto actual de requisitos
B. Una revisión del Modelo de Casos de Uso completo
C. Una revisión de casos de uso y sus diagramas
Andrés Vignaga - DCC
Ingeniería de Requisitos
40
GM23: Revisar Requisitos (2)
• Es recomendable realizar reuniones de tipo A y B
en cada iteración
• Durante Inception y Elaboration se realiza
además una reunión de tipo C para todos los
requisitos existentes
• Durante Construction la reunión de tipo C es para
los requisitos atacados en la iteración actual
• Al finalizar la revisión documentar los resultados
en un Registro de Revisión
• Los defectos se documentan de acuerdo al
proceso de gestión de cambios del proyecto
Andrés Vignaga - DCC
Ingeniería de Requisitos
41