03 Gestión Requerimientos – Casos de Uso

IIC2143 – Ingeniería de Software (I/2013)

Material preparado por Juan Felipe Calderón-Maureira

Tabla de contenidos

• Gestión y etapas en la especificación de requerimientos

• Casos de uso– Definición– Elementos– Uso de UML en Casos de uso

Cómo se obtienen requerimientos

Descubrimiento

Clasificación

Priorización y

negociación

Especificación

Partida

Actividades cíclicas e incrementale

s

Etapas en adquisición de requerimientos

Descubrimiento• Se interactúa con los participantes del sistema para descubrir sus requerimientos

• Se consideran los requerimientos de dominio

Clasificación y organización• Agrupa requerimientos relacionados en torno a grupos coherentes, generalmente en torno a un modelo preliminar de la arquitectura.

Etapas en adquisición de requerimientos

Priorización y negociación• Se priorizan los requerimientos y resuelven conflictos entre los involucrados.

• Se construye un “compromiso” y consenso respecto de los requerimientos.

Especificación de requerimientos• Requerimientos se documentan. Se genera la primera release del documento.

Problemas en adquisición de requerimientos

• Clientes/participantes no “saben lo que quieren”: desconocimiento de lo que sería capaz un sistema de forma realista.

• Jerga del dominio puede no ser entendible para ingenieros de software.

• Pueden existir duplicidades y conflictos de requerimientos, provenientes de múltiples participantes.

• Existencia de factores “políticos” de las organizaciones (y gerentes).

• Cambio en el entorno/dominio donde se toman los requerimientos.

Técnicas para la obtención de requerimientos

EntrevistasDos tipos.• Cerradas respuestas a cuestionarios• Abiertas no hay agenda predefinidaProblemas de las entrevistas• Especialistas del dominio usan jerga específica; pueden “alivianar” el uso de terminologías específicas, no obstante ello puede dar a lugar a malas interpretaciones por parte de los ingenieros.

• Excesiva familiaridad con el dominio puede hacer que se caiga en obviedades… que no lo son para los ingenieros de requerimientos (y que pueden no estar al tanto de ellas).

Técnicas para la obtención de requerimientos

¿Cómo hacer buenas entrevistas?• Evitar tener ideas preconcebidas de los requerimientos

• Escuchar a los participantes• Ser capaz de formalizar requerimientos muy “fantasiosos” de la contraparte.

• Ser proactivo: usar preguntas que indaguen más, proponer requerimientos, fabricar prototipos.

• No usar “¿Qué es lo que quiere?”. Definir un contexto, para ser eficientes y efectivos en el proceso.

Técnicas para la obtención de requerimientos

Escenarios• Corresponden a ejemplos concretos de uso del sistema.

• Usualmente considera un pequeño número de interracciones.

• Puede incluir:• El estado del sistema cuando se inicia el escenario

• El flujo de eventos• Descripción de casos fallidos y los pasos que se siguen

• Otras actividades en paralelo• Estado del sistema cuando termina el escenario

Técnicas para la obtención de requerimientos

Casos de uso• Técnica de descubrimiento de requerimientos introducida por (Jacobson et al., 1993)

• Describe interacciones individuales entre el sistema y sus usuarios (u otros sistemas externos).

• Cada caso de uso se documenta con una descripción textual.

• Para construir casos de uso se utiliza UML (que se verá más adelante).

Técnicas para la obtención de requerimientos

Etnografía• En el contexto de la ingeniería de software, la etnografía es una técnica de observación que se usa para entender los procesos operacionales.

• Un analista se introduce en el ambiente laboral donde se inserta el sistema.

• Ayuda a descubrir los siguientes tipos de requerimientos• Los que derivan de la forma de trabajo de la gente (no del proceso, sino cómo realmente lo llevan a cabo).

• Los que emergen a partir de la cooperación y conocimiento en actividades realizadas por otras personas.

• Se puede complementar con el uso de prototipos, los cuales se trabajan junto con los usuarios del sistema.

• Este enfoque no es el adecuado para descubrir requerimientos de organización o dominio, debe usarse como complemento a otras técnicas.

Validación de requerimientos

• Corresponde al proceso en que se chequea que los requerimientos definan realmente lo que el cliente se necesita.

• Es importante porque errores en los requerimientos pueden llevar a altos costos de corrección.

• Existen varios tipos de comprobaciones que se pueden realizar: validez, consistencia, completitud, factibilidad, verificabilidad.

• Las técnicas que se utilizan usualmente para estas comprobaciones son las siguientes:• Revisiones de documento de requerimientos• Creación de prototipos• Generación de casos de prueba

