lsi-2000-10

Metodologa para la Elicitacinde Requisitos de Sistemas Software

Versin 2.1

Amador Durn Toro

Beatriz Bernrdez Jimnez

Informe Tcnico LSI200010

Departamento de Lenguajes y Sistemas Informticos

Facultad de Informtica y Estadstica

Sevilla, octubre de 2000

Este trabajo ha sido financiado por Ministerio de Educacin y Ciencia de Espaaa travs del proyecto "MENHIR"de la CICYT TIC 970593C0501

Lista de cambiosNm. Fecha Descripcin Autor/es

0 13/10/1998 Versin 1.0 A. Durn y B.Bernrdez

1 04/11/1998 [pg. 18] En el apartado de importancia de la plantilla general derequisitos del sistema, donde apareca En este apartado se indica laimportancia que tiene el caso de uso para el clienteaparece ahora En esteapartado se indica la importancia que tiene el requisito para el cliente"

A. Durn

2 04/11/1998 [pg. 18] En el apartado de urgencia de la plantilla general de re-quisitos del sistema, donde apareca . . . incluyendo la funcionalidadexpresada en el caso de usoaparece ahora . . . incluyendo las capacidadesexpresadas en el requisito"

A. Durn

3 04/11/1998 [pg. 23] En la descripcin de la relacin extends entre casos deuso, donde apareca En cierta forma, B completa la funcionalidad deAaparece ahora En cierta forma, A completa la funcionalidad de B"

A. Durn

4 04/11/1998 [pgs. 3, 6, 8, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 30] Correccionesortogrficas diversas

A. Durn

5 04/11/1998 Versin 1.1 A. Durn6 18/10/1999 En la versin 2.0 se han introducido numerosos cambios, los prin-

cipales son los siguientes:A. Durn

El ttulo cambia de Norma para la Recoleccin de Requisitos de un Siste-ma Software a Metodologa para la Elicitacin de Requisitos de SistemasSoftwareLa primera seccin del documento pasa de denominarse Objetivo yalcance a Objetivo de la metodologaSe han eliminado de la tarea 1 las referencias relativas a la construc-cin de modelos de anlisis del dominioEn la tarea 2 se habla de reuniones en lugar de hacerlo especfica-mente de entrevistasSe ha aadido la tarea 3 Identificar los objetivos del sistema como tareaprevia a la identificacin de los requisitos y se ha diseado unaplantilla especfica para los objetivosSe han cambiado todas las apariciones de otros requisitos por requi-sitos no funcionalesSe ha cambiado el contenido de las secciones Introduccin y Objeti-vos del sistema del DRSSe han aadido al DRS las secciones Participantes en el proyecto yMatriz de rastreabilidadSe ha contemplado la posibilidad de organizar los requisitos de for-ma que no sean una lista planaSe han aadido las descripciones de las tcnicas de JAD y brains-tormingSe ha reescrito la descripcin de la tcnica de los casos de usoSe ha cambiado el nombre de la relacin uses entre casos de uso aincludes para adaptar la notacin a UMLSe han aadido plantillas especficas para objetivos y actoresSe han aadido nuevos campos y patronesL a todas las plantillas,introduciendo el concepto de patrn lingsticoSe han eliminado los subpasos de la plantilla para requisitos fun-cionales (casos de uso)Se ha reescrito la mayor parte del ejemplo de aplicacin de la me-todologa

7 18/10/1999 Versin 2.0 A. Durn8 18/10/2000 En la versin 2.1 se han introducido algunos cambios realizados

durante la elaboracin de la tesis doctoral de A. Durn [Durn2000].

A. Durn

9 18/10/1999 Versin 2.1 A. Durn

ndice General

1 Objetivo de la metodologa 1

2 Tareas recomendadas 12.1 Tarea 1: Obtener informacin sobre el dominio del proble-

ma y el sistema actual . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 32.1.3 Productos internos . . . . . . . . . . . . . . . . . . . . 32.1.4 Productos entregables . . . . . . . . . . . . . . . . . . 32.1.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 4

2.2 Tarea 2: Preparar y realizar las sesiones de elicitacin/ne-gociacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 Productos internos . . . . . . . . . . . . . . . . . . . . 52.2.4 Productos entregables . . . . . . . . . . . . . . . . . . 52.2.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 5

2.3 Tarea 3: Identificar/revisar los objetivos del sistema . . . . . 52.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3 Productos internos . . . . . . . . . . . . . . . . . . . . 62.3.4 Productos entregables . . . . . . . . . . . . . . . . . . 62.3.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 6

2.4 Tarea 4: Identificar/revisar los requisitos de almacenamien-to de informacin . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 62.4.3 Productos internos . . . . . . . . . . . . . . . . . . . . 72.4.4 Productos entregables . . . . . . . . . . . . . . . . . . 7

i

2.4.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 72.5 Tarea 5: Identificar/revisar los requisitos funcionales . . . . 7

2.5.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 72.5.3 Productos internos . . . . . . . . . . . . . . . . . . . . 82.5.4 Productos entregables . . . . . . . . . . . . . . . . . . 82.5.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 8

2.6 Tarea 6: Identificar/revisar los requisitos no funcionales . . . 82.6.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.2 Descripcin . . . . . . . . . . . . . . . . . . . . . . . . 82.6.3 Productos internos . . . . . . . . . . . . . . . . . . . . 92.6.4 Productos entregables . . . . . . . . . . . . . . . . . . 102.6.5 Tcnicas recomendadas . . . . . . . . . . . . . . . . . 10

3 Productos entregables 103.1 Documento de requisitos del sistema . . . . . . . . . . . . . . 10

3.1.1 Portada . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Lista de cambios . . . . . . . . . . . . . . . . . . . . . 123.1.3 ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.4 Listas de figuras y tablas . . . . . . . . . . . . . . . . . 133.1.5 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 133.1.6 Participantes en el proyecto . . . . . . . . . . . . . . . 133.1.7 Descripcin del sistema actual . . . . . . . . . . . . . 133.1.8 Objetivos del sistema . . . . . . . . . . . . . . . . . . . 143.1.9 Catlogo de requisitos del sistema . . . . . . . . . . . 143.1.10 Requisitos de almacenamiento de informacin . . . . 143.1.11 Requisitos funcionales . . . . . . . . . . . . . . . . . . 143.1.12 Diagrama de casos de uso . . . . . . . . . . . . . . . . 143.1.13 Definicin de los actores . . . . . . . . . . . . . . . . . 143.1.14 Casos de uso del sistema . . . . . . . . . . . . . . . . . 15

ii

3.1.15 Requisitos no funcionales . . . . . . . . . . . . . . . . 153.1.16 Matriz de rastreabilidad objetivos/requisitos . . . . . 153.1.17 Conflictos pendientes de resolucin . . . . . . . . . . 153.1.18 Glosario de trminos . . . . . . . . . . . . . . . . . . . 163.1.19 Apndices . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Tcnicas 164.1 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 Preparacin de entrevistas . . . . . . . . . . . . . . . . 174.1.2 Realizacin de entrevistas . . . . . . . . . . . . . . . . 184.1.3 Anlisis de las entrevistas . . . . . . . . . . . . . . . . 19

4.2 Joint Application Development . . . . . . . . . . . . . . . . . 204.2.1 Participantes del JAD . . . . . . . . . . . . . . . . . . 204.2.2 Fases del JAD . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.1 Fases del brainstorming . . . . . . . . . . . . . . . . . 24

4.4 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.1 Diagramas de casos de uso . . . . . . . . . . . . . . . 274.4.2 Relaciones entre casos de uso . . . . . . . . . . . . . . 274.4.3 Organizacin de casos de uso . . . . . . . . . . . . . . 28

5 Plantillas y patrones lingsticos para elicitacin de requisitos 295.1 Plantilla para los objetivos del sistema . . . . . . . . . . . . . 305.2 Plantilla para requisitos de almacenamiento de informacin 335.3 Plantilla para actores . . . . . . . . . . . . . . . . . . . . . . . 345.4 Plantilla para requisitos funcionales . . . . . . . . . . . . . . 355.5 Plantilla para requisitos no funcionales . . . . . . . . . . . . . 395.6 Plantilla para conflictos . . . . . . . . . . . . . . . . . . . . . . 39

A Ejemplo: gestin de un vdeoclub 45A.1 Objetivos del sistema . . . . . . . . . . . . . . . . . . . . . . . 45

iii

A.2 Requisitos de almacenamiento de informacin . . . . . . . . 46A.3 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 48

A.3.1 Diagramas de casos de uso . . . . . . . . . . . . . . . 48A.3.2 Definicin de actores . . . . . . . . . . . . . . . . . . . 51A.3.3 Casos de uso del sistema . . . . . . . . . . . . . . . . . 51

A.4 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 67

iv

ndice de Figuras

1 Tareas de elicitacin de requisitos . . . . . . . . . . . . . . . . 22 Estructura del Documento de Requisitos del Sistema . . . . . 113 Portada del Documento de Requisitos del Sistema . . . . . . 124 Lista de cambios del Documento de Requisitos del Sistema . 125 Matriz de rastreabilidad del Documento de Requisitos del

Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . 267 Representacin grfica de las relaciones includes y extends . . 288 Representacin grfica de los paquetes de casos de uso . . . 299 La plantilla como elemento de elicitacin y negociacin . . . 3010 Plantilla y patronesL para objetivos . . . . . . . . . . . . . . 3111 Plantilla y patronesL para requisitos de almacenamiento

