Ta bla 4 . Plant illa para la descripción de requerim ient os funcionales.

RF - < id> < Nom bre descript ivo>

Ve r sión < Núm ero de versión act ual> ( < Fecha de versión act ual> )
Au t or < Aut or de versión act ual> ( < Com pañía del aut or> )
< Fuent e de versón act ual> ( < Organización fuent e del
Fu e n t e
requerim ient o> )
Pr opósit o < Propósit o del requerim ient o>
El sist em a debe com port arse com o se describe en la
D e scr ipción siguient e secuencia de int ereacciones cuando < event o
disparador>
< Que sist em a es considerado caj a negra en la perspect iva
Alca nce Y N ive l
de diseño>
< Lo que se espera del ent orno para la realización del
Pr e condición
requerim ient o>
Condición de Éx it o < Est ado del ent orno que indica que se realizó con éxit o>
< Est ado del ent orno cuado el requerim ient o es abort ado o
Condición de Fr a ca so
falla>
Act or e s < Prim ario> { < Secundarios> }
Eve n t o D ispa r a dor < Event o disparador o t rigger>
Pa so Acción
… …
n { el { < act or> . Sist em a} < acción
{ el { < act or> .
Sist em a} < acción
Se cue n cia N or m a l ej ecut ada por
n.1 act or / sist em a> ,Pasos
descrit os en < caso de
uso ( RF- x) > es
ej ecut ada}
… …
… …
Post con dición < Post condición del caso de uso>
Pa so Acción
Ex ce pcione s Y
p if < condición de excepción> , { el {
Ex t e n sione s
… …
I N FORM ACI ÓN RELACI ON AD A
Pr ior ida d < grado de prioridad del requerim ient o>
Est e caso de uso se espera ser ej ecut ado < núm ero de
Fr e cu e ncia
veces> núm er o de veces/ < unidad de t iem po>
Pa so Acción
D e se m pe ñ o q m segundos
… …
Ca n a le s h a cia los < Ar chivos, int eract ivo, base de dat os, et c>
Act or e s
Ca r a ct e r íst ica s < List a de caráct eríst icas que pueden afect ar las
Abie r t a s deciciones sobre el caso de uso>
< List a de requerim ient os que incluyen est e
Su pe r ior e s
requerim ient o>
Su bor dina dos < Vínculos hacia subrequer im ient os>
Com e nt a r ios < com ent arios adicionales acerca del requerim ient o
COCKBURN , Alist air. Basic Use Case Tem plat e [ online] . Disponible en I nt ernet :
< ht t p: / / m em bers.aol.com / acockburn>

La correspondient e definición de cada uno de los cam pos de est a

plant illa es:
• Ve r sión : De acuerdo a las recom endaciones de la I EEE77 , y de
com pañías líderes en procesos de soft ware com o Rat ional 78 , un
requerim ient o debe perm it ir m anej ar sus dist int as versiones de
m anera que se pueda analizar la evolución del m ism o a t ravés del
t iem po. Para t odo requerim ient o, est e cam po debe est ar ocupado
por la versión act ual, con su correspondient e núm ero y fecha.
• Au t or , Fue n t e : Cont iene el nom bre de la organización y el aut or
del requerim ient o.
• Pr opósit o: Cont iene la descripción del porqué el requerim ient o
consignado es necesario para alcanzar los obj et ivos del negocio 79 .
• D e scr ipción : Para los requerim ient os funcionales, est a plant illa
cont iene un pat rón lingüíst ico que indica que debe ser llenado y
los event os que disparan el requerim ient o.
• Alca n ce y N ive l: Cuál sist em a debe ser considerado com o caj a
negra para est e requerim ient o.

77
I N STI TUTE FOR ELECTRON I CS AN D ELECTRI CAL EN GI N EERS. I EEE Guide for
Developing Syst em Requirem ent s Specificat ions I EEE/ ANSI St andard 1233–1996. s.I .:
La inst it ución, 1996.
78
OBERG, Op. cit .

79
D AVI S, A. M. 201 Principles of Soft ware Developm ent . McGraw–Hill, 1995.
• Pr e con dición : Se ingresan las condiciones necesarias que se
deben t ener para llevar a cabo el requerim ient o que se est á
describiendo.
• Con dición de Éx it o: Condición que indica si la ej ecución del
requerim ient o fue exit osa.
• Con dición de Fr a ca so: Condición que indica que la ej ecución del
requerim ient o fue abort ada o falló.
• Act or e s: Act or prim ario, y/ o list a de act ores secundarios del
requerim ient o.
• Eve n t o D ispa r a dor : Event o que dispara la realización del
requerim ient o.
• Se cu e n cia Or din a r ia : Aquí se deposit a la secuencia de
int eracciones que t iene el usuario con el sist em a, en orden de
llevar a cabo una funcionalidad u operación. Los pasos que se
llevan a cabo en pueden a su vez cont ener sub- pasos o secuencias
anidadas, asum iendo que sólo una de est as se puede llevar a
cabo.
• Poscon dicion e s: Son los est ados a los cuales se debe llegar o los
result ados que se deben obt ener después de ej ecut ar la
funcionalidad descrit a en el requerim ient o.
• Ex ce pcion e s Y Ex t e n sion e s: Durant e la int eracción descrit a en
la secuencia ordinaria se pueden present ar excepciones o
ext ensiones condicionales, debido a fluj os alt ernat ivos de dicha
int eracción ent re el usuario y el sist em a. Es est e cam po se
especifica la secuencia que se t om aría si se present a la excepción
o se indica si la funcionalidad descrit a en el requerim ient o se
abort a.
 • Pr ior ida d: I ndica que t an im port ant e es el requerim ient o, que
grado de prioridad t iene el requerim ient o para los usuarios y
client es80 .
• Fr e cu e n cia : Frecuencia con la que se lleva a cabo la ej ecución del
requerim ient o en un int ervalo de t iem po. Se indica la t olerancia a
fallos que t iene el requerim ient o de acuerdo al núm ero de event os
que se ut iliza el requerim ient o y el t iem po que el m ism o debe
est ar disponible.
• D e se m pe ñ o: Aquí se especifica un t iem po de t olerancia respect o
al t iem po de respuest a del sist em a para alguno o t odos los pasos
de la secuencia ordinaria.
• Ca n a le s h a cia los a ct or e s: Canales com o archivos, int eract ivo,
base de dat os a t ravés de los cuales se expresa el result ado de la
ej ecución del requerim ient o
• Ca r a ct e r íst ica s Abie r t a s: List a de caract eríst icas que pueden
afect ar las decisiones sobre el caso de uso
• Su pe r ior e s: List a de requerim ient os que incluyen est e
requerim ient o
• Su bor din a dos: Vínculos hacia subrequerim ient os.
• Com e n t a r ios: En est e cam po se ingresa t oda la inform ación que
no se pudo agregar a ninguno de los cam pos.

80
D AVI S, Op. cit .
Así m ism o, se debe puede t ener una plant illa para la descripción de
requerim ient os no funcionales ( …Véase Tabla 5…) .

Ta bla 5 . Plant illa para la descripción de requerim ient os no funcionales.

RN - 3 Sist em a Operat ivo
Ve r sión 1,0 ( May, 25, 2005)
Au t or M. Ariza( Universidad de Javeriana)
Fu e nt e M. Torres ( Proyect o Em presa de Teléfonos de Bogot á)
D e scr ipción El sist em a debe operar sobre el Sist em a Operat ivo Linux
Pr ior ida d Alt a
Com e n t a r ios Verificar la com pat ibilidad ent re versiones diferent es de Linux

D URÁN TORO, A. et al. A requirem ent s elicit at ion approach based in t em plat es and
pat t erns [ online] . Disponible en I nt ernet :
< ht t p: / / wer.inf.puc- rio.br/ WERpapers/ art igos/ art igos_WER99/ t oro.pdf>

o Gráficas y Diagram as: Los casos de Uso son const ruidos

conform e a la not ación est ándar de UML, donde la descripción
de los casos de uso perm it en m últ iples act ores, exist iendo una
visión única del caso para cada act or envuelt o en él.

o Est rat egia Orient ada a Act ores: propone ident ificar com o
prim er paso a los act ores del sist em a, com o m edio para
ident ificar los casos de uso.

• Escenarios ( 2 – Alt e r n a t iva B) .

Para la especificación de escenarios, se debe est ablecer un conj unt o de
reglas que perm it an definir el cont enido de los m ism os, ya sea
est ableciendo una plat illa com o en los casos de uso.