Metodología REM

Metodología para la Elicitaciónde Requisitos de Sistemas Software

Versión 2.1

Amador Durán Toro

Beatriz Bernárdez Jiménez

Informe Técnico LSI–2000–10

Departamento de Lenguajes y Sistemas Informáticos

Facultad de Informática y Estadística

Sevilla, octubre de 2000

Este trabajo ha sido financiado por Ministerio de Educación y Ciencia de Españaa través del proyecto "MENHIR"de la CICYT TIC 97–0593–C05–01

Lista de cambiosNúm. Fecha Descripción Autor/es

0 13/10/1998 Versión 1.0 A. Durán y B.Bernárdez

1 04/11/1998 [pág. 18] En el apartado de importancia de la plantilla general derequisitos del sistema, donde aparecía “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. Durán

2 04/11/1998 [pág. 18] En el apartado de urgencia de la plantilla general de re-quisitos del sistema, donde aparecía “. . . incluyendo la funcionalidadexpresada en el caso de usoaparece ahora “. . . incluyendo las capacidadesexpresadas en el requisito"

A. Durán

3 04/11/1998 [pág. 23] En la descripción de la relación extends entre casos deuso, donde aparecía “En cierta forma, B completa la funcionalidad deAaparece ahora “En cierta forma, A completa la funcionalidad de B"

A. Durán

4 04/11/1998 [págs. 3, 6, 8, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 30] Correccionesortográficas diversas

A. Durán

5 04/11/1998 Versión 1.1 A. Durán6 18/10/1999 En la versión 2.0 se han introducido numerosos cambios, los prin-

cipales son los siguientes:A. Durán

El título cambia de Norma para la Recolección de Requisitos de un Siste-ma Software a Metodología para la Elicitación de Requisitos de SistemasSoftwareLa primera sección del documento pasa de denominarse Objetivo yalcance a Objetivo de la metodologíaSe han eliminado de la tarea 1 las referencias relativas a la construc-ción de modelos de análisis del dominioEn la tarea 2 se habla de reuniones en lugar de hacerlo específica-mente de entrevistasSe ha añadido la tarea 3 Identificar los objetivos del sistema como tareaprevia a la identificación de los requisitos y se ha diseñado unaplantilla específica para los objetivosSe han cambiado todas las apariciones de otros requisitos por requi-sitos no funcionalesSe ha cambiado el contenido de las secciones Introducción y Objeti-vos del sistema del DRSSe han añadido 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 añadido las descripciones de las técnicas de JAD y brains-tormingSe ha reescrito la descripción de la técnica de los casos de usoSe ha cambiado el nombre de la relación uses entre casos de uso aincludes para adaptar la notación a UMLSe han añadido plantillas específicas para objetivos y actoresSe han añadido nuevos campos y patrones–L a todas las plantillas,introduciendo el concepto de patrón lingüísticoSe han eliminado los subpasos de la plantilla para requisitos fun-cionales (casos de uso)Se ha reescrito la mayor parte del ejemplo de aplicación de la me-todología

7 18/10/1999 Versión 2.0 A. Durán8 18/10/2000 En la versión 2.1 se han introducido algunos cambios realizados

durante la elaboración de la tesis doctoral de A. Durán [Durán2000].

A. Durán

9 18/10/1999 Versión 2.1 A. Durán

Índice General

1 Objetivo de la metodología 1

2 Tareas recomendadas 12.1 Tarea 1: Obtener información sobre el dominio del proble-

ma y el sistema actual . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 32.1.3 Productos internos . . . . . . . . . . . . . . . . . . . . 32.1.4 Productos entregables . . . . . . . . . . . . . . . . . . 32.1.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 4

2.2 Tarea 2: Preparar y realizar las sesiones de elicitación/ne-gociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 Productos internos . . . . . . . . . . . . . . . . . . . . 52.2.4 Productos entregables . . . . . . . . . . . . . . . . . . 52.2.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 5

2.3 Tarea 3: Identificar/revisar los objetivos del sistema . . . . . 52.3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3 Productos internos . . . . . . . . . . . . . . . . . . . . 62.3.4 Productos entregables . . . . . . . . . . . . . . . . . . 62.3.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 6

2.4 Tarea 4: Identificar/revisar los requisitos de almacenamien-to de información . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 62.4.3 Productos internos . . . . . . . . . . . . . . . . . . . . 72.4.4 Productos entregables . . . . . . . . . . . . . . . . . . 7

i

2.4.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 72.5 Tarea 5: Identificar/revisar los requisitos funcionales . . . . 7

2.5.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 72.5.3 Productos internos . . . . . . . . . . . . . . . . . . . . 82.5.4 Productos entregables . . . . . . . . . . . . . . . . . . 82.5.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 8

2.6 Tarea 6: Identificar/revisar los requisitos no funcionales . . . 82.6.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.2 Descripción . . . . . . . . . . . . . . . . . . . . . . . . 82.6.3 Productos internos . . . . . . . . . . . . . . . . . . . . 92.6.4 Productos entregables . . . . . . . . . . . . . . . . . . 102.6.5 Técnicas recomendadas . . . . . . . . . . . . . . . . . 10

3 Productos entregables 10

3.1 Documento de requisitos del sistema . . . . . . . . . . . . . . 103.1.1 Portada . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Lista de cambios . . . . . . . . . . . . . . . . . . . . . 123.1.3 Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.4 Listas de figuras y tablas . . . . . . . . . . . . . . . . . 133.1.5 Introducción . . . . . . . . . . . . . . . . . . . . . . . . 133.1.6 Participantes en el proyecto . . . . . . . . . . . . . . . 133.1.7 Descripción del sistema actual . . . . . . . . . . . . . 133.1.8 Objetivos del sistema . . . . . . . . . . . . . . . . . . . 143.1.9 Catálogo de requisitos del sistema . . . . . . . . . . . 143.1.10 Requisitos de almacenamiento de información . . . . 143.1.11 Requisitos funcionales . . . . . . . . . . . . . . . . . . 143.1.12 Diagrama de casos de uso . . . . . . . . . . . . . . . . 143.1.13 Definición 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 resolución . . . . . . . . . . 153.1.18 Glosario de términos . . . . . . . . . . . . . . . . . . . 163.1.19 Apéndices . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Técnicas 164.1 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 Preparación de entrevistas . . . . . . . . . . . . . . . . 174.1.2 Realización de entrevistas . . . . . . . . . . . . . . . . 184.1.3 Análisis 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 Organización de casos de uso . . . . . . . . . . . . . . 28

5 Plantillas y patrones lingüísticos para elicitación de requisitos 295.1 Plantilla para los objetivos del sistema . . . . . . . . . . . . . 305.2 Plantilla para requisitos de almacenamiento de información 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: gestión de un vídeo–club 45A.1 Objetivos del sistema . . . . . . . . . . . . . . . . . . . . . . . 45

iii

A.2 Requisitos de almacenamiento de información . . . . . . . . 46A.3 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 48

A.3.1 Diagramas de casos de uso . . . . . . . . . . . . . . . 48A.3.2 Definición de actores . . . . . . . . . . . . . . . . . . . 51A.3.3 Casos de uso del sistema . . . . . . . . . . . . . . . . . 51

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

iv

Índice de Figuras

1 Tareas de elicitación 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 Representación gráfica de las relaciones includes y extends . . 288 Representación gráfica de los paquetes de casos de uso . . . 299 La plantilla como elemento de elicitación y negociación . . . 3010 Plantilla y patrones–L para objetivos . . . . . . . . . . . . . . 3111 Plantilla y patrones–L para requisitos de almacenamiento

de información . . . . . . . . . . . . . . . . . . . . . . . . . . 3312 Plantilla y patrones–L para actores . . . . . . . . . . . . . . . 3513 Plantilla y patrones–L para requisitos funcionales (casos de

uso) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3614 Ejemplo de caso de uso de conexión de usuario (plantilla) . . 3815 Ejemplo de caso de uso de conexión de usuario (Coleman) . 3816 Plantilla y patrones–L para requisitos no funcionales . . . . . 4017 Plantilla para conflictos . . . . . . . . . . . . . . . . . . . . . . 4118 Diagrama de subsistemas . . . . . . . . . . . . . . . . . . . . 4819 Diagrama de casos de uso del subsistema Gestión de socios 4820 Diagrama de casos de uso del subsistema Gestión de películas 4921 Diagrama de casos de uso del subsistema Gestión de alqui-

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

v

vi

Objetivo de la metodología 1

1 Objetivo de la metodología

El objetivo de esta metodología es la definición de las tareas a realizar,los productos a obtener y las técnicas a emplear durante la actividad deelicitación de requisitos de la fase de ingeniería de requisitos del desarrollo desoftware.

En esta metodología 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 metodología es el Docu-mento de Requisitos del Sistema (DRS), definido en la sección 3.1, pág. 10.

La estructura de este documento es la siguiente: en la sección 2 se des-criben las tareas recomendadas, en la sección 3 se definen los productosentregables, en este caso el DRS, y por último, en la sección 4 se describenalgunas de las técnicas recomendadas para obtener los productos. Tam-bién se incluye como apéndice un ejemplo de aplicación de esta metodo-logía.

2 Tareas recomendadas

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

Tarea 1: Obtener información sobre el dominio del problema y el sistemaactual.

Tarea 2: Preparar y realizar las reuniones de elicitación/negociación.

Tarea 3: Identificar/revisar los objetivos del sistema.