de informacin . . . . . . . . . . . . . . . . . . . . . . . . . . 3312 Plantilla y patronesL para actores . . . . . . . . . . . . . . . 3513 Plantilla y patronesL para requisitos funcionales (casos de

uso) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3614 Ejemplo de caso de uso de conexin de usuario (plantilla) . . 3815 Ejemplo de caso de uso de conexin de usuario (Coleman) . 3816 Plantilla y patronesL para requisitos no funcionales . . . . . 4017 Plantilla para conflictos . . . . . . . . . . . . . . . . . . . . . . 4118 Diagrama de subsistemas . . . . . . . . . . . . . . . . . . . . 4819 Diagrama de casos de uso del subsistema Gestin de socios 4820 Diagrama de casos de uso del subsistema Gestin de pelculas 4921 Diagrama de casos de uso del subsistema Gestin de alqui-

leres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

v

Objetivo de la metodologa 1

1 Objetivo de la metodologa

El objetivo de esta metodologa es la definicin de las tareas a realizar,los productos a obtener y las tcnicas a emplear durante la actividad deelicitacin de requisitos de la fase de ingeniera de requisitos del desarrollo desoftware.

En esta metodologa se distinguen dos tipos de productos: los produc-tos entregables y los productos no entregables o internos. Los productos en-tregables son aquellos que se entregan oficialmente al cliente como partedel desarrollo en fechas previamente acordadas, mientras que los no entre-gables son productos internos al desarrollo que no se entregan al cliente.

El nico producto entregable definido en esta metodologa es el Docu-mento de Requisitos del Sistema (DRS), definido en la seccin 3.1, pg. 10.

La estructura de este documento es la siguiente: en la seccin 2 se des-criben las tareas recomendadas, en la seccin 3 se definen los productosentregables, en este caso el DRS, y por ltimo, en la seccin 4 se describenalgunas de las tcnicas recomendadas para obtener los productos. Tam-bin se incluye como apndice un ejemplo de aplicacin de esta metodo-loga.

2 Tareas recomendadas

Las tareas recomendadas para obtener los productos descritos en esta me-todologa son las siguientes:

Tarea 1: Obtener informacin sobre el dominio del problema y el sistemaactual.

Tarea 2: Preparar y realizar las reuniones de elicitacin/negociacin.

Tarea 3: Identificar/revisar los objetivos del sistema.

Tarea 4: Identificar/revisar los requisitos de almacenamiento de informa-cin.

Tarea 5: Identificar/revisar los requisitos funcionales.

Tarea 6: Identificar/revisar los requisitos no funcionales.

Tarea 7: Priorizar objetivos y requisitos.

A. Durn, B. Bernrdez Sevilla, Octubre 2000

2 Metodologa para la Elicitacin de Requisitos de Sistemas Software

El orden recomendado de realizacin para estas tareas es: 1. . . 7, aun-que las tareas 4, 5, y 6 pueden realizarse simultneamente o en cualquierorden que se considere oportuno (ver figura 1). La tarea 1 es opcional ydepende del conocimiento previo que tenga el equipo de desarrollo sobreel dominio del problema y el sistema actual.

Elicitacin de RequisitosElicitacin de Requisitos

Obtenerinformacin sobre

el dominio delproblema y elsistema actual

Obtenerinformacin sobre

el dominio delproblema y elsistema actual

Preparar yrealizar las

sesiones deelicitacin/

negociacin

Preparar yrealizar las

sesiones deelicitacin/

negociacin

Identificar/revisar losobjetivos

del sistema

Identificar/revisar losobjetivos

del sistema

Identificar/revisar losrequisitos

deinformacin


deinformacin


funcionales


funcionales


nofuncionales


nofuncionales

Priorizarobjetivos yrequisitos

Priorizarobjetivos yrequisitos

Figura 1: Tareas de elicitacin de requisitos

En las siguientes secciones se describen cada una de las tareas mencio-nadas.

Dpto. de Lenguajes y Sistemas Informticos Informe Tcnico LSI200010

Tarea 1: Obtener informacin sobre el dominio del problema y el sistema actual 3

2.1 Tarea 1: Obtener informacin sobre el dominio del pro-blema y el sistema actual

2.1.1 Objetivos

Conocer el dominio del problema. Conocer la situacin actual.

2.1.2 Descripcin

Antes de mantener las reuniones con los clientes y usuarios e identificarlos requisitos es fundamental conocer el dominio del problema y los con-textos organizacional y operacional, es decir, la situacin actual.

Enfrentarse a un desarrollo sin conocer las caractersticas principales niel vocabulario propio de su dominio suele provocar que el producto finalno sea el esperado por clientes ni usuarios.

Por otro lado, mantener reuniones con clientes y usuarios sin conocerlas caractersticas de su actividad har que probablemente no se entien-dan sus necesidades y que su confianza inicial hacia el desarrollo se veadeteriorada enormemente.

Esta tarea es opcional, ya que puede que no sea necesario realizarla siel equipo de desarrollo tiene experiencia en el dominio del problema y elsistema actual es conocido.

2.1.3 Productos internos

Informacin recopilada: libros, artculos, folletos comerciales, desa-rrollos previos sobre el mismo dominio, etc.

Modelos del sistema actual.

2.1.4 Productos entregables

Introduccin, participantes en el proyecto, principalmente clientes ydesarrolladores, y descripcin del sistema actual como parte del DRS(ver secciones 3.1.53.1.7, pgs. 1313).



2.1.5 Tcnicas recomendadas

Obtener informacin de fuentes externas al negocio del cliente: folle-tos, informes sobre el sector, publicaciones, consultas con expertos,etc.

En el caso de que se trate de un dominio muy especfico puede sernecesario recurrir a fuentes internas al propio negocio del cliente,en cuyo caso pueden utilizarse las tcnicas auxiliares de elicitacinde requisitos como el estudio de documentacin, observacin in si-tu, cuestionarios, inmersin o aprendizaje, etc. (ver secciones 4.14.3,pgs. 1623).

Modelado del sistema actual [Laguna et al. 1999, Garca et al. 2000].

2.2 Tarea 2: Preparar y realizar las sesiones de elicitacin/ne-gociacin

2.2.1 Objetivos

Identificar a los usuarios participantes.

Conocer las necesidades de clientes y usuarios.

Resolver posibles conflictos.

2.2.2 Descripcin

Teniendo en cuenta la informacin recopilada en la tarea anterior, en estatarea se deben preparar y realizar las reuniones con los clientes y usuariosparticipantes con objeto de obtener sus necesidades y resolver posiblesconflictos que se hayan detectado en iteraciones previas del proceso.

Esta tarea es especialmente crtica y ha de realizarse con especial cui-dado, ya que generalmente el equipo de desarrollo no conoce los detallesespecficos 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 saberel equipo de desarrollo para llevar a cabo su labor.


Tarea 3: Identificar/revisar los objetivos del sistema 5


Notas tomadas durante las reuniones, transcripciones o actas de reu-niones, formularios, grabaciones en cinta o vdeo de las reuniones ocualquier otra documentacin que se considere oportuna.


Participantes en el proyecto, en concreto los usuarios participantes,como parte del DRS (ver seccin 3.1.6, pg. 13).

Objetivos, requisitos o conflictos, que se hayan identificado clara-mente durante las sesiones de elicitacin, como parte del DRS (versecciones 3.1.83.1.9 y 3.1.17, pgs. 1414 y 15)


Tcnicas de elicitacin de requisitos (ver secciones 4.14.3, pgs. 1623), incluyendo las plantillas de objetivos, requisitos y conflictos des-critas en la seccin 5, pg. 29, que pueden usarse directamente du-rante las sesiones de elicitacin.

Tcnicas de negociacin como WinWin [Boehm et al. 1994].

2.3 Tarea 3: Identificar/revisar los objetivos del sistema

2.3.1 Objetivos

Identificar los objetivos que se esperan alcanzar mediante el sistemasoftware a desarrollar.

Revisar, en el caso de que haya conflictos, los objetivos previamenteidentificados.

2.3.2 Descripcin

A partir de la informacin obtenida en la tarea anterior, en esta tarea sedeben identificar qu objetivos se esperan alcanzar una vez que el sistemasoftware a desarrollar se encuentre en explotacin o revisarlos en funcin



de los conflictos identificados. Puede que los objetivos hayan sido propor-cionados antes de comenzar el desarrollo.


No hay productos internos en esta tarea.


Objetivos del sistema como parte del DRS (ver seccin 3.1.8, pg. 14).


Anlisis de factores crticos de xito [MAP 1995] o alguna tcnicasimilar de identificacin de objetivos.

Plantilla para especificar los objetivos del sistema (ver seccin 5.1,pg. 30).

2.4 Tarea 4: Identificar/revisar los requisitos de almacena-miento de informacin

2.4.1 Objetivos

Identificar los requisitos de almacenamiento de informacin que de-ber cumplir el sistema software a desarrollar.

Revisar, en el caso de que haya conflictos, los requisitos de almace-namiento de informacin previamente identificados.

2.4.2 Descripcin

A partir de la informacin obtenida en la tareas 1 y 2, y teniendo en cuentalos objetivos identificados en la tarea 3 y el resto de los requisitos, en estatarea se debe identificar, o revisar si existen conflictos, qu informacinrelevante para el cliente deber gestionar y almacenar el sistema softwarea desarrollar.

Inicialmente se partirn de conceptos generales para posteriormente irdetallndolos hasta obtener todos los datos relevantes.


Tarea 5: Identificar/revisar los requisitos funcionales 7




Requisitos de almacenamiento de informacin como parte del DRS(ver seccin 3.1.10, pg. 14).


Plantilla para requisitos de almacenamiento de informacin (ver sec-cin 5.2, pg. 33).

2.5 Tarea 5: Identificar/revisar los requisitos funcionales

2.5.1 Objetivos

Identificar los actores del sistema del sistema software a desarrollar. Identificar los requisitos funcionales (casos de uso) que deber cum-

plir el sistema software a desarrollar.

Revisar, en el caso de que haya conflictos, los requisitos funcionalespreviamente identificados.

