Universidad de Chile

Escuela de Ingeniera
Departamento de Ciencia de la Computacin

Documento de Requisitos

de Usuario / Software
Sistema de Ejemplo

[Comentario: todo lo que est entre parntesis es un comentario,

por lo tanto debe ser instanciado o removido incluyendo este
comentario]
Fecha:

[fecha ltimo cambio]

Versin:

[versin actual]

Equipo de Desarrollo:
[Colocar aqu los miembros ms relevantes (interlocutores y/o responsables) del equipo de
desarrollo.
Nombre 1 (Rol, Contacto)
Nombre 2 (Rol, Contacto)
Nombre 3 (Rol, Contacto)
Nombre 4 (Rol, Contacto)
Por ejemplo:
Nombre
Juan Carlos Prez

Rol
Administrador del Proyecto

Documento de Requisitos de Sistema de Ejemplo

Pgina 1

Contacto
[email protected]
(56 2) 345-4369

Juana Alvarez

Analista

[email protected]
(56 2) 345-4363

Alberto Gonzlez

Diseador

[email protected]
(56 2) 345-4367

Pedro Gutirrez

Analista/Implementador

[email protected]
(56 2) 345-4364

Jos Fleitas

Implementador

[email protected]
(56 2) 345-4365

Jorge Rodrguez

Tester

[email protected]
(56 2) 345-4363

]
Contraparte:
[Colocar aqu los miembros ms relevantes (interlocutores y/o responsables) de la contraparte.
Estas personas son miembros de la organizacin cliente, y tienen algn tipo de dedicacin para
apoyar el desarrollo de este proyecto.
Nombre 1 (Rol, Contacto)
Nombre 2 (Rol, Contacto)
Nombre 3 (Rol, Contacto)
Nombre 4 (Rol, Contacto)
Por ejemplo:
Nombre

Rol

Contacto

Sergio F. Ochoa

Cliente/Profesor

Mara Cecilia Rivara

Cliente/Coordinadora/Profesor [email protected]
(56 2) 678-4365

Francia Ormeo

Secretaria

[email protected]
(56 2) 678-4366

Margarita Serei

Contadora

[email protected]
(56 2) 678-4367

Jos A. Pino

Profesor

[email protected]
(56 2) 678-4368

Documento de Requisitos de Sistema de Ejemplo

Pgina 2

[email protected]
(56 2) 678-4364

Historia del Documento

Versin

Fecha

0.1

08/08/2005

Razn del Cambio

Primer borrador

Documento de Requisitos de Sistema de Ejemplo

Pgina 3

Autor(es)

ndice
Historia del Documento............................................................................................................iii
1
1.1
1.2
1.3
1.4
1.5
2
2.1
2.2
2.3
2.4
2.5
3
3.1
3.2
3.3
4
4.1
4.2

Introduccin...................................................................................................................... 4
Propsito del Sistema......................................................................................................4
Alcance del Proyecto.......................................................................................................4
Contexto........................................................................................................................... 4
Definiciones, Acrnimos y Abreviaturas...........................................................................4
Referencias...................................................................................................................... 4
Descripcin General......................................................................................................... 4
Caractersticas de los Usuarios........................................................................................4
Perspectiva del Producto segn los Usuarios/Clientes....................................................4
Ambiente Operacional de la Solucin..............................................................................4
Relacin con Otros Proyectos..........................................................................................4
Descripcin del Modelo....................................................................................................4
Requisitos del Sistema.....................................................................................................4
Requisitos de Usuario......................................................................................................4
Requisitos de Software....................................................................................................4
Matriz de Trazado Requisitos de Usuario vs. Requisitos de Software..............................4
Pruebas de Sistema..........................................................................................................4
Pruebas de Usuario......................................................................................................... 4
Matriz de Trazado Requisitos de Usuario vs. Pruebas.....................................................4

Documento de Requisitos de Sistema de Ejemplo

Pgina 4

1 Introduccin
En esta introduccin se describe brevemente el contexto, objetivos y alcance del
sistema a desarrollar, as como la documentacin relativa al mismo. Esta
informacin est basada en el Documento de Proposicin de Proyecto (DPP) de
Sistema de Ejemplo.
[Para usar esta plantilla, debe remover todos los prrafos que estn entre corchetes,
como ste, y reemplazarlos por un texto adecuado (este es el nico prrafo entre
corchetes que no se reemplaza por nada). Adems, debe ir al men File (archivo),
opcin Properties (propiedades), y modificar las propiedades Subject (o Asunto) y
Comments (comentarios). Una vez modificado, actualice las referencias
seleccionando todo el documento y presione F9. Seleccione el pie de pgina y
actualice la referencia al nombre del sistema.]

1.1 Propsito del Sistema

[Describir aqu qu hace y qu es el sistema. Para proyectos pequeos, media
pgina debera ser ms que suficiente.]

1.2 Alcance del Proyecto

[Describir hasta dnde llega el proyecto: qu es y qu no es. Para proyectos
pequeos, media pgina debera ser ms que suficiente.]

1.3 Contexto
[Dar informacin respecto del contexto del desarrollo y el contexto en el que se tiene
que insertar el sistema. Tecnologas que estarn involucradas, trabajos previos,
vnculos con otros sistemas, etc. Escriba lo que necesite, en general los grficos son
bienvenidos, pues ayudan mucho a la comprensin]

1.4 Definiciones, Acrnimos y Abreviaturas

[Indique aqu la definicin de las palabras claves (o keywords) que se emplearn
en el documento, y que el lector no necesariamente conoce. De la misma manera,
coloque el significado de todas siglas o abreviaturas que se empleen. Tanto las
siglas como las definiciones tienen que expresar lo que el/los autores del documento
entienden, y no necesariamente dar definiciones generales. La idea es poder
entender en toda su magnitud el documento que se est leyendo, y nada ms. La
lista DEBE estar en orden alfabtico para facilitar la bsqueda de conceptos.
Ejemplos de definiciones, siglas y abreviaturas son las siguientes:

Comunicacin Wireless: Tipo de comunicacin de datos que se efecta a travs

de antenas embebidas o adosadas a dispositivos computacionales.
Documento de Requisitos de Sistema de Ejemplo
Pgina 1

TCP (Transmisin Control Protocol): Protocolo de comunicacin de datos

orientado a la conexin. Generalmente usado en redes de computadoras.
URD (User Requirement Document): Documento que expresa los requisitos de los
usuarios/clientes de un sistema.
REP_1: Se le llamar de esta manera a los reportes de ventas que el sistema debe
emitir al finalizar la jornada laboral.]

1.5 Referencias
[Enumere la documentacin y bibliografa utilizada como apoyo para construir este
documento. Coloque fechas y versiones de documentos cuando corresponda. Por
ejemplo:

1. ESA Software Engineering Standards. PSS-05-0 Issue 2. ESA Board for

Software Standardization and Control (BSSC) - European Space Agency.
(1991). URL: www.ess.co.at/ECOSIM/ESA.txt.
2. URD (User Requirement Document) 3.1.
3. SRD (Software Requirement Document) 2.0.]

Documento de Requisitos de Sistema de Ejemplo

Pgina 2

2 Descripcin General
Esta seccin describe los requisitos funcionales de los Usuarios/Clientes (seccin 2.1sistema,
sus interfaces externa, las condiciones de excepcin y las clases de pruebas que se harn para
verificar que los requisitos se cumplen.

2.1 Caractersticas de los Usuarios

[Ac se deben identificar los tipos de usuarios, los atributos generales de cada tipo y la
cantidad de personas en cada categora. Por ejemplo:
Los usuarios del sistema son:
Tipo de
Descripcin
Usuario

# Actual

#
Futura
(1 ao)

Usuarios
Contactables

Slo puede hacer la reserva de un

recurso en particular en mdulos en los
que el recurso este disponible, es decir,
no haya sido reservado por otro usuario
con anterioridad. Adems puede
cancelar su propia reserva y modificarla
siempre y cuando el horario est
disponible.

25

30

Sergio Ochoa, (56

2) 678-4364
[email protected]
.cl

Sper
Usuario

Puede realizar reservas de un recurso

sobre cualquier mdulo, incluso si esta
ocupado por otro usuario. Adems
puede cancelar y modificar cualquier
reserva hecha en el sistema.

Jaime Rodrguez,
(56 2) 678-4364
[email protected].
cl

Usuario
Administrador

Realiza todo el manejo recursos y

estadsticas, es decir, puede agregar,
eliminar, modificar, deshabilitar o
habilitar cualquier recurso del sistema y
maneja las estadsticas, personalizando
la estadstica que quiere obtener
desplegndola en pantalla. El manejo
de usuarios se realiza a travs del SAU.

Andrs Neyem, (56

2) 678-4365
[email protected]
e.cl

Este es cualquier persona que visite la

pgina del sistema, slo puede
consultar la informacin de las reservas
y los recursos disponibles.

50 por
da (muy
variable)

Usuario
Comn

Usuario
general o
visitante

Documento de Requisitos de Sistema de Ejemplo

Pgina 3

Pedro Peralta, (56

2) 678-4365
[email protected]

Luca Ortega, (56

2) 678-4365
[email protected]

70 por
da (muy
variable)

Juan Aguirre, (56

2) 678-43647
[email protected].
cl

El siguiente esquema refleja la interaccin de cada usuario con los mdulos del sistema:
Consultar:

Reservar

- reservas
- recursos.
Usuario
General

Manejo de
Recursos

Usuario Comn

Manejo de
Recursos

Usuario Administrador

Manejo de
Usuarios

SAU

Sper Usuario

2.2 Perspectiva del Producto segn los Usuarios/Clientes

[Ac debe colocarse la perspectiva que tienen los clientes y los usuarios acerca del producto.
Cada tipo de usuario tiene diferentes expectativas, y cada tipo de cliente tambin. El cliente es
el que aporta la visin de la organizacin. Eso debera estar expresado ac. Basta con colocar
una oracin por cada tipo de usuario y cliente]

2.3 Ambiente Operacional de la Solucin

[Ac se describen brevemente los componentes principales del ambiente operacional, donde
deber vivir la solucin que est siendo desarrollada. Esto puede describir el escenario actual,
o bien el futuro, si es que se realizar una compra de equipamiento. Por ejemplo:
El ambiente operacional involucrado en este sistema es el siguiente:
El sistema funcionar un servidor con las siguientes caractersticas:

pentium de 2,4 Ghz, con

mother board D845

1,5 G Ram DDR

2 disco scsi 18 Gb Barracuda

2 interfaces de red D-link 10/100

El servidor funciona con un sistema operativo Redhat 8 (con actualizaciones al dia). Este
servidor posee una configuracin orientada a la prestacin de servicios web con caractersticas
de seguridad y funcionalidad del ms alto nivel. Como servidor web, SID utiliza Apache 2.0.40
con el mdulo PHP4 y con el mdulo SSL. Este ltimo permite al servidor establecer
conexiones seguras del tipo HTTPS. El sistema de gestin estar implementado en PHP4 y
ser accesible desde Internet y poseer una base de datos propia. Adems deber mirar la
informacin de la base de datos del Workflow, que estar presente en el mismo servidor.
Las bases de datos MySQL utilizadas por el sistema estn funcionando en el mismo servidor
SID. La versin instalada de MySQL es la 3.23.55a (mysql-max). La aplicacin deber ser
usable desde los browsers MSIE 5.0, Netscape 4.78, Opera 7.0 y Konqueror 3.04.
Para un buen funcionamiento del sistema, el usuario deber acceder a l a travs de un
computador que tenga por lo menos las capacidades de un PC pentium III de 300 MHz con 64
MB de RAM, con un monitor de 17 pulgadas con una resolucin de 1024x768 pixeles.

Documento de Requisitos de Sistema de Ejemplo

Pgina 4

La comunicacin al interior de la organizacin se realiza a travs de redes Ethernet a 100mbps

cabladas con UTP, cat.5, y redes wireless IEEE 802.11b/g a 10Mbps. Ambos tipos de redes
utilizan TCP/IP como protocolo de comunicacin. Para la macro-distribucin de paquetes se
emplean mayoritariamente routers y switches inteligentes.]

2.4 Relacin con Otros Proyectos

[Ac de debe especificar si este proyecto tiene relacin con algn sistema ya implementado,
con otro proyecto en ejecucin o planificado. Por ejemplo:
El sistema no depende de otros sistemas, ni otros sistemas dependen de l. Sin embargo, por
ser un proyecto para el DCC en el cual se involucran usuarios pertenecientes al DCC existe
una relacin de coordinacin con otros sistemas asociados al manejo de perfiles de usuario, ya
sea para acadmicos, alumnos, secretarias u otros.
En particular, el manejo de usuarios del sistema estar integrado con otros 2 proyectos que se
estn desarrollando actualmente para el DCC, estos son: el sistema de administracin de
publicaciones cientficas (grupo 6, curso cc51a) y el sistema contable del PEC (grupo 5, curso
cc51a). As el acceso al sistema se realizar en forma conjunta con los otros 2 sistemas a
travs del sitio Web del DCC cuya direccin es: www.dcc.uchile.cl, mediante el ingreso de un
username y un password de cada usuario y en forma directa para acadmicos conectados
desde su PC en el DCC. Esto crear una sesin del usuario, que podr ingresar al sitio de
nuestro proyecto con el rol que tenga asignado. Esto ser muy conveniente para usuarios de
los 3 sistemas, principalmente acadmicos ya que tendrn un identificador comn para todos
los sistemas ingresando a cualquiera de ellos en forma de una Intranet.
Esto significar una coordinacin asociada a usuarios entre los 3 sistemas en cuanto a un
manejo comn de tablas asociadas a usuarios, la coordinacin estar a cargo del auxiliar del
curso Renzo Angles. Adems los sistemas debern tener un look & feel similar al sitio actual del
DCC, ocupando los mismos CSS que el sitio del DCC.]

2.5 Descripcin del Modelo

[Aqu hay que presentar un diagrama general de casos de uso, diagrama de bloques o bien un
DFD de nivel 1 o 2, que refleje el funcionamiento actual. En caso de ser necesario, se puede
agregar una explicacin del funcionamiento general del sistema actual. Por ejemplo:
El modelo lgico del sistema ser mostrado mediante diagramas de casos de uso que
muestran las funcionalidades bsicas del sistema y sus actores, este es el siguiente:

Documento de Requisitos de Sistema de Ejemplo

Pgina 5

Reservas

Consultar reserva

Reservar recurso en horarios

disponibles
Usuario General
Cancelar reserva propia

Usuario Comn

Modificar reserva propia

Reservar recurso en cualquier horario

Cancelar cualquier reserva

Modificar cualquier reserva

Super Usuario

Documento de Requisitos de Sistema de Ejemplo

Pgina 6

Recursos
Consultar Recurso

Agregar recurso
Usuario General

Eliminar recurso

Modificar informacin del recurso

Reservar

Usuario Administrador

Deshabilitar recurso

Habilitar recurso

Documento de Requisitos de Sistema de Ejemplo

Pgina 7

Usuarios
Agregar usuario

Eliminar Usuarios

SAU
Modificar informacin de usuario

Estadsticas
Obtencin de estadsticas

Usuario Administrador

Documento de Requisitos de Sistema de Ejemplo

Pgina 8

3 Requisitos del Sistema

Esta seccin describe los requisitos de los Usuarios y de los Clientes (seccin 3.1), y los
requisitos de software (seccin 3.2) con los que debe cumplir el sistema. [Para facilitar la
especificacin y la administracin de requisitos, puede emplearse la herramienta ReqAdmin,
las cual est disponible en ChileForge: http://chileforge.cl/projects/reqadmin]

3.1 Requisitos de Usuario

[Esta seccin describe los requisitos usuario del sistema, por categora. La planilla definida
para especificar los requisitos contiene los siguientes atributos:
Atributo
Identificador
Nombre
Descripcin
Prioridad

Fuente
Estabilidad

Estado
Listado de Usuarios
Caso de Prueba

Descripcin
Este es un cdigo nico que sirve para identificar o reconocer el
requisito. Para los requisitos de usuarios se utilizar el formato
RUXXXX y para los de software RSXXXX
Nombre en lenguaje normal del requisito
Descripcin del requisito. Qu aspectos involucra, en qu
consiste, etc.
Prioridad asociada al requisito, esta puede ser crtica, deseable
o innecesaria. Un requisito es crtico si afecta una operacin
crtica del negocio. Si existe algn proceso que se quiera incluir
para mejorar los procesos actuales, estamos ante un requisito
deseable y si se trata de un requisito informativo o que puede
esperar para fases posteriores, el requisito es catalogado como
innecesario.
Documento o persona desde la cual surgi el requisito
Este campo tiene como propsito sealar si el requisito puede o
no puede estar sujeto a cambio durante el ciclo de vida del
software (tranzable o intranzable). El estndar de la ESA lo
define como estable o no estable.
Estado actual del requisito dentro del desarrollo (Cumple, No
Cumple, Ambiguo)
Son los tipos de usuarios que estn asociados al requisito
Caso con el cual se probar si se cumple o no con el requisito en
el sistema.

3.1.1 Requisitos de Capacidades

[Ac hay que colocar la lista de requisitos de capacidad con la que debera cumplir el producto
segn los clientes y los usuarios involucrados. Estos requisitos pueden ser ambiguos, y en ese
caso hay que desambiguarlos a travs del uso de prototipos rpidos, por ejemplo. Un vez que
los requisitos han sido desambiguados, se los debe especificar como requisitos de software
(que se presentan en la seccin 3.2). Un ejemplo de la especificacin de un requisito de
usuario es la siguiente:
UR100

Incrustar Discusin

Documento de Requisitos de Sistema de Ejemplo

Pgina 9

Prioridad: Alta

Los usuarios deben poder incrustar un componente configurable en un componente de

contenido en el cliente CDS. Y al hacer esto deben tener la opcin de configurarlo definiendo
el nombre de la discusin, una afirmacin/pregunta, una fecha de expiracin y una prioridad, y
tener asociados el autor, la fecha de creacin y un identificador de la discusin.
Fuente: Entrevista con el cliente
Estabilidad: Intranzable

Usuarios: Profesor, Auxiliar (Usuarios del Cliente

CDS)
Estado: No cumplido

CP005

3.1.2 Requisitos de Calidad

[Ac hay que colocar la lista de requisitos de calidad con los que debera cumplir el producto.
Estos requisitos no pueden ser ambiguos, y por lo que en esta fase deberan ser
desambiguados (en caso de ser necesario). Estos requisitos se deben especificar segn el
formato preestablecido.]

3.1.3 Requisitos de Restriccin

[Ac hay que colocar la lista de requisitos que especifican restricciones a cerca de cmo debe
ser construido (se refiere a conexiones con otros sistemas, o adhesin a los estndares de la
empresa) y operado el software. Estos requisitos no pueden ser ambiguos, y por lo que en
esta fase deberan ser desambiguados (en caso de ser necesario). Estos requisitos se deben
especificar segn el formato preestablecido.]

3.2 Requisitos de Software

[Los requisitos de software representan est basados en los requisitos de usuario, y
representan la visin de la empresa desarrolladora acerca de lo que hay que disear y
construir. Estos requisitos no pueden ser ambiguos. La planilla definida para especificar los
requisitos contiene los siguientes atributos:
Atributo
Identificador
Nombre
Descripcin
Prioridad

Descripcin
Este es un cdigo nico que sirve para identificar o reconocer el
requisito. Para los requisitos de usuarios se utilizar el formato
RUXXXX y para los de software RSXXXX
Nombre en lenguaje normal del requisito
Descripcin del requisito. Qu aspectos involucra, en qu
consiste, etc.
Prioridad asociada al requisito, esta puede ser crtica, deseable
o innecesaria. Un requisito es crtico si afecta una operacin
crtica del negocio. Si existe algn proceso que se quiera incluir
para mejorar los procesos actuales, estamos ante un requisito
deseable y si se trata de un requisito informativo o que puede
esperar para fases posteriores, el requisito es catalogado como

Documento de Requisitos de Sistema de Ejemplo

Pgina 10

Fuente
Estabilidad

Estado
Listado de Usuarios
Caso de Prueba

innecesario.
Documento o persona desde la cual surgi el requisito
Este campo tiene como propsito sealar si el requisito puede o
no puede estar sujeto a cambio durante el ciclo de vida del
software (tranzable o intranzable). El estndar de la ESA lo
define como estable o no estable.
Estado actual del requisito dentro del desarrollo (Cumple, No
Cumple, Ambiguo)
Son los tipos de usuarios que estn asociados al requisito
Caso con el cual se probar si se cumple o no con el requisito en
el sistema.

De la misma manera, tambin se gener una clasificacin para los requisitos de software. Las
categoras definidas para los requisitos de software son las siguientes:

Funcionales: Indican cules deben ser las capacidades del software. Se derivan del modelo
lgico.

Interfaz: Especifican el hardware, software o elementos de bases de datos con los que el
sistema o sus componentes interactan o se comunican.

Operacionales: Especifican la forma en que correr el sistema y como se comunicar con

los operadores humanos. Incluyen todas las interfaces de usuario, interaccin humanocomputador, y requisitos logsticos y organizacionales.

Recursos (Ambiente Operacional): Especifican los lmites superiores de los recursos fsicos
tales como capacidad de procesamiento, memoria principal, espacio en disco, etc.

Usabilidad: Estos son los relacionados con el esfuerzo de uso, y la evaluacin del uso,
realizada por los usuarios.

Mantenibilidad: Requisitos relacionados con el esfuerzo de hacer modificaciones.

Especifican cuan fcil es reparar fallas y adaptar el software a nuevos requisitos

Portabilidad: Tiene que ver con la habilidad de ser transferido de un ambiente a otro.

Confiabilidad: Son aquellos que estn relacionados con la capacidad de mantener un nivel
adecuado de servicio, bajo ciertas condiciones y por cierto tiempo. Especifican los tiempos
medios entre fallas aceptables.

Interoperabilidad: Habilidad de interactuar con determinados sistemas.

Rendimiento: Establecen valores numricos para variables medibles que guardan relacin
con el rendimiento del sistema.

Documentacin: Especifican requisitos particulares del proyecto para la documentacin.

Escalabilidad: Especifica la capacidad del sistema para mantener, si no mejorar, su

rendimiento medio conforme aumenta el nmero de usuarios.

Documento de Requisitos de Sistema de Ejemplo

Pgina 11

3.3 Matriz de Trazado Requisitos de Usuario vs. Requisitos de

Software

Documento de Requisitos de Sistema de Ejemplo

Pgina 12

4 Pruebas de Sistema
4.1 Pruebas de Usuario
En esta seccin se especificarn las pruebas que se harn sobre el sistema, para
determinar que se cumplen los requisitos de usuario. Una prueba puede dar
lugar a muchos casos de prueba.

4.2 Matriz de Trazado Requisitos de Usuario vs. Pruebas

Tabla 1: Matriz de requisitos de usuario versus las pruebas

RP1
RU1 x
RU2
RU3
RU4

RP2

RP3

RP4

RP5

4.3

Documento de Requisitos de Sistema de Ejemplo

Pgina 13

X
x

RP6

RP7

RP8

RP9
x

RP10
X