Tarea 4: Identificar/revisar los requisitos de almacenamiento de informa-ción.

Tarea 5: Identificar/revisar los requisitos funcionales.

Tarea 6: Identificar/revisar los requisitos no funcionales.

Tarea 7: Priorizar objetivos y requisitos.

A. Durán, B. Bernárdez Sevilla, Octubre 2000

2 Metodología para la Elicitación de Requisitos de Sistemas Software

El orden recomendado de realización para estas tareas es: 1. . . 7, aun-que las tareas 4, 5, y 6 pueden realizarse simultáneamente 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.

Elicitación de RequisitosElicitación de Requisitos

Obtenerinformación sobre

el dominio delproblema y elsistema actual

Obtenerinformación sobre

el dominio delproblema y elsistema actual

Preparar yrealizar las

sesiones deelicitación/

negociación

Preparar yrealizar las

sesiones deelicitación/

negociación

Identificar/revisar losobjetivos

del sistema

Identificar/revisar losobjetivos

del sistema

Identificar/revisar losrequisitos

deinformación


deinformación


funcionales


funcionales


nofuncionales


nofuncionales

Priorizarobjetivos yrequisitos

Priorizarobjetivos yrequisitos

Figura 1: Tareas de elicitación de requisitos

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

Dpto. de Lenguajes y Sistemas Informáticos Informe Técnico LSI–2000–10

Tarea 1: Obtener información sobre el dominio del problema y el sistema actual 3

2.1 Tarea 1: Obtener información sobre el dominio del pro-blema y el sistema actual

2.1.1 Objetivos

• Conocer el dominio del problema.

• Conocer la situación actual.

2.1.2 Descripción

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 situación actual.

Enfrentarse a un desarrollo sin conocer las características 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 características 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

• Información recopilada: libros, artículos, folletos comerciales, desa-rrollos previos sobre el mismo dominio, etc.

• Modelos del sistema actual.

2.1.4 Productos entregables

• Introducción, participantes en el proyecto, principalmente clientes ydesarrolladores, y descripción del sistema actual como parte del DRS(ver secciones 3.1.5–3.1.7, págs. 13–13).



2.1.5 Técnicas recomendadas

• Obtener información 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 específico puede sernecesario recurrir a fuentes internas al propio negocio del cliente,en cuyo caso pueden utilizarse las técnicas auxiliares de elicitaciónde requisitos como el estudio de documentación, observación in si-tu, cuestionarios, inmersión o aprendizaje, etc. (ver secciones 4.1–4.3,págs. 16–23).

• Modelado del sistema actual [Laguna et al. 1999, García et al. 2000].

2.2 Tarea 2: Preparar y realizar las sesiones de elicitación/ne-gociación

2.2.1 Objetivos

• Identificar a los usuarios participantes.

• Conocer las necesidades de clientes y usuarios.

• Resolver posibles conflictos.

2.2.2 Descripción

Teniendo en cuenta la información 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 crítica y ha de realizarse con especial cui-dado, ya que generalmente el equipo de desarrollo no conoce los detallesespecíficos de la organización 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 vídeo de las reuniones ocualquier otra documentación que se considere oportuna.


• Participantes en el proyecto, en concreto los usuarios participantes,como parte del DRS (ver sección 3.1.6, pág. 13).

• Objetivos, requisitos o conflictos, que se hayan identificado clara-mente durante las sesiones de elicitación, como parte del DRS (versecciones 3.1.8–3.1.9 y 3.1.17, págs. 14–14 y 15)


• Técnicas de elicitación de requisitos (ver secciones 4.1–4.3, págs. 16–23), incluyendo las plantillas de objetivos, requisitos y conflictos des-critas en la sección 5, pág. 29, que pueden usarse directamente du-rante las sesiones de elicitación.

• Técnicas de negociación 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 Descripción

A partir de la información 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 explotación o revisarlos en función



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 sección 3.1.8, pág. 14).


• Análisis de factores críticos de éxito [MAP 1995] o alguna técnicasimilar de identificación de objetivos.

• Plantilla para especificar los objetivos del sistema (ver sección 5.1,pág. 30).

2.4 Tarea 4: Identificar/revisar los requisitos de almacena-miento de información

2.4.1 Objetivos

• Identificar los requisitos de almacenamiento de información que de-berá cumplir el sistema software a desarrollar.

• Revisar, en el caso de que haya conflictos, los requisitos de almace-namiento de información previamente identificados.

2.4.2 Descripción

A partir de la información 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é informaciónrelevante para el cliente deberá gestionar y almacenar el sistema softwarea desarrollar.

Inicialmente se partirán de conceptos generales para posteriormente irdetallándolos hasta obtener todos los datos relevantes.


Tarea 5: Identificar/revisar los requisitos funcionales 7




• Requisitos de almacenamiento de información como parte del DRS(ver sección 3.1.10, pág. 14).