2.5.2 Descripcin

A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuentalos objetivos identificados en la tarea 3 y el resto de los requisitos, en estatarea se debe identificar, o revisar si existen conflictos, qu debe hacer elsistema a desarrollar con la informacin identificada en la tarea anterior.

Inicialmente se identificarn los actores que interactuarn con el siste-ma, es decir aquellas personas u otros sistemas que sern los orgenes odestinos de la informacin que consumir o producir el sistema a desa-rrollar y que forman su entorno.

A continuacin se identificarn 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 definir todas las situaciones posi-bles.




Requisitos funcionales como parte del DRS (ver seccin 3.1.11, pg.14).


Casos de uso (ver seccin 4.4, pg. 25). Plantilla para actores (ver seccin 5.3, pg. 34). Plantilla para los requisitos funcionales (ver seccin 5.4, pg. 35).

2.6 Tarea 6: Identificar/revisar los requisitos no funciona-les

2.6.1 Objetivos

Identificar los requisitos no funcionales del sistema software a desa-rrollar.

2.6.2 Descripcin

A partir de la informacin obtenida en las tareas 1 y 2, y teniendo en cuentalos objetivos identificados en la tarea 3 y el resto de los requisitos, en estatarea se deben identificar, o revisar si existen conflictos, los requisitos nofuncionales, normalmente de carcter tcnico o legal.

Algunos tipos de requisitos que se suelen incluir en esta seccin son lossiguientes:


Tarea 6: Identificar/revisar los requisitos no funcionales 9

Requisitos de comunicaciones del sistemaSon requisitos de carcter tcnico relativos a las comunicaciones quedeber soportar el sistema software a desarrollar. Por ejemplo: elsistema deber utilizar el protocolo TCP/IP para las comunicaciones conotros sistemas.

Requisitos de interfaz de usuarioEste tipo de requisitos especifica las caractersticas que deber tenerel sistema en su comunicacin con el usuario. Por ejemplo: la interfazde usuario del sistema deber ser consistente con los estndares definidos enIBMs Common User Access.

Se debe ser cuidadoso con este tipo de requisitos, ya que en esta fasede desarrollo todava no se conocen bien las dificultades que puedensurgir a la hora de disear e implementar las interfaces, por esto noes conveniente entrar en detalles demasiado especficos.

Requisitos de fiabilidadLos requisitos de fiabilidad deben establecer los factores que se re-quieren para la fiabilidad del software en tiempo de explotacin. Lafiabilidad mide la probabilidad del sistema de producir una respues-ta satisfactoria a las demandas del usuario. Por ejemplo: la tasa defallos del sistema no podr ser superior a 2 fallos por semana.

Requisitos de entorno de desarrolloEste tipo de requisitos especifican si el sistema debe desarrollarse conun producto especfico. Por ejemplo: el sistema deber desarrollarse conOracle 7 como servidor y clientes Visual Basic 4.

Requisitos de portabilidadLos requisitos de portabilidad definen qu caractersticas deber te-ner el software para que sea fcil utilizarlo en otra mquina o bajootro sistema operativo. Por ejemplo: el sistema deber funcionar en lossistemas operativos Windows 95, Windows 98 y Windows NT 4.0, siendoadems posible el acceso al sistema a travs de Internet usando cualquiernavegador compatible con HTML 3.0.






Requisitos no funcionales del sistema como parte del DRS (ver sec-cin 3.1.15, pg. 15).


Plantilla para requisitos no funcionales (ver seccin 5.5, pg. 39).

3 Productos entregables

El nico producto entregable que se contempla en esta metodologa es elDocumento de Requisitos del Sistema (DRS).

3.1 Documento de requisitos del sistema

La estructura del DRS puede verse en la figura 2. En las siguientes seccio-nes se describe con detalle cada seccin del DRS.

3.1.1 Portada

La portada del DRS debe tener el formato que puede verse en la figura 3.Los elementos que deben aparecer son los siguientes:

Nombre del proyecto: el nombre del proyecto al que pertenece elDRS.

Versin: la versin del DRS que se entrega al cliente. La versin secompone de dos nmeros X e Y . El primero indica la versin, y sedebe incrementar cada vez que se hace una nueva entrega formalal cliente. Cuando se incremente el primer nmero, el segundo de-be volver a comenzar en cero. El segundo nmero indica cambiosdentro de la misma versin an no entregada, y se debe incrementarcada vez que se publica una versin con cambios respecto a la lti-ma que se public y que no se vaya a entregar formalmente todava.Este tipo de versiones pueden ser internas al equipo de desarrollo oser entregadas al cliente a ttulo orientativo.


Documento de requisitos del sistema 11

PortadaLista de cambiosndiceLista de figurasLista de tablas

1 Introduccin

2 Participantes en el proyecto

3 Descripcin del sistema actual [opcional]

4 Objetivos del sistema

5 Catlogo de requisitos del sistema

5.1 Requisitos de almacenamiento de informacin5.2 Requisitos funcionales

5.2.1 Diagramas de casos de uso5.2.2 Definicin de actores5.2.3 Casos de uso del sistema

5.3 Requisitos no funcionales

6 Matriz de rastreabilidad objetivos/requisitos

7 Conflictos pendientes de resolucin [opcional, pueden iren un documento aparte]

8 Glosario de trminos [opcional]

Apndices [opcionales]

Figura 2: Estructura del Documento de Requisitos del Sistema



Proyecto nombre del proyecto

Documento deRequisitos del Sistema

Versin X.YFecha fecha

Realizado por equipo de desarrolloRealizado para cliente

Figura 3: Portada del Documento de Requisitos del Sistema

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 especifiquen,para cada versin del documento, los cambios producidos en el mismocon un formato similar al que puede verse en la figura 4. Para cada cambiorealizado se debe incluir el nmero de orden, la fecha, una descripcin ylos autores.

Nm. Fecha Descripcin Autores0 fecha0 Versin x.y autor01 fecha1 descripcin cambio1 autor1

......

......

n fechan descripcin cambion autorn

Figura 4: Lista de cambios del Documento de Requisitos del Sistema



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 san-grarn las entradas del ndice para ayudar a comprender la estructura deldocumento.

3.1.4 Listas de figuras y tablas

El DRS deber incluir listas de las figuras y tablas que aparezcan en el mis-mo. Dichas listas sern dos ndices que indicarn el nmero, la descripciny la pgina en que aparece cada figura o tabla del DRS.

3.1.5 Introduccin

Esta seccin debe contener una descripcin breve de las principales ca-ractersticas del sistema software que se va a desarrollar, la situacin ac-tual que genera la necesidad del nuevo desarrollo, la problemtica que seacomete, y cualquier otra consideracin que site al posible lector en elcontexto 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 pro-yecto, tanto desarrolladores como clientes y usuarios. Para cada partici-pante se deber indicar su nombre, el papel que desempea en el proyecto,la organizacin a la que pertenece y cualquier otra informacin adicionalque se considere oportuna.

3.1.7 Descripcin del sistema actual

Esta seccin debe contener una descripcin del sistema actual en el casode que se haya acometido su estudio. Para describir el sistema actual pue-de utilizarse cualquier tcnica que se considere oportuno, por ejemplo lasdescritas en [Laguna et al. 1999] (Diagrama DocumentosTarea, DDT) o en[Garca et al. 2000] (Diagramas de Actividad, tambin descritos en [Booch etal. 1999]).



3.1.8 Objetivos del sistema

Esta seccin debe contener una lista con los objetivos que se esperan alcan-zar cuando el sistema software a desarrollar est en explotacin, especifi-cados mediante la plantilla para objetivos descrita en la seccin 5.1, pg.30.

3.1.9 Catlogo de requisitos del sistema

Esta seccin se divide en las siguientes subsecciones en las que se descri-ben los requisitos del sistema. Cada uno de los grandes grupos de requi-sitos, de almacenamiento de informacin, funcionales y no funcionales,podrn dividirse para ayudar a la legibilidad del documento, por ejem-plo dividiendo cada subseccin en requisitos asociados a un determinadoobjetivo, requisitos con caractersticas comunes, etc.

3.1.10 Requisitos de almacenamiento de informacin

Esta subseccin debe contener la lista de requisitos de almacenamiento deinformacin que se hayan identificado, utilizando para especificarlos laplantilla para requisitos de almacenamiento de informacin descrita en laseccin 5.2, pg. 33.

3.1.11 Requisitos funcionales

Esta subseccin debe contener la lista de requisitos funcionales que se ha-yan identificado, dividindose en los siguientes apartados que se descri-ben a continuacin.

3.1.12 Diagrama de casos de uso

Este apartado debe contener los diagramas de casos de uso del sistemaque se hayan realizado.

3.1.13 Definicin de los actores

Este apartado debe contener una lista con los actores que se hayan iden-tificado, especificados mediante la plantilla para actores de casos de usodescrita en la seccin 5.3, pg. 34.



3.1.14 Casos de uso del sistema

Este apartado debe contener los casos de uso que se hayan identificado,especificados mediante la plantilla para requisitos funcionales descrita enla seccin 5.4, pg. 35.

3.1.15 Requisitos no funcionales

Esta subseccin debe contener la lista los requisitos no funcionales del sis-tema que se hayan identificado, especificados mediante la plantilla pararequisitos no funcionales descrita en la seccin 5.5, pg. 39.

3.1.16 Matriz de rastreabilidad objetivos/requisitos

Esta seccin debe contener una matriz objetivorequisito, de forma que paracada objetivo se pueda conocer con qu requisitos est asociado. El forma-to de la matriz de rastreabilidad puede verse en la figura 5.

OBJ01 OBJ02 . . . OBJ-nRI01 RI02 . . .RF01 RF02 . . .RNF01 RNF02 . . .

Figura 5: Matriz de rastreabilidad del Documento de Requisitos del Siste-ma

