Documento de Requisitos

de Usuario / Software

Sistema de Ejemplo
[Comentario: todo lo que está entre paréntesis es un comentario,
por lo tanto debe ser instanciado o removido… incluyendo este
comentario]

Fecha: [fecha último cambio]

Versión: [versión actual]

Equipo de Desarrollo:

Por ejemplo:
Nombre Rol Contacto
Juan Carlos Pérez Administrador del Proyecto [email protected]
(56 2) 345-4369
Juana Alvarez Analista [email protected]
(56 2) 345-4363
Alberto González Diseñador [email protected]
(56 2) 345-4367

Documento de Requisitos de Sistema de Ejemplo

Página 1
 Historia del Documento

Versión Fecha Razón del Cambio Autor(es)

0.1 08/08/2005 Primer borrador

Documento de Requisitos de Sistema de Ejemplo

Página 2
 Índice

Historia del Documento.............................................................................................................ii

1 Introducción...................................................................................................................... 1
1.1 Propósito del Sistema.....................................................................................................................1
1.2 Alcance del Proyecto......................................................................................................................1
1.3 Contexto.........................................................................................................................................1
1.4 Definiciones, Acrónimos y Abreviaturas........................................................................................1
1.5 Referencias.....................................................................................................................................2

2 Descripción General......................................................................................................... 3
2.1 Características de los Usuarios.......................................................................................................3
2.2 Tabla de Requisitos del Software...................................................................................................4
2.3 Requisitos de Usuario.....................................................................................................................4

Documento de Requisitos de Sistema de Ejemplo

Página 3
1

Documento de Requisitos de Sistema de Ejemplo

Página 4
2 Introducción
En esta introducción se describe brevemente el contexto, objetivos y alcance del
sistema a desarrollar, así como la documentación relativa al mismo. Esta
información está basada en el Documento de Proposición de Proyecto (DPP) de
Sistema de Ejemplo.
[Para usar esta plantilla, debe remover todos los párrafos que están entre corchetes,
como éste, y reemplazarlos por un texto adecuado (este es el único párrafo entre
corchetes que no se reemplaza por nada). Además, debe ir al menú File (archivo),
opción 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 página y
actualice la referencia al nombre del sistema.]

2.1 Propósito del Sistema

[Describir aquí qué hace y qué es el sistema. Para proyectos pequeños, media
página debería ser más que suficiente.]

2.2 Alcance del Proyecto

[Describir hasta dónde llega el proyecto: qué es y qué no es. Para proyectos
pequeños, media página debería ser más que suficiente.]

2.3 Contexto
[Dar información respecto del contexto del desarrollo y el contexto en el que se tiene
que insertar el sistema. Tecnologías que estarán involucradas, trabajos previos,
vínculos con otros sistemas, etc. Escriba lo que necesite, en general los gráficos son
bienvenidos, pues ayudan mucho a la comprensión]

2.4 Definiciones, Acrónimos y Abreviaturas

[Indique aquí la definición de las “palabras claves” (o keywords) que se emplearán
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 más. La
lista DEBE estar en orden alfabético para facilitar la búsqueda de conceptos.
Ejemplos de definiciones, siglas y abreviaturas son las siguientes:

Comunicación Wireless: Tipo de comunicación de datos que se efectúa a través

de antenas embebidas o adosadas a dispositivos computacionales.
TCP (Transmisión Control Protocol): Protocolo de comunicación de datos
orientado a la conexión. Generalmente usado en redes de computadoras.
URD (User Requirement Document): Documento que expresa los requisitos de los
usuarios/clientes de un sistema.

Documento de Requisitos de Sistema de Ejemplo

Página 1
 REP_1: Se le llamará de esta manera a los reportes de ventas que el sistema debe
emitir al finalizar la jornada laboral.]