• Plantilla para requisitos de almacenamiento de información (ver sec-ción 5.2, pág. 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 Descripción

A partir de la información 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 información identificada en la tarea anterior.

Inicialmente se identificarán los actores que interactuarán con el siste-ma, es decir aquellas personas u otros sistemas que serán los orígenes odestinos de la información que consumirá o producirá el sistema a desa-rrollar y que forman su entorno.

A continuación se identificarán los casos de uso asociados a los actores,los pasos de cada caso de uso y posteriormente se detallarán los casos de



uso con las posibles excepciones hasta definir todas las situaciones posi-bles.




• Requisitos funcionales como parte del DRS (ver sección 3.1.11, pág.14).


• Casos de uso (ver sección 4.4, pág. 25).

• Plantilla para actores (ver sección 5.3, pág. 34).

• Plantilla para los requisitos funcionales (ver sección 5.4, pág. 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 Descripción

A partir de la información 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 carácter técnico o legal.

Algunos tipos de requisitos que se suelen incluir en esta sección son lossiguientes:


Tarea 6: Identificar/revisar los requisitos no funcionales 9

Requisitos de comunicaciones del sistemaSon requisitos de carácter técnico 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 características que deberá tenerel sistema en su comunicación con el usuario. Por ejemplo: la interfazde usuario del sistema deberá ser consistente con los estándares definidos enIBM’s Common User Access.

Se debe ser cuidadoso con este tipo de requisitos, ya que en esta fasede desarrollo todavía no se conocen bien las dificultades que puedensurgir a la hora de diseñar e implementar las interfaces, por esto noes conveniente entrar en detalles demasiado específicos.

Requisitos de fiabilidadLos requisitos de fiabilidad deben establecer los factores que se re-quieren para la fiabilidad del software en tiempo de explotación. 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 específico. Por ejemplo: el sistema deberá desarrollarse conOracle 7 como servidor y clientes Visual Basic 4.

Requisitos de portabilidadLos requisitos de portabilidad definen qué características deberá te-ner el software para que sea fácil utilizarlo en otra máquina o bajootro sistema operativo. Por ejemplo: el sistema deberá funcionar en lossistemas operativos Windows 95, Windows 98 y Windows NT 4.0, siendoademás posible el acceso al sistema a través de Internet usando cualquiernavegador compatible con HTML 3.0.






• Requisitos no funcionales del sistema como parte del DRS (ver sec-ción 3.1.15, pág. 15).


• Plantilla para requisitos no funcionales (ver sección 5.5, pág. 39).

3 Productos entregables

El único producto entregable que se contempla en esta metodología 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 sección 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.

• Versión: la versión del DRS que se entrega al cliente. La versión secompone de dos números X e Y . El primero indica la versión, y sedebe incrementar cada vez que se hace una nueva entrega formalal cliente. Cuando se incremente el primer número, el segundo de-be volver a comenzar en cero. El segundo número indica cambiosdentro de la misma versión aún no entregada, y se debe incrementarcada vez que se publica una versión con cambios respecto a la últi-ma que se publicó y que no se vaya a entregar formalmente todavía.Este tipo de versiones pueden ser internas al equipo de desarrollo oser entregadas al cliente a título orientativo.


Documento de requisitos del sistema 11

PortadaLista de cambiosÍndiceLista de figurasLista de tablas

1 Introducción

2 Participantes en el proyecto

3 Descripción del sistema actual [opcional]

4 Objetivos del sistema

5 Catálogo de requisitos del sistema

5.1 Requisitos de almacenamiento de información5.2 Requisitos funcionales

5.2.1 Diagramas de casos de uso5.2.2 Definición de actores5.2.3 Casos de uso del sistema

5.3 Requisitos no funcionales

6 Matriz de rastreabilidad objetivos/requisitos

7 Conflictos pendientes de resolución [opcional, pueden iren un documento aparte]

8 Glosario de términos [opcional]

Apéndices [opcionales]

Figura 2: Estructura del Documento de Requisitos del Sistema



Proyecto nombre del proyecto

Documento deRequisitos del Sistema

Versión X.YFecha fecha

Realizado por equipo de desarrolloRealizado para cliente

Figura 3: Portada del Documento de Requisitos del Sistema

• Fecha: fecha de la publicación de la versión.

• 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 versión 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 número de orden, la fecha, una descripción ylos autores.

Núm. Fecha Descripción Autores0 fecha0 Versión x.y autor01 fecha1 descripción cambio1 autor1

......

......

n fechan descripción cambion autorn

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



3.1.3 Índice

El índice del DRS debe indicar la página en la que comienza cada sección,subsección o apartado del documento. En la medida de lo posible, se san-grarán 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 serán dos índices que indicarán el número, la descripcióny la página en que aparece cada figura o tabla del DRS.

3.1.5 Introducción

Esta sección debe contener una descripción breve de las principales ca-racterísticas del sistema software que se va a desarrollar, la situación ac-tual que genera la necesidad del nuevo desarrollo, la problemática que seacomete, y cualquier otra consideración que sitúe al posible lector en elcontexto oportuno para comprender el resto del documento.

3.1.6 Participantes en el proyecto

Esta sección 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 desempeña en el proyecto,la organización a la que pertenece y cualquier otra información adicionalque se considere oportuna.

3.1.7 Descripción del sistema actual

Esta sección debe contener una descripción del sistema actual en el casode que se haya acometido su estudio. Para describir el sistema actual pue-de utilizarse cualquier técnica que se considere oportuno, por ejemplo lasdescritas en [Laguna et al. 1999] (Diagrama Documentos–Tarea, DDT) o en[García et al. 2000] (Diagramas de Actividad, también descritos en [Booch etal. 1999]).



3.1.8 Objetivos del sistema

Esta sección debe contener una lista con los objetivos que se esperan alcan-zar cuando el sistema software a desarrollar esté en explotación, especifi-cados mediante la plantilla para objetivos descrita en la sección 5.1, pág.30.

3.1.9 Catálogo de requisitos del sistema

Esta sección 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 información, funcionales y no funcionales,podrán dividirse para ayudar a la legibilidad del documento, por ejem-plo dividiendo cada subsección en requisitos asociados a un determinadoobjetivo, requisitos con características comunes, etc.

3.1.10 Requisitos de almacenamiento de información

Esta subsección debe contener la lista de requisitos de almacenamiento deinformación que se hayan identificado, utilizando para especificarlos laplantilla para requisitos de almacenamiento de información descrita en lasección 5.2, pág. 33.

3.1.11 Requisitos funcionales

Esta subsección debe contener la lista de requisitos funcionales que se ha-yan identificado, dividiéndose en los siguientes apartados que se descri-ben a continuación.

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 Definición 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 sección 5.3, pág. 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 sección 5.4, pág. 35.

3.1.15 Requisitos no funcionales

Esta subsección 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 sección 5.5, pág. 39.

3.1.16 Matriz de rastreabilidad objetivos/requisitos

Esta sección debe contener una matriz objetivo–requisito, 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.

OBJ–01 OBJ–02 . . . OBJ-nRI–01 • •RI–02 •. . .RF–01 •RF–02 • •. . .RNF–01 •RNF–02 •. . .

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

3.1.17 Conflictos pendientes de resolución

Esta sección, 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 aún están pendientes de resolución, des-critos mediante la plantilla para conflictos.



3.1.18 Glosario de términos

Esta sección, que se incluirá si se considera oportuno, deberá contener unalista ordenada alfabéticamente de los términos específicos del dominio delproblema, acrónimos y abreviaturas que aparezcan en el documento y quese considere que su significado deba ser aclarado. Cada término deberáacompañarse de su significado.

3.1.19 Apéndices

Los apéndices se usarán para proporcionar información adicional a la do-cumentación obligatoria del documento. Sólo deben aparecer si se consi-deran oportunos y se identificarán con letras ordenadas alfabéticamente:A, B, C, etc.

4 Técnicas

A continuación, se describen algunas de las técnicas que se proponen enesta metodología para obtener los productos de las tareas que se han des-crito.

Las técnicas más habituales en la elicitación de requisitos son las en-trevistas, el Joint Application Development (JAD) o Desarrollo Conjunto deAplicaciones, el brainstorming o tormenta de ideas y la utilización de esce-narios [Weidenhaput et al. 1998, Rolland et al. 1998], más conocidos comocasos de uso [Jacobson et al. 1993, Booch et al. 1999].

A estas técnicas, que se describen en los siguientes apartados, se lassuele apoyar con otras técnicas complementarias como la observación insitu, el estudio de documentación, los cuestionarios, la inmersión 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 técnica de elicitación más utilizada, y de hecho sonprácticamente inevitables en cualquier desarrollo ya que son una de lasformas de comunicación más naturales entre personas.


Entrevistas 17

En las entrevistas se pueden identificar tres fases: preparación, realiza-ción y análisis [Piattini et al. 1996].

4.1.1 Preparación de entrevistas

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

• Estudiar el dominio del problema: conocer las categorías 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 técnicas deestudio de documentación, a bibliografía sobre el tema, documen-tación de proyectos similares realizados anteriormente, la inmersióndentro de la organización 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 número 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 visión global, y secontinúa con los futuros usuarios, que pueden aportar informaciónmás detallada, y con el personal técnico, que aporta detalles sobre elentorno operacional de la organización.Tal como se recomienda en [Piattini et al. 1996], conviene tambiénestudiar el perfil de los entrevistados, buscando puntos en comúncon 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 realización, se pueden enviar cuestionarios que losfuturos entrevistados deben rellenar y devolver, y un pequeño do-cumento de introducción al proyecto de desarrollo, de forma que elentrevistado conozca los temas que se van a tratar y el entrevistadorrecoja información para preparar la entrevista.



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

• Planificar las entrevistas: la fecha, hora, lugar y duración 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 Realización de entrevistas

Dentro de la realización 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 razón de la entrevista, qué se espera conseguir, cómo seutilizará la información, la mecánica de las preguntas, etc.Si se va a utilizar algún tipo de notación gráfica o matemática queel entrevistado no conozca debe explicarse antes de utilizarse. Esfundamental causar buena impresión en los primeros minutos.

2 Desarrollo: la entrevista en si no debería durar más de dos horas,distribuyendo el tiempo en un 20% para el entrevistador y un 80%para el entrevistado.Se deben evitar los monólogos 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 vídeo o audio, siempre que el entrevistado esté de acuerdo [Ro-bertson y Robertson 1999].Durante esta fase se pueden emplear distintas técnicas:

• Preguntas abiertas: también denominadas de libre contexto [Gau-se y Weinberg 1989], estas preguntas no pueden respondersecon un "sí" o un "no", permiten una mayor comunicación y evi-tan la sensación de interrogatorio. Por ejemplo, "¿Qué se hacepara registrar un pedido?", "Dígame qué se debe hacer cuando uncliente pide una factura" o "¿Cómo se rellena un albarán?".


Entrevistas 19

Estas preguntas se suelen utilizar al comienzo de la entrevista,pasando posteriormente a preguntas más 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 utilización.Una posibilidad es utilizar las plantillas descritas en la sección 5,pág. 29, como mecanismos tanto de obtención de información,ya que su estructura indica la información 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 comunicación [Goleman 1996, Gole-man 1999].

• Mostrar interés en todo momento: es fundamental cuidar lacomunicación no verbal [Davis 1985] durante la entrevista: tonode voz, movimiento, expresión 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 atención, etc. Debeevitarse bostezar, reclinarse en el sillón, mirar hacia otro lado,etc.

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

4.1.3 Análisis de las entrevistas

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

Una vez elaborada la información, se puede enviar al entrevistado paraconfirmar los contenidos. También es importante evaluar la propia entre-vista para determinar los aspectos mejorables.



4.2 Joint Application Development

La técnica 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 días. En estas reuniones seayuda a los clientes y usuarios a formular problemas y explorar posiblessoluciones, involucrándolos y haciéndolos sentirse partícipes del desarro-llo.

Esta técnica se base en cuatro principios [Raghavan et al. 1994]: diná-mica de grupo, el uso de ayudas visuales para mejorar la comunicación(diagramas, transparencias, multimedia, herramientas CASE, etc.), man-tener un proceso organizado y racional y una filosofía de documentaciónWYSIWYG (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 diseño delsoftware. En este documento sólo se verá con detalle el primero de ellos.

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

En comparación 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 documentación generada, no sólo los ingenieros de requisitos.

• Implica más 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 comunicación y lideraz-go. Algunas habilidades importantes que debe tener son: entender ypromover la dinámica de grupo, iniciar y centrar discusiones, reco-nocer cuándo la reunión se está desviando del tema y reconducirla,manejar las distintas personalidades y formas de ser de los partici-pantes, evitar que decaiga la reunión aunque sea larga y difícil, etc.

• Analista: es el responsable de la producción 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 decisión final de que se lle-ve a cabo el desarrollo. Debe proporcionar a los demás participantesinformación 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 visión global del sistema. Durante el JAD/Designsuelen incorporarse futuros usuarios finales.

• Representantes de sistemas de información: son personas expertosen sistemas de información que deben ayudar a los usuarios a com-prender qué es o no factible con la tecnología actual y el esfuerzo queimplica.

• Especialistas: son personas que pueden proporcionar informacióndetallada sobre aspectos muy concretos, tanto del punto de vista delos usuarios porque conocen muy bien el funcionamiento de una par-te de la organización, como desde el punto de vista de los desarro-lladores porque conocen perfectamente ciertos aspectos técnicos dela instalación hardware de la organización.

4.2.2 Fases del JAD

Dentro de la técnica del JAD se distinguen tres fases [Raghavan et al. 1994]:

1 Adaptación: es responsabilidad del jefe del JAD, ayudado por unoo dos analistas, adaptar la técnica del JAD para cada proyecto. Laadaptación debe comenzar por definir el proyecto a alto nivel, para



lo cual pueden ser necesarias entrevistas previas con algunos clientesy usuarios. También suele ser necesario recabar información sobre laorganización para familiarizarse con el dominio del problema, porejemplo utilizando técnicas complementarias como el estudio de do-cumentación o la observación 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 duración y el número de sesiones acelebrar, definir el formato de la documentación sobre la que se tra-bajará y preparar transparencias introductorias y todo el material au-diovisual que considere oportuno.

2 Celebración 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 Presentación: 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 mecánica de las sesiones y laplanificación prevista.

2.2 Definir objetivos y requisitos: el jefe del JAD promueve la dis-cusión para elicitar los objetivos o requisitos de alto nivel me-diante preguntas como: "¿Por qué se construye el sistema?", "¿Québeneficios se esperan del nuevo sistema?", "¿Cómo puede beneficiar ala organización 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 algún otro medio que permita quepermanezcan visibles durante la discusión. Una posibilidad esutilizar para ello las plantillas descritas en la sección 5, pág. 29.

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


Brainstorming 23

En el caso de los sistemas de información, 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 sesión que no se han podido resolver, deben do-cumentarse para las siguientes sesiones y ser asignadas a unapersona responsable de su solución para una fecha determina-da, para lo cual puede utilizarse la plantilla de conflictos descri-ta en la sección 5.6, pág. 39.

2.5 Concluir la sesión: el jefe del JAD concluye la sesión revisandocon los demás participantes la información elicitada y las deci-siones tomadas. Se da la oportunidad a todos los participantesde expresar cualquier consideración adicional, fomentando porparte del jefe del JAD el sentimiento de propiedad y compromi-so de todos los participantes sobre los requisitos elicitados.

3 Conclusión: una vez terminadas las sesiones es necesario transfor-mar las transparencias, notas y demás documentación generada endocumentos formales. Se distinguen tres pasos:

3.1 Completar la documentación: los analistas recopilan la docu-mentación generada durante las sesiones en documentos con-formes a las normas o estándares vigentes en la organizaciónpara la que se desarrolla el proyecto.

3.2 Revisar la documentación: la documentación generada se en-vía a todos los participantes para que la comenten. Si los co-mentarios son lo suficientemente importantes, se convoca otrareunión para discutirlos.

3.3 Validar la documentación: una vez revisados todos los comen-tarios, el jefe del JAD envía el documento al patrocinador eje-cutivo para su aprobación. Una vez aprobado el documento seenvían copias definitivas a cada uno de los participantes.

4.3 Brainstorming

El brainstorming o tormenta de ideas es una técnica de reuniones en grupocuyo objetivo es la generación de ideas en un ambiente libre de críticaso juicios [Gause y Weinberg 1989, Raghavan et al. 1994]. Las sesionesde brainstorming suelen estar formadas por un número de cuatro a diez



participantes, uno de los cuales es el jefe de la sesión, encargado más decomenzar la sesión que de controlarla.

Como técnica de elicitación 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 elicitación,cuando los requisitos son todavía muy difusos.

Frente al JAD, el brainstorming tiene la ventaja de que es muy fácilde aprender y requiere poca organización, de hecho, hay propuestas derealización de brainstorming por vídeo–conferencia a través 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 técnicas.

4.3.1 Fases del brainstorming

En el brainstorming se distinguen las siguientes fases [Raghavan et al.1994]:

1 Preparación: la preparación para una sesión de brainstorming re-quiere que se seleccione a los participantes y al jefe de la sesión, ci-tarlos y preparar la sala donde se llevará a cabo la sesión. Los partici-pantes en una sesión de brainstorming para elicitación de requisitosson normalmente clientes, usuarios, ingenieros de requisitos, desa-rrolladores y, si es necesario, algún experto en temas relevantes parael proyecto.

2 Generación: el jefe abre la sesión 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-sión, bien aleatoriamente. El jefe es siempre el responsable de darla palabra a un participante. Este proceso continúa hasta que el jefedecide parar, bien porque no se están generando suficientes ideas, encuyo caso la reunión se pospone, bien porque el número de ideas seasuficiente para pasar a la siguiente fase. Durante esta fase se debenobservar las siguientes reglas:

• Se prohíbe la crítica de ideas, de forma que los participantes sesientan libres de formular cualquier idea.


Casos de uso 25

• Se fomentan las ideas más avanzadas, que aunque no sean fac-tibles, estimulan a los demás participantes a explorar nuevassoluciones más creativas.

• Se debe generar un gran número de ideas, ya que cuantas másideas se presenten más 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 técnica del JAD, que todas las ideas generadas estén 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 sección 5, pág. 29, pueden utilizarse dichasplantillas para que los participantes tengan visibles las ideas que sevan generando.

3 Consolidación: 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 estarían bien pero que noson esenciales y las que podrían ser apropiadas para una próxi-ma versión del sistema a desarrollar.

4 Documentación: después de la sesión, el jefe produce la documen-tación oportuna conteniendo las ideas priorizadas y comentarios ge-nerados durante la consolidación.

4.4 Casos de uso

Los casos de uso son una técnica para la especificación 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 descripción de una secuencia de interacciones en-tre el sistema y uno o más 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 interactúan con el siste-ma cuyos requisitos se están describiendo [Scheneider y Winters 1998].

Los casos de uso presentan ciertas ventajas sobre la descripción me-ramente textual de los requisitos funcionales [Firesmith 1997], ya que fa-cilitan la elicitación de requisitos y son fácilmente comprensibles por losclientes y usuarios. Además, pueden servir de base a las pruebas del sis-tema y a la documentación para los usuarios [Weidenhaput et al. 1998].

A pesar de ser una técnica ampliamente aceptada, existen múltiplespropuestas para su utilización concreta [Cockburn 1997]. En esta metodo-logía se propone la utilización de los casos de uso como técnica tanto deelicitación como de especificación de los requisitos funcionales del siste-ma. Para la descripción 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 lingüísticos (versección 5.4, pág. 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 representación gráfica en los denominadosdiagramas de casos de uso [Booch et al. 1999]. En estos diagramas, los actoresse representan en forma de pequeños monigotes y los casos de uso se re-presentan por elipses contenidas dentro de un rectángulo que representaal sistema. La participación de los actores en los casos de uso se indicapor una flecha entre el actor y el caso de uso que apunta en la dirección enla que fluye la información. Un ejemplo de este tipo de diagramas puedeverse en la figura 6.

Los diagramas de casos de uso sirven para proporcionar una visiónglobal 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 descripción. Las dos relaciones posibles y sus semánticassegún [Booch et al. 1999] son las siguientes, cuya representación gráficapuede 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-más, siempre que ocurre A ocurre también 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 sólo tiene significado cuando se utiliza para describiralguna funcionalidad que es común 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 relación cuando se detectan subsecuencias deinteracciones comunes a varios casos de uso. Dichas subsecuenciascomunes se sacan "factor común"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 "extraído". De esta forma se evita repetir



A B C

X Y

<<includes>><<extends>><<includes>>

<<includes>>

Figura 7: Representación gráfica 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, segúnse 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 Organización de casos de uso

En la mayoría de sistemas, el número 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 fácil 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-prensión. 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 lingüísticos para elicitación de requisitos 29

Sistema

Actor 2Actor 1

A<<subsistema>>

B<<subsistema>>

C<<subsistema>>

Figura 8: Representación gráfica de los paquetes de casos de uso

5 Plantillas y patrones lingüísticos para elicita-ción de requisitos

Las plantillas y patrones lingüísticos que se presentan en los siguientesapartados están pensados para utilizarse tanto durante las reuniones deelicitación 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 expresión de requisitos. Por otro lado, también puedenusarse como elementos de elicitación y negociación durante las reunionescon clientes y usuarios de forma similar a las conocidas tarjetas CRC (Clase,Responsabilidad, Colaboración) [Wirfs-Brock et al. 1990] (ver figura 9).

De esta forma se consigue que durante las sesiones de elicitación setrabaje con una filosofía WYSIWYG, tal como se propone en las técnicasde JAD o brainstorming, ya que los participantes manejan directamente ladocumentación final, favoreciéndose así su implicación en el proceso.

Como fruto de la experiencia de su utilización, para algunos camposde las plantillas se han identificado frases "estándar"que son habituales enlas especificaciones de requisitos y que se han parametrizado. Estas fra-ses, a las que hemos denominado patrones lingüísticos, o abreviadamentepatrones–L, pueden usarse para rellenar los campos de las plantillas dán-dole valores a los parámetros con la información oportuna.



Figura 9: La plantilla como elemento de elicitación y negociación

Ambos aspectos, la estructuración de la información en forma de plan-tilla y la propuesta de frases "estándar", facilita la redacción de los requi-sitos, permitiendo a los participantes en las actividades de elicitación cen-trarse en expresar sus necesidades y no en cómo expresarlas.

En la notación usada para describir los patrones–L, 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 lospatrones–L 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 dichosserían 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–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)

. . .Fuentes • <fuente de la versión actual> (<organización de la fuente>)

. . .Descripción El sistema deberá <objetivo a cumplir por el sistema>Subobjetivos • OBJ–x <nombre del subobjetivo>

• . . .Importancia <importancia del objetivo>Urgencia <urgencia del objetivo>Estado <estado del objetivo>Estabilidad <estabilidad del objetivo>Comentarios <comentarios adicionales sobre el objetivo>

Figura 10: Plantilla y patrones–L para objetivos

El significado de los campos que la componen, cuya mayoría está pre-sente también 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 uncódigo único y un nombre descriptivo. Con objeto de conseguir unarápida identificación, los identificadores de los objetivos comienzancon OBJ.

• Versión: para poder gestionar distintas versiones, este campo con-tiene el número y la fecha de la versión actual del objetivo.

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

• Descripción: este campo contiene un patrón–L que se debe comple-tar con la descripción 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 jerarquía de objetivos previa ala identificación 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-mérico o alguna expresión enumerada como vital, importante o queda-ría bien, tal como se propone en [IBM OOTC 1997]. En el caso de queno se haya establecido aún la importancia, se puede indicar que estápor determinar (PD), equivalente al TBD (To Be Determined) empleadoen las especificaciones escritas en inglés.

• 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-mérico o una expresión enumerada como inmediatamente, hay presióno puede esperar [IBM OOTC 1997], o PD en el caso de que aún no sehaya determinado.

• Estado: este campo indica el estado del objetivo desde el punto devista de su desarrollo. El objetivo puede estar en construcción si se es-tá elaborando, pendiente de negociación si tiene algún conflicto asocia-do pendiente de solución, pendiente de validación si no tiene ningúnconflicto pendiente y está a la espera de validación o, por último,puede estar validado si ha sido validado por clientes y usuarios.

• Estabilidad: este campo indica la estabilidad del objetivo, es deciruna estimación de la probabilidad de que pueda sufrir cambios en elfuturo. Esta estabilidad puede indicarse mediante un valor numéricoo mediante una expresión enumerada como alta, media o baja o PD enel caso de que aún no se haya determinado.

La información sobre la estabilidad, bien a nivel de objetivos comoen este caso, bien a nivel de requisitos, ayuda a los diseñadores adiseñar software que prevea de antemano la necesidad de posiblescambios futuros en aquellos aspectos relacionados con los elementosidentificados como inestables durante la fase de ingeniería de requi-sitos, favoreciendo así el mantenimiento y la evolución del software[Brackett 1990].

• Comentarios: cualquier otra información sobre el objetivo que noencaje en los campos anteriores puede recogerse en este apartado.


Plantilla para requisitos de almacenamiento de información 33

5.2 Plantilla para requisitos de almacenamiento de infor-mación

Lo más importante en los sistemas de información es precisamente la in-formación que gestionan. La plantilla para requisitos de almacenamientode información, que puede verse en la figura 11, ayuda a los clientes yusuarios a responder a la pregunta "¿qué información, 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 código único y un nombre descriptivo.Con objeto de conseguir una rápida identificación, los identificado-res de los requisitos de almacenamiento de información comienzancon RI.

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

RI–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)


. . .Objetivos asociados • OBJ–x <nombre del objetivo>

. . .Requisitos asociados • Rx–y <nombre del requisito>

. . .Descripción El sistema deberá almacenar la información correspondiente

a <concepto relevante>. En concreto:Datos específicos • <datos específicos sobre el concepto relevante>

• . . .Intervalo temporal { pasado y presente, sólo presente }Importancia <importancia del requisito>Urgencia <urgencia del requisito>Estado <estado del requisito>Estabilidad <estabilidad del requisito>Comentarios <comentarios adicionales sobre el requisito>

Figura 11: Plantilla y patrones–L para requisitos de almacenamiento deinformación



• Objetivos asociados: este campo debe contener una lista con los ob-jetivos a los que está asociado el requisito. Esto permite conocer quérequisitos harán que el sistema a desarrollar alcance los objetivospropuestos y justifican de esta forma la existencia o propósito delrequisito.

• Descripción: para los requisitos de almacenamiento de informacióneste campo usa un patrón–L que se debe completar con el conceptorelevante sobre el que se debe almacenar información.

• Datos específicos: este campo contiene una lista de los datos espe-cíficos asociados al concepto relevante, de los que pueden indicar-se todos aquellos aspectos que se considere oportunos (descripción,restricciones, ejemplos, etc.).

• Intervalo temporal: este campo indica durante cuánto tiempo es re-levante la información para el sistema. Puede tomar los valores pa-sado y presente, si la información es siempre relevante, o sólo presentesi la información 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 ex–empleados son relevantespara el sistema, mientras que un periodo de tiempo de sólo presenteindicaría que los ex–empleados 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 algún tipo de archivos históricos.

• Requisitos asociados: en este campo se indican otros requisitos queestén asociados por algún 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 [García 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 definición del resto de los


Plantilla para requisitos funcionales 35

ACT–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)


. . .Descripción Este actor representa a <rol que representa el actor>Comentarios <comentarios adicionales sobre el actor>

Figura 12: Plantilla y patrones–L para actores

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

El único campo específico de esta plantilla es la descripción, en la quese usa un patrón–L que debe completarse con la descripción 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 información no sólo almacenan información, también de-ben proporcionar servicios usando la información 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 "¿quédebe hacer el sistema con la información almacenada para alcanzar los objetivosde su negocio?".

El significado de los campos específicos de esta plantilla es el siguiente(los campos comunes con la plantilla para requisitos de almacenamientode información 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 más bajo nivel, por ejemplo registrar un nuevo socio o consultarlos pedidos pendientes.



RF–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)




. . .Descripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso { durante la realización de los casos de uso<lista de casos de uso>, cuando <evento de activación> }

Precondición <precondición del caso de uso>Secuencia Paso Acciónnormal p1 {El actor <actor>, El sistema} <acción/es realizada/s por

actor/sistema>p2 Se realiza el caso de uso <caso de uso (RF–x)>p3 Si <condición>, {el actor <actor>, el sistema} <acción/es

realizada/s por actor/sistema>p4 Si <condición>, se realiza el caso de uso <caso de uso

(RF–x)>. . . . . .

Postcondición <postcondición del caso de uso>Excepciones Paso Acción

pi Si <condición de excepción>, {el actor <actor>, el sis-tema} <acción/es realizada/s por actor/sistema>, a conti-nuación este caso de uso {continúa, termina}

pj Si <condición de excepción>, se realiza el caso de uso<caso de uso (RF–x)>, a continuación este caso de uso{continúa, termina}

. . . . . .Rendimiento Paso Cota de tiempo

q m <unidad de tiempo>. . . . . .

Frecuencia esperada <no de veces> veces / <unidad de tiempo>Importancia <importancia del requisito>Urgencia <urgencia del requisito>Estado <estado del requisito>Estabilidad <estabilidad del requisito>Comentarios <comentarios adicionales sobre el requisito>

Figura 13: Plantilla y patrones–L para requisitos funcionales (casos de uso)


Plantilla para requisitos funcionales 37

• Descripción: para los requisitos funcionales, este campo contiene unpatrón–L que debe completarse de forma distinta en función de queel caso de uso sea abstracto o concreto (ver sección 4.4.2, pág. 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 activación que provoca su realización.En versiones anteriores de este patrón–L, aparecían las expresionescaso de uso abstracto y caso de uso concreto. La experiencia durantela utilización de estas plantillas en proyectos reales nos ha llevado aeliminar dichas expresiones, que resultaban difíciles de entender porlos participantes en el proceso de elicitación.

• Precondición: 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 más acciones, o se realiza (se incluye) otro caso de uso. Un pasopuede tener una condición de realización, en cuyo caso si se realizaraotro caso de uso se tendría una relación de extensión. Se asume que,después de realizar el último paso, el caso de uso termina.Otras propuestas similares, por ejemplo [Coleman 1998], proponenutilizar estructuras similares al pseudocódigo para expresar las inte-racciones de los casos de uso. En nuestra opinión, esto puede llevar aque dichas descripciones sean excesivamente complejas de entenderpara los participantes sin conocimientos de programación y se correel peligro de especificar los casos de uso con un estilo cercano a laprogramación.Para representar estructuras condicionales complejas se puede recu-rrir a añadir información aparte, por ejemplo una tabla de decisión,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 artículos de un pedido se puede optar por frasescomo "el sistema procesa todos los artículos del pedido introducidos por elusuario", en lugar de estructuras como:

REPETIRprocesar artículo del pedido introducido por el usuario

HASTA que no haya más artículos



Otro ejemplo puede ser especificar que el usuario puede intentar co-nectarse al sistema un máximo de tres veces. Una posible especifica-ción sería la que puede verse en la figura 14, bastante más natural yfácil de entender que la que puede verse en la figura 15 utilizando lapropuesta descrita en [Coleman 1998].

Secuencia Paso Acciónnormal 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 1–3)hasta un máximo de tres veces

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

Excepciones Paso Acción4 Si el usuario ha intentado tres veces acceder sin éxito, el

sistema rechaza el acceso del usuario, a continuación estecaso de uso termina

Figura 14: Ejemplo de caso de uso de conexión 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 conexión de usuario (Coleman)


Plantilla para requisitos no funcionales 39

• Postcondición: en este campo se expresan en lenguaje natural lascondiciones que se deben cumplir después de la terminación normaldel caso de uso.

• Excepciones: este campo especifica el comportamiento del sistemaen el caso de que se produzca alguna situación excepcional durantela realización de un paso determinado.Después de realizar las acciones o el caso de uso asociados a la ex-cepción (una extensión), el caso de uso puede continuar la secuencianormal o terminar, lo que suele ir acompañado por una cancelaciónde todas las acciones realizadas en el caso de uso dejando al sistemaen el mismo estado que antes de comenzar el caso de uso, asumiendouna semántica transaccional.Inicialmente, la expresión utilizada para indicar una terminación anor-mal del caso de uso como resultado de una excepción era "este casode uso aborta". La experiencia durante su aplicación nos llevó a laconclusión de que el termino abortar resultaba emocionalmente moles-to para algunos participantes [Goleman 1996], por lo que se cambiópor "este caso de uso termina" con el significado comentado anterior-mente.

• Rendimiento: en este campo puede especificarse el tiempo máximopara cada paso en el que el sistema realice un acción.

• Frecuencia esperada: en este campo se indica la frecuencia espera-da de realización del caso de uso, que aunque no es realmente unrequisito, es una información 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 específico de estaplantilla es la descripción, en la que se usa un patrón–L 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 elicitación puede sernecesario resolver mediante algún tipo de negociación posibles conflic-



RNF–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)




. . .Descripción El sistema deberá <capacidad del sistema>Importancia <importancia del requisito>Urgencia <urgencia del requisito>Estado <estado del requisito>Estabilidad <estabilidad del requisito>Comentarios <comentarios adicionales sobre el requisito>

Figura 16: Plantilla y patrones–L para requisitos no funcionales

tos en los requisitos–C 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-mación correspondiente a los requisitos–C, cada conflicto debe po-derse identificar de forma única y tener un nombre descriptivo. Elprefijo propuesto para lograr una rápida identificación es CFL.

• Versión, 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 resolución.

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

• Descripción: este campo debe contener la descripción del conflicto.

• Alternativas: este campo debe contener una lista con las posiblesalternativas de solución que se hayan identificado para solucionar elconflicto así como los autores de dicha alternativas.


Referencias 41

CFL–<id> <nombre descriptivo>Versión <no de la versión actual> (<fecha de la versión actual>)Autores • <autor de la versión actual> (<organización del autor>)


. . .Objs./Reqs.en conflicto

• OBJ/Ryy--x <nombre del objetivo o requisito en conflicto>. . .

Descripción <descripción del conflicto>Alternativas • <descripción alternativa de solución> (<autores alternativa>)

. . .Solución <descripción de la solución adoptada (si se ha acordado)>Importancia <importancia de la resolución del conflicto>Urgencia <urgencia de la resolución del conflicto>Estado <estado del resolución del conflicto>Comentarios <comentarios adicionales sobre el conflicto>

Figura 17: Plantilla para conflictos

• Solución: este campo debe contener la descripción de la soluciónnegociada del conflicto, una vez que se haya acordado.

• Importancia, Urgencia: estos campos indican respectivamente la im-portancia y la urgencia de la resolución del conflicto.

• Estado: este campo indica el estado de resolución del conflicto, quepodrá estar en negociación 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. Addison–Wesley, 1999.

[Brackett 1990] J. W. Brackett. Software Requirements. Curriculum Mo-dule SEI–CM–19–1.2, Software Engineering Institute, Carnegie MellonUniversity, 1990. Disponible en http://www.sei.cmu.edu .

[Cockburn 1997] A. Cockburn. Structuring Use Cases with Goals. Journalof Object–Oriented 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 comunicación no verbal, volumen 616 de El Librode Bolsillo. Alianza Editorial, 1985.

[Durán 2000] A. Durán. Un Entorno Metodológico de Ingeniería de Requisitospara Sistemas de Información. 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 .

[García et al. 2000] J. García, M. J. Ortín, B. Moros, y J. Nicolás. Modeladode Casos de Uso y Conceptual a partir del Modelado del Negocio. EnActas de las V Jornadas de Trabajo Menhir, Granada, 2000.

[García 2000] F. J. García. Modelo de Reutilización Soportado por EstructurasComplejas de Reutilización 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. También aparece en [Thayer y Dorfman1997]. Disponible en http://www.cse.ucsd.edu/˜goguen .

[Goleman 1996] D. Goleman. La Inteligencia Emocional. Kairós, 1996.

[Goleman 1999] D. Goleman. La Práctica de la Inteligencia Emocional. Kai-rós, 1999.


Referencias 43

[IBM OOTC 1997] IBM OOTC. Developing Object–Oriented Software. IBMObject–Oriented Technology Center. Prentice–Hall, 1997.

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

[Jacobson et al. 1993] I. Jacobson, M. Christerson, P. Jonsson, y G. Över-gaard. Object–Oriented Software Engineering: A Use Case Driven Approach.Addison–Wesley, 4a edición, 1993.

[Jacobson et al. 1997] I. Jacobson, M. Griss, y P. Jonsson. Software Reuse: Ar-chitecture, Process and Organization for Business Success. Addison–Wesley,1997.

[Laguna et al. 1999] M. A. Laguna, J. M. Marqués, y F. J. García. Una He-rramienta para la Captura de Requisitos de Usuario. En Actas de lasJISBD’99, Cáceres, 1999.

[MAP 1995] MAP. Metodología de Planificación y Desarrollo de Sistemas deInformación. MÉTRICA Versión 2.1. Tecnos/Ministerio para las Admi-nistraciones Públicas, 1995.

[Piattini et al. 1996] M. G. Piattini, J. A. Calvo-Manzano, J. Cervera, yL. Fernández. Análisis y Diseño Detallado de Aplicaciones Informáticas deGestión. ra–ma, 1996.

[Raghavan et al. 1994] S. Raghavan, G. Zelesnik, y G. Ford. Lecture Noteson Requirements Elicitation. Educational Materials CMU/SEI–94–EM–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 theRequirement Process. Addison–Wesley, 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 Técnico Versión 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. Addison–Wesley, 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 edición,1997. Es la 2a edición 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):34–45, Marzo/Abril 1998. Es-te artículo aparece también en las actas del ICRE’98 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 Object–Oriented Software. Prentice–Hall, 1990.