3.1.17 Conflictos pendientes de resolucin

Esta seccin, que se incluir en el caso de que no se opte por registrar losconflictos en un documento aparte, deber contener los conflictos identi-ficados durante el proceso y que an estn pendientes de resolucin, des-critos mediante la plantilla para conflictos.



3.1.18 Glosario de trminos

Esta seccin, que se incluir si se considera oportuno, deber contener unalista ordenada alfabticamente de los trminos especficos del dominio delproblema, acrnimos y abreviaturas que aparezcan en el documento y quese considere que su significado deba ser aclarado. Cada trmino deberacompaarse de su significado.

3.1.19 Apndices

Los apndices se usarn para proporcionar informacin adicional a la do-cumentacin obligatoria del documento. Slo deben aparecer si se consi-deran oportunos y se identificarn con letras ordenadas alfabticamente:A, B, C, etc.

4 Tcnicas

A continuacin, se describen algunas de las tcnicas que se proponen enesta metodologa para obtener los productos de las tareas que se han des-crito.

Las tcnicas ms habituales en la elicitacin de requisitos son las en-trevistas, el Joint Application Development (JAD) o Desarrollo Conjunto deAplicaciones, el brainstorming o tormenta de ideas y la utilizacin de esce-narios [Weidenhaput et al. 1998, Rolland et al. 1998], ms conocidos comocasos de uso [Jacobson et al. 1993, Booch et al. 1999].

A estas tcnicas, que se describen en los siguientes apartados, se lassuele apoyar con otras tcnicas complementarias como la observacin insitu, el estudio de documentacin, los cuestionarios, la inmersin en el ne-gocio del cliente [Goguen y Linde 1993] o haciendo que los ingenieros derequisitos sean aprendices del cliente [Beyer y Holtzblatt 1995].

4.1 Entrevistas

Las entrevistas son la tcnica de elicitacin ms utilizada, y de hecho sonprcticamente inevitables en cualquier desarrollo ya que son una de lasformas de comunicacin ms naturales entre personas.


Entrevistas 17

En las entrevistas se pueden identificar tres fases: preparacin, realiza-cin y anlisis [Piattini et al. 1996].

4.1.1 Preparacin de entrevistas

Las entrevistas no deben improvisarse, por lo que conviene realizar lassiguiente tareas previas:

Estudiar el dominio del problema: conocer las categoras y con-ceptos de la comunidad de clientes y usuarios es fundamental parapoder entender las necesidades de dicha comunidad y su forma deexpresarlas [Goguen y Linde 1993], y para generar en los clientes yusuarios la confianza de que el ingeniero de requisitos entiende susproblemas.Para conocer el dominio del problema se puede recurrir a tcnicas deestudio de documentacin, a bibliografa sobre el tema, documen-tacin de proyectos similares realizados anteriormente, la inmersindentro de la organizacin para la que se va a desarrollar [Goguen yLinde 1993] o a periodos de aprendizaje por partes de los ingenierosde requisitos [Beyer y Holtzblatt 1995].

Seleccionar a las personas a las que se va a entrevistar: se debeminimizar el nmero de entrevistas a realizar, por lo que es funda-mental seleccionar a las personas a entrevistar. Normalmente se co-mienza por los directivos, que pueden ofrecer una visin global, y secontina con los futuros usuarios, que pueden aportar informacinms detallada, y con el personal tcnico, que aporta detalles sobre elentorno operacional de la organizacin.Tal como se recomienda en [Piattini et al. 1996], conviene tambinestudiar el perfil de los entrevistados, buscando puntos en comncon el entrevistador que ayuden a romper el hielo.

Determinar el objetivo y contenido de las entrevistas: para mini-mizar el tiempo de la entrevista es fundamental fijar el objetivo quese pretende alcanzar y determinar previamente su contenido.Previamente a su realizacin, se pueden enviar cuestionarios que losfuturos entrevistados deben rellenar y devolver, y un pequeo do-cumento de introduccin al proyecto de desarrollo, de forma que elentrevistado conozca los temas que se van a tratar y el entrevistadorrecoja informacin para preparar la entrevista.



Es importante que los cuestionarios, si se usan, se preparen cuida-dosamente teniendo en cuenta quin los va a responder y no incluirconceptos que se asuman conocidos cuando puedan no serlo.

Planificar las entrevistas: la fecha, hora, lugar y duracin de las en-trevista deben fijarse teniendo en cuenta siempre la agenda del en-trevistado.En general, se deben buscar sitios agradables donde no se produzcaninterrupciones y que resulten naturales a los entrevistados, tal comose describe en [Goguen y Linde 1993].

4.1.2 Realizacin de entrevistas

Dentro de la realizacin de las entrevistas se distinguen tres etapas, talcomo se expone en [Piattini et al. 1996]:

1 Apertura: el entrevistador debe presentarse e informar al entrevista-do sobre la razn de la entrevista, qu se espera conseguir, cmo seutilizar la informacin, la mecnica de las preguntas, etc.Si se va a utilizar algn tipo de notacin grfica o matemtica queel entrevistado no conozca debe explicarse antes de utilizarse. Esfundamental 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 delentrevistador, contemplando la posibilidad de que una tercera per-sona tome notas durante la entrevista o grabar la entrevista en cintade vdeo o audio, siempre que el entrevistado est de acuerdo [Ro-bertson y Robertson 1999].Durante esta fase se pueden emplear distintas tcnicas:

Preguntas abiertas: tambin denominadas de libre contexto [Gau-se y Weinberg 1989], estas preguntas no pueden respondersecon un "s" o un "no", permiten una mayor comunicacin y evi-tan la sensacin de interrogatorio. Por ejemplo, "Qu se hacepara registrar un pedido?", "Dgame qu se debe hacer cuando uncliente pide una factura" o "Cmo se rellena un albarn?".


Entrevistas 19

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 respues-ta a las preguntas que se formulan [Raghavan et al. 1994]. En[Gause y Weinberg 1989, cap. 6] se exponen interesantes ejem-plos de este tipo de preguntas y consejos para su utilizacin.Una posibilidad es utilizar las plantillas descritas en la seccin 5,pg. 29, como mecanismos tanto de obtencin de informacin,ya que su estructura indica la informacin a buscar, como deregistro de las respuestas a este tipo de preguntas.

Utilizar palabras apropiadas: se deben evitar tecnicismos queno conozca el entrevistado y palabras o frases que puedan per-turbar emocionalmente la comunicacin [Goleman 1996, Gole-man 1999].

Mostrar inters en todo momento: es fundamental cuidar lacomunicacin no verbal [Davis 1985] durante la entrevista: tonode voz, movimiento, expresin facial, etc.Por ejemplo, para animar a alguien a hablar puede asentirse conla cabeza, decir "ya entiendo", "s", repetir algunas respuestas da-das, hacer pausas, poner una postura de atencin, etc. Debeevitarse bostezar, reclinarse en el silln, mirar hacia otro lado,etc.

3 Terminacin: al terminar la entrevista se debe recapitular para con-firmar que no ha habido confusiones en la informacin recogida,agradecer al entrevistado su colaboracin y citarle para una nuevaentrevista si fuera necesario, dejando siempre abierta la posibilidadde volver a contactar para aclarar dudas que surjan al estudiar lainformacin o al contrastarla con otros entrevistados.

4.1.3 Anlisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas, pasar-las a limpio, reorganizar la informacin, contrastarla con otras entrevistaso fuentes de informacin, etc.

Una vez elaborada la informacin, se puede enviar al entrevistado paraconfirmar los contenidos. Tambin es importante evaluar la propia entre-vista para determinar los aspectos mejorables.



4.2 Joint Application Development

La tcnica denominada JAD (Joint Application Development, Desarrollo Con-junto de Aplicaciones), desarrollada por IBM en 1977, es una alternativa alas entrevistas individuales que se desarrolla a lo largo de un conjunto dereuniones en grupo durante un periodo de 2 a 4 das. En estas reuniones seayuda a los clientes y usuarios a formular problemas y explorar posiblessoluciones, involucrndolos y hacindolos sentirse partcipes del desarro-llo.

Esta tcnica se base en cuatro principios [Raghavan et al. 1994]: din-mica de grupo, el uso de ayudas visuales para mejorar la comunicacin(diagramas, transparencias, multimedia, herramientas CASE, etc.), man-tener un proceso organizado y racional y una filosofa de documentacinWYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), porla que durante las reuniones se trabaja directamente sobre los documentosa generar.

El JAD tiene dos grandes pasos, el JAD/Plan cuyo objetivo es elicitar yespecificar requisitos, y el JAD/Design, en el que se aborda el diseo delsoftware. En este documento slo se ver con detalle el primero de ellos.

Debido a las necesidades de organizacin que requiere y a que no sueleadaptarse bien a los horarios de trabajo de los clientes y usuarios, estatcnica no suele emplearse con frecuencia, aunque cuando se aplica sueletener buenos resultados, especialmente para elicitar requisitos en el campode los sistemas de informacin [Raghavan et al. 1994].

En comparacin con las entrevistas individuales, presenta las siguien-tes ventajas:

Ahorra tiempo al evitar que las opiniones de los clientes se contras-ten por separado.

Todo el grupo, incluyendo los clientes y los futuros usuarios, revisala 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 seisclases de participantes o roles en el JAD:


Joint Application Development 21

Jefe del JAD: es el responsable de todo el proceso y asume el controldurante las reuniones. Debe tener dotes de comunicacin y lideraz-go. Algunas habilidades importantes que debe tener son: entender ypromover la dinmica de grupo, iniciar y centrar discusiones, reco-nocer cundo la reunin se est desviando del tema y reconducirla,manejar las distintas personalidades y formas de ser de los partici-pantes, evitar que decaiga la reunin aunque sea larga y difcil, etc.

