PLANILLA DE

ESPECIFICACIÓN DE
REQUERIMIENTOS
PRY1111
 DOCUMENTAR

» En la experiencia anterior pudimos observar que los

requerimientos funcionales de nuestro proyecto debemos
ordenarlos a través de un modelo de casos de uso.
» Una vez realizado el modelo, debemos documentar estos
requerimientos

2
 PLANTILLA DE
ESPECIFICACIÓN
» La especificación de RF- 01 Sacar Dinero
Objetivos asociados OBJ–01 Retirar dinero desde cuenta del usuario

requerimientos nos Requisitos asociados

Versión
RI–02 Información de acceso de cliente
1.0
Actores Cliente_banco
permitirá transformar Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de un cliente de
un banco solicite el retiro de dinero desde su cuenta bancaria a través del cajero
automático
nuestro modelo a un Precondición
Secuencia
El solicitante debe ser cliente del banco para poder realizar el procedimiento
Paso Acción
Normal
documento que 2
1 El usuario se autentica usando su número
de cuenta y número secreto
El sistema da la bienvenida al usuario,

especifique las 3
mostrando el menú principal en la pantalla.
Usando el teclado, el usuario selecciona en
el menú la opción “sacar dinero”.

acciones y 4 El sistema muestra por pantalla un recuadro

para que el usuario introduzca la cantidad
deseada y la opción de cancelar.

características 5 El usuario teclea la cantidad y pulsa el botón

“Aceptar” de la teclera.

principales de cada 6 El sistema actualiza el saldo de la cuenta del

usuario y facilita el dinero por el dispensador
de efectivo.

uno de los Postcondición

Excepciones
El solicitante se le descuenta el valor de dinero retirado del total que posee en su cuenta
Paso Acción
1 El número de cuenta o número secreto es
requerimientos incorrecto: El sistema notifica el error por
pantalla y termina la operación.

funcionales. 5

» Para ello trabajaremos con
6
El usuario selecciona la opción “cancelar”: El
sistema termina la operación
La cantidad solicitada por el usuario es
mayor que los fondos disponibles: El
sistema notifica el error por pantalla y
termina la operación.
Rendimiento Paso Cota de tiempo
4 3 segundos
Frecuencia esperada 100 veces/día
6 3 segundos

una plantilla estándar Estabilidad alta

3
 CASO DE EJEMPLO

» Para ver la transformación de un modelo de casos de uso a la

tabla de especificación de requerimientos
» Nos basaremos en el ejemplo visto en la experiencia anterior del cajero automático.
Utilizaremos el Caso de Uso “Retirar dinero”

Cajero Automático

<<include>>
Retirar dinero Login

Consultar Saldo

Cliente_banco
Depositar dinero

Depositar Depositar
efectivo Cheque 4
 ANALISANDO EL CASO

» Para comenzar debemos analizar los casos de uso modelados,

entendiendo su funcionamiento y todos los elementos que
participan en él.
» A continuación mostraremos la tabla de especificación dividida
en partes para que puedas entender que debes anotar en cada
ítem.

5
 PRIMER GRUPO -
DESCRIPCIÓN
» El Primer grupo nos ayuda a identificar el Requerimiento del Cliente
con el Requerimiento funcional del Caso de Uso en versión Diagrama.
Además, describe los aspectos generales de su funcionalidad y
alcances.
RF- <id del caso> nombre del requerimiento funcional
Versión número de versión y fecha
Actores Los actores que interactúan directamente con el
sistema, tanto los primarios quienes inician el CU,
como los secundarios que interactúan con el sistema
luego que este ha iniciado.
Objetivos asociados Se especifica cuales objetivos del proyecto están
asociados al requerimiento

Requerimientos asociados Los requerimientos asociados nos permiten realizar un

enlace con el resto de los requerimientos que posee el
proyecto
Descripción Es un párrafo que resume el objetivo del caso de uso.
Sin dar detalles del cómo, la descripción del caso de
uso resume todo lo que el caso de uso hace.
6
 PRIMER GRUPO -
EJEMPLO

RF- 01 Retirar Dinero

Versión 1.0
Actores Cliente_banco
Objetivos asociados OBJ–01 Retirar dinero desde cuenta del usuario

Requerimientos RI–02 Información de acceso de cliente

asociados

Descripción El sistema deberá comportarse tal como se