Ejemplo: gestión de un vídeo–club 45

A Ejemplo: gestión de un vídeo–club

En este apéndice se ofrecen algunos ejemplos de aplicación de las técni-cas propuestas en esta metodología suponiendo el caso de la gestión depequeño vídeo–club.

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

El ejemplo no es una especificación de requisitos completa, se incluyesólo a modo de ejemplo.

A.1 Objetivos del sistema

OBJ–01 Gestionar las cintas y películasDescripción El sistema deberá gestionar las cintas y películas disponibles en el

vídeo club: adquisiciones, retiradas, disponibilidad, etc.Estabilidad altaComentarios ninguno

OBJ–02 Gestionar los sociosDescripción El sistema deberá gestionar las socios del vídeo–club: altas, bajas,

modificaciones de datos, sanciones, personas autorizadas, cuentas,etc.

Estabilidad altaComentarios ninguno

OBJ–02 Gestionar los alquileresDescripción El sistema deberá gestionar los alquileres de cintas: entregas, devolu-

ciones, devoluciones tardías, reclamaciones, disponibilidad, etc.Estabilidad altaComentarios ninguno



A.2 Requisitos de almacenamiento de información

RI–01 Información sobre películasObjetivos asociados • OBJ–01 Gestionar las películas y cintasRequisitos asociados • RF–04 Alta de película