2.5 Referencias
[Enumere la documentación y bibliografía 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

Página 2
3 Descripción General
Esta sección describe los requisitos funcionales de los Usuarios/Clientes (sección 2.1sistema,
sus interfaces externa, las condiciones de excepción y las clases de pruebas que se harán para
verificar que los requisitos se cumplen.

3.1 Características de los Usuarios

[Acá se deben identificar los tipos de usuarios, los atributos generales de cada tipo y la
cantidad de personas en cada categoría. Por ejemplo:

Los usuarios del sistema son:

Tipo de Usuario Descripción

Usuario Común Sólo puede hacer la reserva de un recurso en particular en

módulos en los que el recurso este disponible, es decir, no
haya sido reservado por otro usuario con anterioridad.
Además puede cancelar su propia reserva y modificarla
siempre y cuando el horario esté disponible.

Súper Usuario Puede realizar reservas de un recurso sobre cualquier

módulo, incluso si esta ocupado por otro usuario. Además
puede cancelar y modificar cualquier reserva hecha en el
sistema.

Usuario Administrador Realiza todo el manejo recursos y estadísticas, es decir,

puede agregar, eliminar, modificar, deshabilitar o habilitar
cualquier recurso del sistema y maneja las estadísticas,
personalizando la estadística que quiere obtener
desplegándola en pantalla. El manejo de usuarios se realiza a
través del SAU.

Usuario general o Este es cualquier persona que visite la página del sistema,
visitante sólo puede consultar la información de las reservas y los
recursos disponibles.

Documento de Requisitos de Sistema de Ejemplo

Página 3
3.2 Tabla de Requisitos del Software
[Los requisitos de software representan está basados en los requisitos de usuario, y
representan la visión de la empresa desarrolladora acerca de lo que hay que diseñar y
construir. Estos requisitos no pueden ser ambiguos.

Identificador Tipo de Nombre del Requisito

Requisito
RU1 Usuario Nombre en lenguaje normal del requisito

RU2 Usuario Puede realizar reservas de un recurso sobre cualquier

módulo, incluso si esta ocupado por otro usuario. Además
puede cancelar y modificar cualquier reserva hecha en el
sistema.

UR100 Capacidad Incrustar Discusión

3.3 Requisitos de Usuario

[Esta sección describe Descripción

los requisitos usuario
del sistema, por
categoría. La planilla
definida para
especificar los
requisitos contiene los

Documento de Requisitos de Sistema de Ejemplo

Página 4
 siguientes
atributos:Atributo
Identificador Este es un código ú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 Nombre en lenguaje normal del requisito
Descripción Descripción del requisito. Qué aspectos involucra, en qué
consiste, etc.
Prioridad Prioridad asociada al requisito, esta puede ser crítica, deseable
o innecesaria. Un requisito es crítico si afecta una operación
crítica del negocio. Si existe algún 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.
Fuente Documento o persona desde la cual surgió el requisito
Usuarios Son los tipos de usuarios que están asociados al requisito
Caso de Prueba Caso con el cual se probará si se cumple o no con el requisito en
el sistema.

UR100 Incrustar Discusión 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 opción de configurarlo definiendo
el nombre de la discusión, una afirmación/pregunta, una fecha de expiración y una prioridad, y
tener asociados el autor, la fecha de creación y un identificador de la discusión.
Fuente: Entrevista con el cliente Usuarios: Profesor, Auxiliar (Usuarios del Cliente
CDS)
OBS: Podemos agregar diseños, mockups o descripción de base de datos

3.3.1 Requisitos de Capacidades

[Acá hay que colocar la lista de requisitos de capacidad con la que debería cumplir el producto
según los clientes y los usuarios involucrados. Estos requisitos pueden ser ambiguos, y en ese
caso hay que desambiguarlos a través del uso de prototipos rápidos, por ejemplo. Un vez que
los requisitos han sido desambiguados, se los debe especificar como requisitos de software
(que se presentan en la sección 3.2). Un ejemplo de la especificación de un requisito de
usuario es la siguiente:

UR100 Incrustar Discusión 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 opción de configurarlo definiendo
el nombre de la discusión, una afirmación/pregunta, una fecha de expiración y una prioridad, y
tener asociados el autor, la fecha de creación y un identificador de la discusión.
Fuente: Entrevista con el cliente Usuarios: Profesor, Auxiliar (Usuarios del Cliente

Documento de Requisitos de Sistema de Ejemplo

Página 5
 CDS)
OBS:

3.3.2 Requisitos de Calidad

[Acá hay que colocar la lista de requisitos de calidad con los que debería cumplir el producto.
Estos requisitos no pueden ser ambiguos, y por lo que en esta fase deberían ser
desambiguados (en caso de ser necesario). Estos requisitos se deben especificar según el
formato preestablecido.]

3.3.3 Requisitos de Restricción

[Acá hay que colocar la lista de requisitos que especifican restricciones a cerca de cómo debe
ser construido (se refiere a conexiones con otros sistemas, o adhesión a los estándares de la
empresa) y operado el software. Estos requisitos no pueden ser ambiguos, y por lo que en
esta fase deberían ser desambiguados (en caso de ser necesario). Estos requisitos se deben
especificar según el formato preestablecido.]

De la misma manera, también se generó una clasificación para los requisitos de software. Las
categorías definidas para los requisitos de software son las siguientes:

 Funcionales: Indican cuáles deben ser las capacidades del software. Se derivan del modelo
lógico.

 Interfaz: Especifican el hardware, software o elementos de bases de datos con los que el
sistema o sus componentes interactúan 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, interacción humano-
computador, y requisitos logísticos y organizacionales.

 Recursos (Ambiente Operacional): Especifican los límites superiores de los recursos físicos
tales como capacidad de procesamiento, memoria principal, espacio en disco, etc.

 Usabilidad: Estos son los relacionados con el esfuerzo de uso, y la evaluación del uso,
realizada por los usuarios.

 Mantenibilidad: Requisitos relacionados con el esfuerzo de hacer modificaciones.

Especifican cuan fácil 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.

Documento de Requisitos de Sistema de Ejemplo

Página 6
 Confiabilidad: Son aquellos que están 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 numéricos para variables medibles que guardan relación
con el rendimiento del sistema.

 Documentación: Especifican requisitos particulares del proyecto para la documentación.

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

rendimiento medio conforme aumenta el número de usuarios.

3.4

Documento de Requisitos de Sistema de Ejemplo

Página 7