describe en el siguiente caso de un cliente de
un banco solicite el retiro de dinero desde su
cuenta bancaria a través del cajero automático

7
 SEGUNDO GRUPO -
DESCRIPCIÓN
» El Segundo grupo se define la secuencia de acción con los pasos a
seguir, uno a uno, para que se cumpla la funcionalidad que se define
como objetivo en el desarrollo del sistema y las excepciones que
identifican posibles aspectos que pueden hacer que no se cumpla la
secuencia normal.
Precondición Las precondiciones no son eventos que disparan o activan el
Caso de uso en el sistema. Sin embargo, son declaraciones en
las cuales el caso de uso puede comenzar
Secuencia Normal Paso Acción
  1  
El flujo básico es un camino 2  
simple, sin ramificaciones y en él 3  
suelen hacerse una serie de 4  
asunciones, las alternativas a 5  
estos presuntos son los flujos 6  
alternos n  
Postcondición Donde me lleva el sistema luego de la acción definida
Excepciones Paso Acción
  1  
se relacionan a lo que ocurre si no 2  
se cumple con alguna etapa de la 3  
secuencia normal 8
 SEGUNDO GRUPO -
EJEMPLO
Precondición El solicitante debe ser cliente del banco para poder realizar el procedimiento
Secuencia Paso Acción
Normal 1 El usuario se autentica usando su número de cuenta y número secreto
2 El sistema da la bienvenida al usuario, mostrando el menú principal en la
pantalla.
3 Usando el teclado, el usuario selecciona en el menú la opción “sacar dinero”.
4 El sistema muestra por pantalla un recuadro para que el usuario introduzca la
cantidad deseada y la opción de cancelar.
5 El usuario teclea la cantidad y pulsa el botón “Aceptar” de la teclera.
6 El sistema actualiza el saldo de la cuenta del usuario y facilita el dinero por el
dispensador de efectivo.
Postcondición El solicitante se le descuenta el valor de dinero retirado del total que posee
en su cuenta
Excepciones Paso Acción
1 El número de cuenta o número secreto es incorrecto: El sistema notifica el error
por pantalla y termina la operación.
5 El usuario selecciona la opción “cancelar”: El sistema termina la operación
6 La cantidad solicitada por el usuario es mayor que los fondos disponibles: El
sistema notifica el error por pantalla y termina la operación.

9
 TERCER GRUPO -
DESCRIPCIÓN
» Y el tercer grupo es Auxiliar de los anteriores y define factores
no funcionales o ambientales que determinan una
funcionalidad, como por ejemplo, la frecuencia de acceso al
sistema o el rendimiento en relación al tiempo u otro factor.

Rendimiento Paso Cota de tiempo

     
Especifica el rendimiento    
en tiempo de los pasos
que el sistema debe
realizar alguna acción

Frecuencia esperada nº de veces / unidad de tiempo

Comentarios comentarios adicionales

10
 TERCER GRUPO -
EJEMPLO

Rendimiento Paso Cota de tiempo

4 3 segundos
6 3 segundos
Frecuencia 100 veces/día
esperada
Comentarios No Procede

11
 REFERENCIAS

Casos Prácticos de UML, Celia Gutiérrez Cosío, Estos

Editorial Complutense, primera edición, 2011
Libros están
disponibllees
bib en la
iblio
ioteca DUOC y
pueden se
r vistos d
Manual de UML, Paul Kimmel, manera dig
igital
e
McGRAW-HILL Interamericana editores, 2008

Estructuración y Especificación de Casos de Uso

https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-
especificacin-de-casos-de-uos

Definición de casos de uso

https://www.ibm.com/support/knowledgecenter/es/SSWSR9_11.0.0/
com.ibm.pim.dev.doc/pim_tsk_arc_definingusecases.html 12
 APLICANDO

TABLAS DE ESPECIFICACIÓM DE REQUERIMIENTOS

► Ahora deben transformar su modelo de casos de uso de tu proyecto al

documento de especificació de requerimientos.
► Recuerda que cada tabla esta asociada a UN caso de uso de tu modelo.
►PLANTILLA de Especificación de Requerimientos
►EJEMPLO de Especificación de Requermientos

En agilidad los
requisitos se definen
y analizan de forma
constante. La
metodología mas
usada es SCRUM 13