• RF–05 Alta de cinta de vídeo• RF–08 Baja de cinta de vídeo• RF–10 Consulta de película• RF–13 Consulta de películas alquiladas un día determinado

Descripción El sistema deberá almacenar la información correspondientea las películas del vídeo–club. En concreto:

Datos específicos • Título de la película• Cintas de la película alquiladas en cada momento• Cintas de la película disponibles para ser alquiladas en cada

momento• Tipo de la película: infantil, acción, ciencia-ficción o adultos• Duración de la película, en horas y minutos• Actores principales de la película• Director de la película• Productora de la película• Año de producción de la película

Intervalo temporal pasado y presenteEstabilidad altaComentarios ninguno


Requisitos de almacenamiento de información 47

RI–02 Información sobre sociosObjetivos asociados • OBJ–02 Gestionar los sociosRequisitos asociados • RF–01 Alta de socio

• RF–02 Baja de socio• RF–03 Modificación de datos de un socio• RF–11 Consulta de un socio• RF–12 Consulta de socios con pagos pendientes• RF–12 Consulta de los socios más rentables• RF–15 Identificación de socio

Descripción El sistema deberá almacenar la información correspondientea los socios del vídeo–club. En concreto:

Datos específicos • Número de socio, que deberá ser único para cada socio• Número del documento nacional de identidad• Nombre y apellidos• Fecha de nacimiento• Sexo• Fecha de alta como socio• Dirección• Teléfonos• Películas alquiladas en un momento dado

