Proyecto: -----------Incluir el nombre del proyecto------------------------------------------------------------

Fecha: dd/mm/aaaa
Versión: aa-mm-dd- ##

Esquema general del documento de requerimientos del sistema de software – CI-4712

1 Introducción
1.1 Alcance del documento
1.2 Glosario, (incluir Acrónimos y Abreviaturas)
Contiene las definiciones de todos los términos, siglas y abreviaciones que se utilizarán en el documento
1.3 Documentos relacionados – Anexos y apéndices
Lista (índice) de los anexos y apéndices a los cuales se hará referencia en el documento

N° de Anexo / Fecha Título / Nombre Autor ID del documento

Anexo ## - dd/mm/aaaa Texto Texto ###-texto

2 Descripciones de Casos de Uso

2.1 Tabla de Actores / Interesados
2.2 Tabla de Casos de Uso
2.3 Diagramas de cada Caso de Uso (formato general)
2.4 Especificaciones de cada Caso de Uso
Puede utilizar el esquema siguiente:

Caso de Uso – ID Defina la sintaxis del ID (incluir la sintaxis en el glosario).

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso
de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para
conseguir un objetivo específico.
Nombre/ID: Nombre del caso de uso. Puede combinarlo con el ID del caso de uso.
Descripción: Describir el objetivo y el propósito del caso de uso.
Requerimiento: Lista de los requerimientos que abarcan a este caso de uso.

1 de 5
 Proyecto: -----------Incluir el nombre del proyecto------------------------------------------------------------
Fecha: dd/mm/aaaa
Versión: aa-mm-dd- ##

Caso de Uso – ID Defina la sintaxis del ID (incluir la sintaxis en el glosario).

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso
de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para
conseguir un objetivo específico.
Precondiciones: Lista de precondiciones antes de llevarse a cabo el proceso.
Flujo Normal: Describa la interacción entre un actor y el sistema, en base a pasos enumerados.
Actor Sistema
Describir cada uno de los pasos del flujo realizado por un actor. Describir cada uno de los pasos del flujo realizado por algún recurso
del sistema.

Flujo Alterno:
El flujo alterno describe el comportamiento del sistema en caso de alguna excepción sobre el flujo normal del proceso o evento
Actor Sistema
Describir cada paso alterno del flujo realizado por un actor. Describir cada paso alterno del flujo realizado por algún recurso del
sistema.

Postcondiciones: Listar las condiciones en que se encuentra el sistema después de haberse ejecutado el proceso.
Requerimientos Nombrar y describir cualquier requerimiento que no haya sido abarcado por el flujo normal o los alternos.
Especiales:
Puntos de Extensión: Se debe mencionar y describir los puntos en los cuales el flujo de eventos se extiende por otros casos de uso.

Nota: Cada paso del flujo de los eventos debe ser enumerado, manteniendo una secuencia entre los pasos del flujo realizado por un actor y los
pasos del flujo realizado por algún recurso del sistema.

3 Requerimientos Funcionales
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Son entendidos como
capacidades que debe exhibir una aplicación con el fin de resolver un problema. Se clasifican en:

2 de 5
 Proyecto: -----------Incluir el nombre del proyecto------------------------------------------------------------
Fecha: dd/mm/aaaa
Versión: aa-mm-dd- ##

• Requerimientos de datos o información, también denominados requerimientos de contenido, requerimientos conceptuales o

requerimientos de almacenamiento de información. Éstos requerimientos responden a preguntas del tipo ¿qué información debe almacenar
y administrar el sistema?
• Requerimientos de interfaz (con el usuario), también llamados en algunas propuestas requerimientos de interacción o de usuario.
Responden a la pregunta ¿cómo va a interactuar el usuario con el sistema?
• Requerimientos de navegación, recogen las necesidades de navegación del usuario.
• Requerimientos de personalización, describen cómo debe adaptarse el sistema en función de qué tipo de usuario interactúe con él y de
la descripción actual de dicho usuario.
• Requerimientos transaccionales o funcionales internos, recogen qué debe hacer el sistema de forma interna, sin incluir aspectos de
interfaz o interacción. También son conocidos en el ambiente web como requerimientos de servicios.

Utilice el esquema siguiente:

ID del Requerimiento: Colocar el ID del requerimiento funcional. Defina la sintaxis del ID (incluir la sintaxis en el glosario).

Nombre del Requerimiento: Colocar el nombre del requerimiento funcional.

Identificación del Identificación del requerimiento funcional (debe ser consistente con su identificación y utilización en el
requerimiento: glosario).

Características: Tipo de requerimiento según la clasificación anterior. Definir todas las características.

Descripción del Describir el requerimiento funcional con información suficiente para ser utilizada más adelante en el
requerimiento: proceso de especificación y diseño. Pueden utilizar representaciones gráficas si lo desean, y estas
deben anexarse al documento.
Requerimiento NO funcional: Especificar el (los) requerimientos NO funcionales que impactan en este requerimiento funcional.
Explique en detalle.
Prioridad del requerimiento:
O Alta O Media Alta O Media O Media Baja O Baja

3 de 5
 Proyecto: -----------Incluir el nombre del proyecto------------------------------------------------------------
Fecha: dd/mm/aaaa
Versión: aa-mm-dd- ##

4 Requerimientos No Funcionales
Requerimientos no funcionales: son llamados también requerimientos de calidad, y describen aquellos niveles deseables de calidad de las
funcionalidades y servicios que provee la aplicación. Para definir el tipo de requerimientos no funcionales, los autores y desarrolladores se
basan en el estándar ISO/IEC 9126: este define un modelo independiente de la tecnología para caracterizar la calidad de software y considera
las siguientes características:
1. Funcionalidad: describe la presencia de funciones (funcionalidades) para alcanzar propiedades definidas. Ejemplos:
interoperabilidad, seguridad
2. Confiabilidad: describe la disponibilidad que tiene el producto para mantener sus niveles de rendimiento bajo condiciones
específicas y en un tiempo dado. Ejemplos: madurez, tolerante a fallas, recuperabilidad.
3. Usabilidad: describe el esfuerzo requerido por el usuario en la utilización de la aplicación. Ejemplo: velocidad de aprendizaje,
eficacia, operabilidad.
4. Eficiencia: describe la tasa entre el nivel de rendimiento de la aplicación y los recursos que ésta utiliza bajo condiciones
específicas.
5. Capacidad de mantenimiento: describe el esfuerzo requerido para implementar cambios predeterminados en una aplicación.
Ejemplo: estabilidad, validaciones.
6. Portabilidad: describe la conveniencia de que una aplicación pueda ser llevada de un ambiente a otro. Ejemplo: adaptabilidad,
capacidad de instalación, capacidad de replicar.
7. Otras según las condiciones y restricciones del dominio.

Utilice el siguiente esquema:

ID del Requerimiento: Colocar el ID del requerimiento no funcional. Defina la sintaxis del ID (incluir la sintaxis en el glosario).

Nombre del Requerimiento: Colocar el nombre del requerimiento no funcional.

Identificación del Identificación del requerimiento no funcional (debe ser consistente con su identificación y utilización en el
requerimiento: glosario).

4 de 5
 Proyecto: -----------Incluir el nombre del proyecto------------------------------------------------------------
Fecha: dd/mm/aaaa
Versión: aa-mm-dd- ##

Características: Tipo de requerimiento según la clasificación anterior. Definir todas las características. Puede utilizar las
sub características asociadas el estándar ISO/IEC 9126.
Descripción del Describir el requerimiento no funcional con información suficiente para ser utilizada más adelante en el
requerimiento: proceso de especificación y diseño. Pueden utilizar representaciones gráficas si lo desean, y estas deben
anexarse al documento.
Requerimiento funcional Especificar el (los) requerimiento(s) funcional(es) que es (son) impactado(s) por este requerimiento no
impactado: funcional. Explique en detalle.
Prioridad del requerimiento:
O Alta O Media Alta O Media O Media Baja O Baja
Aspectos sobre la Organización. Políticas internas.
Describa cómo se satisfacen cada una de las políticas internas de la organización (condiciones y restricciones del dominio, de la organización,
etc.).

Aspectos sobre la Organización/Staff. Aspectos legales.

Defina los aspectos legales que pudieran afectar el proyecto o cada una de las entregas.

5 de 5