Analista: es el responsable de la produccin de los documentos quese deben generar durante las sesiones JAD. Debe tener la habilidadde organizar bien las ideas y expresarlas claramente por escrito. Enel caso de que se utilizan herramientas software durante las sesiones,debe ser capaz de manejarlas eficientemente.

Patrocinador ejecutivo: es el que tiene la decisin final de que se lle-ve a cabo el desarrollo. Debe proporcionar a los dems participantesinformacin sobre la necesidad del nuevo sistema y los beneficiosque se espera obtener de l.

Representantes de los usuarios: durante el JAD/Plan, suelen ser di-rectivos con una visin global del sistema. Durante el JAD/Designsuelen incorporarse futuros usuarios finales.

Representantes de sistemas de informacin: son personas expertosen sistemas de informacin que deben ayudar a los usuarios a com-prender qu es o no factible con la tecnologa actual y el esfuerzo queimplica.

Especialistas: son personas que pueden proporcionar informacindetallada sobre aspectos muy concretos, tanto del punto de vista delos usuarios porque conocen muy bien el funcionamiento de una par-te de la organizacin, como desde el punto de vista de los desarro-lladores porque conocen perfectamente ciertos aspectos tcnicos dela 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 unoo dos analistas, adaptar la tcnica del JAD para cada proyecto. Laadaptacin debe comenzar por definir el proyecto a alto nivel, para



lo cual pueden ser necesarias entrevistas previas con algunos clientesy usuarios. Tambin suele ser necesario recabar informacin sobre laorganizacin para familiarizarse con el dominio del problema, porejemplo utilizando tcnicas complementarias como el estudio de do-cumentacin o la observacin in situ.Una vez obtenida una primera idea de los objetivos del proyecto, esnecesario seleccionar a los participantes, citarles para las reunionesy proporcionarles una lista con los temas que se van a tratar en lasreuniones para que las puedan preparar.El jefe del JAD debe decidir la duracin y el nmero de sesiones acelebrar, definir el formato de la documentacin sobre la que se tra-bajar y preparar transparencias introductorias y todo el material au-diovisual que considere oportuno.

2 Celebracin de las sesiones JAD: durante las sesiones, los partici-pantes exponen sus ideas y se discuten, analizan y refinan hasta al-canzar un acuerdo. Los pasos que se recomienda seguir para esteproceso son los siguientes:

2.1 Presentacin: se presenta y se da la bienvenida a todos los parti-cipantes por parte del patrocinador ejecutivo y del jefe del JAD.El patrocinador ejecutivo expone brevemente las necesidadesque han llevado al desarrollo y los beneficios que se esperanobtener. El jefe del JAD explica la mecnica de las sesiones y laplanificacin prevista.

2.2 Definir objetivos y requisitos: el jefe del JAD promueve la dis-cusin para elicitar los objetivos o requisitos de alto nivel me-diante preguntas como: "Por qu se construye el sistema?", "Qubeneficios se esperan del nuevo sistema?", "Cmo puede beneficiar ala organizacin en el futuro?", "Qu restricciones de recursos dispo-nibles, normas o leyes afectan al proyecto?", "Es importante la segu-ridad de los datos?", . . .A medida que se van elicitando requisitos, el analista los escri-be en transparencias o en algn otro medio que permita quepermanezcan visibles durante la discusin. Una posibilidad esutilizar para ello las plantillas descritas en la seccin 5, pg. 29.

2.3 Delimitar el mbito del sistema: una vez obtenido un nmeroimportante de requisitos, es necesario organizarlos y llegar a unacuerdo sobr el mbito del nuevo sistema.


Brainstorming 23

En el caso de los sistemas de informacin, es til identificar a losusuarios potenciales (actores) y determinar qu tareas les ayuda-r a realizar (casos de uso).

2.4 Documentar temas abiertos: aquellas cuestiones que hayan sur-gido durante la sesin que no se han podido resolver, deben do-cumentarse para las siguientes sesiones y ser asignadas a unapersona responsable de su solucin para una fecha determina-da, para lo cual puede utilizarse la plantilla de conflictos descri-ta en la seccin 5.6, pg. 39.

2.5 Concluir la sesin: el jefe del JAD concluye la sesin revisandocon los dems participantes la informacin elicitada y las deci-siones tomadas. Se da la oportunidad a todos los participantesde expresar cualquier consideracin adicional, fomentando porparte del jefe del JAD el sentimiento de propiedad y compromi-so de todos los participantes sobre los requisitos elicitados.

3 Conclusin: una vez terminadas las sesiones es necesario transfor-mar las transparencias, notas y dems documentacin generada endocumentos formales. Se distinguen tres pasos:

3.1 Completar la documentacin: los analistas recopilan la docu-mentacin generada durante las sesiones en documentos con-formes a las normas o estndares vigentes en la organizacinpara la que se desarrolla el proyecto.

3.2 Revisar la documentacin: la documentacin generada se en-va a todos los participantes para que la comenten. Si los co-mentarios son lo suficientemente importantes, se convoca otrareunin para discutirlos.

3.3 Validar la documentacin: una vez revisados todos los comen-tarios, el jefe del JAD enva el documento al patrocinador eje-cutivo para su aprobacin. Una vez aprobado el documento seenvan copias definitivas a cada uno de los participantes.

4.3 Brainstorming

El brainstorming o tormenta de ideas es una tcnica de reuniones en grupocuyo objetivo es la generacin de ideas en un ambiente libre de crticaso juicios [Gause y Weinberg 1989, Raghavan et al. 1994]. Las sesionesde brainstorming suelen estar formadas por un nmero de cuatro a diez



participantes, uno de los cuales es el jefe de la sesin, encargado ms decomenzar la sesin que de controlarla.

Como tcnica de elicitacin de requisitos, el brainstorming puede ayu-dar a generar una gran variedad de vistas del problema y a formularlode 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 fcilde aprender y requiere poca organizacin, de hecho, hay propuestas derealizacin 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 queotras 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 re-quiere que se seleccione a los participantes y al jefe de la sesin, ci-tarlos y preparar la sala donde se llevar a cabo la sesin. Los partici-pantes en una sesin de brainstorming para elicitacin de requisitosson normalmente clientes, usuarios, ingenieros de requisitos, desa-rrolladores y, si es necesario, algn experto en temas relevantes parael proyecto.

2 Generacin: el jefe abre la sesin exponiendo un enunciado generaldel problema a tratar, que hace de semilla para que se vayan generan-do ideas. Los participantes aportan libremente nuevas ideas sobre elproblema semilla, bien por un orden establecido por el jefe de la se-sin, bien aleatoriamente. El jefe es siempre el responsable de darla palabra a un participante. Este proceso contina hasta que el jefedecide parar, bien porque no se estn generando suficientes ideas, encuyo caso la reunin se pospone, bien porque el nmero de ideas seasuficiente para pasar a la siguiente fase. Durante esta fase se debenobservar las siguientes reglas:

Se prohbe la crtica de ideas, de forma que los participantes sesientan libres de formular cualquier idea.


Casos de uso 25

Se fomentan las ideas ms avanzadas, que aunque no sean fac-tibles, estimulan a los dems participantes a explorar nuevassoluciones ms creativas.

Se debe generar un gran nmero de ideas, ya que cuantas msideas se presenten ms probable ser que se generen mejoresideas.

Se debe alentar a los participantes a combinar o completar lasideas de otros participantes. Para ello, es necesario, al igual queen la tcnica del JAD, que todas las ideas generadas estn visi-bles para todos los participantes en todo momento.

Una posibilidad es utilizar como semilla objetivos del sistema e iridentificando requisitos. Si estos requisitos se recogen en las plan-tillas propuestas en la seccin 5, pg. 29, pueden utilizarse dichasplantillas para que los participantes tengan visibles las ideas que sevan generando.

3 Consolidacin: en esta fase se deben organizar y evaluar las ideasgeneradas durante la fase anterior. Se suelen seguir tres pasos:

3.1 Revisar ideas: se revisan las ideas generadas para clarificarlas.Es habitual identificar ideas similares, en cuyo caso se unificanen un solo enunciado.

3.2 Descartar ideas: aquellas ideas que los participantes considerenexcesivamente avanzadas se descartan.

3.3 Priorizar ideas: se priorizan las ideas restantes, identificandolas absolutamente esenciales, las que estaran bien pero que noson esenciales y las que podran ser apropiadas para una prxi-ma versin del sistema a desarrollar.

4 Documentacin: despus de la sesin, el jefe produce la documen-tacin oportuna conteniendo las ideas priorizadas y comentarios ge-nerados durante la consolidacin.

4.4 Casos de uso

Los casos de uso son una tcnica para la especificacin de requisitos fun-cionales propuesta inicialmente en [Jacobson et al. 1993] y que actualmenteforma parte de la propuesta de UML [Booch et al. 1999].



Un caso de uso es la descripcin de una secuencia de interacciones en-tre el sistema y uno o ms actores en la que se considera al sistema comouna caja negra y en la que la que los actores obtienen resultados observa-bles.

Los actores son personas u otros sistemas que interactan con el siste-ma cuyos requisitos se estn describiendo [Scheneider y Winters 1998].

Los casos de uso presentan ciertas ventajas sobre la descripcin me-ramente textual de los requisitos funcionales [Firesmith 1997], ya que fa-cilitan la elicitacin de requisitos y son fcilmente comprensibles por losclientes y usuarios. Adems, pueden servir de base a las pruebas del sis-tema y a la documentacin para los usuarios [Weidenhaput et al. 1998].