• La técnica de casos de prueba se verá en el capítulo de Testing

Administración de requerimientos

• Requerimientos cambian, en particular para sistemas grandes:• Los ambientes de producción (donde opera el sistema), generalmente cambian después de la instalación.

• Los que financian el sistema no son los mismos que lo usan, existiendo conflictos de poder e intereses.

• Muchos usuarios generan requerimientos que pueden ser contradictorios entre sí.

• Es importante la planeación del proceso de su adquisición. Este proceso es posible apoyarlo con herramientas computacionales:• Repositorio e requerimientos• Sistemas que manejan el cambio• Sistemas que administran su tracking.

Casos de uso

• Corresponden a descripciones textuales, usadas para descubrir y describir requerimientos.

• Se componen de dos elementos esenciales• Actores: corresponden a alguien que tiene un comportamiento, que se asocia a un rol. Puede ser una persona, un sistema (externo al que se está modelando, o bien una organización).

• Escenario: es una secuencia específica de accioens e interacciones entre actores y sistema. Usualmente se denomina instancia del caso de uso.

• Un caso de uso, en conclusión, se constituye como una colección de escenarios exitosos y fallidos, que describen como un actor (o un conjunto de ellos), usan un sistema para lograr una meta.

Modelo de casos de uso

• Corresponde al conjunto de todos los casos de usos ya escritos, constituyéndose como un modelo de la funcionalidad del sistema y su entorno.

• Algunas aclaraciones importantes:• Los casos de uso no son diagramas, son documentos de texto.

• La creación de un modelo de casos de uso, por ende, es la creación de un documento de texto, no de diagramas.

• No obstante, existen diagramas provistos por UML que complementan su especificación.

Ventajas de los casos de uso

• Los casos de uso son una buena manera de mantener simples las especificaciones del sistema, de tal forma que sean entendibles por todos los involucrados

• En los casos de uso se enfatiza las metas de los usuarios.

• Es posible, al igual que en los documentos de requerimientos, un mayor grado de profundidad, detalle, sofisticación y formalidad, que evoluciona en el tiempo.

Relación con el concepto de requerimiento

• Según (Larman, 2007), los casos de uso más que un elemento que ayuda a descubrir requerimientos. De hecho, constituyen especificaciones de requerimientos:• Son requerimientos funcionales de alto nivel, pues especifican qué es lo que el sistema debe hacer (desde un punto de vista de los usuarios, no de sistema).

• Son requerimientos no funcionales, puesto que se especifica el grado de calidad que se espera del sistema, para lo que debe hacer.

• Según (Cockburn, 2001), los casos de uso definen un contrato de cómo el sistema debe funcionar.

Actores

• 3 tipos• Actores principales sus metas deben ser satisfechas a través del sistema.

• Actores secundarios (o “support actors”) proveen un servicio al sistema (información, procesamiento, etc.)

• Actor externo es aquel que no es ninguno de los dos anteriores , pero está interesado en el caso de uso. Generalmente no participan de las interacciones del mismo (de forma directa).

Grados de profundidad (formatos)

• Resumen ejecutivo• Un solo párrafo, que describe el principal suceso del escenario.

• Se utiliza durante las primeras iteraciones en el descubrimiento de requerimientos, para tener una impresión rápida de los actores y lo que esperan.

• Casual• Igual que el anterior, pero extendido, donde cada párrafo corresponde a distintos escenarios.

• Detallado (o completo)• Todas las etapas y variaciones están escritas en detalle.• Se construyen después de varias interacciones en el descubrimiento de requerimientos, permitiendo obtener detalles que permitan construir una arquitectura del sistema.

Plantilla para un caso de uso detallado (I) (Cockburn, 2001)

Sección Hint para completarlaNombre del caso de uso Partir con un verboScope (o alcance) Corresponde al sistema y

su fronteraNivel Dos niveles: meta de

usuario o sub-función (XX)

Actor principal Invoca al sistema para obtener sus servicios

Stakeholders e intereses Colocar a quienes les importe el caso de uso, y lo que quieren

Precondiciones El estado que debe ser verdadero antes de la ejecución.

Postcondiciones El estado que debe ser verdadero, luego de una ejecución exitosa

Flujo básico de eventos Happy path, secuencia detallada de acciones.

Extensiones o flujos alternativos

Escenarios alternativos al anterior, que pueden ser exitosos o fallidos

Plantilla para un caso de uso detallado (II)(Cockburn, 2001)