Intervalo temporal sólo presenteEstabilidad altaComentarios ninguno

RI–03 Información sobre cuentas de sociosObjetivos asociados • OBJ–02 Gestionar los sociosRequisitos asociados • RF–01 Alta de socio

• RF–02 Baja de socio• RF–05 Alquiler de cinta de vídeo• RF–08 Devolución de cintas de vídeo• RF–09 Ingreso a cuenta• RF–11 Consulta de un socio• RF–12 Consulta de socios con pagos pendientes

Descripción El sistema deberá almacenar la información correspondientea las cuentas de los socios del vídeo–club. En concreto:

Datos específicos • 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 debeindicar también la película alquilada y la fecha del alquiler

Intervalo temporal sólo presenteEstabilidad altaComentarios Un socio puede hacer ingresos a cuenta, por ejemplo para

enviar a sus hijos por películas sin que éstos tengan que lle-var dinero



A.3 Requisitos funcionales

A.3.1 Diagramas de casos de uso

<<subsistema>>Gestión de

Socios

<<subsistema>>Gestión dePelículas

<<subsistema>>Gestión deAlquileres

Figura 18: Diagrama de subsistemas

<<includes>>

Baja de socio (RF-02)

Consulta de un socio (RF-11)

Consulta de socios con pagospendientes (RF-12)

Empleado delvídeo-club

Socio