A pesar de ser una tcnica ampliamente aceptada, existen mltiplespropuestas para su utilizacin concreta [Cockburn 1997]. En esta metodo-loga se propone la utilizacin de los casos de uso como tcnica tanto deelicitacin como de especificacin de los requisitos funcionales del siste-ma. Para la descripcin concreta de los casos de uso se proponen plan-tillas, en las que las interacciones se numeran siguiendo las propuestasde [Cockburn 1997], [Scheneider y Winters 1998] y [Coleman 1998] y sedescriben usando lenguaje natural en forma de patrones lingsticos (verseccin 5.4, pg. 35).

Sistema

Caso de uso A

Caso de uso B

Caso de uso C

Actor 1Actor 2

Figura 6: Diagrama de casos de uso


Casos de uso 27

4.4.1 Diagramas de casos de uso

Los casos de uso tienen una representacin grfica en los denominadosdiagramas de casos de uso [Booch et al. 1999]. En estos diagramas, los actoresse representan en forma de pequeos monigotes y los casos de uso se re-presentan por elipses contenidas dentro de un rectngulo que representaal sistema. La participacin de los actores en los casos de uso se indicapor una flecha entre el actor y el caso de uso que apunta en la direccin enla que fluye la informacin. Un ejemplo de este tipo de diagramas puedeverse en la figura 6.

Los diagramas de casos de uso sirven para proporcionar una visinglobal del conjunto de casos de uso de un sistema as como de los actoresy los casos de uso en los que stos intervienen. Las interacciones concretasentre 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 parasimplificar su descripcin. Las dos relaciones posibles y sus semnticassegn [Booch et al. 1999] son las siguientes, cuya representacin grficapuede verse en el ejemplo de la figura 7.

includes: se dice que un caso de uso A incluye el caso de uso B, cuan-do B es una parte del caso de uso A, es decir, la secuencia de interac-ciones de B forma parte de la secuencia de interacciones de A.

El caso de uso B se realiza siempre dentro del caso de uso A. Ade-ms, siempre que ocurre A ocurre tambin B, por lo que se dice queB 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 mis-mo, por lo que slo tiene significado cuando se utiliza para describiralguna funcionalidad que es comn a otros casos de uso. Por otraparte, un caso de uso ser concreto si puede ser iniciado por un actory realizado por s mismo.

Se suele utilizar esta relacin cuando se detectan subsecuencias deinteracciones comunes a varios casos de uso. Dichas subsecuenciascomunes se sacan "factor comn"de los casos de uso que las contie-nen y se les da forma de casos de uso que son incluidos por los casosde uso de los que se han "extrado". De esta forma se evita repetir



A B C

X Y

Figura 7: Representacin grfica de las relaciones includes y extends

las mismas subsecuencias de interacciones una y otra vez en varioscasos de uso.

extends: un caso de uso A extiende a otro caso de uso B cuando A esuna subsecuencia de interacciones de B que ocurre en una determi-nada circunstancia.En cierta forma, A completa la funcionalidad de B. El caso de usoA puede realizarse o no cuando se realiza el caso de uso B, segnse den las circunstancias. Por otro lado, el caso de uso A puede serun caso de uso abstracto o concreto, en cuyo caso puede ocurrir sinnecesidad de que ocurra el caso de uso B.

4.4.3 Organizacin de casos de uso

En la mayora de sistemas, el nmero de casos de uso es lo suficientemen-te elevado como para que sea oportuno organizarlos de alguna forma enlugar 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 paque-tes descritos en la propuesta de UML [Booch et al. 1999]. De esta forma,los casos de uso pueden organizarse en niveles, facilitando as su com-prensin. 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 funciona-les, los paquetes que los agrupan pueden estereotiparse como subsistemas[Scheneider y Winters 1998], tal como puede verse en el ejemplo de la fi-gura 8.


Plantillas y patrones lingsticos para elicitacin de requisitos 29

Sistema

Actor 2Actor 1

A

B

C

Figura 8: Representacin grfica de los paquetes de casos de uso

5 Plantillas y patrones lingsticos para elicita-cin de requisitos

Las plantillas y patrones lingsticos que se presentan en los siguientesapartados estn pensados para utilizarse tanto durante las reuniones deelicitacin con clientes y usuarios como para registrar y gestionar los re-quisitos.

Su objetivo es doble: por un lado intentar paliar la falta de propuestasconcretas sobre la expresin de requisitos. Por otro lado, tambin puedenusarse como elementos de elicitacin y negociacin durante las reunionescon clientes y usuarios de forma similar a las conocidas tarjetas CRC (Clase,Responsabilidad, Colaboracin) [Wirfs-Brock et al. 1990] (ver figura 9).

De esta forma se consigue que durante las sesiones de elicitacin setrabaje con una filosofa WYSIWYG, tal como se propone en las tcnicasde JAD o brainstorming, ya que los participantes manejan directamente ladocumentacin final, favorecindose as su implicacin en el proceso.

Como fruto de la experiencia de su utilizacin, para algunos camposde las plantillas se han identificado frases "estndar"que son habituales enlas especificaciones de requisitos y que se han parametrizado. Estas fra-ses, a las que hemos denominado patrones lingsticos, o abreviadamentepatronesL, pueden usarse para rellenar los campos de las plantillas dn-dole valores a los parmetros con la informacin oportuna.



Figura 9: La plantilla como elemento de elicitacin y negociacin

Ambos aspectos, la estructuracin de la informacin en forma de plan-tilla y la propuesta de frases "estndar", facilita la redaccin de los requi-sitos, permitiendo a los participantes en las actividades de elicitacin cen-trarse en expresar sus necesidades y no en cmo expresarlas.

En la notacin usada para describir los patronesL, las palabras o fra-ses entre < y > deben ser convenientemente reemplazadas, mientras quelas palabras o frases que se encuentren entre { y } y separadas por comasrepresentan opciones de las que se debe escoger una.

En las siguientes secciones se describen las plantillas propuestas y lospatronesL identificados.

5.1 Plantilla para los objetivos del sistema

Los objetivos del sistema pueden considerarse como requisitos de alto nivel[Sawyer y Kontoya 1999], de forma que los requisitos propiamente dichosseran la forma de alcanzar los objetivos. La plantilla propuesta para losobjetivos puede verse en la figura 10.


Plantilla para los objetivos del sistema 31

OBJ Versin ()Autores ()

. . .Fuentes ()

. . .Descripcin El sistema deber Subobjetivos OBJx

. . .Importancia Urgencia Estado Estabilidad Comentarios

Figura 10: Plantilla y patronesL para objetivos

El significado de los campos que la componen, cuya mayora est pre-sente tambin en las plantillas para los requisitos, es el siguiente:

Identificador y nombre descriptivo: siguiendo la propuesta, entreotros, de [Sawyer et al. 1997], cada objetivo debe identificarse por uncdigo nico y un nombre descriptivo. Con objeto de conseguir unarpida identificacin, los identificadores de los objetivos comienzancon OBJ.

Versin: para poder gestionar distintas versiones, este campo con-tiene el nmero y la fecha de la versin actual del objetivo.

Autores, Fuentes: estos campos contienen el nombre y la organiza-cin de los autores (normalmente desarrolladores) y de las fuentes(clientes o usuarios), de la versin actual del objetivo, de forma quela rastreabilidad pueda llegar hasta las personas que propusieron lanecesidad del requisito.

Descripcin: este campo contiene un patrnL que se debe comple-tar con la descripcin del objetivo.

Subobjetivos: en este campo pueden indicarse los subobjetivos quedependen del objetivo que se est describiendo. En sistemas comple-jos puede ser necesario establecer una jerarqua de objetivos previa ala identificacin de los requisitos. En caso de que sto no sea necesa-rio, puede ignorarse este campo.



Importancia: este campo indica la importancia del cumplimiento delobjetivo para los clientes y usuarios. Se puede asignar un valor nu-mrico o alguna expresin enumerada como vital, importante o queda-ra bien, tal como se propone en [IBM OOTC 1997]. En el caso de queno se haya establecido an la importancia, se puede indicar que estpor determinar (PD), equivalente al TBD (To Be Determined) empleadoen las especificaciones escritas en ingls.

Urgencia: este campo indica la urgencia del cumplimiento del obje-tivo para los clientes y usuarios en el supuesto caso de un desarrolloincremental. Como en el caso anterior, se puede asignar un valor nu-mrico o una expresin enumerada como inmediatamente, hay presino puede esperar [IBM OOTC 1997], o PD en el caso de que an no sehaya determinado.

Estado: este campo indica el estado del objetivo desde el punto devista de su desarrollo. El objetivo puede estar en construccin si se es-t elaborando, pendiente de negociacin si tiene algn conflicto asocia-do pendiente de solucin, pendiente de validacin si no tiene ningnconflicto pendiente y est a la espera de validacin o, por ltimo,puede estar validado si ha sido validado por clientes y usuarios.

Estabilidad: este campo indica la estabilidad del objetivo, es deciruna estimacin de la probabilidad de que pueda sufrir cambios en elfuturo. Esta estabilidad puede indicarse mediante un valor numricoo mediante una expresin enumerada como alta, media o baja o PD enel caso de que an no se haya determinado.

La informacin sobre la estabilidad, bien a nivel de objetivos comoen este caso, bien a nivel de requisitos, ayuda a los diseadores adisear software que prevea de antemano la necesidad de posiblescambios futuros en aquellos aspectos relacionados con los elementosidentificados como inestables durante la fase de ingeniera de requi-sitos, favoreciendo as el mantenimiento y la evolucin del software[Brackett 1990].

Comentarios: cualquier otra informacin sobre el objetivo que noencaje en los campos anteriores puede recogerse en este apartado.


Plantilla para requisitos de almacenamiento de informacin 33

5.2 Plantilla para requisitos de almacenamiento de infor-macin

Lo ms importante en los sistemas de informacin es precisamente la in-formacin que gestionan. La plantilla para requisitos de almacenamientode informacin, que puede verse en la figura 11, ayuda a los clientes yusuarios a responder a la pregunta "qu informacin, relevante para los obje-tivos de su negocio, debe ser almacenada por el sistema?".

