Versin 2.2
Amador Durn Toro Beatriz Bernrdez Jimnez
Informe Tcnico LSI200010 (revisado) Departamento de Lenguajes y Sistemas Informticos Escuela Tcnica Superior de Ingeniera Informtica Sevilla, octubre de 2001
Este trabajo ha sido o est siendo nanciado por los siguientes proyectos: Proyecto CICYT "MENHIR"(TIC 970593C0503) Proyecto CICYT "GEOZOCO"(TIC 20001106C0201) Proyecto CYTED "WEST"(VII.18)
Lista de cambios
Nm. 0 1 Fecha 13/10/1998 04/11/1998 Descripcin Versin 1.0 [pg. 18] En el apartado de importancia de la plantilla general de requisitos del sistema, donde apareca "En este apartado se indica la importancia que tiene el caso de uso para el cliente" aparece ahora "En este apartado se indica la importancia que tiene el requisito para el cliente". [pg. 18] En el apartado de urgencia de la plantilla general de requisitos del sistema, donde apareca ". . . incluyendo la funcionalidad expresada en el caso de uso" aparece ahora . . . incluyendo las capacidades expresadas en el requisito". [pg. 23] En la descripcin de la relacin extends entre casos de uso, donde apareca "En cierta forma, B completa la funcionalidad de A" aparece ahora "En cierta forma, A completa la funcionalidad de B". [pgs. 3, 6, 8, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 30] Correcciones ortogrcas diversas. Publicacin de la versin 1.1. En la versin 2.0 se han introducido numerosos cambios, los principales son los siguientes: El ttulo cambia de Norma para la Recoleccin de Requisitos de un Sistema Software a Metodologa para la Elicitacin de Requisitos de Sistemas Software. La primera seccin del documento pasa de denominarse Objetivo y alcance a Objetivo de la metodologa. Se han eliminado de la tarea 1 las referencias relativas a la construccin de modelos de anlisis del dominio. En la tarea 2 se habla de reuniones en lugar de hacerlo especcamente de entrevistas. Se ha aadido la tarea 3 Identicar los objetivos del sistema como tarea previa a la identicacin de los requisitos y se ha diseado una plantilla especca para los objetivos. Se han cambiado todas las apariciones de otros requisitos por requisitos no funcionales. Se ha cambiado el contenido de las secciones Introduccin y Objetivos del sistema del DRS. Se han aadido al DRS las secciones Participantes en el proyecto y Matriz de rastreabilidad. Se ha contemplado la posibilidad de organizar los requisitos de forma que no sean una lista plana. Se han aadido las descripciones de las tcnicas de JAD y brainstorming. Se ha reescrito la descripcin de la tcnica de los casos de uso. Se ha cambiado el nombre de la relacin uses entre casos de uso a includes para adaptar la notacin a UML. Se han aadido plantillas especcas para objetivos y actores. Se han aadido nuevos campos y patronesL a todas las plantillas, introduciendo el concepto de patrn lingstico. Se han eliminado los subpasos de la plantilla para requisitos funcionales (casos de uso). Se ha reescrito la mayor parte del ejemplo de aplicacin de la metodologa. Versin 2.0. En la versin 2.1 se han introducido algunos cambios realizados durante la elaboracin de la tesis doctoral de A. Durn [Durn 2000]. Versin 2.1 (Informe Tcnico LSI200010) En la versin 2.2 se han introducido algunos cambios realizados durante la implementacin de la herramienta CASE REM. Estos cambios afectan a algunos campos de algunas plantillas, aunque no de una forma signicativa. Versin 2.2. Autor/es A. Durn y B. Bernrdez A. Durn
04/11/1998
A. Durn
04/11/1998
A. Durn
4 5 6
7 8
18/10/1999 18/10/2000
A. Durn A. Durn
9 10
18/10/2000 26/10/2001
A. Durn A. Durn
11
26/10/2001
A. Durn
ndice General
1 Objetivo de la metodologa 2 Tareas recomendadas 2.1 Tarea 1: Obtener informacin sobre el dominio del problema y el sistema actual . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . . 1 1 3 3 3 3 3 4 4 4 4 5 5 5 5 5 5 6 6 6 6 6 6 7 7 7
Tarea 2: Preparar y realizar las sesiones de elicitacin/negociacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . . i
2.3
Tarea 3: Identicar/revisar los objetivos del sistema . . . . . 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5
2.4
Tarea 4: Identicar/revisar los requisitos de informacin . . 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5
2.5
Tarea 5: Identicar/revisar los requisitos funcionales . . . . 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . Descripcin . . . . . . . . . . . . . . . . . . . . . . . . Productos internos . . . . . . . . . . . . . . . . . . . . Productos entregables . . . . . . . . . . . . . . . . . . Tcnicas recomendadas . . . . . . . . . . . . . . . . .
7 7 8 8 8 8 9 9 9 10 10 10 10 11 11 11 14 14 14 14 14 15 15 15 15 15 15 16 16
2.6
Tarea 6: Identicar/revisar los requisitos no funcionales . . . 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5
3 Productos entregables 3.1 Documento de requisitos del sistema . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 Portada . . . . . . . . . . . . . . . . . . . . . . . . . . . Lista de cambios . . . . . . . . . . . . . . . . . . . . . ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . Listas de guras y tablas . . . . . . . . . . . . . . . . . Introduccin . . . . . . . . . . . . . . . . . . . . . . . . Participantes en el proyecto . . . . . . . . . . . . . . . Descripcin del sistema actual . . . . . . . . . . . . . Objetivos del sistema . . . . . . . . . . . . . . . . . . . Catlogo de requisitos del sistema . . . . . . . . . . .
3.1.10 Requisitos de informacin . . . . . . . . . . . . . . . . 3.1.11 Requisitos funcionales . . . . . . . . . . . . . . . . . . 3.1.12 Diagrama de casos de uso . . . . . . . . . . . . . . . . 3.1.13 Denicin de los actores . . . . . . . . . . . . . . . . . 3.1.14 Casos de uso del sistema . . . . . . . . . . . . . . . . . 3.1.15 Requisitos no funcionales . . . . . . . . . . . . . . . . ii
3.1.16 Matriz de rastreabilidad objetivos/requisitos . . . . . 16 3.1.17 Glosario de trminos . . . . . . . . . . . . . . . . . . . 16 3.1.18 Conictos pendientes de resolucin . . . . . . . . . . 17 3.1.19 Apndices . . . . . . . . . . . . . . . . . . . . . . . . . 17 4 Tcnicas 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.3 4.4 4.3.1 4.4.1 4.4.2 4.4.3 17 Preparacin de entrevistas . . . . . . . . . . . . . . . . 18 Realizacin de entrevistas . . . . . . . . . . . . . . . . 19 Anlisis de las entrevistas . . . . . . . . . . . . . . . . 20 Participantes del JAD . . . . . . . . . . . . . . . . . . 21 Fases del JAD . . . . . . . . . . . . . . . . . . . . . . . 22 Fases del brainstorming . . . . . . . . . . . . . . . . . 25 Diagramas de casos de uso . . . . . . . . . . . . . . . 27 Relaciones entre casos de uso . . . . . . . . . . . . . . 27 Organizacin de casos de uso . . . . . . . . . . . . . . 29 30
Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Plantillas y patrones lingsticos para elicitacin de requisitos 5.1 5.2 5.3 5.4 5.5 5.6
Plantilla para los objetivos del sistema . . . . . . . . . . . . . 32 Plantillas para requisitos de informacin . . . . . . . . . . . . 34 Plantilla para actores . . . . . . . . . . . . . . . . . . . . . . . 36 Plantilla para requisitos funcionales . . . . . . . . . . . . . . 37 Plantilla para requisitos no funcionales . . . . . . . . . . . . . 42 Plantilla para conictos . . . . . . . . . . . . . . . . . . . . . . 42 48
A.3 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . A.3.1 Diagramas de casos de uso . . . . . . . . . . . . . . . A.3.2 Denicin de actores . . . . . . . . . . . . . . . . . . . A.3.3 Casos de uso del sistema . . . . . . . . . . . . . . . . . A.4 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . .
52 52 55 55 71
iv
ndice de Figuras
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Tareas de elicitacin de requisitos . . . . . . . . . . . . . . . . 2 Estructura del Documento de Requisitos del Sistema . . . . . 12 Portada del Documento de Requisitos del Sistema . . . . . . 13 Lista de cambios del Documento de Requisitos del Sistema . 13 Matriz de rastreabilidad del Documento de Requisitos del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . 28 Representacin grca de las relaciones includes y extends . . 28 Representacin grca de los paquetes de casos de uso . . . 30 La plantilla como elemento de elicitacin y negociacin . . . 31 Plantilla y patronesL para objetivos . . . . . . . . . . . . . . 32 Plantilla y patronesL para requisitos de almacenamiento de informacin . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Plantilla y patronesL para requisitos de restricciones de informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Plantilla y patronesL para actores . . . . . . . . . . . . . . . 36 Plantilla y patronesL para requisitos funcionales (casos de uso) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Plantilla y patronesL para requisitos funcionales (forma tradicional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Ejemplo de caso de uso de conexin de usuario (plantilla) . . 41 Ejemplo de caso de uso de conexin de usuario (Coleman) . 41 Plantilla y patronesL para requisitos no funcionales . . . . . 42 Plantilla para conictos . . . . . . . . . . . . . . . . . . . . . . 43 Diagrama de subsistemas . . . . . . . . . . . . . . . . . . . . 52 Diagrama de casos de uso del subsistema Gestin de socios 52 Diagrama de casos de uso del subsistema Gestin de pelculas 53 Diagrama de casos de uso del subsistema Gestin de alquileres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
vi
Objetivo de la metodologa
1 Objetivo de la metodologa
El objetivo de esta metodologa es la denicin de las tareas a realizar, los productos a obtener y las tcnicas a emplear durante la actividad de elicitacin de requisitos de la fase de ingeniera de requisitos del desarrollo de software. En esta metodologa se distinguen dos tipos de productos: los productos entregables y los productos no entregables o internos. Los productos entregables son aquellos que se entregan ocialmente al cliente como parte del desarrollo en fechas previamente acordadas, mientras que los no entregables son productos internos al desarrollo que no se entregan al cliente. El nico producto entregable denido en esta metodologa es el Documento de Requisitos del Sistema (DRS), denido en la seccin 3.1, pg. 11. La estructura de este documento es la siguiente: en la seccin 2 se describen las tareas recomendadas, en la seccin 3 se denen los productos entregables, en este caso el DRS, y por ltimo, en la seccin 4 se describen algunas de las tcnicas recomendadas para obtener los productos. Tambin se incluye como apndice un ejemplo de aplicacin de esta metodologa.
2 Tareas recomendadas
Las tareas recomendadas para obtener los productos descritos en esta metodologa son las siguientes: Tarea 1: Obtener informacin sobre el dominio del problema y el sistema actual. Tarea 2: Preparar y realizar las reuniones de elicitacin/negociacin. Tarea 3: Identicar/revisar los objetivos del sistema. Tarea 4: Identicar/revisar los requisitos de informacin. Tarea 5: Identicar/revisar los requisitos funcionales. Tarea 6: Identicar/revisar los requisitos no funcionales. Tarea 7: Priorizar objetivos y requisitos.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
El orden recomendado de realizacin para estas tareas es: 1. . . 7, aunque las tareas 4, 5, y 6 pueden realizarse simultneamente o en cualquier orden que se considere oportuno (ver gura 1). La tarea 1 es opcional y depende del conocimiento previo que tenga el equipo de desarrollo sobre el dominio del problema y el sistema actual.
2.1 Tarea 1: Obtener informacin sobre el dominio del problema y el sistema actual
2.1.1 Objetivos
Informacin recopilada: libros, artculos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc. Modelos del sistema actual.
2.1.4 Productos entregables
Introduccin, participantes en el proyecto, principalmente clientes y desarrolladores, descripcin del sistema actual y glosario de trminos como parte del DRS (ver secciones 3.1.53.1.7 y 3.1.17, pgs. 1414 y 16).
A. Durn, B. Bernrdez Sevilla, Octubre 2001
Obtener informacin de fuentes externas al negocio del cliente: folletos, informes sobre el sector, publicaciones, consultas con expertos, etc.
En el caso de que se trate de un dominio muy especco puede ser necesario recurrir a fuentes internas al propio negocio del cliente, en cuyo caso pueden utilizarse las tcnicas auxiliares de elicitacin de requisitos como el estudio de documentacin, observacin in situ, cuestionarios, inmersin o aprendizaje, etc. (ver secciones 4.14.3, pgs. 1724).
Construccin de glosarios de trminos [Leite et al. 1997]. Modelado del sistema actual [Laguna et al. 1999, Ortn et al. 2001].
Identicar a los usuarios participantes. Conocer las necesidades de clientes y usuarios. Resolver posibles conictos.
2.2.2 Descripcin Teniendo en cuenta la informacin recopilada en la tarea anterior, en esta tarea se deben preparar y realizar las reuniones con los clientes y usuarios participantes con objeto de obtener sus necesidades y resolver posibles conictos que se hayan detectado en iteraciones previas del proceso. Esta tarea es especialmente crtica y ha de realizarse con especial cuidado, ya que generalmente el equipo de desarrollo no conoce los detalles especcos de la organizacin para la que se va a desarrollar el sistema y, por otra parte, los clientes y posibles usuarios no saben qu necesita saber el equipo de desarrollo para llevar a cabo su labor.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Notas tomadas durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o vdeo de las reuniones o cualquier otra documentacin que se considere oportuna.
2.2.4 Productos entregables
Participantes en el proyecto, en concreto los usuarios participantes, como parte del DRS (ver seccin 3.1.6, pg. 14). Objetivos, requisitos o conictos, que se hayan identicado claramente durante las sesiones de elicitacin, como parte del DRS (ver secciones 3.1.83.1.9 y 3.1.18, pgs. 1515 y 17)
2.2.5 Tcnicas recomendadas
Tcnicas de elicitacin de requisitos (ver secciones 4.14.3, pgs. 17 24), incluyendo las plantillas de objetivos, requisitos y conictos descritas en la seccin 5, pg. 30, que pueden usarse directamente durante las sesiones de elicitacin. Tcnicas de negociacin como WinWin [Boehm et al. 1994].
Identicar los objetivos que se esperan alcanzar mediante el sistema software a desarrollar. Revisar, en el caso de que haya conictos, los objetivos previamente identicados.
2.3.2 Descripcin A partir de la informacin obtenida en la tarea anterior, en esta tarea se deben identicar qu objetivos se esperan alcanzar una vez que el sistema software a desarrollar se encuentre en explotacin o revisarlos en funcin
A. Durn, B. Bernrdez Sevilla, Octubre 2001
de los conictos identicados. Puede que los objetivos hayan sido proporcionados antes de comenzar el desarrollo. 2.3.3 Productos internos
Objetivos del sistema como parte del DRS (ver seccin 3.1.8, pg. 15).
2.3.5 Tcnicas recomendadas
Anlisis de factores crticos de xito [MAP 1995] o alguna tcnica similar de identicacin de objetivos. Plantilla para especicar los objetivos del sistema (ver seccin 5.1, pg. 32).
Identicar los requisitos de almacenamiento de informacin que deber cumplir el sistema software a desarrollar. Identicar los requisitos de restricciones de informacin o reglas de negocio que deber cumplir el sistema software a desarrollar. Revisar, en el caso de que haya conictos, los requisitos de almacenamiento y/o de restricciones de informacin previamente identicados.
2.4.2 Descripcin A partir de la informacin obtenida en la tareas 1 y 2, y teniendo en cuenta los objetivos identicados en la tarea 3 y el resto de los requisitos, en esta tarea se debe identicar, o revisar si existen conictos, qu informacin
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
relevante para el cliente deber gestionar y almacenar el sistema software a desarrollar as como qu restricciones o reglas de negocio debe cumplir dicha informacin. Inicialmente se partirn de conceptos generales para posteriormente ir detallndolos hasta obtener todos los datos relevantes.
Requisitos de almacenamiento de informacin como parte del DRS (ver seccin 3.1.10, pg. 15).
Plantilla para requisitos de almacenamiento de informacin (ver seccin 5.2, pg. 34). Plantilla para requisitos de restricciones de informacin (ver seccin 5.2, pg. 34).
Identicar los actores del sistema del sistema software a desarrollar. Identicar los requisitos funcionales, expresados de forma tradicional o como casos de uso, que deber cumplir el sistema software a desarrollar. Revisar, en el caso de que haya conictos, los requisitos funcionales previamente identicados.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
8 2.5.2 Descripcin
A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuenta los objetivos identicados en la tarea 3 y el resto de los requisitos, en esta tarea se debe identicar, o revisar si existen conictos, qu debe hacer el sistema a desarrollar con la informacin identicada en la tarea anterior. Inicialmente se identicarn los actores que interactuarn con el sistema, es decir aquellas personas u otros sistemas que sern los orgenes o destinos de la informacin que consumir o producir el sistema a desarrollar y que forman su entorno. A continuacin se identicarn los casos de uso asociados a los actores, los pasos de cada caso de uso y posteriormente se detallarn los casos de uso con las posibles excepciones hasta denir todas las situaciones posibles. En el caso de que se considere necesario, se podr optar por expresar algunos o todos los requisitos funcionales de la forma tradicional, es decir, mediante un prrafo en lenguaje natural, en lugar de hacerlo mediante casos de uso. 2.5.3 Productos internos
Requisitos funcionales como parte del DRS (ver seccin 3.1.11, pg. 15).
2.5.5 Tcnicas recomendadas
Casos de uso (ver seccin 4.4, pg. 26). Plantilla para actores (ver seccin 5.3, pg. 36). Plantilla para casos de uso (ver seccin 5.4, pg. 37). Plantilla para requisitos funcionales (ver seccin 5.4, pg. 37).
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Identicar los requisitos no funcionales del sistema software a desarrollar. Revisar, en el caso de que haya conictos, los requisitos no funcionales previamente identicados.
2.6.2 Descripcin A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuenta los objetivos identicados en la tarea 3 y el resto de los requisitos, en esta tarea se deben identicar, o revisar si existen conictos, los requisitos no funcionales, normalmente de carcter tcnico o legal. Algunos tipos de requisitos que se suelen incluir en esta seccin son los siguientes: Requisitos de comunicaciones del sistema Son requisitos de carcter tcnico relativos a las comunicaciones que deber soportar el sistema software a desarrollar. Por ejemplo: el sistema deber utilizar el protocolo TCP/IP para las comunicaciones con otros sistemas. Requisitos de interfaz de usuario Este tipo de requisitos especica las caractersticas que deber tener el sistema en su comunicacin con el usuario. Por ejemplo: la interfaz de usuario del sistema deber ser consistente con los estndares denidos en IBMs Common User Access. Se debe ser cuidadoso con este tipo de requisitos, ya que en esta fase de desarrollo todava no se conocen bien las dicultades que pueden surgir a la hora de disear e implementar las interfaces, por esto no es conveniente entrar en detalles demasiado especcos. Requisitos de abilidad Los requisitos de abilidad deben establecer los factores que se requieren para la abilidad del software en tiempo de explotacin. La
A. Durn, B. Bernrdez Sevilla, Octubre 2001
10
abilidad mide la probabilidad del sistema de producir una respuesta satisfactoria a las demandas del usuario. Por ejemplo: la tasa de fallos del sistema no podr ser superior a 2 fallos por semana. Requisitos de entorno de desarrollo Este tipo de requisitos especican si el sistema debe desarrollarse con un producto especco. Por ejemplo: el sistema deber desarrollarse con Oracle 7 como servidor y clientes Visual Basic 4. Requisitos de portabilidad Los requisitos de portabilidad denen qu caractersticas deber tener el software para que sea fcil utilizarlo en otra mquina o bajo otro sistema operativo. Por ejemplo: el sistema deber funcionar en los sistemas operativos Windows 95, Windows 98 y Windows NT 4.0, siendo adems posible el acceso al sistema a travs de Internet usando cualquier navegador compatible con HTML 3.0.
Requisitos no funcionales del sistema como parte del DRS (ver seccin 3.1.15, pg. 16).
3 Productos entregables
El nico producto entregable que se contempla en esta metodologa es el Documento de Requisitos del Sistema (DRS).
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
11
3.1.1 Portada La portada del DRS debe tener el formato que puede verse en la gura 3. Los elementos que deben aparecer son los siguientes:
Nombre del proyecto: el nombre del proyecto al que pertenece el DRS. Versin: la versin del DRS que se entrega al cliente. La versin se compone de dos nmeros e . El primero indica la versin, y se debe incrementar cada vez que se hace una nueva entrega formal al cliente. Cuando se incremente el primer nmero, el segundo debe volver a comenzar en cero. El segundo nmero indica cambios dentro de la misma versin an no entregada, y se debe incrementar cada vez que se publica una versin con cambios respecto a la ltima que se public y que no se vaya a entregar formalmente todava. Este tipo de versiones pueden ser internas al equipo de desarrollo o ser entregadas al cliente a ttulo orientativo. Fecha: fecha de la publicacin de la versin. Equipo de desarrollo: nombre de la empresa o equipo de desarrollo. Cliente: nombre del cliente, normalmente otra empresa.
3.1.2 Lista de cambios El documento debe incluir una lista de cambios en la que se especiquen, para cada versin del documento, los cambios producidos en el mismo con un formato similar al que puede verse en la gura 4. Para cada cambio realizado se debe incluir el nmero de orden, la fecha, una descripcin y los autores.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
12
Portada Lista de cambios ndice Lista de guras Lista de tablas 1 Introduccin 2 Participantes en el proyecto 3 Descripcin del sistema actual 4 Objetivos del sistema 5 Catlogo de requisitos del sistema 5.1 Requisitos de informacin 5.2 Requisitos funcionales 5.2.1 Diagramas de casos de uso 5.2.2 Denicin de actores 5.2.3 Casos de uso del sistema 5.3 Requisitos no funcionales 6 Matriz de rastreabilidad objetivos/requisitos 7 Glosario de trminos 8 Conictos pendientes de resolucin [opcional, pueden ir en un documento aparte] Apndices [opcionales]
13
Nm. 0 1 . . .
A. Durn, B. Bernrdez
14 3.1.3 ndice
El ndice del DRS debe indicar la pgina en la que comienza cada seccin, subseccin o apartado del documento. En la medida de lo posible, se sangrarn las entradas del ndice para ayudar a comprender la estructura del documento.
3.1.4 Listas de guras y tablas El DRS deber incluir listas de las guras y tablas que aparezcan en el mismo. Dichas listas sern dos ndices que indicarn el nmero, la descripcin y la pgina en que aparece cada gura o tabla del DRS.
3.1.5 Introduccin Esta seccin debe contener una descripcin breve de las principales caractersticas del sistema software que se va a desarrollar, la situacin actual que genera la necesidad del nuevo desarrollo, la problemtica que se acomete, y cualquier otra consideracin que site al posible lector en el contexto oportuno para comprender el resto del documento.
3.1.6 Participantes en el proyecto Esta seccin debe contener una lista con todos los participantes en el proyecto, tanto desarrolladores como clientes y usuarios. Para cada participante se deber indicar su nombre, el papel que desempea en el proyecto, la organizacin a la que pertenece y cualquier otra informacin adicional que se considere oportuna.
3.1.7 Descripcin del sistema actual Esta seccin debe contener una descripcin del sistema actual en el caso de que se haya acometido su estudio. Para describir el sistema actual puede utilizarse cualquier tcnica que se considere oportuno, por ejemplo las descritas en [Laguna et al. 1999] (Diagrama DocumentosTarea, DDT) o en [Ortn et al. 2001] (Diagramas de Actividad, tambin descritos en [Booch et al. 1999]).
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
15
3.1.8 Objetivos del sistema Esta seccin debe contener una lista con los objetivos que se esperan alcanzar cuando el sistema software a desarrollar est en explotacin, especicados mediante la plantilla para objetivos descrita en la seccin 5.1, pg. 32. 3.1.9 Catlogo de requisitos del sistema Esta seccin se divide en las siguientes subsecciones en las que se describen los requisitos del sistema. Cada uno de los grandes grupos de requisitos, de informacin, funcionales y no funcionales, podrn dividirse para ayudar a la legibilidad del documento, por ejemplo dividiendo cada subseccin en requisitos asociados a un determinado objetivo, requisitos con caractersticas comunes, etc. 3.1.10 Requisitos de informacin Esta subseccin debe contener la lista de requisitos de almacenamiento y de restricciones de informacin que se hayan identicado, utilizando para especicarlos las plantillas para requisitos de informacin descritas en la seccin 5.2, pg. 34. 3.1.11 Requisitos funcionales Esta subseccin debe contener la lista de requisitos funcionales que se hayan identicado, dividindose en los siguientes apartados que se describen a continuacin. 3.1.12 Diagrama de casos de uso Este apartado debe contener los diagramas de casos de uso del sistema que se hayan realizado. 3.1.13 Denicin de los actores Este apartado debe contener una lista con los actores que se hayan identicado, especicados mediante la plantilla para actores de casos de uso descrita en la seccin 5.3, pg. 36.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
16
3.1.14 Casos de uso del sistema Este apartado debe contener los casos de uso que se hayan identicado, especicados mediante la plantilla para requisitos funcionales descrita en la seccin 5.4, pg. 37. En el caso de que se considere oportuno, tambin se podrn expresar algunos o todos los requisitos funcionales de la forma tradicional, usando para ello la plantilla descrita en la seccin indicada previamente. 3.1.15 Requisitos no funcionales Esta subseccin debe contener la lista los requisitos no funcionales del sistema que se hayan identicado, especicados mediante la plantilla para requisitos no funcionales descrita en la seccin 5.5, pg. 42. 3.1.16 Matriz de rastreabilidad objetivos/requisitos Esta seccin debe contener una matriz objetivorequisito, de forma que para cada objetivo se pueda conocer con qu requisitos est asociado. El formato de la matriz de rastreabilidad puede verse en la gura 5.
RI01 RI02 ... RF01 RF02 ... RNF01 RNF02 ... OBJ01 OBJ02 ... OBJ-n
Figura 5: Matriz de rastreabilidad del Documento de Requisitos del Sistema 3.1.17 Glosario de trminos Esta seccin, deber contener una lista ordenada alfabticamente de los trminos especcos del dominio del problema, acrnimos y abreviaturas que aparezcan en el documento y que se considere que su signicado deba ser aclarado. Cada trmino deber acompaarse de su signicado.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Tcnicas
17
3.1.18 Conictos pendientes de resolucin Esta seccin, que se incluir en el caso de que no se opte por registrar los conictos en un documento aparte, deber contener los conictos identicados durante el proceso y que an estn pendientes de resolucin, descritos mediante la plantilla para conictos. 3.1.19 Apndices Los apndices se usarn para proporcionar informacin adicional a la documentacin obligatoria del documento. Slo deben aparecer si se consideran oportunos y se identicarn con letras ordenadas alfabticamente: A, B, C, etc.
4 Tcnicas
A continuacin, se describen algunas de las tcnicas que se proponen en esta metodologa para obtener los productos de las tareas que se han descrito. Las tcnicas ms habituales en la elicitacin de requisitos son las entrevistas, el Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones, el brainstorming o tormenta de ideas y la utilizacin de escenarios [Weidenhaput et al. 1998, Rolland et al. 1998], ms conocidos como casos de uso [Jacobson et al. 1993, Booch et al. 1999]. A estas tcnicas, que se describen en los siguientes apartados, se las suele apoyar con otras tcnicas complementarias como la observacin in situ, el estudio de documentacin, los cuestionarios, la inmersin en el negocio del cliente [Goguen y Linde 1993] o haciendo que los ingenieros de requisitos sean aprendices del cliente [Beyer y Holtzblatt 1995].
4.1 Entrevistas
Las entrevistas son la tcnica de elicitacin ms utilizada, y de hecho son prcticamente inevitables en cualquier desarrollo ya que son una de las formas de comunicacin ms naturales entre personas. En las entrevistas, y en otras tcnicas de interaccin, se pueden identicar tres fases: preparacin, realizacin y anlisis [Piattini et al. 1996].
A. Durn, B. Bernrdez Sevilla, Octubre 2001
18
4.1.1 Preparacin de entrevistas Las entrevistas no deben improvisarse, por lo que conviene realizar las siguiente tareas previas:
Estudiar el dominio del problema: conocer las categoras y conceptos de la comunidad de clientes y usuarios es fundamental para poder entender las necesidades de dicha comunidad y su forma de expresarlas [Goguen y Linde 1993], y para generar en los clientes y usuarios la conanza de que el ingeniero de requisitos entiende sus problemas.
Para conocer el dominio del problema se puede recurrir a tcnicas de estudio de documentacin, a bibliografa sobre el tema, documentacin de proyectos similares realizados anteriormente, la inmersin dentro de la organizacin para la que se va a desarrollar [Goguen y Linde 1993] o a periodos de aprendizaje por partes de los ingenieros de requisitos [Beyer y Holtzblatt 1995].
Seleccionar a las personas a las que se va a entrevistar: se debe minimizar el nmero de entrevistas a realizar, por lo que es fundamental seleccionar a las personas a entrevistar. Normalmente se comienza por los directivos, que pueden ofrecer una visin global, y se contina con los futuros usuarios, que pueden aportar informacin ms detallada, y con el personal tcnico, que aporta detalles sobre el entorno operacional de la organizacin.
Tal como se recomienda en [Piattini et al. 1996], conviene tambin estudiar el perl de los entrevistados, buscando puntos en comn con el entrevistador que ayuden a romper el hielo.
Determinar el objetivo y contenido de las entrevistas: para minimizar el tiempo de la entrevista es fundamental jar el objetivo que se pretende alcanzar y determinar previamente su contenido.
Previamente a su realizacin, se pueden enviar cuestionarios que los futuros entrevistados deben rellenar y devolver, y un pequeo documento de introduccin al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se van a tratar y el entrevistador recoja informacin para preparar la entrevista. Es importante que los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta quin los va a responder y no incluir conceptos que se asuman conocidos cuando puedan no serlo.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Entrevistas
19
Planicar las entrevistas: la fecha, hora, lugar y duracin de las entrevista deben jarse teniendo en cuenta siempre la agenda del entrevistado.
En general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados, tal como se describe en [Goguen y Linde 1993]. 4.1.2 Realizacin de entrevistas Dentro de la realizacin de las entrevistas se distinguen tres etapas, tal como se expone en [Piattini et al. 1996]: 1 Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razn de la entrevista, qu se espera conseguir, cmo se utilizar la informacin, la mecnica de las preguntas, etc. Si se va a utilizar algn tipo de notacin grca o matemtica que el entrevistado no conozca debe explicarse antes de utilizarse. Es fundamental causar buena impresin en los primeros minutos. 2 Desarrollo: la entrevista en si no debera durar ms de dos horas, distribuyendo el tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar los monlogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de vdeo o audio, siempre que el entrevistado est de acuerdo [Robertson y Robertson 1999]. Durante esta fase se pueden emplear distintas tcnicas:
Preguntas abiertas: tambin denominadas de libre contexto [Gause y Weinberg 1989], estas preguntas no pueden responderse con un "s" o un "no", permiten una mayor comunicacin y evitan la sensacin de interrogatorio. Por ejemplo, "Qu se hace para registrar un pedido?", "Dgame qu se debe hacer cuando un cliente pide una factura" o "Cmo se rellena un albarn?". Estas preguntas se suelen utilizar al comienzo de la entrevista, pasando posteriormente a preguntas ms concretas. En general, se debe evitar la tendencia a anticipar una respuesta a las preguntas que se formulan [Raghavan et al. 1994]. En
A. Durn, B. Bernrdez Sevilla, Octubre 2001
20
[Gause y Weinberg 1989, cap. 6] se exponen interesantes ejemplos de este tipo de preguntas y consejos para su utilizacin. Una posibilidad es utilizar las plantillas descritas en la seccin 5, pg. 30, como mecanismos tanto de obtencin de informacin, ya que su estructura indica la informacin a buscar, como de registro de las respuestas a este tipo de preguntas.
Utilizar palabras apropiadas: se deben evitar tecnicismos que no conozca el entrevistado y palabras o frases que puedan perturbar emocionalmente la comunicacin [Goleman 1996, Goleman 1999]. Mostrar inters en todo momento: es fundamental cuidar la comunicacin no verbal [Davis 1985] durante la entrevista: tono de voz, movimiento, expresin facial, etc. Por ejemplo, para animar a alguien a hablar puede asentirse con la cabeza, decir "ya entiendo", "s", repetir algunas respuestas dadas, hacer pausas, poner una postura de atencin, etc. Debe evitarse bostezar, reclinarse en el silln, mirar hacia otro lado, etc.
3 Terminacin: al terminar la entrevista se debe recapitular para conrmar que no ha habido confusiones en la informacin recogida, agradecer al entrevistado su colaboracin y citarle para una nueva entrevista si fuera necesario, dejando siempre abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la informacin o al contrastarla con otros entrevistados. 4.1.3 Anlisis de las entrevistas Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la informacin, contrastarla con otras entrevistas o fuentes de informacin, etc. Una vez elaborada la informacin, se puede enviar al entrevistado para conrmar los contenidos. Tambin es importante evaluar la propia entrevista para determinar los aspectos mejorables.
21
las entrevistas individuales que se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de 2 a 4 das. En estas reuniones se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrndolos y hacindolos sentirse partcipes del desarrollo. Esta tcnica se base en cuatro principios [Raghavan et al. 1994]: dinmica de grupo, el uso de ayudas visuales para mejorar la comunicacin (diagramas, transparencias, multimedia, herramientas CASE, etc.), mantener un proceso organizado y racional y una losofa de documentacin WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar. El JAD tiene dos grandes pasos, el JAD/Plan cuyo objetivo es elicitar y especicar requisitos, y el JAD/Design, en el que se aborda el diseo del software. En este documento slo se ver con detalle el primero de ellos. Debido a las necesidades de organizacin que requiere y a que no suele adaptarse bien a los horarios de trabajo de los clientes y usuarios, esta tcnica no suele emplearse con frecuencia, aunque cuando se aplica suele tener buenos resultados, especialmente para elicitar requisitos en el campo de los sistemas de informacin [Raghavan et al. 1994]. En comparacin con las entrevistas individuales, presenta las siguientes ventajas:
Ahorra tiempo al evitar que las opiniones de los clientes se contrasten por separado. Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la documentacin generada, no slo los ingenieros de requisitos. Implica ms a los clientes y usuarios en el desarrollo.
4.2.1 Participantes del JAD Tal como se expone en [Raghavan et al. 1994], se pueden distinguir seis clases de participantes o roles en el JAD:
Jefe del JAD: es el responsable de todo el proceso y asume el control durante las reuniones. Debe tener dotes de comunicacin y liderazgo. Algunas habilidades importantes que debe tener son: entender y
A. Durn, B. Bernrdez Sevilla, Octubre 2001
22
promover la dinmica de grupo, iniciar y centrar discusiones, reconocer cundo la reunin se est desviando del tema y reconducirla, manejar las distintas personalidades y formas de ser de los participantes, evitar que decaiga la reunin aunque sea larga y difcil, etc.
Analista: es el responsable de la produccin de los documentos que se deben generar durante las sesiones JAD. Debe tener la habilidad de organizar bien las ideas y expresarlas claramente por escrito. En el caso de que se utilizan herramientas software durante las sesiones, debe ser capaz de manejarlas ecientemente. Patrocinador ejecutivo: es el que tiene la decisin nal de que se lleve a cabo el desarrollo. Debe proporcionar a los dems participantes informacin sobre la necesidad del nuevo sistema y los benecios que se espera obtener de l. Representantes de los usuarios: durante el JAD/Plan, suelen ser directivos con una visin global del sistema. Durante el JAD/Design suelen incorporarse futuros usuarios nales. Representantes de sistemas de informacin: son personas expertos en sistemas de informacin que deben ayudar a los usuarios a comprender qu es o no factible con la tecnologa actual y el esfuerzo que implica. Especialistas: son personas que pueden proporcionar informacin detallada sobre aspectos muy concretos, tanto del punto de vista de los usuarios porque conocen muy bien el funcionamiento de una parte de la organizacin, como desde el punto de vista de los desarrolladores porque conocen perfectamente ciertos aspectos tcnicos de la instalacin hardware de la organizacin.
4.2.2 Fases del JAD Dentro de la tcnica del JAD se distinguen tres fases [Raghavan et al. 1994]: 1 Adaptacin: es responsabilidad del jefe del JAD, ayudado por uno o dos analistas, adaptar la tcnica del JAD para cada proyecto. La adaptacin debe comenzar por denir el proyecto a alto nivel, para lo cual pueden ser necesarias entrevistas previas con algunos clientes y usuarios. Tambin suele ser necesario recabar informacin sobre la organizacin para familiarizarse con el dominio del problema, por
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
23
ejemplo utilizando tcnicas complementarias como el estudio de documentacin o la observacin in situ. Una vez obtenida una primera idea de los objetivos del proyecto, es necesario seleccionar a los participantes, citarles para las reuniones y proporcionarles una lista con los temas que se van a tratar en las reuniones para que las puedan preparar. El jefe del JAD debe decidir la duracin y el nmero de sesiones a celebrar, denir el formato de la documentacin sobre la que se trabajar y preparar transparencias introductorias y todo el material audiovisual que considere oportuno. 2 Celebracin de las sesiones JAD: durante las sesiones, los participantes exponen sus ideas y se discuten, analizan y renan hasta alcanzar un acuerdo. Los pasos que se recomienda seguir para este proceso son los siguientes: 2.1 Presentacin: se presenta y se da la bienvenida a todos los participantes por parte del patrocinador ejecutivo y del jefe del JAD. El patrocinador ejecutivo expone brevemente las necesidades que han llevado al desarrollo y los benecios que se esperan obtener. El jefe del JAD explica la mecnica de las sesiones y la planicacin prevista. 2.2 Denir objetivos y requisitos: el jefe del JAD promueve la discusin para elicitar los objetivos o requisitos de alto nivel mediante preguntas como: "Por qu se construye el sistema?", "Qu benecios se esperan del nuevo sistema?", "Cmo puede beneciar a la organizacin en el futuro?", "Qu restricciones de recursos disponibles, normas o leyes afectan al proyecto?", "Es importante la seguridad de los datos?", . . . A medida que se van elicitando requisitos, el analista los escribe en transparencias o en algn otro medio que permita que permanezcan visibles durante la discusin. Una posibilidad es utilizar para ello las plantillas descritas en la seccin 5, pg. 30. 2.3 Delimitar el mbito del sistema: una vez obtenido un nmero importante de requisitos, es necesario organizarlos y llegar a un acuerdo sobr el mbito del nuevo sistema. En el caso de los sistemas de informacin, es til identicar a los usuarios potenciales (actores) y determinar qu tareas les ayudar a realizar (casos de uso).
A. Durn, B. Bernrdez Sevilla, Octubre 2001
24
2.4 Documentar temas abiertos: aquellas cuestiones que hayan surgido durante la sesin que no se han podido resolver, deben documentarse para las siguientes sesiones y ser asignadas a una persona responsable de su solucin para una fecha determinada, para lo cual puede utilizarse la plantilla de conictos descrita en la seccin 5.6, pg. 42. 2.5 Concluir la sesin: el jefe del JAD concluye la sesin revisando con los dems participantes la informacin elicitada y las decisiones tomadas. Se da la oportunidad a todos los participantes de expresar cualquier consideracin adicional, fomentando por parte del jefe del JAD el sentimiento de propiedad y compromiso de todos los participantes sobre los requisitos elicitados. 3 Conclusin: una vez terminadas las sesiones es necesario transformar las transparencias, notas y dems documentacin generada en documentos formales. Se distinguen tres pasos: 3.1 Completar la documentacin: los analistas recopilan la documentacin generada durante las sesiones en documentos conformes a las normas o estndares vigentes en la organizacin para la que se desarrolla el proyecto. 3.2 Revisar la documentacin: la documentacin generada se enva a todos los participantes para que la comenten. Si los comentarios son lo sucientemente importantes, se convoca otra reunin para discutirlos. 3.3 Validar la documentacin: una vez revisados todos los comentarios, el jefe del JAD enva el documento al patrocinador ejecutivo para su aprobacin. Una vez aprobado el documento se envan copias denitivas a cada uno de los participantes.
4.3 Brainstorming
El brainstorming o tormenta de ideas es una tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas en un ambiente libre de crticas o juicios [Gause y Weinberg 1989, Raghavan et al. 1994]. Las sesiones de brainstorming suelen estar formadas por un nmero de cuatro a diez participantes, uno de los cuales es el jefe de la sesin, encargado ms de comenzar la sesin que de controlarla.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Brainstorming
25
Como tcnica de elicitacin de requisitos, el brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de elicitacin, cuando los requisitos son todava muy difusos. Frente al JAD, el brainstorming tiene la ventaja de que es muy fcil de aprender y requiere poca organizacin, de hecho, hay propuestas de realizacin de brainstorming por vdeoconferencia a travs de Internet [Raghavan et al. 1994]. Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras tcnicas. 4.3.1 Fases del brainstorming En el brainstorming se distinguen las siguientes fases [Raghavan et al. 1994]: 1 Preparacin: la preparacin para una sesin de brainstorming requiere que se seleccione a los participantes y al jefe de la sesin, citarlos y preparar la sala donde se llevar a cabo la sesin. Los participantes en una sesin de brainstorming para elicitacin de requisitos son normalmente clientes, usuarios, ingenieros de requisitos, desarrolladores y, si es necesario, algn experto en temas relevantes para el proyecto. 2 Generacin: el jefe abre la sesin exponiendo un enunciado general del problema a tratar, que hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas ideas sobre el problema semilla, bien por un orden establecido por el jefe de la sesin, bien aleatoriamente. El jefe es siempre el responsable de dar la palabra a un participante. Este proceso contina hasta que el jefe decide parar, bien porque no se estn generando sucientes ideas, en cuyo caso la reunin se pospone, bien porque el nmero de ideas sea suciente para pasar a la siguiente fase. Durante esta fase se deben observar las siguientes reglas:
Se prohbe la crtica de ideas, de forma que los participantes se sientan libres de formular cualquier idea. Se fomentan las ideas ms avanzadas, que aunque no sean factibles, estimulan a los dems participantes a explorar nuevas soluciones ms creativas.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
26
Se debe generar un gran nmero de ideas, ya que cuantas ms ideas se presenten ms probable ser que se generen mejores ideas. Se debe alentar a los participantes a combinar o completar las ideas de otros participantes. Para ello, es necesario, al igual que en la tcnica del JAD, que todas las ideas generadas estn visibles para todos los participantes en todo momento.
Una posibilidad es utilizar como semilla objetivos del sistema e ir identicando requisitos. Si estos requisitos se recogen en las plantillas propuestas en la seccin 5, pg. 30, pueden utilizarse dichas plantillas para que los participantes tengan visibles las ideas que se van generando. 3 Consolidacin: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: 3.1 Revisar ideas: se revisan las ideas generadas para claricarlas. Es habitual identicar ideas similares, en cuyo caso se unican en un solo enunciado. 3.2 Descartar ideas: aquellas ideas que los participantes consideren excesivamente avanzadas se descartan. 3.3 Priorizar ideas: se priorizan las ideas restantes, identicando las absolutamente esenciales, las que estaran bien pero que no son esenciales y las que podran ser apropiadas para una prxima versin del sistema a desarrollar. 4 Documentacin: despus de la sesin, el jefe produce la documentacin oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.
Casos de uso
27
Los actores son personas u otros sistemas que interactan con el sistema cuyos requisitos se estn describiendo [Scheneider y Winters 1998]. Los casos de uso presentan ciertas ventajas sobre la descripcin meramente textual de los requisitos funcionales [Firesmith 1997], ya que facilitan la elicitacin de requisitos y son fcilmente comprensibles por los clientes y usuarios. Adems, pueden servir de base a las pruebas del sistema y a la documentacin para los usuarios [Weidenhaput et al. 1998]. A pesar de ser una tcnica ampliamente aceptada, existen mltiples propuestas para su utilizacin concreta [Cockburn 1997]. En esta metodologa se propone la utilizacin de los casos de uso como tcnica tanto de elicitacin como de especicacin de los requisitos funcionales del sistema. Para la descripcin concreta de los casos de uso se proponen plantillas, en las que las interacciones se numeran siguiendo las propuestas de [Cockburn 1997], [Scheneider y Winters 1998] y [Coleman 1998] y se describen usando lenguaje natural en forma de patrones lingsticos (ver seccin 5.4, pg. 37).
4.4.1 Diagramas de casos de uso Los casos de uso tienen una representacin grca en los denominados diagramas de casos de uso [Booch et al. 1999]. En estos diagramas, los actores se representan en forma de pequeos monigotes y los casos de uso se representan por elipses contenidas dentro de un rectngulo que representa al sistema. La participacin de los actores en los casos de uso se indica por una echa entre el actor y el caso de uso que apunta en la direccin en la que uye la informacin. Un ejemplo de este tipo de diagramas puede verse en la gura 6. Los diagramas de casos de uso sirven para proporcionar una visin global del conjunto de casos de uso de un sistema as como de los actores y los casos de uso en los que stos intervienen. Las interacciones concretas entre los actores y el sistema no se muestran en este tipo de diagramas.
4.4.2 Relaciones entre casos de uso A veces conviene establecer relaciones entre distintos casos de uso para simplicar su descripcin. Las dos relaciones posibles y sus semnticas segn [Booch et al. 1999] son las siguientes, cuya representacin grca puede verse en el ejemplo de la gura 7.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
28
Caso de uso A
Actor 1
B
<<includes>> <<includes>> <<includes>>
<<extends>>
Casos de uso
29
includes: se dice que un caso de uso incluye el caso de uso , cuando es una parte del caso de uso , es decir, la secuencia de interacciones de forma parte de la secuencia de interacciones de .
El caso de uso se realiza siempre dentro del caso de uso . Adems, siempre que ocurre ocurre tambin , por lo que se dice que es un caso de uso abstracto [Jacobson et al. 1997, Firesmith 1997]. Un caso de uso es abstracto si no puede ser realizado por s mismo, por lo que slo tiene signicado cuando se utiliza para describir alguna funcionalidad que es comn a otros casos de uso. Por otra parte, un caso de uso ser concreto si puede ser iniciado por un actor y realizado por s mismo. Se suele utilizar esta relacin cuando se detectan subsecuencias de interacciones comunes a varios casos de uso. Dichas subsecuencias comunes se sacan "factor comn"de los casos de uso que las contienen y se les da forma de casos de uso que son incluidos por los casos de uso de los que se han "extrado". De esta forma se evita repetir las mismas subsecuencias de interacciones una y otra vez en varios casos de uso.
extends: un caso de uso extiende a otro caso de uso cuando es una subsecuencia de interacciones de que ocurre en una determinada circunstancia.
En cierta forma, completa la funcionalidad de . El caso de uso puede realizarse o no cuando se realiza el caso de uso , segn se den las circunstancias. Por otro lado, el caso de uso puede ser un caso de uso abstracto o concreto, en cuyo caso puede ocurrir sin necesidad de que ocurra el caso de uso . 4.4.3 Organizacin de casos de uso En la mayora de sistemas, el nmero de casos de uso es lo sucientemente elevado como para que sea oportuno organizarlos de alguna forma en lugar de tener una lista plana por la que no es fcil navegar. Una posible forma de organizar los casos de uso es recurrir a los paquetes descritos en la propuesta de UML [Booch et al. 1999]. De esta forma, los casos de uso pueden organizarse en niveles, facilitando as su comprensin. Cada paquete contiene a otros paquetes o a varios casos de uso. En el caso de que los casos de uso se agrupen por criterios funcionales, los paquetes que los agrupan pueden estereotiparse como subsistemas
A. Durn, B. Bernrdez Sevilla, Octubre 2001
30
A <<subsistema>>
Sistema
Figura 8: Representacin grca de los paquetes de casos de uso [Scheneider y Winters 1998], tal como puede verse en el ejemplo de la gura 8.
31
Figura 9: La plantilla como elemento de elicitacin y negociacin las especicaciones de requisitos y que se han parametrizado. Estas frases, a las que hemos denominado patrones lingsticos, o abreviadamente patronesL, pueden usarse para rellenar los campos de las plantillas dndole valores a los parmetros con la informacin oportuna. Ambos aspectos, la estructuracin de la informacin en forma de plantilla y la propuesta de frases "estndar", facilita la redaccin de los requisitos, permitiendo a los participantes en las actividades de elicitacin centrarse en expresar sus necesidades y no en cmo expresarlas. En la notacin usada para describir los patronesL, las palabras o frases entre y deben ser convenientemente reemplazadas, las palabras o frases que se encuentren entre { y } y separadas por comas representan opciones de las que se debe escoger una y las palabras entre [ y ] son opcionales, es decir, pueden aparecer o no. En las siguientes secciones se describen las plantillas propuestas y los patronesL identicados.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
32
Figura 10: Plantilla y patronesL para objetivos El signicado de los campos que la componen, cuya mayora est presente tambin en las plantillas para los requisitos, es el siguiente:
Identicador y nombre descriptivo: siguiendo la propuesta, entre otros, de [Sawyer et al. 1997], cada objetivo debe identicarse por un cdigo nico y un nombre descriptivo. Con objeto de conseguir una rpida identicacin, los identicadores de los objetivos comienzan con OBJ. Versin: para poder gestionar distintas versiones, este campo contiene el nmero y la fecha de la versin actual del objetivo. Autores, Fuentes: estos campos contienen el nombre y la organizacin de los autores (normalmente desarrolladores) y de las fuentes (clientes o usuarios), de la versin actual del objetivo, de forma que la rastreabilidad pueda llegar hasta las personas que propusieron la necesidad del objetivo. Descripcin: este campo contiene un patrnL que se debe completar con la descripcin del objetivo.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
33
Subobjetivos: en este campo pueden indicarse los subobjetivos que dependen del objetivo que se est describiendo. En sistemas complejos puede ser necesario establecer una jerarqua de objetivos previa a la identicacin de los requisitos. En caso de que sto no sea necesario, puede ignorarse este campo. Importancia: este campo indica la importancia del cumplimiento del objetivo para los clientes y usuarios. Se puede asignar un valor numrico o alguna expresin enumerada como vital, importante o quedara bien, tal como se propone en [IBM OOTC 1997]. En el caso de que no se haya establecido an la importancia, se puede indicar que est por determinar (PD), equivalente al TBD (To Be Determined) empleado en las especicaciones escritas en ingls. Urgencia: este campo indica la urgencia del cumplimiento del objetivo para los clientes y usuarios en el supuesto caso de un desarrollo incremental. Como en el caso anterior, se puede asignar un valor numrico o una expresin enumerada como inmediatamente, hay presin o puede esperar [IBM OOTC 1997], o PD en el caso de que an no se haya determinado. Estado: este campo indica el estado del objetivo desde el punto de vista de su desarrollo. El objetivo puede estar en construccin si se est elaborando, pendiente de negociacin si tiene algn conicto asociado pendiente de solucin, pendiente de vericacin si no tiene ningn conicto pendiente y est a la espera de vericacin o, pendiente de validacin si ya ha sido vericado y est a la espera de validacin o por ltimo, puede estar validado si ya ha sido validado por clientes y usuarios. Estabilidad: este campo indica la estabilidad del objetivo, es decir una estimacin de la probabilidad de que pueda sufrir cambios en el futuro. Esta estabilidad puede indicarse mediante un valor numrico o mediante una expresin enumerada como alta, media o baja o PD en el caso de que an no se haya determinado.
La informacin sobre la estabilidad, bien a nivel de objetivos como en este caso, bien a nivel de requisitos, ayuda a los diseadores a disear software que prevea de antemano la necesidad de posibles cambios futuros en aquellos aspectos relacionados con los elementos identicados como inestables durante la fase de ingeniera de requisitos, favoreciendo as el mantenimiento y la evolucin del software [Brackett 1990].
A. Durn, B. Bernrdez Sevilla, Octubre 2001
34
Comentarios: cualquier otra informacin sobre el objetivo que no encaje en los campos anteriores puede recogerse en este apartado.
Identicador y nombre descriptivo: siguiendo las recomendaciones, entre otros, de [IEEE 1993] y [Sawyer et al. 1997], cada requisito se debe identicar por un cdigo nico y un nombre descriptivo. Con objeto de conseguir una rpida identicacin, los identicadores de los requisitos de almacenamiento de informacin comienzan con IRQ y los de requisitos de restricciones de informacin con CRQ. Versin, Autores, Fuentes: estos campos tienen el mismo signicado que en la plantilla para objetivos aunque referidos al requisito. Objetivos asociados: este campo debe contener una lista con los objetivos a los que est asociado el requisito, es decir de los objetivos de los que depende. Esto permite conocer qu requisitos harn que el sistema a desarrollar alcance los objetivos propuestos y justican de esta forma la existencia o propsito del requisito. Requisitos asociados: en este campo se indican otros requisitos que estn asociados por algn motivo con el requisito que se est describiendo, es decir de los requisitos de los que depende. De esta forma se posibilita tener una rastreabilidad horizontal, similar a las relaciones entre assets del mismo nivel descritas en [Garca 2000]. Descripcin: para los requisitos de almacenamiento de informacin este campo usa un patrnL que se debe completar con el concepto relevante sobre el que se debe almacenar informacin. En el caso de los requisitos de restricciones de informacin, este campo usa un
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
35
IRQ id Versin Autores Fuentes Objetivos asociados Requisitos asociados Descripcin Datos especcos Tiempo de vida Ocurrencias simult. Importancia Urgencia Estado Estabilidad Comentarios
nombre descriptivo no de la versin actual ( fecha de la versin actual ) autor de la versin actual ( organizacin del autor ) ... fuente de la versin actual ( organizacin de la fuente ) ... OBJx nombre del objetivo ... Rxy nombre del requisito ... El sistema deber almacenar la informacin correspondiente a concepto relevante . En concreto: datos especcos sobre el concepto relevante ... Medio Mximo tiempo medio de vida tiempo mximo de vida Medio Mximo no medio de ocurr. simult. no mximo de ocurr. simult. importancia del requisito urgencia del requisito estado del requisito estabilidad del requisito comentarios adicionales sobre el requisito
36
patrnL que se debe completar con la restriccin o regla de negocio que debe cumplir la informacin almacenada por el sistema.
Datos especcos: este campo contiene una lista de los datos especcos asociados al concepto relevante, de los que pueden indicarse todos aquellos aspectos que se considere oportunos (descripcin, restricciones, ejemplos, etc.). Tiempo de vida: este campo indica el tiempo de vida medio y mximo que se espera para cada ocurrencia del concepto relevante. Ocurrencias simultneas: este campo indica el nmero medio y mximo de ocurrencias simultneas del concepto relevante. Tanto este campo como el anterior permiten a los diseadores prever determinadas necesidades del sistema a desarrollar en lo relativo a las necesidades de almacenamiento de informacin. Importancia, Urgencia, Estado, Estabilidad, Comentarios: estos campos tienen el mismo signicado que en la plantilla para objetivos aunque referidos al requisito.
Figura 13: Plantilla y patronesL para actores El nico campo especco de esta plantilla es la descripcin, en la que se usa un patrnL que debe completarse con la descripcin del rol o papel que representa el actor respecto al sistema. El signicado del resto de los campos es el mismo que para las plantillas anteriores.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
37
Identicador y nombre descriptivo: igual que en las plantillas anteriores, excepto que los identicadores de los requisitos funcionales empiezan con UC para los casos de uso y con FRQ para los requisitos funcionales expresados de la forma tradicional, y que para los casos de uso, el nombre descriptivo suele coincidir con el objetivo que los actores esperan alcanzar al realizarlo. No se debe confundir este objetivo con los objetivos del sistema. El objetivo que los actores esperan alcanzar al realizar un caso de uso es de ms bajo nivel, por ejemplo registrar un nuevo socio o consultar los pedidos pendientes. Descripcin: para los requisitos funcionales expresados de la forma tradicional, este campo contiene un patrnL que debe completarse con la capacidad o funcionalidad que debe presentar el sistema a desarrollar.
Para los requisitos funcionales expresados como casos de uso, este campo contiene un patrnL que debe completarse de forma distinta en funcin de que el caso de uso sea abstracto o concreto (ver seccin 4.4.2, pg. 27). Si el caso de uso es abstracto, deben indicarse los casos de uso en los que se debe realizar, es decir, aquellos desde los que es incluido o a los que extiende. Si, por el contrario, se trata de un caso de uso concreto, se debe indicar el evento de activacin que provoca su realizacin, y en el caso de que sea incluido desde, o extienda a, otros casos de uso, se debern indicar dichos casos de uso.
Precondicin: en este campo se expresan en lenguaje natural las condiciones necesarias para que se pueda realizar el caso de uso. Estas
A. Durn, B. Bernrdez Sevilla, Octubre 2001
38
nombre descriptivo no de la versin actual ( fecha de la versin actual ) autor de la versin actual ( organizacin del autor ) ... fuente de la versin actual ( organizacin de la fuente ) ... OBJx nombre del objetivo ... Rxy
Postcondicin Excepciones
Rendimiento
... El sistema deber comportarse tal como se describe en el siguiente caso de uso { abstracto durante la realizacin de los siguientes casos de uso: lista de casos de uso , cuando evento de activacin [o durante la realizacin de los siguientes casos de uso: lista de casos de uso ]} precondicin del caso de uso Paso Accin {El actor actor , El sistema} accin/es realizada/s por actor/sistema Se realiza el caso de uso caso de uso (RFx) Si condicin , {el actor actor , el sistema} accin/es realizada/s por actor/sistema Si condicin , se realiza el caso de uso caso de uso (RFx) ... ... postcondicin del caso de uso Paso Accin Si condicin de excepcin , {el actor actor , el sistema} accin/es realizada/s por actor/sistema , a continuacin este caso de uso {contina, queda sin efecto} Si condicin de excepcin , se realiza el caso de uso caso de uso (RFx) , a continuacin este caso de uso {contina, queda sin efecto} ... ... Paso Cota de tiempo q m unidad de tiempo ... ... no de veces veces / unidad de tiempo importancia del requisito urgencia del requisito estado del requisito estabilidad del requisito comentarios adicionales sobre el requisito
39
Figura 15: Plantilla y patronesL para requisitos funcionales (forma tradicional) condiciones se establecen bien sobre el entorno en el que opera el sistema, y que por lo tanto quedarn fuera de su control, bien sobre el estado del propio sistema.
Secuencia normal: este campo contiene la secuencia normal de interacciones del caso de uso. En cada paso, un actor o el sistema realiza una o ms acciones, o se realiza (se incluye) otro caso de uso. Un paso puede tener una condicin de realizacin, en cuyo caso si se realizara otro caso de uso se tendra una relacin de extensin. Se asume que, despus de realizar el ltimo paso, el caso de uso termina.
Otras propuestas similares, por ejemplo [Coleman 1998], proponen utilizar estructuras similares al pseudocdigo para expresar las interacciones de los casos de uso. En nuestra opinin, esto puede llevar a que dichas descripciones sean excesivamente complejas de entender para los participantes sin conocimientos de programacin y se corre el peligro de especicar los casos de uso con un estilo cercano a la programacin. Para representar estructuras condicionales complejas se puede recurrir a aadir informacin aparte, por ejemplo una tabla de decisin, y referenciarla desde el paso o los pasos oportunos. En el caso de estructuras iterativas, su uso puede evitarse con un uso cuidadoso del lenguaje natural. Por ejemplo, para indicar que se
A. Durn, B. Bernrdez Sevilla, Octubre 2001
40
procesan todos los artculos de un pedido se puede optar por frases como "el sistema procesa todos los artculos del pedido introducidos por el usuario", en lugar de estructuras como:
REPETIR procesar artculo del pedido introducido por el usuario HASTA que no haya ms artculos
Otro ejemplo puede ser especicar que el usuario puede intentar conectarse al sistema un mximo de tres veces. Una posible especicacin sera la que puede verse en la gura 16, bastante ms natural y fcil de entender que la que puede verse en la gura 17 utilizando la propuesta descrita en [Coleman 1998].
Postcondicin: en este campo se expresan en lenguaje natural las condiciones que se deben cumplir despus de la terminacin normal del caso de uso. Al igual que en el caso de las precondiciones, las postcondiciones se pueden establecer tanto sobre el entorno del sistema como sobre el estado del propio sistema. Excepciones: este campo especica el comportamiento del sistema en el caso de que se produzca alguna situacin excepcional durante la realizacin de un paso determinado.
Despus de realizar las acciones o el caso de uso asociados a la excepcin (una extensin), el caso de uso puede continuar la secuencia normal o quedar sin efecto, en cuyo caso se cancelan todas las acciones realizadas en el caso de uso dejando al sistema en el mismo estado que antes de comenzar el caso de uso, asumiendo una semntica transaccional del mismo, tal como se describe en [Jacobson et al. 1997]. Inicialmente, la expresin utilizada para indicar una terminacin anormal del caso de uso como resultado de una excepcin era "este caso de uso aborta". La experiencia durante su aplicacin nos llev a la conclusin de que el termino abortar resultaba emocionalmente molesto para algunos participantes [Goleman 1996], por lo que se cambi por "este caso de uso queda sin efecto" con el signicado comentado anteriormente.
Rendimiento: en este campo puede especicarse el tiempo mximo para cada paso en el que el sistema realice un accin.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
41
Secuencia normal
Paso 1 2 3 4
5 Excepciones Paso 4
Accin El sistema solicita al usuario su nombre de usuario y su clave de acceso El usuario proporciona el sistema su nombre y su clave de acceso El sistema comprueba si el nombre de usuario y la clave de acceso son correctas Si el nombre de usuario y la clave no son correctas, el sistema permite al usuario repetir el intento (pasos 13) hasta un mximo de tres veces Si el nombre de usuario y la clave son correctas, el sistema permite el acceso al usuario Accin Si el usuario ha intentado tres veces acceder sin xito, el sistema rechaza el acceso del usuario, a continuacin este caso de uso termina
1. El sistema inicializa intentos a 0 2. REPETIR 2.1 El sistema solicita al usuario su nombre de usuario 2.2 El usuario proporciona al sistema su nombre de usuario 2.3 El sistema solicita al usuario su clave 2.4 El usuario proporciona al sistema su clave 2.5 El sistema comprueba si el nombre de usuario y la clave son correctas 2.6 El sistema incrementa intentos HASTA QUE el nombre de usuario y la clave sean correctas o intentos = 3 3. SI el nombre de usuario y la clave son correctas 3.1 El sistema permite el acceso al usuario SINO 3.2 El sistema rechaza el acceso del usuario FINSI
A. Durn, B. Bernrdez
42
Frecuencia esperada: en este campo se indica la frecuencia esperada de realizacin del caso de uso, que aunque no es realmente un requisito, es una informacin interesante para los desarrolladores.
43
Identicador y nombre descriptivo: al igual que el resto de la informacin correspondiente a los requisitosC, cada conicto debe poderse identicar de forma nica y tener un nombre descriptivo. El prejo propuesto para lograr una rpida identicacin es CFL. Versin, Autores, Fuentes: estos campos tienen el mismo signicado que en las plantillas para objetivos y requisitos, aunque referidos al conicto. En este caso especial, las fuentes son los participantes que deben participar en las posibles negociaciones necesarias para su resolucin. Objetivos y requisitos en conicto: este campo debe contener una lista con los objetivos y/o requisitos afectados por el conicto. Descripcin: este campo debe contener la descripcin del conicto. Alternativas: este campo debe contener una lista con las posibles alternativas de solucin que se hayan identicado para solucionar el conicto as como los autores de dicha alternativas. Solucin: este campo debe contener la descripcin de la solucin negociada del conicto, una vez que se haya acordado. Importancia, Urgencia: estos campos indican respectivamente la importancia y la urgencia de la resolucin del conicto.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
44
Estado: este campo indica el estado de resolucin del conicto, que podr estar no resuelto, en negociacin o bien resuelto. Comentarios: este campo tienen el mismo signicado que en las plantillas descritas previamente.
Referencias
[Beyer y Holtzblatt 1995] H. R. Beyer y K. Holtzblatt. Apprenticing with the Customer. Communications of the ACM, 38(5), Mayo 1995. [Boehm et al. 1994] B. W. Boehm, P. Bose, E. Horowitz, y M.-J. Lee. Software Requirements as Negotiated Win Conditions. En Proceedings of the First International Conference on Requirements Engineering, 1994. Disponible en http://sunset.usc.edu/TechRpts/Papers/NGPMRequirements93.ps. [Booch et al. 1999] G. Booch, J. Rumbaugh, y I. Jacobson. The Unied Modeling Language User Guide. AddisonWesley, 1999. [Brackett 1990] J. W. Brackett. Software Requirements. Curriculum Module SEICM191.2, Software Engineering Institute, Carnegie Mellon University, 1990. Disponible en http://www.sei.cmu.edu. [Cockburn 1997] A. Cockburn. Structuring Use Cases with Goals. Journal of ObjectOriented Programming, Sept. y Nov./Dic. 1997. Disponible en http://members.aol.com/acockburn/papers/usecases.htm. [Coleman 1998] D. Coleman. A Use Case Template: Draft for Discussion. Fusion Newsletter, Abril 1998. Disponible en http://www.hpl.hp.com/fusion/md_newletters.html. [Davis 1985] F. Davis. La comunicacin no verbal, volumen 616 de El Libro de Bolsillo. Alianza Editorial, 1985. [Durn 2000] A. Durn. Un Entorno Metodolgico de Ingeniera de Requisitos para Sistemas de Informacin. Tesis doctoral, Universidad de Sevilla, 2000. [Firesmith 1997] D. G. Firesmith. Uses Cases: the Pros and Cons, 1997. Disponible en http://www.ksccary.com/usecjrnl.html.
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Referencias
45
[Garca 2000] F. J. Garca. Modelo de Reutilizacin Soportado por Estructuras Complejas de Reutilizacin Denominadas Mecanos. Tesis doctoral, Universidad de Salamanca, 2000. [Gause y Weinberg 1989] D. C. Gause y G. M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House, 1989. [Goguen y Linde 1993] J. A. Goguen y C. Linde. Techniques for Requirements Elicitation. En Proceedings of the First International Symposium on Requirements Engineering, 1993. Tambin aparece en [Thayer y Dorfman 1997]. Disponible en http://www.cse.ucsd.edu/goguen. [Goleman 1996] D. Goleman. La Inteligencia Emocional. Kairs, 1996. [Goleman 1999] D. Goleman. La Prctica de la Inteligencia Emocional. Kairs, 1999. [IBM OOTC 1997] IBM OOTC. Developing ObjectOriented Software. IBM ObjectOriented Technology Center. PrenticeHall, 1997. [IEEE 1993] IEEE. IEEE Recommended Practice for Software Requirements Specications. IEEE/ANSI Standard 8301993, Institute of Electrical and Electronics Engineers, 1993. [Jacobson et al. 1993] I. Jacobson, M. Christerson, P. Jonsson, y G. vergaard. ObjectOriented Software Engineering: A Use Case Driven Approach. AddisonWesley, 4a edicin, 1993. [Jacobson et al. 1997] I. Jacobson, M. Griss, y P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. AddisonWesley, 1997. [Laguna et al. 1999] M. A. Laguna, J. M. Marqus, y F. J. Garca. Una Herramienta para la Captura de Requisitos de Usuario. En Actas de las JISBD99, Cceres, 1999. [Leite et al. 1997] J. C. S. P. Leite, G. Rossi, F. Balaguer, V. Maiorana, G. Kaplan, G. Hadad, y A. Oliveros. Enhancing a Requirements Baseline with Scenarios. En Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE97), 1997. [MAP 1995] MAP. Metodologa de Planicacin y Desarrollo de Sistemas de Informacin. MTRICA Versin 2.1. Tecnos/Ministerio para las Administraciones Pblicas, 1995.
A. Durn, B. Bernrdez Sevilla, Octubre 2001
46
[Ortn et al. 2001] M. J. Ortn, J. Garca, B. Moros, y J. Nicols. El Modelo de Negocio como Base del Modelo de Requisitos. En Actas de las Jornadas de Ingeniera de Requisitos Aplicada, Sevilla, 2001. [Piattini et al. 1996] M. G. Piattini, J. A. Calvo-Manzano, J. Cervera, y L. Fernndez. Anlisis y Diseo Detallado de Aplicaciones Informticas de Gestin. rama, 1996. [Raghavan et al. 1994] S. Raghavan, G. Zelesnik, y G. Ford. Lecture Notes on Requirements Elicitation. Educational Materials CMU/SEI94EM 10, Software Engineering Institute, Carnegie Mellon University, 1994. Disponible en http://www.sei.cmu.edu. [Robertson y Robertson 1999] S. Robertson y J. Robertson. Mastering the Requirement Process. AddisonWesley, 1999. [Rolland et al. 1998] C. Rolland, C. Ben Achour, C. Cauvet, J. Ralyt, A. Sutcliffe, N. A. M. Maiden, M. Jarke, P. Haumer, K. Pohl, E. Dubois, y P. Heymans. A Proposal for a Scenario Classication Framework. Requirements Engineering Journal, 3(1), 1998. Disponible en http://sunsite.informatik.rwthaachen.de/CREWS/reports98.htm. [Sawyer et al. 1997] P. Sawyer, I. Sommerville, y S. Viller. Requirements Process Improvement through The Phased Introduction of Good Practice. Software Process Improvement and Practice, 3(1), 1997. Disponible en http://www.comp.lancs.ac.uk/computing/research/cseg/ reaims/publications.html. [Sawyer y Kontoya 1999] P. Sawyer y G. Kontoya. SWEBOK: Software Requirements Engineering Knowledge Area Description. Informe Tcnico Versin 0.5, SWEBOK Project, 1999. Disponible en http://www.swebok.org. [Scheneider y Winters 1998] G. Scheneider y J. P. Winters. Applying Use Cases: a Practical Guide. AddisonWesley, 1998. [Thayer y Dorfman 1990] R. H. Thayer y M. Dorfman, editores. System and Software Requirements Engineering. IEEE Computer Society Press, 1990. [Thayer y Dorfman 1997] R. H. Thayer y M. Dorfman, editores. Software Requirements Engineering. IEEE Computer Society Press, 2a edicin, 1997. Es la 2a edicin de [Thayer y Dorfman 1990].
Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010 (revisado)
Referencias
47
[Weidenhaput et al. 1998] K. Weidenhaput, K. Pohl, M. Jarke, y P. Haumer. Scenarios in System Development: Current Practice. IEEE Software, 15(2):3445, Marzo/Abril 1998. Este artculo aparece tambin en las actas del ICRE98 y est disponible en http://sunsite.informatik.rwthaachen.de/CREWS/reports97.htm. [Wirfs-Brock et al. 1990] R. Wirfs-Brock, B. Wilkerson, y L. Wiener. Designing ObjectOriented Software. PrenticeHall, 1990.
A. Durn, B. Bernrdez
48
OBJ02 Descripcin
Estabilidad Comentarios
Gestionar los socios El sistema deber gestionar la informacin correspondiente a los socios del vdeoclub: altas, bajas, modicaciones de datos, sanciones, personas autorizadas y cuentas. alta ninguno
OBJ02 Descripcin
Estabilidad Comentarios
Gestionar los alquileres El sistema deber gestionar la informacin correspondiente a los alquileres de cintas: entregas, devoluciones, devoluciones tardas, reclamaciones y disponibilidad. alta ninguno
Requisitos de informacin
49
Estabilidad Comentarios
Relacin entre pelculas y cintas OBJ01 Gestionar las pelculas y cintas IRQ01 Informacin sobre pelculas La informacin almacenada por el sistema deber satisfacer la siguiente restriccin: una cinta de vdeo contiene como mucho una pelcula, sin embargo es posible que pelculas de muy larga duracin se presenten en formato de dos o ms cintas. alta ninguno
A. Durn, B. Bernrdez
50
IRQ02 Objetivos asociados Requisitos asociados
Estabilidad Comentarios
Informacin sobre socios OBJ02 Gestionar los socios FRQ01 Alta de socio FRQ02 Baja de socio FRQ03 Modicacin de datos de un socio FRQ11 Consulta de un socio FRQ12 Consulta de socios con pagos pendientes FRQ12 Consulta de los socios ms rentables FRQ15 Identicacin de socio El sistema deber almacenar la informacin correspondiente a los socios del vdeoclub. En concreto: Nmero de socio Nmero del documento nacional de identidad Nombre y apellidos Fecha de nacimiento Sexo Fecha de alta como socio Direccin Telfonos Pelculas alquiladas en un momento dado alta ninguno
Estabilidad Comentarios
Unicidad de nmeros de socio OBJ02 Gestionar los socios IRQ02 Informacin sobre socios FRQ01 Alta de socio La informacin almacenada por el sistema deber satisfacer la siguiente restriccin: los nmeros de socio debern ser nicos para cada socio, es decir, no puede haber dos socios distintos con el mismo nmero. alta ninguno
Requisitos de informacin
IRQ03 Objetivos asociados Requisitos asociados
51
Estabilidad Comentarios
Informacin sobre cuentas de socios OBJ02 Gestionar los socios FRQ01 Alta de socio FRQ02 Baja de socio FRQ05 Alquiler de cinta de vdeo FRQ08 Devolucin de cintas de vdeo FRQ09 Ingreso a cuenta FRQ11 Consulta de un socio FRQ12 Consulta de socios con pagos pendientes El sistema deber almacenar la informacin correspondiente a las cuentas de los socios del vdeoclub. En concreto: Saldo de la cuenta en cada momento Ingresos realizados en la cuenta, indicando fecha y cantidad Cargos realizados en la cuenta, indicando fecha, motivo y cantidad Pagos pendientes, indicando motivo que podr ser alquiler no pagado o multa; en el caso de alquiler no pagado se debe indicar tambin la pelcula alquilada y la fecha del alquiler alta Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por pelculas sin que stos tengan que llevar dinero
Estabilidad Comentarios
Alquiler de pelculas de ms de una cinta OBJ03 Gestionar los alquileres IRQ02 Informacin sobre socios FRQ06 Alquiler de cintas de vdeo La informacin almacenada por el sistema deber satisfacer la siguiente restriccin: los alquileres de pelculas que se presentan en varias cintas se consideran como un nico alquiler aunque el socio se lleve ms de una cinta. alta ninguno
A. Durn, B. Bernrdez
52
<<includes>> Socio Baja de socio (UC-02) <<includes>> Identificacin de socio (UC-15) Modificacin de los datos de un socio (UC-03)
Requisitos funcionales
53
A. Durn, B. Bernrdez
54
Socio
Devolucin de cintas de vdeo (UC-08) Identificacin de socio (UC-15) Ingreso a cuenta (UC-09)
Requisitos funcionales
55
A. Durn, B. Bernrdez
56
Postcondicin Excepciones
Requisitos funcionales
UC02 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Baja de socio OBJ02 Gestionar las socios
57
Postcondicin Excepciones
A. Durn, B. Bernrdez
58
UC03 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal
Requisitos funcionales
UC11 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Consulta de un socio OBJ02 Gestionar las socios
59
Postcondicin Excepciones
A. Durn, B. Bernrdez
60
UC12 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal
IRQ02 Informacin sobre socios IRQ03 Informacin sobre cuentas de socios El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado del vdeoclub lo considere oportuno Ninguna Paso Accin 1 El empleado del vdeoclub solicita al sistema comenzar el proceso de consulta de los socios con pagos pendientes 2 El sistema muestra una lista ordenada por cantidad pendiente con la siguiente informacin por cada socio: nombre, apellidos, cantidad total pendiente y detalle de las cantidades pendientes 3 Si el empleado del vdeoclub solicita la impresin de los datos, el sistema imprime la lista Ninguna Paso Accin Paso Cota de tiempo 2 5 segundos 1 vez/semana ninguno
Requisitos funcionales
UC15 Objetivos asociados Requisitos asociados Descripcin Identicacin de socio OBJ02 Gestionar las socios
61
Postcondicin Excepciones
A. Durn, B. Bernrdez
62
Postcondicin Excepciones
IRQ01 Informacin sobre pelculas IRQ05 Alta de cinta de vdeo El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando se adquiera una cinta de una pelcula nueva La pelcula no est registrada en el sistema Paso Accin 1 El empleado del vdeoclub solicita al sistema comenzar el proceso de alta de pelcula 2 El sistema solicita los siguientes datos de la nueva pelcula: ttulo, tipo de pelcula, duracin, actores principales, director, productora y ao de produccin 3 El empleado del vdeoclub proporciona los datos requeridos y solicita al sistema que los almacene 4 El sistema almacena los datos proporcionados 5 El sistema informa al empleado del vdeoclub que el proceso ha terminado con xito El sistema ha almacenado la informacin correspondiente a la nueva pelcula Paso Accin 4 Si el sistema detecta que la pelcula ya est registrada, el sistema informa de la situacin al empleado del vdeoclub permitindole modicar los datos proporcionados, a continuacin este caso de uso contina Paso Cota de tiempo 4 1 segundo 1 vez/da ninguno
Requisitos funcionales
UC05 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Alta de cinta de vdeo OBJ01 Gestionar las cintas y pelculas
63
A. Durn, B. Bernrdez
64
UC08 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal
Postcondicin Excepciones
Requisitos funcionales
UC10 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Consulta de una pelcula OBJ01 Gestionar las cintas y pelculas
65
A. Durn, B. Bernrdez
66
Postcondicin Excepciones
IRQ02 Informacin sobre socios IRQ03 Informacin sobre cuentas de socios El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando un socio solicite alquilar una o ms cintas de vdeo Ninguna de las cintas a alquilar est registradas como alquiladas Paso Accin 1 El empleado del vdeoclub solicita al sistema comenzar el proceso de alquiler de cintas de vdeo 2 Se realiza el caso de uso UC15 (Identicacin de socio) 2 El sistema solicita que se identiquen las cintas que desean alquilar 3 El empleado del vdeoclub identica las cintas y solicita al sistema que registre el alquiler 4 El sistema almacena la informacin de los alquileres 5 Si el socio decide pagar al contado, el sistema imprime el ticket con el importe correspondiente y registra el pago como un ingreso en la cuenta del socio 6 Si el socio decide pagar a cuenta, el sistema registra el cargo en la cuenta del socio 7 El sistema comunica al empleado del vdeoclub que el proceso de registro ha terminado con xito Las cintas a alquilar estn registradas como alquiladas y la cuenta del socio est actualizada Paso Accin 3 Si alguna de las cintas est registrada como alquilada, el sistema comunicar la situacin al empleado del vdeoclub y excluir la cinta del alquiler, a continuacin este caso de uso contina Paso Cota de tiempo 4 1 segundo 50 veces/da ninguno
Requisitos funcionales
UC07 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Devolucin de cintas de vdeo OBJ03 Gestionar los alquileres
67
Postcondicin Excepciones
IRQ02 Informacin sobre socios IRQ03 Informacin sobre cuentas de socios El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando un socio solicite devolver una o ms cintas de vdeo Todas las cintas a devolver estn registradas como alquiladas Paso Accin 1 El empleado del vdeoclub solicita al sistema comenzar el proceso de devolucin de cintas de vdeo 2 El sistema solicita que se identiquen las cintas que se desean devolver 3 El empleado del vdeoclub identica las cintas y solicita al sistema que registre su devolucin 4 El sistema registra los devoluciones 5 Si alguna cinta ha sido devuelta fuera de plazo, el sistema registra la multa correspondiente como un cargo en la cuenta del socio 6 Si el socio decide pagar al contado, el sistema imprime el ticket con el importe correspondiente y registra el pago como un ingreso en la cuenta del socio 7 Si el socio decide pagar a cuenta, el sistema registra el cargo en la cuenta del socio Las cintas a alquilar estn registradas como alquiladas y la cuenta del socio est actualizada Paso Accin 4 Si alguna de las cintas est registrada como alquilada, el sistema comunica la situacin al empleado del vdeoclub y excluye la cinta del alquiler, a continuacin este caso de uso contina Paso Cota de tiempo 4 1 segundo 50 veces/da ninguno
A. Durn, B. Bernrdez
68
UC09 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal
IRQ02 Informacin sobre socios IRQ03 Informacin sobre cuentas de socios El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando un socio solicite hacer un ingreso en su cuenta El socio tiene disponible su carnet Paso Accin 1 El empleado del vdeoclub solicita al sistema comenzar el proceso de ingreso en cuenta 2 El sistema solicita que se identique al socio y se indique la cantidad a ingresar 3 El empleado del vdeoclub proporciona al sistema la identicacin del socio y la cantidad a ingresar 4 El sistema registra el ingreso e informa del nuevo saldo 3 El empleado del vdeoclub comunica al socio su nuevo saldo El saldo de la cuenta del socio est actualizado Paso Accin Paso Cota de tiempo 4 1 segundo 5 veces/da Mientras no se implemente se puede hacer que todos los pagos sean al contado
Requisitos funcionales
UC13 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal Consulta de las pelculas alquiladas un da determinado OBJ03 Gestionar los alquileres
69
A. Durn, B. Bernrdez
70
UC14 Objetivos asociados Requisitos asociados Descripcin Precondicin Secuencia normal
Requisitos no funcionales
71
A. Durn, B. Bernrdez
72