Alta de socio (RF-01)

<<includes>>

Modificación de los datosde un socio (RF-03)

Identificaciónde socio (RF-15)

Figura 19: Diagrama de casos de uso del subsistema Gestión de socios


Requisitos funcionales 49

<<extends>>

Consulta de película (RF-10)


Alta de cinta de vídeo (RF-05)

Baja de cinta de vídeo (RF-08)

Alta de película (RF-04)

Figura 20: Diagrama de casos de uso del subsistema Gestión de películas



<<includes>>

Consulta de los socios másrentables (RF-14)


Socio

Ingreso a cuenta (RF-09)

Identificaciónde socio (RF-15)

Alquiler de cinta de vídeo(RF-06)

Devolución de cintas de vídeo(RF-08)

Consulta de películas alquiladasun día determinado (RF-13)

Figura 21: Diagrama de casos de uso del subsistema Gestión de alquileres



A.3.2 Definición de actores

ACT–01 SocioDescripción Este actor representa a los socios del vídeo–clubComentarios ninguno

ACT–02 Empleado del vídeo–clubDescripción Este actor representa a los empleados del vídeo–clubComentarios ninguno

A.3.3 Casos de uso del sistema

(ver páginas siguientes)



A.3.3.1 Casos de uso del subsistema Gestión de socios

RF–01 Alta de socioObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre sociosDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando alguien solicite su ingreso comosocio

Precondición El solicitante no es un socio del vídeo–club y tiene su docu-mentación disponible

Secuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de alta de un nuevo socio2 El sistema solicita los siguientes datos del nuevo socio:

no del DNI, nombre, apellidos, fecha de nacimiento,sexo, dirección y teléfonos de contacto

3 El empleado del vídeo–club solicita los datos requeri-dos y la documentación al nuevo socio

4 El empleado del vídeo–club comprueba que los datosdel nuevo socio coinciden con los de la documentaciónaportada

5 El empleado del vídeo–club proporciona los datos re-queridos y solicita al sistema que los almacene

6 El sistema almacena los datos proporcionados, impri-me el carnet de socio e informa al empleado del vídeo–club de que el proceso ha terminado con éxito

7 El empleado del vídeo–club entrega el carnet al nuevosocio

Postcondición El solicitante es socio del vídeo–club y el saldo de su cuenta es0

Excepciones Paso Acción4 Si la documentación aportada no es correcta, el em-

pleado del vídeo–club cancela la operación, a conti-nuación este caso de uso termina

5 Si el sistema detecta que el nuevo socio ya es sociodel vídeo–club, el sistema informa de la situación alempleado del vídeo–club permitiéndole modificar losdatos proporcionados, a continuación este caso de usocontinúa

5 Si el empleado del vídeo–club solicita cancelar la ope-ración, el sistema cancela la operación, a continuacióneste caso de uso termina

Rendimiento Paso Cota de tiempo4 5 segundos

Frecuencia esperada 10 veces/díaEstabilidad altaComentarios La frecuencia será mucho mayor durante los dos primeros me-

ses, probablemente 100 veces/día



RF–02 Baja de socioObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre sociosDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando un socio solicite su bajaPrecondición El solicitante es un socio del vídeo–club y tiene su documenta-

ción disponibleSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de baja de un socio2 Se realiza el caso de uso RF–15 (Identificación de socio)3 El empleado del vídeo–club solicita al sistema que eli-

mine la información correspondiente al socio4 El sistema elimina los datos correspondientes al socio e

informa al empleado del vídeo–club de que el procesoha terminado con éxito

4 El empleado del vídeo–club inhabilita el carnet al socioque se acaba de dar de baja

Postcondición El solicitante no es socio del vídeo–clubExcepciones Paso Acción

3 Si el socio tiene pagos pendientes, el sistema el siste-ma comunica la situación al empleado del vídeo–cluby cancela la operación, a continuación este caso de usotermina

3 Si el empleado del vídeo–club solicita cancelar la ope-ración, el sistema el sistema cancela la operación, acontinuación este caso de uso termina

Rendimiento Paso Cota de tiempo6 1 segundo

Frecuencia esperada 1 vez/mesEstabilidad altaComentarios Si el socio que desea darse de baja tiene un pago pendiente,

puede hacer un ingreso por su importe y repetir el proceso dedarse de baja



RF–03 Modificación de los datos de un socioObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre sociosDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando un socio solicite la modificaciónde sus datos

Precondición El solicitante es un socio del vídeo–club y tiene su documenta-ción disponible


zar el proceso de modificación de los datos de un deun socio

2 Se realiza el caso de uso RF–15 (Identificación de socio)3 El sistema muestra los siguientes datos correspondien-

tes al socio a modificar: no del DNI, nombre, apelli-dos, fecha de nacimiento, sexo, dirección y teléfonosde contacto

4 El sistema permite al empleado del vídeo–club modi-ficar los siguientes datos: dirección y teléfonos de con-tacto

5 El empleado del vídeo–club modifica los datos que elsistema le permite y solicita al sistema que los almace-ne

6 El sistema modifica los datos correspondientes al socioe informa al empleado del vídeo–club de que el proce-so ha terminado con éxito

7 Si algún dato modificado aparece en el carnet de socio,el sistema imprime un nuevo carnet de socio

8 Si fue necesario imprimir un nuevo carnet de socio, elempleado del vídeo–club entrega el nuevo carnet al so-cio e inhabilita el antiguo

Postcondición La información del socio está actualizadaExcepciones Paso Acción

5 Si el empleado del vídeo–club solicita cancelar la ope-ración, el sistema el sistema cancela la operación, acontinuación este caso de uso termina


Frecuencia esperada 1 vez/mesComentarios ninguno



RF–11 Consulta de un socioObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre sociosDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando el empleado del vídeo–club lo con-sidere oportuno

Precondición NingunaSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de consulta de los datos de un socio2 El sistema solicita que se identifique al socio3 El empleado del vídeo–club proporciona los datos de

identificación al sistema4 El sistema muestra la siguiente información asociada

al socio: nombre, apellidos, dirección, números de te-léfono, alquileres pendientes y saldo de su cuenta

5 Si el empleado del vídeo–club solicita la impresión delos datos, el sistema imprime los datos del socio

Postcondición NingunaExcepciones Paso Acción


5 Si el sistema no tiene registrado ningún socio con laidentificación proporcionada, el sistema comunica alempleado del vídeo–club la situación, a continuacióneste caso de uso termina


Frecuencia esperada 5 veces/díaComentarios El formato de visualización de los datos está pendiente de de-

finición



RF–12 Consulta de socios con pagos pendientesObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre socios

• RI–03 Información sobre cuentas de sociosDescripción El sistema deberá comportarse tal como se describe en el si-



zar el proceso de consulta de los socios con pagos pen-dientes

2 El sistema muestra una lista ordenada por cantidadpendiente con la siguiente información por cada socio:nombre, apellidos, cantidad total pendiente y detallede las cantidades pendientes

3 Si el empleado del vídeo–club solicita la impresión delos datos, el sistema imprime la lista


– –Rendimiento Paso Cota de tiempo

2 5 segundosFrecuencia esperada 1 vez/semanaComentarios ninguno



RF–15 Identificación de socioObjetivos asociados • OBJ–02 Gestionar las sociosRequisitos asociados • RI–02 Información sobre sociosDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso durante la realización de los casos de uso:• RF–02 Baja de socio• RF–03 Modificación de datos de un socio• RF–06 Alquiler de cintas de vídeo

Precondición El socio tiene su documentación disponibleSecuencia Paso Acciónnormal 1 El sistema solicita que se identifique al socio

2 El empleado del vídeo–club solicita el carnet de socio3 El empleado del vídeo–club proporciona los datos de

identificación al sistema4 El sistema muestra los números de teléfonos que el so-

cio proporcionó cuando se dio de alta5 El empleado del vídeo–club solicita al socio que le con-

firme alguno de los números de teléfono registrados enel sistema

6 El empleado del vídeo–club confirma la identidad delsocio al sistema


3 Si el sistema detecta que el supuesto socio no es so-cio del vídeo–club, el sistema comunica al empleadodel vídeo–club la situación, a continuación este casode uso aborta

5 Si el socio no conoce ningún número de teléfono regis-trado en el sistema y no puede demostrar su identidad,el empleado del vídeo–club retiene el carnet de socio ycancela la operación, a continuación este caso de usoaborta

5 Si el socio no conoce ningún número de teléfono re-gistrado pero puede demostrar su identidad por otrosmedios, el empleado del vídeo–club le recuerda los nú-meros de teléfonos que proporcionó cuando se dio dealta, a continuación este caso de uso continúa

Rendimiento Paso Cota de tiempo– –

Frecuencia esperada 50 veces/díaComentarios ninguno



A.3.3.2 Casos de uso del subsistema Gestión de películas

RF–04 Alta de películaObjetivos asociados • OBJ–01 Gestionar las cintas y películasRequisitos asociados • RI–01 Información sobre películas

• RF–05 Alta de cinta de vídeoDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando se adquiera una cinta de una pelí-cula nueva

Precondición La película no está registrada en el sistemaSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de alta de película2 El sistema solicita los siguientes datos de la nueva pe-

lícula: título, tipo de película, duración, actores princi-pales, director, productora y año de producción

3 El empleado del vídeo–club proporciona los datos re-queridos y solicita al sistema que los almacene

4 El sistema almacena los datos proporcionados e infor-ma al empleado del vídeo–club de que el proceso haterminado con éxito