El significado de los campos de la plantilla es el siguiente:

Identificador y nombre descriptivo: siguiendo las recomendacio-nes, entre otros, de [IEEE 1993] y [Sawyer et al. 1997], cada requisitose debe identificar por un cdigo nico y un nombre descriptivo.Con objeto de conseguir una rpida identificacin, los identificado-res de los requisitos de almacenamiento de informacin comienzancon RI.

Versin, Autores, Fuentes: estos campos tienen el mismo significadoque en la plantilla para objetivos aunque referidos al requisito.

RI Versin ()Autores ()

. . .Fuentes ()

. . .Objetivos asociados OBJx

. . .Requisitos asociados Rxy

. . .Descripcin El sistema deber almacenar la informacin correspondiente

a . En concreto:Datos especficos

. . .Intervalo temporal { pasado y presente, slo presente }Importancia Urgencia Estado Estabilidad Comentarios

Figura 11: Plantilla y patronesL para requisitos de almacenamiento deinformacin



Objetivos asociados: este campo debe contener una lista con los ob-jetivos a los que est asociado el requisito. Esto permite conocer qurequisitos harn que el sistema a desarrollar alcance los objetivospropuestos y justifican de esta forma la existencia o propsito delrequisito.

Descripcin: para los requisitos de almacenamiento de informacineste campo usa un patrnL que se debe completar con el conceptorelevante sobre el que se debe almacenar informacin.

Datos especficos: este campo contiene una lista de los datos espe-cficos asociados al concepto relevante, de los que pueden indicar-se todos aquellos aspectos que se considere oportunos (descripcin,restricciones, ejemplos, etc.).

Intervalo temporal: este campo indica durante cunto tiempo es re-levante la informacin para el sistema. Puede tomar los valores pa-sado y presente, si la informacin es siempre relevante, o slo presentesi la informacin tiene un periodo de validez concreto.Por ejemplo, si el concepto es empleados, y el intervalo de tiempo espasado y presente, quiere decir que los exempleados son relevantespara el sistema, mientras que un periodo de tiempo de slo presenteindicara que los exempleados no se deben considerar.Un intervalo temporal de pasado y presente suele implicar consi-derar la necesidad de dispositivos de almacenamiento con grandescapacidades o la necesidad de algn tipo de archivos histricos.

Requisitos asociados: en este campo se indican otros requisitos queestn asociados por algn motivo con el requisito que se est descri-biendo, permitiendo as tener una rastreabilidad horizontal, similar alas relaciones entre assets del mismo nivel descritas en [Garca 2000].

Importancia, Urgencia, Estado, Estabilidad, Comentarios: estos cam-pos tienen el mismo significado que en la plantilla para objetivosaunque referidos al requisito.

5.3 Plantilla para actores

Aunque, estrictamente hablando, los actores de los casos de uso no sonrequisitos, por homogeneidad con el estilo de definicin del resto de los


Plantilla para requisitos funcionales 35

ACT Versin ()Autores ()

. . .Fuentes ()

. . .Descripcin Este actor representa a Comentarios

Figura 12: Plantilla y patronesL para actores

elementos que componen el catlogo de requisitos se ha descrito la planti-lla para definirlos que puede verse en la figura 12.

El nico campo especfico de esta plantilla es la descripcin, en la quese usa un patrnL que debe completarse con la descripcin del rol o papelque representa el actor respecto al sistema. El significado del resto de loscampos es el mismo que para las plantillas anteriores.

5.4 Plantilla para requisitos funcionales

Los sistemas de informacin no slo almacenan informacin, tambin de-ben proporcionar servicios usando la informacin que almacenan. La plan-tilla de requisitos funcionales, que puede verse en la figura 13, describe ca-sos de uso y ayuda a los clientes y usuarios a responder a la pregunta "qudebe hacer el sistema con la informacin almacenada para alcanzar los objetivosde su negocio?".

El significado de los campos especficos de esta plantilla es el siguiente(los campos comunes con la plantilla para requisitos de almacenamientode informacin tienen el mismo significado):

Identificador y nombre descriptivo: igual que en la plantilla an-terior, excepto que los identificadores de los requisitos funcionalesempiezan con RF y que el nombre descriptivo suele coincidir con elobjetivo que los actores esperan alcanzar al realizar el caso de uso.No se debe confundir este objetivo con los objetivos del sistema. Elobjetivo que los actores esperan alcanzar al realizar un caso de usoes de ms bajo nivel, por ejemplo registrar un nuevo socio o consultarlos pedidos pendientes.



RF Versin ()Autores ()

. . .Fuentes ()



. . .Descripcin El sistema deber comportarse tal como se describe en el si-

guiente caso de uso { durante la realizacin de los casos de uso, cuando }

Precondicin Secuencia Paso Accinnormal p1 {El actor , El sistema} p2 Se realiza el caso de uso p3 Si, {el actor, el sistema}p4 Si , se realiza el caso de uso . . . . . .

Postcondicin Excepciones Paso Accin

pi Si , {el actor , el sis-tema} , a conti-nuacin este caso de uso {contina, termina}

pj Si , se realiza el caso de uso, a continuacin este caso de uso{contina, termina}

. . . . . .Rendimiento Paso Cota de tiempo

q m . . . . . .

Frecuencia esperada veces / Importancia Urgencia Estado Estabilidad Comentarios

Figura 13: Plantilla y patronesL para requisitos funcionales (casos de uso)


Plantilla para requisitos funcionales 37

Descripcin: para los requisitos funcionales, este campo contiene unpatrnL que debe completarse de forma distinta en funcin de queel 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 losque se debe realizar, es decir, aquellos desde los que es incluido o a losque extiende. Si, por el contrario, se trata de un caso de uso concreto,se debe indicar el evento de activacin que provoca su realizacin.En versiones anteriores de este patrnL, aparecan las expresionescaso de uso abstracto y caso de uso concreto. La experiencia durantela utilizacin de estas plantillas en proyectos reales nos ha llevado aeliminar dichas expresiones, que resultaban difciles de entender porlos participantes en el proceso de elicitacin.

Precondicin: en este campo se expresan en lenguaje natural las con-diciones necesarias para que se pueda realizar el caso de uso.

Secuencia normal: este campo contiene la secuencia normal de inte-racciones del caso de uso. En cada paso, un actor o el sistema realizauna o ms acciones, o se realiza (se incluye) otro caso de uso. Un pasopuede tener una condicin de realizacin, en cuyo caso si se realizaraotro 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], proponenutilizar estructuras similares al pseudocdigo para expresar las inte-racciones de los casos de uso. En nuestra opinin, esto puede llevar aque dichas descripciones sean excesivamente complejas de entenderpara los participantes sin conocimientos de programacin y se correel peligro de especificar los casos de uso con un estilo cercano a laprogramacin.Para representar estructuras condicionales complejas se puede recu-rrir 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 unuso cuidadoso del lenguaje natural. Por ejemplo, para indicar que seprocesan todos los artculos de un pedido se puede optar por frasescomo "el sistema procesa todos los artculos del pedido introducidos por elusuario", en lugar de estructuras como:

REPETIRprocesar artculo del pedido introducido por el usuario

HASTA que no haya ms artculos



Otro ejemplo puede ser especificar que el usuario puede intentar co-nectarse al sistema un mximo de tres veces. Una posible especifica-cin sera la que puede verse en la figura 14, bastante ms natural yfcil de entender que la que puede verse en la figura 15 utilizando lapropuesta descrita en [Coleman 1998].

Secuencia Paso Accinnormal 1 El sistema solicita al usuario su nombre de usuario y su

clave de acceso2 El usuario proporciona el sistema su nombre y su clave

de acceso3 El sistema comprueba si el nombre de usuario y la clave

de acceso son correctas4 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

5 Si el nombre de usuario y la clave son correctas, el sistemapermite el acceso al usuario

Excepciones Paso Accin4 Si el usuario ha intentado tres veces acceder sin xito, el

sistema rechaza el acceso del usuario, a continuacin estecaso de uso termina

Figura 14: Ejemplo de caso de uso de conexin de usuario (plantilla)

1. El sistema inicializa intentos a 0

2. REPETIR2.1 El sistema solicita al usuario su nombre de usuario2.2 El usuario proporciona al sistema su nombre de usuario2.3 El sistema solicita al usuario su clave2.4 El usuario proporciona al sistema su clave2.5 El sistema comprueba si el nombre de usuario y

la clave son correctas2.6 El sistema incrementa intentos

HASTA QUE el nombre de usuario y la clave sean correctas ointentos = 3

3. SI el nombre de usuario y la clave son correctas3.1 El sistema permite el acceso al usuario

SINO3.2 El sistema rechaza el acceso del usuario

FINSI

Figura 15: Ejemplo de caso de uso de conexin de usuario (Coleman)


Plantilla para requisitos no funcionales 39

Postcondicin: en este campo se expresan en lenguaje natural lascondiciones que se deben cumplir despus de la terminacin normaldel caso de uso.

Excepciones: este campo especifica el comportamiento del sistemaen el caso de que se produzca alguna situacin excepcional durantela realizacin de un paso determinado.Despus de realizar las acciones o el caso de uso asociados a la ex-cepcin (una extensin), el caso de uso puede continuar la secuencianormal o terminar, lo que suele ir acompaado por una cancelacinde todas las acciones realizadas en el caso de uso dejando al sistemaen el mismo estado que antes de comenzar el caso de uso, asumiendouna semntica transaccional.Inicialmente, la expresin utilizada para indicar una terminacin anor-mal del caso de uso como resultado de una excepcin era "este casode uso aborta". La experiencia durante su aplicacin nos llev a laconclusin de que el termino abortar resultaba emocionalmente moles-to para algunos participantes [Goleman 1996], por lo que se cambipor "este caso de uso termina" con el significado comentado anterior-mente.

