Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Metodología para La Elicitación
Metodología para La Elicitación
Lista de cambios
Nm.
0
Fecha
13/10/1998
04/11/1998
04/11/1998
04/11/1998
04/11/1998
5
6
04/11/1998
18/10/1999
7
8
18/10/1999
18/10/2000
18/10/1999
Descripcin
Versin 1.0
[pg. 18] En el apartado de importancia de la plantilla general de
requisitos del sistema, donde apareca En este apartado se indica la
importancia que tiene el caso de uso para el clienteaparece ahora En este
apartado se indica la importancia que tiene el requisito para el cliente"
[pg. 18] En el apartado de urgencia de la plantilla general de requisitos del sistema, donde apareca . . . incluyendo la funcionalidad
expresada en el caso de usoaparece ahora . . . incluyendo las capacidades
expresadas en el requisito"
[pg. 23] En la descripcin de la relacin extends entre casos de
uso, donde apareca En cierta forma, B completa la funcionalidad de
Aaparece ahora En cierta forma, A completa la funcionalidad de B"
[pgs. 3, 6, 8, 15, 16, 17, 18, 19, 22, 23, 24, 26, 27, 30] Correcciones
ortogrficas diversas
Versin 1.1
En la versin 2.0 se han introducido numerosos cambios, los principales son los siguientes:
El ttulo cambia de Norma para la Recoleccin de Requisitos de un Sistema Software a Metodologa para la Elicitacin de Requisitos de Sistemas
Software
La primera seccin del documento pasa de denominarse Objetivo y
alcance a Objetivo de la metodologa
Se han eliminado de la tarea 1 las referencias relativas a la construccin de modelos de anlisis del dominio
En la tarea 2 se habla de reuniones en lugar de hacerlo especficamente de entrevistas
Se ha aadido la tarea 3 Identificar los objetivos del sistema como tarea
previa a la identificacin de los requisitos y se ha diseado una
plantilla especfica para los objetivos
Se han cambiado todas las apariciones de otros requisitos por requisitos no funcionales
Se ha cambiado el contenido de las secciones Introduccin y Objetivos del sistema del DRS
Se han aadido al DRS las secciones Participantes en el proyecto y
Matriz de rastreabilidad
Se ha contemplado la posibilidad de organizar los requisitos de forma que no sean una lista plana
Se han aadido las descripciones de las tcnicas de JAD y brainstorming
Se ha reescrito la descripcin de la tcnica de los casos de uso
Se ha cambiado el nombre de la relacin uses entre casos de uso a
includes para adaptar la notacin a UML
Se han aadido plantillas especficas para objetivos y actores
Se han aadido nuevos campos y patronesL a todas las plantillas,
introduciendo el concepto de patrn lingstico
Se han eliminado los subpasos de la plantilla para requisitos funcionales (casos de uso)
Se ha reescrito la mayor parte del ejemplo de aplicacin de la metodologa
Versin 2.0
En la versin 2.1 se han introducido algunos cambios realizados
durante la elaboracin de la tesis doctoral de A. Durn [Durn
2000].
Versin 2.1
Autor/es
A. Durn y B.
Bernrdez
A. Durn
A. Durn
A. Durn
A. Durn
A. Durn
A. Durn
A. Durn
A. Durn
A. Durn
ndice General
1 Objetivo de la metodologa
Tareas recomendadas
2.1
2.2
2.3
2.4
2.1.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.1.4
Productos entregables . . . . . . . . . . . . . . . . . .
2.1.5
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
2.2.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.2.4
Productos entregables . . . . . . . . . . . . . . . . . .
2.2.5
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
2.3.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.3.4
Productos entregables . . . . . . . . . . . . . . . . . .
2.3.5
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
2.4.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.4.4
Productos entregables . . . . . . . . . . . . . . . . . .
2.4.5
2.5
2.6
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
2.5.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.5.4
Productos entregables . . . . . . . . . . . . . . . . . .
2.5.5
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
2.6.1
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2
Descripcin . . . . . . . . . . . . . . . . . . . . . . . .
2.6.3
Productos internos . . . . . . . . . . . . . . . . . . . .
2.6.4
Productos entregables . . . . . . . . . . . . . . . . . .
10
2.6.5
Tcnicas recomendadas . . . . . . . . . . . . . . . . .
10
3 Productos entregables
3.1
10
10
3.1.1
Portada . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.2
Lista de cambios . . . . . . . . . . . . . . . . . . . . .
12
3.1.3
ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.4
13
3.1.5
Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.6
Participantes en el proyecto . . . . . . . . . . . . . . .
13
3.1.7
13
3.1.8
14
3.1.9
14
14
14
14
14
15
ii
15
15
15
16
3.1.19 Apndices . . . . . . . . . . . . . . . . . . . . . . . . .
16
Tcnicas
16
4.1
Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.1.1
Preparacin de entrevistas . . . . . . . . . . . . . . . .
17
4.1.2
Realizacin de entrevistas . . . . . . . . . . . . . . . .
18
4.1.3
19
20
4.2.1
20
4.2.2
21
Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.1
24
Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.4.1
27
4.4.2
27
4.4.3
28
4.2
4.3
4.4
29
5.1
30
5.2
33
5.3
34
5.4
35
5.5
39
5.6
39
45
45
46
48
48
51
51
67
iv
ndice de Figuras
1
11
12
12
15
26
28
29
30
10
31
11
33
12
35
13
36
14
38
15
38
16
40
17
41
18
Diagrama de subsistemas . . . . . . . . . . . . . . . . . . . .
48
19
48
20
21
50
vi
Objetivo de la metodologa
1 Objetivo de la metodologa
El objetivo de esta metodologa es la definicin de las tareas a realizar,
los productos a obtener y las tcnicas a emplear durante la actividad de
elicitacin de requisitos de la fase de ingeniera de requisitos del desarrollo de
software.
En esta metodologa se distinguen dos tipos de productos: los productos entregables y los productos no entregables o internos. Los productos entregables son aquellos que se entregan oficialmente al cliente como parte
del desarrollo en fechas previamente acordadas, mientras que los no entregables son productos internos al desarrollo que no se entregan al cliente.
El nico producto entregable definido en esta metodologa es el Documento de Requisitos del Sistema (DRS), definido en la seccin 3.1, pg. 10.
La estructura de este documento es la siguiente: en la seccin 2 se describen las tareas recomendadas, en la seccin 3 se definen los productos
entregables, en este caso el DRS, y por ltimo, en la seccin 4 se describen
algunas de las tcnicas recomendadas para obtener los productos. Tambin se incluye como apndice un ejemplo de aplicacin de esta metodologa.
2 Tareas recomendadas
Las tareas recomendadas para obtener los productos descritos en esta metodologa son las siguientes:
Tarea 1: Obtener informacin sobre el dominio del problema y el sistema
actual.
Tarea 2: Preparar y realizar las reuniones de elicitacin/negociacin.
Tarea 3: Identificar/revisar los objetivos del sistema.
Tarea 4: Identificar/revisar los requisitos de almacenamiento de informacin.
Tarea 5: Identificar/revisar los requisitos funcionales.
Tarea 6: Identificar/revisar los requisitos no funcionales.
Tarea 7: Priorizar objetivos y requisitos.
A. Durn, B. Bernrdez
El orden recomendado de realizacin para estas tareas es: 1. . . 7, aunque las tareas 4, 5, y 6 pueden realizarse simultneamente o en cualquier
orden que se considere oportuno (ver figura 1). La tarea 1 es opcional y
depende del conocimiento previo que tenga el equipo de desarrollo sobre
el dominio del problema y el sistema actual.
Elicitacin
Elicitacinde
deRequisitos
Requisitos
Obtener
Obtener
informacin sobre
informacin sobre
el dominio del
el dominio del
problema y el
problema y el
sistema actual
sistema actual
Preparar y
Preparar y
realizar las
realizar las
sesiones de
sesiones de
elicitacin/
elicitacin/
negociacin
negociacin
Identificar/
Identificar/
revisar los
revisar los
objetivos
objetivos
del sistema
del sistema
Identificar/
Identificar/
revisar los
revisar los
requisitos
requisitos
de
de
informacin
informacin
Identificar/
Identificar/
revisar los
revisar los
requisitos
requisitos
funcionales
funcionales
Identificar/
Identificar/
revisar los
revisar los
requisitos
requisitos
no
no
funcionales
funcionales
Priorizar
Priorizar
objetivos y
objetivos y
requisitos
requisitos
2.1
2.1.1 Objetivos
Conocer el dominio del problema.
Conocer la situacin actual.
2.1.2
Descripcin
Productos internos
Informacin recopilada: libros, artculos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc.
Modelos del sistema actual.
2.1.4 Productos entregables
Introduccin, participantes en el proyecto, principalmente clientes y
desarrolladores, y descripcin del sistema actual como parte del DRS
(ver secciones 3.1.53.1.7, pgs. 1313).
A. Durn, B. Bernrdez
2.2.3
Productos internos
Notas tomadas durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o vdeo de las reuniones o
cualquier otra documentacin que se considere oportuna.
2.2.4
Productos entregables
Tcnicas recomendadas
Objetivos
Descripcin
de los conflictos identificados. Puede que los objetivos hayan sido proporcionados antes de comenzar el desarrollo.
2.3.3
Productos internos
Tcnicas recomendadas
Objetivos
Identificar los requisitos de almacenamiento de informacin que deber cumplir el sistema software a desarrollar.
Revisar, en el caso de que haya conflictos, los requisitos de almacenamiento de informacin previamente identificados.
2.4.2 Descripcin
A partir de la informacin obtenida en la tareas 1 y 2, y teniendo en cuenta
los objetivos identificados en la tarea 3 y el resto de los requisitos, en esta
tarea se debe identificar, o revisar si existen conflictos, qu informacin
relevante para el cliente deber gestionar y almacenar el sistema software
a desarrollar.
Inicialmente se partirn de conceptos generales para posteriormente ir
detallndolos hasta obtener todos los datos relevantes.
Dpto. de Lenguajes y Sistemas Informticos
2.4.3
Productos internos
Productos entregables
Objetivos
uso con las posibles excepciones hasta definir todas las situaciones posibles.
2.5.3
Productos internos
Objetivos
Descripcin
10
Tcnicas recomendadas
3 Productos entregables
El nico producto entregable que se contempla en esta metodologa es el
Documento de Requisitos del Sistema (DRS).
3.1
La estructura del DRS puede verse en la figura 2. En las siguientes secciones se describe con detalle cada seccin del DRS.
3.1.1
Portada
La portada del DRS debe tener el formato que puede verse en la figura 3.
Los elementos que deben aparecer son los siguientes:
Nombre del proyecto: el nombre del proyecto al que pertenece el
DRS.
Versin: la versin del DRS que se entrega al cliente. La versin se
compone de dos nmeros X e Y . El primero indica la versin, y se
debe incrementar cada vez que se hace una nueva entrega formal
al cliente. Cuando se incremente el primer nmero, el segundo debe volver a comenzar en cero. El segundo nmero indica cambios
dentro de la misma versin an no entregada, y se debe incrementar
cada vez que se publica una versin con cambios respecto a la ltima que se public y que no se vaya a entregar formalmente todava.
Este tipo de versiones pueden ser internas al equipo de desarrollo o
ser entregadas al cliente a ttulo orientativo.
Dpto. de Lenguajes y Sistemas Informticos
11
Portada
Lista de cambios
ndice
Lista de figuras
Lista de tablas
1 Introduccin
2 Participantes en el proyecto
3 Descripcin del sistema actual [opcional]
4 Objetivos del sistema
5 Catlogo de requisitos del sistema
5.1 Requisitos de almacenamiento de informacin
5.2 Requisitos funcionales
5.2.1 Diagramas de casos de uso
5.2.2 Definicin de actores
5.2.3 Casos de uso del sistema
5.3 Requisitos no funcionales
6 Matriz de rastreabilidad objetivos/requisitos
7 Conflictos pendientes de resolucin [opcional, pueden ir
en un documento aparte]
8 Glosario de trminos [opcional]
Apndices [opcionales]
A. Durn, B. Bernrdez
12
Documento de
Requisitos del Sistema
Versin X.Y
Fecha fecha
Lista de cambios
Fecha
fecha0
fecha1
..
.
.
..
fechan
Descripcin
Versin x.y
descripcin cambio1
Autores
autor0
autor1
...
descripcin cambion
..
.
autorn
3.1.3
13
ndice
El ndice del DRS debe indicar la pgina en la que comienza cada seccin,
subseccin o apartado del documento. En la medida de lo posible, se sangrarn las entradas del ndice para ayudar a comprender la estructura del
documento.
3.1.4
El DRS deber incluir listas de las figuras y tablas que aparezcan en el mismo. Dichas listas sern dos ndices que indicarn el nmero, la descripcin
y la pgina en que aparece cada figura o tabla del DRS.
3.1.5
Introduccin
Esta seccin debe contener una descripcin breve de las principales caractersticas del sistema software que se va a desarrollar, la situacin actual que genera la necesidad del nuevo desarrollo, la problemtica que se
acomete, y cualquier otra consideracin que site al posible lector en el
contexto oportuno para comprender el resto del documento.
3.1.6
Participantes en el proyecto
Esta seccin debe contener una lista con todos los participantes en el proyecto, tanto desarrolladores como clientes y usuarios. Para cada participante se deber indicar su nombre, el papel que desempea en el proyecto,
la organizacin a la que pertenece y cualquier otra informacin adicional
que se considere oportuna.
3.1.7
Esta seccin debe contener una descripcin del sistema actual en el caso
de que se haya acometido su estudio. Para describir el sistema actual puede utilizarse cualquier tcnica que se considere oportuno, por ejemplo las
descritas en [Laguna et al. 1999] (Diagrama DocumentosTarea, DDT) o en
[Garca et al. 2000] (Diagramas de Actividad, tambin descritos en [Booch et
al. 1999]).
A. Durn, B. Bernrdez
14
Esta seccin se divide en las siguientes subsecciones en las que se describen los requisitos del sistema. Cada uno de los grandes grupos de requisitos, de almacenamiento de informacin, funcionales y no funcionales,
podrn dividirse para ayudar a la legibilidad del documento, por ejemplo dividiendo cada subseccin en requisitos asociados a un determinado
objetivo, requisitos con caractersticas comunes, etc.
3.1.10
15
3.1.14
Este apartado debe contener los casos de uso que se hayan identificado,
especificados mediante la plantilla para requisitos funcionales descrita en
la seccin 5.4, pg. 35.
3.1.15
Requisitos no funcionales
Esta subseccin debe contener la lista los requisitos no funcionales del sistema que se hayan identificado, especificados mediante la plantilla para
requisitos no funcionales descrita en la seccin 5.5, pg. 39.
RI01
RI02
...
RF01
RF02
...
RNF01
RNF02
...
OBJ01
OBJ02
...
OBJ-n
3.1.17
Esta seccin, que se incluir en el caso de que no se opte por registrar los
conflictos en un documento aparte, deber contener los conflictos identificados durante el proceso y que an estn pendientes de resolucin, descritos mediante la plantilla para conflictos.
A. Durn, B. Bernrdez
16
Tcnicas
4.1
Entrevistas
Entrevistas
17
En las entrevistas se pueden identificar tres fases: preparacin, realizacin y anlisis [Piattini et al. 1996].
4.1.1
Preparacin de entrevistas
18
Es importante que los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta quin los va a responder y no incluir
conceptos que se asuman conocidos cuando puedan no serlo.
Planificar las entrevistas: la fecha, hora, lugar y duracin de las entrevista deben fijarse teniendo en cuenta siempre la agenda del entrevistado.
En general, se deben buscar sitios agradables donde no se produzcan
interrupciones y que resulten naturales a los entrevistados, tal como
se describe en [Goguen y Linde 1993].
4.1.2
Realizacin de entrevistas
19
Entrevistas
Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la informacin, contrastarla con otras entrevistas
o fuentes de informacin, etc.
Una vez elaborada la informacin, se puede enviar al entrevistado para
confirmar los contenidos. Tambin es importante evaluar la propia entrevista para determinar los aspectos mejorables.
A. Durn, B. Bernrdez
20
21
Dentro de la tcnica del JAD se distinguen tres fases [Raghavan et al. 1994]:
1 Adaptacin: es responsabilidad del jefe del JAD, ayudado por uno
o dos analistas, adaptar la tcnica del JAD para cada proyecto. La
adaptacin debe comenzar por definir el proyecto a alto nivel, para
A. Durn, B. Bernrdez
22
Brainstorming
23
4.3
Brainstorming
24
Casos de uso
25
Se fomentan las ideas ms avanzadas, que aunque no sean factibles, estimulan a los dems participantes a explorar nuevas
soluciones ms creativas.
Se debe generar un gran nmero de ideas, ya que cuantas ms
ideas se presenten ms probable ser que se generen mejores
ideas.
Se debe alentar a los participantes a combinar o completar las
ideas de otros participantes. Para ello, es necesario, al igual que
en la tcnica del JAD, que todas las ideas generadas estn visibles para todos los participantes en todo momento.
Una posibilidad es utilizar como semilla objetivos del sistema e ir
identificando requisitos. Si estos requisitos se recogen en las plantillas propuestas en la seccin 5, pg. 29, pueden utilizarse dichas
plantillas para que los participantes tengan visibles las ideas que se
van generando.
3 Consolidacin: en esta fase se deben organizar y evaluar las ideas
generadas durante la fase anterior. Se suelen seguir tres pasos:
3.1 Revisar ideas: se revisan las ideas generadas para clarificarlas.
Es habitual identificar ideas similares, en cuyo caso se unifican
en un solo enunciado.
3.2 Descartar ideas: aquellas ideas que los participantes consideren
excesivamente avanzadas se descartan.
3.3 Priorizar ideas: se priorizan las ideas restantes, identificando
las absolutamente esenciales, las que estaran bien pero que no
son esenciales y las que podran ser apropiadas para una prxima versin del sistema a desarrollar.
4 Documentacin: despus de la sesin, el jefe produce la documentacin oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidacin.
4.4
Casos de uso
Los casos de uso son una tcnica para la especificacin de requisitos funcionales propuesta inicialmente en [Jacobson et al. 1993] y que actualmente
forma parte de la propuesta de UML [Booch et al. 1999].
A. Durn, B. Bernrdez
26
Un caso de uso es la descripcin de una secuencia de interacciones entre el sistema y uno o ms actores en la que se considera al sistema como
una caja negra y en la que la que los actores obtienen resultados observables.
Los actores son personas u otros sistemas que interactan con el sistema cuyos requisitos se estn describiendo [Scheneider y Winters 1998].
Los casos de uso presentan ciertas ventajas sobre la descripcin meramente textual de los requisitos funcionales [Firesmith 1997], ya que facilitan la elicitacin de requisitos y son fcilmente comprensibles por los
clientes y usuarios. Adems, pueden servir de base a las pruebas del sistema y a la documentacin para los usuarios [Weidenhaput et al. 1998].
A pesar de ser una tcnica ampliamente aceptada, existen mltiples
propuestas para su utilizacin concreta [Cockburn 1997]. En esta metodologa se propone la utilizacin de los casos de uso como tcnica tanto de
elicitacin como de especificacin de los requisitos funcionales del sistema. Para la descripcin concreta de los casos de uso se proponen plantillas, en las que las interacciones se numeran siguiendo las propuestas
de [Cockburn 1997], [Scheneider y Winters 1998] y [Coleman 1998] y se
describen usando lenguaje natural en forma de patrones lingsticos (ver
seccin 5.4, pg. 35).
Caso de uso A
Actor 1
Caso de uso B
Actor 2
Caso de uso C
Sistema
Casos de uso
4.4.1
27
28
B
<<includes>>
<<includes>>
<<includes>>
<<extends>>
4.4.3
En la mayora de sistemas, el nmero de casos de uso es lo suficientemente elevado como para que sea oportuno organizarlos de alguna forma en
lugar de tener una lista plana por la que no es fcil navegar.
Una posible forma de organizar los casos de uso es recurrir a los paquetes descritos en la propuesta de UML [Booch et al. 1999]. De esta forma,
los casos de uso pueden organizarse en niveles, facilitando as su comprensin. Cada paquete contiene a otros paquetes o a varios casos de uso.
En el caso de que los casos de uso se agrupen por criterios funcionales, los paquetes que los agrupan pueden estereotiparse como subsistemas
[Scheneider y Winters 1998], tal como puede verse en el ejemplo de la figura 8.
Dpto. de Lenguajes y Sistemas Informticos
29
A
<<subsistema>>
B
<<subsistema>>
Actor 1
Actor 2
C
<<subsistema>>
Sistema
30
31
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
El sistema deber <objetivo a cumplir por el sistema>
OBJx <nombre del subobjetivo>
...
<importancia del objetivo>
<urgencia del objetivo>
<estado del objetivo>
<estabilidad del objetivo>
<comentarios adicionales sobre el objetivo>
32
33
5.2
Lo ms importante en los sistemas de informacin es precisamente la informacin que gestionan. La plantilla para requisitos de almacenamiento
de informacin, que puede verse en la figura 11, ayuda a los clientes y
usuarios a responder a la pregunta "qu informacin, relevante para los objetivos 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 recomendaciones, entre otros, de [IEEE 1993] y [Sawyer et al. 1997], cada requisito
se debe identificar por un cdigo nico y un nombre descriptivo.
Con objeto de conseguir una rpida identificacin, los identificadores de los requisitos de almacenamiento de informacin comienzan
con RI.
Versin, Autores, Fuentes: estos campos tienen el mismo significado
que en la plantilla para objetivos aunque referidos al requisito.
RI<id>
Versin
Autores
Fuentes
Objetivos asociados
Requisitos asociados
Descripcin
Datos especficos
Intervalo temporal
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
OBJx <nombre del objetivo>
...
Rxy <nombre del requisito>
...
El sistema deber almacenar la informacin correspondiente
a <concepto relevante>. En concreto:
<datos especficos sobre el concepto relevante>
...
{ pasado y presente, slo presente }
<importancia del requisito>
<urgencia del requisito>
<estado del requisito>
<estabilidad del requisito>
<comentarios adicionales sobre el requisito>
34
Objetivos asociados: este campo debe contener una lista con los objetivos a los que est asociado el requisito. Esto permite conocer qu
requisitos harn que el sistema a desarrollar alcance los objetivos
propuestos y justifican de esta forma la existencia o propsito del
requisito.
Descripcin: para los requisitos de almacenamiento de informacin
este campo usa un patrnL que se debe completar con el concepto
relevante sobre el que se debe almacenar informacin.
Datos especficos: este campo contiene una lista de los datos especficos asociados al concepto relevante, de los que pueden indicarse todos aquellos aspectos que se considere oportunos (descripcin,
restricciones, ejemplos, etc.).
Intervalo temporal: este campo indica durante cunto tiempo es relevante la informacin para el sistema. Puede tomar los valores pasado y presente, si la informacin es siempre relevante, o slo presente
si la informacin tiene un periodo de validez concreto.
Por ejemplo, si el concepto es empleados, y el intervalo de tiempo es
pasado y presente, quiere decir que los exempleados son relevantes
para el sistema, mientras que un periodo de tiempo de slo presente
indicara que los exempleados no se deben considerar.
Un intervalo temporal de pasado y presente suele implicar considerar la necesidad de dispositivos de almacenamiento con grandes
capacidades o la necesidad de algn tipo de archivos histricos.
Requisitos asociados: en este campo se indican otros requisitos que
estn asociados por algn motivo con el requisito que se est describiendo, permitiendo as tener una rastreabilidad horizontal, similar a
las relaciones entre assets del mismo nivel descritas en [Garca 2000].
Importancia, Urgencia, Estado, Estabilidad, Comentarios: estos campos tienen el mismo significado que en la plantilla para objetivos
aunque referidos al requisito.
5.3
35
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
Este actor representa a <rol que representa el actor>
<comentarios adicionales sobre el actor>
5.4
Los sistemas de informacin no slo almacenan informacin, tambin deben proporcionar servicios usando la informacin que almacenan. La plantilla de requisitos funcionales, que puede verse en la figura 13, describe casos de uso y ayuda a los clientes y usuarios a responder a la pregunta "qu
debe hacer el sistema con la informacin almacenada para alcanzar los objetivos
de su negocio?".
El significado de los campos especficos de esta plantilla es el siguiente
(los campos comunes con la plantilla para requisitos de almacenamiento
de informacin tienen el mismo significado):
Identificador y nombre descriptivo: igual que en la plantilla anterior, excepto que los identificadores de los requisitos funcionales
empiezan con RF y que el nombre descriptivo suele coincidir con el
objetivo que los actores esperan alcanzar al realizar el caso de uso.
No se debe confundir este objetivo con los objetivos del sistema. El
objetivo que los actores esperan alcanzar al realizar un caso de uso
es de ms bajo nivel, por ejemplo registrar un nuevo socio o consultar
los pedidos pendientes.
A. Durn, B. Bernrdez
36
RF<id>
Versin
Autores
Fuentes
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
OBJx <nombre del objetivo>
...
Rxy <nombre del requisito>
...
El sistema deber comportarse tal como se describe en el siguiente caso de uso { durante la realizacin de los casos de uso
<lista de casos de uso>, cuando <evento de activacin> }
<precondicin del caso de uso>
Paso Accin
p1
{El actor <actor>, El sistema} <accin/es realizada/s por
actor/sistema>
p2
Se realiza el caso de uso <caso de uso (RFx)>
p3
Si <condicin>, {el actor <actor>, el sistema} <accin/es
realizada/s por actor/sistema>
p4
Si <condicin>, se realiza el caso de uso <caso de uso
(RFx)>
...
...
<postcondicin del caso de uso>
Paso Accin
pi
Si <condicin de excepcin>, {el actor <actor>, el sistema} <accin/es realizada/s por actor/sistema>, a continuacin este caso de uso {contina, termina}
pj
Si <condicin de excepcin>, se realiza el caso de uso
<caso de uso (RFx)>, a continuacin este caso de uso
{contina, termina}
...
...
Paso Cota de tiempo
q
m <unidad de tiempo>
...
...
<no de veces> veces / <unidad de tiempo>
<importancia del requisito>
<urgencia del requisito>
<estado del requisito>
<estabilidad del requisito>
<comentarios adicionales sobre el requisito>
37
38
Otro ejemplo puede ser especificar que el usuario puede intentar conectarse al sistema un mximo de tres veces. Una posible especificacin sera la que puede verse en la figura 14, bastante ms natural y
fcil de entender que la que puede verse en la figura 15 utilizando la
propuesta descrita en [Coleman 1998].
Secuencia
normal
Paso
1
2
3
4
5
Excepciones
Paso
4
Accin
El sistema solicita al usuario su nombre de usuario y su
clave de acceso
El usuario proporciona el sistema su nombre y su clave
de acceso
El sistema comprueba si el nombre de usuario y la clave
de acceso son correctas
Si el nombre de usuario y la clave no son correctas, el
sistema permite al usuario repetir el intento (pasos 13)
hasta un mximo de tres veces
Si el nombre de usuario y la clave son correctas, el sistema
permite el acceso al usuario
Accin
Si el usuario ha intentado tres veces acceder sin xito, el
sistema rechaza el acceso del usuario, a continuacin este
caso de uso termina
39
5.6
40
RNF<id>
Versin
Autores
Fuentes
Objetivos asociados
Requisitos asociados
Descripcin
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
OBJx <nombre del objetivo>
...
Rxy <nombre del requisito>
...
El sistema deber <capacidad del sistema>
<importancia del requisito>
<urgencia del requisito>
<estado del requisito>
<estabilidad del requisito>
<comentarios adicionales sobre el requisito>
41
Referencias
CFL<id>
Versin
Autores
Fuentes
Objs./Reqs.
en conflicto
Descripcin
Alternativas
Solucin
Importancia
Urgencia
Estado
Comentarios
<nombre descriptivo>
<no de la versin actual> (<fecha de la versin actual>)
<autor de la versin actual> (<organizacin del autor>)
...
<fuente de la versin actual> (<organizacin de la fuente>)
...
OBJ/Ryy--x <nombre del objetivo o requisito en conflicto>
...
<descripcin del conflicto>
<descripcin alternativa de solucin> (<autores alternativa>)
...
<descripcin de la solucin adoptada (si se ha acordado)>
<importancia de la resolucin del conflicto>
<urgencia de la resolucin del conflicto>
<estado del resolucin del conflicto>
<comentarios adicionales sobre el conflicto>
Referencias
[Beyer y Holtzblatt 1995] H. R. Beyer y K. Holtzblatt. Apprenticing with
the Customer. Communications of the ACM, 38(5), Mayo 1995.
[Boehm et al. 1994] B. W. Boehm, P. Bose, E. Horowitz, y M.-J. Lee. Software Requirements as Negotiated Win Conditions. En Proceedings of
the First International Conference on Requirements Engineering, 1994. Disponible en http://sunset.usc.edu/TechRpts/Papers/NGPMRequirements93.ps.
A. Durn, B. Bernrdez
42
[Booch et al. 1999] G. Booch, J. Rumbaugh, y I. Jacobson. The Unified Modeling Language User Guide. AddisonWesley, 1999.
[Brackett 1990] J. W. Brackett. Software Requirements. Curriculum Module SEICM191.2, Software Engineering Institute, Carnegie Mellon
University, 1990. Disponible en http://www.sei.cmu.edu.
[Cockburn 1997] A. Cockburn. Structuring Use Cases with Goals. Journal
of ObjectOriented Programming, Sept. y Nov./Dic. 1997. Disponible en
http://members.aol.com/acockburn/papers/usecases.htm.
[Coleman 1998] D. Coleman.
A Use Case Template: Draft for
Fusion Newsletter, Abril 1998.
Disponible en
Discussion.
http://www.hpl.hp.com/fusion/md_newletters.html.
[Davis 1985] F. Davis. La comunicacin no verbal, volumen 616 de El Libro
de Bolsillo. Alianza Editorial, 1985.
[Durn 2000] A. Durn. Un Entorno Metodolgico de Ingeniera de Requisitos
para Sistemas de Informacin. Tesis doctoral, Universidad de Sevilla, 2000.
[Firesmith 1997] D. G. Firesmith. Uses Cases: the Pros and Cons, 1997.
Disponible en http://www.ksccary.com/usecjrnl.html.
[Garca et al. 2000] J. Garca, M. J. Ortn, B. Moros, y J. Nicols. Modelado
de Casos de Uso y Conceptual a partir del Modelado del Negocio. En
Actas de las V Jornadas de Trabajo Menhir, Granada, 2000.
[Garca 2000] F. J. Garca. Modelo de Reutilizacin Soportado por Estructuras
Complejas de Reutilizacin Denominadas Mecanos. Tesis doctoral, Universidad de Salamanca, 2000.
[Gause y Weinberg 1989] D. C. Gause y G. M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House, 1989.
[Goguen y Linde 1993] J. A. Goguen y C. Linde. Techniques for Requirements Elicitation. En Proceedings of the First International Symposium on
Requirements Engineering, 1993. Tambin aparece en [Thayer y Dorfman
1997]. Disponible en http://www.cse.ucsd.edu/goguen.
[Goleman 1996] D. Goleman. La Inteligencia Emocional. Kairs, 1996.
[Goleman 1999] D. Goleman. La Prctica de la Inteligencia Emocional. Kairs, 1999.
Dpto. de Lenguajes y Sistemas Informticos
Referencias
43
44
45
OBJ02
Descripcin
Estabilidad
Comentarios
OBJ02
Descripcin
Estabilidad
Comentarios
A. Durn, B. Bernrdez
46
Descripcin
Datos especficos
Intervalo temporal
Estabilidad
Comentarios
Descripcin
Datos especficos
Intervalo temporal
Estabilidad
Comentarios
RI03
Objetivos asociados
Requisitos asociados
Descripcin
Datos especficos
Intervalo temporal
Estabilidad
Comentarios
A. Durn, B. Bernrdez
47
48
<<subsistema>>
Gestin de
Socios
<<subsistema>>
Gestin de
Pelculas
<<subsistema>>
Gestin de
Alquileres
<<includes>>
Socio
Empleado del
vdeo-club
49
Requisitos funcionales
Empleado del
vdeo-club
Baja de cinta de vdeo (RF-08)
A. Durn, B. Bernrdez
50
Socio
Identificacin
de socio (RF-15)
Empleado del
vdeo-club
51
Requisitos funcionales
A.3.2
Definicin de actores
ACT01
Descripcin
Comentarios
Socio
Este actor representa a los socios del vdeoclub
ninguno
ACT02
Descripcin
Comentarios
A.3.3
A. Durn, B. Bernrdez
52
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Estabilidad
Comentarios
Alta de socio
OBJ02 Gestionar las socios
RI02 Informacin sobre socios
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite su ingreso como
socio
El solicitante no es un socio del vdeoclub y tiene su documentacin disponible
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de alta de un nuevo socio
2
El sistema solicita los siguientes datos del nuevo socio:
no del DNI, nombre, apellidos, fecha de nacimiento,
sexo, direccin y telfonos de contacto
3
El empleado del vdeoclub solicita los datos requeridos y la documentacin al nuevo socio
4
El empleado del vdeoclub comprueba que los datos
del nuevo socio coinciden con los de la documentacin
aportada
5
El empleado del vdeoclub proporciona los datos requeridos y solicita al sistema que los almacene
6
El sistema almacena los datos proporcionados, imprime el carnet de socio e informa al empleado del vdeo
club de que el proceso ha terminado con xito
7
El empleado del vdeoclub entrega el carnet al nuevo
socio
El solicitante es socio del vdeoclub y el saldo de su cuenta es
0
Paso Accin
4
Si la documentacin aportada no es correcta, el empleado del vdeoclub cancela la operacin, a continuacin este caso de uso termina
5
Si el sistema detecta que el nuevo socio ya es socio
del vdeoclub, el sistema informa de la situacin al
empleado del vdeoclub permitindole modificar los
datos proporcionados, a continuacin este caso de uso
contina
5
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso termina
Paso Cota de tiempo
4
5 segundos
10 veces/da
alta
La frecuencia ser mucho mayor durante los dos primeros meses, probablemente 100 veces/da
Requisitos funcionales
RF02
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Estabilidad
Comentarios
A. Durn, B. Bernrdez
53
Baja de socio
OBJ02 Gestionar las socios
RI02 Informacin sobre socios
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando un socio solicite su baja
El solicitante es un socio del vdeoclub y tiene su documentacin disponible
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de baja de un socio
2
Se realiza el caso de uso RF15 (Identificacin de socio)
3
El empleado del vdeoclub solicita al sistema que elimine la informacin correspondiente al socio
4
El sistema elimina los datos correspondientes al socio e
informa al empleado del vdeoclub de que el proceso
ha terminado con xito
4
El empleado del vdeoclub inhabilita el carnet al socio
que se acaba de dar de baja
El solicitante no es socio del vdeoclub
Paso Accin
3
Si el socio tiene pagos pendientes, el sistema el sistema comunica la situacin al empleado del vdeoclub
y cancela la operacin, a continuacin este caso de uso
termina
3
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema el sistema cancela la operacin, a
continuacin este caso de uso termina
Paso Cota de tiempo
6
1 segundo
1 vez/mes
alta
Si el socio que desea darse de baja tiene un pago pendiente,
puede hacer un ingreso por su importe y repetir el proceso de
darse de baja
54
RF03
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Requisitos funcionales
RF11
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
A. Durn, B. Bernrdez
55
Consulta de un socio
OBJ02 Gestionar las socios
RI02 Informacin sobre socios
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado del vdeoclub lo considere oportuno
Ninguna
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de consulta de los datos de un socio
2
El sistema solicita que se identifique al socio
3
El empleado del vdeoclub proporciona los datos de
identificacin al sistema
4
El sistema muestra la siguiente informacin asociada
al socio: nombre, apellidos, direccin, nmeros de telfono, alquileres pendientes y saldo de su cuenta
5
Si el empleado del vdeoclub solicita la impresin de
los datos, el sistema imprime los datos del socio
Ninguna
Paso Accin
3
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso termina
5
Si el sistema no tiene registrado ningn socio con la
identificacin proporcionada, el sistema comunica al
empleado del vdeoclub la situacin, a continuacin
este caso de uso termina
Paso Cota de tiempo
4
1 segundo
5 veces/da
El formato de visualizacin de los datos est pendiente de definicin
56
RF12
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Requisitos funcionales
RF15
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
A. Durn, B. Bernrdez
57
Identificacin de socio
OBJ02 Gestionar las socios
RI02 Informacin sobre socios
El sistema deber comportarse tal como se describe en el siguiente caso de uso durante la realizacin de los casos de uso:
RF02 Baja de socio
RF03 Modificacin de datos de un socio
RF06 Alquiler de cintas de vdeo
El socio tiene su documentacin disponible
Paso Accin
1
El sistema solicita que se identifique al socio
2
El empleado del vdeoclub solicita el carnet de socio
3
El empleado del vdeoclub proporciona los datos de
identificacin al sistema
4
El sistema muestra los nmeros de telfonos que el socio proporcion cuando se dio de alta
5
El empleado del vdeoclub solicita al socio que le confirme alguno de los nmeros de telfono registrados en
el sistema
6
El empleado del vdeoclub confirma la identidad del
socio al sistema
Ninguna
Paso Accin
3
Si el sistema detecta que el supuesto socio no es socio del vdeoclub, el sistema comunica al empleado
del vdeoclub la situacin, a continuacin este caso
de uso aborta
5
Si el socio no conoce ningn nmero de telfono registrado en el sistema y no puede demostrar su identidad,
el empleado del vdeoclub retiene el carnet de socio y
cancela la operacin, a continuacin este caso de uso
aborta
5
Si el socio no conoce ningn nmero de telfono registrado pero puede demostrar su identidad por otros
medios, el empleado del vdeoclub le recuerda los nmeros de telfonos que proporcion cuando se dio de
alta, a continuacin este caso de uso contina
Paso Cota de tiempo
50 veces/da
ninguno
58
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Alta de pelcula
OBJ01 Gestionar las cintas y pelculas
RI01 Informacin sobre pelculas
RF05 Alta de cinta de vdeo
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando se adquiera una cinta de una pelcula nueva
La pelcula no est registrada en el sistema
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de alta de pelcula
2
El sistema solicita los siguientes datos de la nueva pelcula: ttulo, tipo de pelcula, duracin, actores principales, director, productora y ao de produccin
3
El empleado del vdeoclub proporciona los datos requeridos y solicita al sistema que los almacene
4
El sistema almacena los datos proporcionados e informa al empleado del vdeoclub de que el proceso ha
terminado con xito
El sistema ha almacenado la informacin correspondiente a la
nueva pelcula
Paso Accin
4
Si el sistema detecta que la pelcula ya est registrada, el sistema informa de la situacin al empleado del
vdeoclub permitindole modificar los datos proporcionados, a continuacin este caso de uso contina
4
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso se cancela
Paso Cota de tiempo
4
1 segundo
1 vez/da
ninguno
Requisitos funcionales
RF05
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
A. Durn, B. Bernrdez
59
Alta de cinta de vdeo
OBJ01 Gestionar las cintas y pelculas
RI01 Informacin sobre pelculas
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando se adquieran nuevas cintas de una
pelcula
Ninguna
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de alta de cinta
2
El sistema solicita que se identifique la pelcula que
contiene la cinta
3
El empleado del vdeoclub identifica la pelcula
4
Si la pelcula no est registrada, se realiza el caso de
uso RF04 (Alta de pelcula)
5
El sistema solicita el nmero de cintas de la pelcula a
dar de alta
6
El empleado del vdeoclub proporciona el nmero de
cintas y solicita al sistema que almacene la informacin
7
El sistema almacena los datos proporcionados, imprime la etiquetas de identificacin de cintas autoadhesivas e informa al empleado del vdeoclub de que el
proceso ha terminado con xito
8
El empleado del vdeoclub pega las etiquetas en las
cintas y las coloca en las estanteras
Las cintas estn registradas en el sistema
Paso Accin
6
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso termina
Paso Cota de tiempo
7
1 segundo
1 vez/da
ninguno
60
RF08
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Requisitos funcionales
RF10
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
A. Durn, B. Bernrdez
61
Consulta de una pelcula
OBJ01 Gestionar las cintas y pelculas
RI01 Informacin sobre pelculas
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado del vdeoclub lo considere oportuno
Ninguna
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de consulta de los datos de una pelcula
2
El sistema solicita que se identifique la pelcula a consultar
3
El empleado del vdeoclub identifica la pelcula a consultar
4
El sistema muestra los siguientes datos correspondientes a la pelcula: ttulo, tema, ao de produccin, actores principales, nombre de la productora y nmero de
cintas disponibles
5
Si el empleado del vdeoclub solicita la impresin de
los datos, el sistema imprime los datos de la pelcula
La informacin correspondiente a la pelcula consultada no ha
cambiado
Paso Accin
3
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso termina
Paso Cota de tiempo
4
1 segundo
1 vez/da
ninguno
62
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Requisitos funcionales
RF07
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
A. Durn, B. Bernrdez
63
Devolucin de cintas de vdeo
OBJ03 Gestionar los alquileres
RI02 Informacin sobre socios
RI03 Informacin sobre cuentas de socios
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando un socio solicite devolver una o
ms cintas de vdeo
Todas las cintas a devolver estn registradas como alquiladas
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de devolucin de cintas de vdeo
2
El sistema solicita que se identifiquen las cintas que se
desean devolver
3
El empleado del vdeoclub identifica las cintas y solicita al sistema que registre su devolucin
4
El sistema registra los devoluciones
5
Si alguna cinta ha sido devuelta fuera de plazo, el sistema registra la multa correspondiente como un cargo
en la cuenta del socio
6
Si el socio decide pagar al contado, el sistema imprime
el ticket con el importe correspondiente y registra el
pago como un ingreso en la cuenta del socio
7
Si el socio decide pagar a cuenta, el sistema registra el
cargo en la cuenta del socio
Las cintas a alquilar estn registradas como alquiladas y la
cuenta del socio est actualizada
Paso Accin
4
Si alguna de las cintas est registrada como alquilada, el sistema comunicar la situacin al empleado del
vdeoclub y excluir la cinta del alquiler, a continuacin este caso de uso contina
Paso Cota de tiempo
4
1 segundo
50 veces/da
ninguno
64
RF09
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
Requisitos funcionales
RF13
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Importancia
Urgencia
Comentarios
A. Durn, B. Bernrdez
65
Consulta de las pelculas alquiladas un da determinado
OBJ03 Gestionar los alquileres
RI01 Informacin sobre pelculas
El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando el empleado del vdeoclub lo considere oportuno
Ninguna
Paso Accin
1
El empleado del vdeoclub solicita al sistema comenzar el proceso de consulta de las pelculas alquiladas
un da determinado
2
El sistema solicita la fecha del da que se quiere consultar, proponiendo la del da actual
3
El empleado del vdeoclub proporciona la fecha del
da determinado al sistema
4
El sistema muestra una lista ordenada por nmero de
alquileres con la siguiente informacin: ttulo y tema
de cada pelcula y nmero de alquileres en el da determinado
5
Si el empleado del vdeoclub solicita la impresin de
los datos, el sistema imprime la lista
La informacin sobre las pelculas no ha cambiado
Paso Accin
3
Si el empleado del vdeoclub solicita cancelar la operacin, el sistema cancela la operacin, a continuacin
este caso de uso termina
Paso Cota de tiempo
4
5 segundos
1 vez/da
importante
hay presin
ninguno
66
RF14
Objetivos asociados
Requisitos asociados
Descripcin
Precondicin
Secuencia
normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Comentarios
67
Requisitos no funcionales
A.4
Requisitos no funcionales
RNF01
Objetivos asociados
Requisitos asociados
Descripcin
Comentarios
RNF02
Objetivos asociados
Requisitos asociados
Descripcin
Comentarios
RNF03
Objetivos asociados
Requisitos asociados
Descripcin
Comentarios
A. Durn, B. Bernrdez
Copias de seguridad
68