Postcondición El sistema ha almacenado la información correspondiente a lanueva película

Excepciones Paso Acción4 Si el sistema detecta que la película ya está registra-

da, el sistema informa de la situación al empleado delvídeo–club permitiéndole modificar los datos propor-cionados, a continuación este caso de uso continúa

4 Si el empleado del vídeo–club solicita cancelar la ope-ración, el sistema cancela la operación, a continuacióneste caso de uso se cancela


Frecuencia esperada 1 vez/díaComentarios ninguno



RF–05 Alta de cinta de vídeoObjetivos asociados • OBJ–01 Gestionar las cintas y películasRequisitos asociados • RI–01 Información sobre películasDescripción El sistema deberá comportarse tal como se describe en el si-

guiente caso de uso cuando se adquieran nuevas cintas de unapelícula


zar el proceso de alta de cinta2 El sistema solicita que se identifique la película que

contiene la cinta3 El empleado del vídeo–club identifica la película4 Si la película no está registrada, se realiza el caso de

uso RF–04 (Alta de película)5 El sistema solicita el número de cintas de la película a

dar de alta6 El empleado del vídeo–club proporciona el número de

cintas y solicita al sistema que almacene la información7 El sistema almacena los datos proporcionados, impri-

me la etiquetas de identificación de cintas autoadhe-sivas e informa al empleado del vídeo–club de que elproceso ha terminado con éxito

8 El empleado del vídeo–club pega las etiquetas en lascintas y las coloca en las estanterías

Postcondición Las cintas están registradas en el sistemaExcepciones Paso Acción






RF–08 Baja de cinta de vídeoObjetivos asociados • OBJ–01 Gestionar las cintas y películasRequisitos asociados • RI–01 Información sobre películasDescripción El sistema deberá comportarse tal como se describe en el si-


Precondición La cinta está registrada en el sistemaSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de baja de cinta de vídeo2 El sistema solicita que se identifique la cinta a dar de

baja3 El empleado del vídeo–club identifica la cinta a elimi-

nar y solicita al sistema que la dé de baja4 El sistema registra la baja de la cinta e informa al em-

pleado del vídeo–club de que el proceso ha terminadocon éxito

5 El empleado del vídeo–club elimina la cinta de las es-tanterías

Postcondición La cinta no está registrada en el sistemaExcepciones Paso Acción

3 Si el sistema no tiene registrada ninguna cinta con laidentificación proporcionada, el sistema comunica alempleado del vídeo–club la situación, a continuacióneste caso de uso termina



Frecuencia esperada 1 vez/mesComentarios ninguno



RF–10 Consulta de una películaObjetivos asociados • OBJ–01 Gestionar las cintas y películasRequisitos asociados • RI–01 Información sobre películasDescripción El sistema deberá comportarse tal como se describe en el si-



zar el proceso de consulta de los datos de una película2 El sistema solicita que se identifique la película a con-

sultar3 El empleado del vídeo–club identifica la película a con-

sultar4 El sistema muestra los siguientes datos correspondien-

tes a la película: título, tema, año de producción, acto-res principales, nombre de la productora y número decintas disponibles

5 Si el empleado del vídeo–club solicita la impresión delos datos, el sistema imprime los datos de la película

Postcondición La información correspondiente a la película consultada no hacambiado

Excepciones Paso Acción3 Si el empleado del vídeo–club solicita cancelar la ope-

ración, el sistema cancela la operación, a continuacióneste caso de uso termina





A.3.3.3 Casos de uso del subsistema Gestión de alquileres

RF–06 Alquiler de cintas de vídeoObjetivos asociados • OBJ–03 Gestionar los alquileresRequisitos asociados • RI–02 Información sobre socios


guiente caso de uso cuando un socio solicite alquilar una omás cintas de vídeo

Precondición Ninguna de las cintas a alquilar está registradas como alquila-das


zar el proceso de alquiler de cintas de vídeo2 Se realiza el caso de uso RF–15 (Identificación de socio)2 El sistema solicita que se identifiquen las cintas que

desean alquilar3 El empleado del vídeo–club identifica las cintas y soli-

cita al sistema que registre el alquiler4 El sistema almacena la información de los alquileres y

comunica al empleado del vídeo–club que el procesode registro ha terminado con éxito

5 Si el socio decide pagar al contado, el sistema imprimeel ticket con el importe correspondiente y registra elpago como un ingreso en la cuenta del socio

6 Si el socio decide pagar a cuenta, el sistema registra elcargo en la cuenta del socio

Postcondición Las cintas a alquilar están registradas como alquiladas y lacuenta del socio está actualizada

Excepciones Paso Acción3 Si alguna de las cintas está registrada como alquila-

da, el sistema comunicar la situación al empleado delvídeo–club y excluir la cinta del alquiler, a continua-ción este caso de uso continúa






RF–07 Devolución de cintas de vídeoObjetivos asociados • OBJ–03 Gestionar los alquileresRequisitos asociados • RI–02 Información sobre socios


guiente caso de uso cuando un socio solicite devolver una omás cintas de vídeo

Precondición Todas las cintas a devolver están registradas como alquiladasSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de devolución de cintas de vídeo2 El sistema solicita que se identifiquen las cintas que se

desean devolver3 El empleado del vídeo–club identifica las cintas y soli-

cita al sistema que registre su devolución4 El sistema registra los devoluciones5 Si alguna cinta ha sido devuelta fuera de plazo, el sis-

tema registra la multa correspondiente como un cargoen la cuenta del socio

6 Si el socio decide pagar al contado, el sistema imprimeel ticket con el importe correspondiente y registra elpago como un ingreso en la cuenta del socio

7 Si el socio decide pagar a cuenta, el sistema registra elcargo en la cuenta del socio

Postcondición Las cintas a alquilar están registradas como alquiladas y lacuenta del socio está actualizada

Excepciones Paso Acción4 Si alguna de las cintas está registrada como alquila-

da, el sistema comunicar la situación al empleado delvídeo–club y excluir la cinta del alquiler, a continua-ción este caso de uso continúa





RF–09 Ingreso a cuentaObjetivos asociados • OBJ–03 Gestionar los alquileresRequisitos asociados • RI–02 Información sobre socios


guiente caso de uso cuando un socio solicite hacer un ingresoen su cuenta

Precondición El socio tiene disponible su carnetSecuencia Paso Acciónnormal 1 El empleado del vídeo–club solicita al sistema comen-

zar el proceso de ingreso en cuenta2 El sistema solicita que se identifique al socio y se indi-

que la cantidad a ingresar3 El empleado del vídeo–club proporciona al sistema la

identificación del socio y la cantidad a ingresar4 El sistema registra el ingreso e informa del nuevo saldo3 El empleado del vídeo–club comunica al socio su nue-

vo saldoPostcondición El saldo de la cuenta del socio está actualizadoExcepciones Paso Acción



Frecuencia esperada 5 veces/díaComentarios Mientras no se implemente se puede hacer que todos los pagos

sean al contado



RF–13 Consulta de las películas alquiladas un día determinadoObjetivos asociados • OBJ–03 Gestionar los alquileresRequisitos asociados • RI–01 Información sobre películasDescripción El sistema deberá comportarse tal como se describe en el si-



zar el proceso de consulta de las películas alquiladasun día determinado

2 El sistema solicita la fecha del día que se quiere con-sultar, proponiendo la del día actual

3 El empleado del vídeo–club proporciona la fecha deldía determinado al sistema

4 El sistema muestra una lista ordenada por número dealquileres con la siguiente información: título y temade cada película y número de alquileres en el día de-terminado


Postcondición La información sobre las películas no ha cambiadoExcepciones Paso Acción



Frecuencia esperada 1 vez/díaImportancia importanteUrgencia hay presiónComentarios ninguno



RF–14 Consulta de los socios más rentablesObjetivos asociados • OBJ–03 Gestionar los alquileresRequisitos asociados • RI–01 Información sobre películasDescripción El sistema deberá comportarse tal como se describe en el si-



zar el proceso de consulta de los socios más rentables2 El sistema solicita el periodo de selección: última se-

mana, último mes, último año o siempre3 El empleado del vídeo–club proporciona el periodo de

selección al sistema4 El sistema muestra una lista ordenada por cantidad de

alquileres realizados con la siguiente información: nú-mero de socio, nombre, apellidos, teléfono y númerode alquileres realizados en el periodo indicado


Postcondición La información sobre los socios no ha cambiadoExcepciones Paso Acción



Frecuencia esperada 1 vez/díaComentarios Si el periodo es siempre, el tiempo de respuesta puede ser muy

alto


Requisitos no funcionales 67

A.4 Requisitos no funcionales

RNF–01 Copias de seguridadObjetivos asociados –Requisitos asociados –Descripción El sistema deberá incorporar algún mecanismo que permita

realizar copias de seguridad de los datos almacenadosComentarios ninguno

RNF–02 Entorno de explotaciónObjetivos asociados –Requisitos asociados –Descripción El sistema deberá deberá funcionar en un entorno de 2 PC’s

Pentium con 16 Mbytes de RAM y 2 GBytes de disco duroconectados en red con sistema operativo Microsoft Windows98

Comentarios ninguno

RNF–03 PortabilidadObjetivos asociados –Requisitos asociados –Descripción El sistema deberá ser fácilmente portable al sistema operativo

Microsoft Windows 2000Comentarios ninguno



Está página está intencionalmente en blanco


Documents

Metodología REM