Rendimiento: en este campo puede especificarse el tiempo mximopara cada paso en el que el sistema realice un accin.

Frecuencia esperada: en este campo se indica la frecuencia espera-da de realizacin del caso de uso, que aunque no es realmente unrequisito, es una informacin interesante para los desarrolladores.

5.5 Plantilla para requisitos no funcionales

Los requisitos no funcionales del sistema se pueden expresar usando laplantilla que puede verse en la figura 16. El nico campo especfico de estaplantilla es la descripcin, en la que se usa un patrnL que debe comple-tarse con la capacidad que deber presentar el sistema, el significado delresto de los campos es el mismo que para las plantillas anteriores.

5.6 Plantilla para conflictos

Como ya se ha comentado, durante las sesiones de elicitacin puede sernecesario resolver mediante algn tipo de negociacin posibles conflic-



RNF Versin ()Autores ()

. . .Fuentes ()



. . .Descripcin El sistema deber Importancia Urgencia Estado Estabilidad Comentarios

Figura 16: Plantilla y patronesL para requisitos no funcionales

tos en los requisitosC elicitados en iteraciones previas del proceso. Paradocumentar dichos conflictos, y las soluciones adoptadas, se propone laplantilla que puede verse en la figura 17.

El significado de los campos de la plantilla es el siguiente:

Identificador y nombre descriptivo: al igual que el resto de la infor-macin correspondiente a los requisitosC, cada conflicto debe po-derse identificar de forma nica y tener un nombre descriptivo. Elprefijo propuesto para lograr una rpida identificacin es CFL.

Versin, Autores, Fuentes: estos campos tienen el mismo significa-do que en las plantillas para objetivos y requisitos, aunque referidosal conflicto. En este caso especial, las fuentes son los participantesque deben participar en las posibles negociaciones necesarias parasu resolucin.

Objetivos y requisitos en conflicto: este campo debe contener unalista con los objetivos y/o requisitos afectados por el conflicto.

Descripcin: este campo debe contener la descripcin del conflicto. Alternativas: este campo debe contener una lista con las posibles

alternativas de solucin que se hayan identificado para solucionar elconflicto as como los autores de dicha alternativas.


Referencias 41

CFL Versin ()Autores ()

. . .Fuentes ()

. . .Objs./Reqs.en conflicto

OBJ/Ryy--x . . .

Descripcin Alternativas ()

. . .Solucin Importancia Urgencia Estado Comentarios

Figura 17: Plantilla para conflictos

Solucin: este campo debe contener la descripcin de la solucinnegociada del conflicto, una vez que se haya acordado.

Importancia, Urgencia: estos campos indican respectivamente la im-portancia y la urgencia de la resolucin del conflicto.

Estado: este campo indica el estado de resolucin del conflicto, quepodr estar en negociacin o bien resuelto.

Comentarios: este campo tienen el mismo significado que en lasplantillas descritas previamente.

Referencias

[Beyer y Holtzblatt 1995] H. R. Beyer y K. Holtzblatt. Apprenticing withthe Customer. Communications of the ACM, 38(5), Mayo 1995.

[Boehm et al. 1994] B. W. Boehm, P. Bose, E. Horowitz, y M.-J. Lee. Soft-ware Requirements as Negotiated Win Conditions. En Proceedings ofthe First International Conference on Requirements Engineering, 1994. Dis-ponible en http://sunset.usc.edu/TechRpts/Papers/NGPM-Requirements93.ps.



[Booch et al. 1999] G. Booch, J. Rumbaugh, y I. Jacobson. The Unified Mo-deling Language User Guide. AddisonWesley, 1999.

[Brackett 1990] J. W. Brackett. Software Requirements. Curriculum Mo-dule SEICM191.2, Software Engineering Institute, Carnegie MellonUniversity, 1990. Disponible en http://www.sei.cmu.edu.

[Cockburn 1997] A. Cockburn. Structuring Use Cases with Goals. Journalof ObjectOriented Programming, Sept. y Nov./Dic. 1997. Disponible enhttp://members.aol.com/acockburn/papers/usecases.htm.

[Coleman 1998] D. Coleman. A Use Case Template: Draft forDiscussion. Fusion Newsletter, Abril 1998. Disponible enhttp://www.hpl.hp.com/fusion/md_newletters.html.

[Davis 1985] F. Davis. La comunicacin no verbal, volumen 616 de El Librode Bolsillo. Alianza Editorial, 1985.

[Durn 2000] A. Durn. Un Entorno Metodolgico de Ingeniera de Requisitospara 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.

[Garca et al. 2000] J. Garca, M. J. Ortn, B. Moros, y J. Nicols. Modeladode Casos de Uso y Conceptual a partir del Modelado del Negocio. EnActas de las V Jornadas de Trabajo Menhir, Granada, 2000.

[Garca 2000] F. J. Garca. Modelo de Reutilizacin Soportado por EstructurasComplejas de Reutilizacin Denominadas Mecanos. Tesis doctoral, Univer-sidad de Salamanca, 2000.

[Gause y Weinberg 1989] D. C. Gause y G. M. Weinberg. Exploring Requi-rements: Quality Before Design. Dorset House, 1989.

[Goguen y Linde 1993] J. A. Goguen y C. Linde. Techniques for Require-ments Elicitation. En Proceedings of the First International Symposium onRequirements Engineering, 1993. Tambin aparece en [Thayer y Dorfman1997]. 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. Kai-rs, 1999.


Referencias 43

[IBM OOTC 1997] IBM OOTC. Developing ObjectOriented Software. IBMObjectOriented Technology Center. PrenticeHall, 1997.

[IEEE 1993] IEEE. IEEE Recommended Practice for Software Require-ments Specifications. IEEE/ANSI Standard 8301993, Institute of Elec-trical and Electronics Engineers, 1993.

[Jacobson et al. 1993] I. Jacobson, M. Christerson, P. Jonsson, y G. ver-gaard. 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: Ar-chitecture, Process and Organization for Business Success. AddisonWesley,1997.

[Laguna et al. 1999] M. A. Laguna, J. M. Marqus, y F. J. Garca. Una He-rramienta para la Captura de Requisitos de Usuario. En Actas de lasJISBD99, Cceres, 1999.

[MAP 1995] MAP. Metodologa de Planificacin y Desarrollo de Sistemas deInformacin. MTRICA Versin 2.1. Tecnos/Ministerio para las Admi-nistraciones Pblicas, 1995.

[Piattini et al. 1996] M. G. Piattini, J. A. Calvo-Manzano, J. Cervera, yL. Fernndez. Anlisis y Diseo Detallado de Aplicaciones Informticas deGestin. rama, 1996.

[Raghavan et al. 1994] S. Raghavan, G. Zelesnik, y G. Ford. Lecture Noteson Requirements Elicitation. Educational Materials CMU/SEI94EM10, Software Engineering Institute, Carnegie Mellon University, 1994.Disponible en http://www.sei.cmu.edu.

[Robertson y Robertson 1999] S. Robertson y J. Robertson. Mastering theRequirement Process. AddisonWesley, 1999.

[Rolland et al. 1998] C. Rolland, C. Ben Achour, C. Cauvet, J. Raly-t, A. Sutcliffe, N. A. M. Maiden, M. Jarke, P. Haumer, K. Pohl,E. Dubois, y P. Heymans. A Proposal for a Scenario Clas-sification Framework. Requirements Engineering Journal, 3(1),1998. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports98.htm.



[Sawyer et al. 1997] P. Sawyer, I. Sommerville, y S. Viller. RequirementsProcess Improvement through The Phased Introduction of Good Practi-ce. Software Process Improvement and Practice, 3(1), 1997. Disponible enhttp://www.comp.lancs.ac.uk/computing/research/cseg/reaims/publications.html.

[Sawyer y Kontoya 1999] P. Sawyer y G. Kontoya. SWEBOK: Softwa-re Requirements Engineering Knowledge Area Description. Infor-me Tcnico Versin 0.5, SWEBOK Project, 1999. Disponible enhttp://www.swebok.org.

[Scheneider y Winters 1998] G. Scheneider y J. P. Winters. Applying UseCases: a Practical Guide. AddisonWesley, 1998.

[Thayer y Dorfman 1990] R. H. Thayer y M. Dorfman, editores. Systemand Software Requirements Engineering. IEEE Computer Society Press,1990.

[Thayer y Dorfman 1997] R. H. Thayer y M. Dorfman, editores. Softwa-re Requirements Engineering. IEEE Computer Society Press, 2a edicin,1997. Es la 2a edicin de [Thayer y Dorfman 1990].

[Weidenhaput et al. 1998] K. Weidenhaput, K. Pohl, M. Jarke,y P. Haumer. Scenarios in System Development: CurrentPractice. IEEE Software, 15(2):3445, Marzo/Abril 1998. Es-te artculo aparece tambin en las actas del ICRE98 y es-t disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports97.htm.

[Wirfs-Brock et al. 1990] R. Wirfs-Brock, B. Wilkerson, y L. Wiener. Desig-ning ObjectOriented Software. PrenticeHall, 1990.


Ejemplo: gestin de un vdeoclub 45

A Ejemplo: gestin de un vdeoclub

En este apndice se ofrecen algunos ejemplos de aplicacin de las tcni-cas propuestas en esta metodologa suponiendo el caso de la gestin depequeo vdeoclub.

Dado que se trata de un ejemplo ficticio se han simplificado las plan-tillas eliminando los campos relativos a versin, autores, fuentes, impor-tancia, urgencia y estado de desarrollo.

El ejemplo no es una especificacin de requisitos completa, se incluyeslo a modo de ejemplo.

Documents

lsi-2000-10