Sección Hint para completarlaRequerimientos especiales

Son los requerimientos no funcionales relacionados con el caso de uso.

Tecnología y modelos de datos

Corresponde a las formas de entrada y salida de información y sus modelos.

Frecuencia de uso Conviene especificarla de forma equivalente a la priorización de requerimientos, para definir su importancia a la hora de la implementación.

Aspectos no resueltos Elementos que no han sido cubiertos aún por el caso de uso.

Algunas aclaraciones de terminología

• Scope: define la frontera del sistema. Permite clasificar a los CU en dos tipos:• Casos de uso de sistema: descripción de un sistema software y/o hardware (en el curso se trabajarán con este tipo de CU).

• Casos de uso de negocios: descripción de cómo un cierto negocio es usado por clientes y proveedores.

• Nivel: nuevamente dos tipos• Meta de usuario: el caso de uso se usa para describir lo que el sistema debe hacer para satisfacer sus necesidades.

• Sub-función: describe etapas secundarias que permiten satisfacer una cierta meta de usuario. Generalmente corresponden a secuencias de eventos que son compartidas entre distintos casos de uso.

Algunas aclaraciones de terminología

• Flujo básico de eventos: describen etapas de tres tipos:• Interacción entre actores (considerando al sistema como actor).

• Validaciones (realizadas por el sistema generalmente)

• Cambio de estado en el sistema (modificaciones en datos, actividades de guardado, etc.)

• Flujos alternativos: corresponden a branches dentro del flujo básico.• Se anotan por separado, ojalá usando algún elemento que lo relacione con el evento del flujo básico correspondiente (p ej, un numeral).

Reglas generales en la definición de CU

• Escribirlos sin detalles de la interfaz de usuario,

• Escribir considerando al sistema como caja negra, sin detalles técnicos (p. ej: se guarda en una base de datos, se usa tal sentencia SQL, se genera tal instrucción).

• Escribirlos sin artículos u otros elementos gramaticales repetitivos (que dificulten su lectura). No es un paper o texto narrativo, es un documento de especificaciones (o que ayuda a obtenerlas)

• La redacción debe ser desde el punto de vista de los actores

Hints generales en la obtención de CU

• Organizar a los actores con sus metas de dos formas:• A medida que se van descubriendo, incorporarlos en un diagrama de casos de uso (se verá más adelante).

• Escribir una lista que relacione actores con sus metas, y luego construir el diagrama.

• En las entrevistas/reuniones con clientes/usuarios/interesados, centrarse en los actores. • La pregunta básica a realizar es: “¿cuáles son sus metas, que tengan un valor medible?”

Hints generales en la obtención de CU

• Seguir una secuencia para su construcción:• Definir la frontera del sistema claramente.• Luego, identificar actores principales• Luego, identificar las metas de los actores principales.• Finalmente, el resto.

• Utilizar ciertos “tests” o principios para su detección (y validación de su relevancia)• Test del jefe: ¿el caso de uso es de importancia para los responsables del uso del sistema? ¿se generan resultados medibles para ellos?

• Test EBP (del inglés, elementary bussines process): ¿las actividades del caso de uso responden a elementos que entregan valor al negocio (medible) ?

• Test del tamaño: ¿el caso de uso tiene un numero de tareas razonable (generalmente, mayor a una)? Si es así, podría constituirse como CU, si no, es sólo una actividad más dentro de otros CU.

Especificaciones formales en CU

• UML provee diagramas para la especificación de casos de uso, en particular para ilustrar casos de uso y actores.

• Recordar que sólo son un complemento a los documentos de texto que describen los casos de uso.

• Se recomienda construir simplemente un solo diagrama de casos de uso, en conjunto con una lista de actores y sus metas. Esto se denomina “diagrama de contexto”.

Ejemplo de notación en diagrama de contexto (Larman, 2007)

NextGen

Process Sale

. . .Cashier

Show com puter system actors with an alternate notation to hum an actors.

prim ary actors on the left

supporting actors on the right

For a use case context diagram , lim it the use cases to user-goal level use cases.

«actor»Paym ent

AuthorizationService

Reglas para su construcción

• Usar estereotipos • Utilizarlos en una fase de descubrimiento de requerimientos, centrarse en la escritura de casos de uso.

Bibliografía

Fundamental• Sommervile, Ian (2011) Ingeniería de Software. Pearson Education, México.

• Larman, Craig (2007) Applying UML and patterns, Pearson Education.

Complementaria (Casos de uso)• Cockburn, A (2001) Writing Effective Use Case, Addison-Weasly.