Logo de la institución u Organización

Proyecto:

Versión: <x.y.z>

Nota: El texto incluido en rectángulos azules y el exhibido en cursiva azul se incluye con el fin de
proporcionar una guía para el llenado de este documento y debe ser eliminado antes de publicar el
documento.
1. Requisitos Funcionales

Debe contener una lista detallada y completa de los requisitos que debe cumplir el
sistema a desarrollar. El nivel de detalle de los requisitos debe ser el suficiente para que
el equipo de desarrollo pueda diseñar un sistema que satisfaga los requisitos y los
encargados de las pruebas puedan determinar si éstos se satisfacen.

Los requisitos se dispondrán en forma de listas numeradas para su identificación,

seguimiento, trazabilidad y validación (ej. RF 01, RF 02, RF 03,...).

Para cada requisito debe completarse la siguiente tabla:

Número de requisito Colocar el ID del requerimiento funcional.

Nombre de requisito Colocar el nombre del requerimiento funcional.
Tipo Requisito Restricción
Fuente del requisito Quién solicita el requisito
Descripción Aquí se debe de realizar una descripción del requerimiento
funcional. Se debe colocar información suficiente de tal manera que
sirva de ayuda para el desarrollador del sistema. Cualquier
representación gráfica debe ser anexada en este apartado.
Prioridad del requisito Alta/Esencial media/ Baja/ Opcional
<colocar una de las Deseado
opciones>

2. Casos de uso del Sistema

< Esta sección debe contener la especificación de los casos de uso del sistema,
incluyendo los correspondientes diagramas, la especificación de los actores y la
especificación de los propios casos de uso. Los casos de uso deben describir cómo se
utilizará el sistema a desarrollar por sus futuros usuarios para realizar sus procesos de
negocio.
Esta sección se divide en las secciones que se describen a continuación.>

2.1 Características del usuario :

Esta sección debe contener las especificaciones de los actores que se hayan
identificado en los casos de uso, es decir, los diferentes tipos de usuarios y otros sistemas
con los que deba interactuar el sistema a desarrollar.

Tipo de usuario [Inserte aquí el texto]

Formación [Inserte aquí el texto]
Habilidades [Inserte aquí el texto]
Actividades [Inserte aquí el texto]
Se debe describir las características generales de los usuarios del producto que incluye nivel
educativo, experiencia, y la especialización técnica.

RESUMEN
Código Caso de Uso Actores participantes
Colocar un código Realizar un resumen del caso de uso. Identificar los actores que
nemotécnico (ID) intervienen.

2.2 Diagramas de Casos de Uso del Sistema

Esta sección debe contener los diagramas de casos de uso del sistema que se hayan identificado.
Se debe tener en cuenta que los diagramas de casos de uso no son más que un índice visual de
los casos de uso identificados, ya que la información relevante de los casos de uso (la interacción
entre los actores y el sistema) no se ve reflejada en los diagramas sino en la especificación de los
propios casos de uso del sistema.

Figura 1. Diagrama de Caso de Uso Principal

2.3 Especificaciones de Casos de Uso
En este apartado se debe recoger la especificación completa de cada caso de uso.
Esto incluye los campos: nombre, descripción, actores, precondiciones, flujo
normal, flujo alternativo, puntos de extensión, entre otros. Se debe elaborar una
tabla de especificación por cada caso de uso.

Caso de Uso-Código
Nombre: Colocar nombre del caso de uso.
Descripción: Describir la responsabilidad y el propósito del caso
de uso.
Requerimiento: Identificar los requisitos funcionales que abarcan a
este caso de uso.
Precondición: Tiene que ver con las condiciones en la que debe
estar el sistema para que se ejecute el caso de uso.
Ejemplo: registro y autenticación del cliente.
Flujo Normal:
En el flujo de casos de uso se describe lo que hace el actor y lo que hace el sistema en respuesta.
Se expresa en forma de un diálogo entre actor y sistema. El flujo básico del caso de uso describe
lo que sucede dentro del sistema. Este flujo puede ser representado en forma gráfica. Hay que
tomar en cuenta que el flujo de un caso de uso, debería tener entre cinco y siete pasos
aproximadamente.

Actor Sistema
Describir cada paso del flujo realizado por un Describir cada paso del flujo realizado por algún
actor. recurso del sistema.
1. 2.
3. 4.
5. 6.
Flujo Alterno:
El flujo alterno se refleja el comportamiento alternativo debido a las irregularidades que ocurren en
el flujo de eventos normal. Pueden ser tan largos como sea necesario para describir los eventos
asociados al comportamiento alternativo.

Actor Sistema
Describir cada paso alterno del flujo Describir cada paso alterno del flujo realizado por
realizado por un actor. algún recurso del sistema.
1.1 1.2
2.1 2.2
3.1 3.2
Poscondición: Listar las condiciones en que se encuentra el
sistema después de haberse ejecutado el sistema.
Requerimientos Especiales: Nombrar y describir cualquier requerimiento que no
haya sido abarcado por el flujo normal o los alternos.
Puntos de Extensión: Se debe mencionar y describir los puntos en los
cuales el flujo de eventos se extiende por otros
 Caso de Uso-Código
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. Requisitos no funcionales

Requisitos de rendimiento
Especificación de los requisitos relacionados con la carga que se espera tenga que
soportar el sistema. Por ejemplo, el número de terminales, el número esperado de
usuarios simultáneamente conectados, número de transacciones por segundo que
deberá soportar el sistema, etc.
Todos estos requisitos deben ser mesurables. Por ejemplo, indicando “el 95% de
las transacciones deben realizarse en menos de 1 segundo”, en lugar de “los
operadores no deben esperar a que se complete la transacción”.

Seguridad

Especificación de elementos que protegerán al software de accesos, usos y

sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas o
accidentales. Los requisitos pueden especificar:
 Empleo de técnicas criptográficas.
 Registro de ficheros con “logs” de actividad.
 Asignación de determinadas funcionalidades a determinados módulos.
 Restricciones de comunicación entre determinados módulos.
 Comprobaciones de integridad de información crítica.

Fiabilidad
Especificación de los factores de fiabilidad necesaria del sistema. Esto se expresa
generalmente como el tiempo entre los incidentes permisibles, o el total de
incidentes permisible.

Disponibilidad

Especificación de los factores de disponibilidad final exigidos al sistema.

Normalmente expresados en % de tiempo en los que el software tiene que mostrar
disponibilidad.

Mantenibilidad

Identificación del tipo de mantenimiento necesario del sistema.

Especificación de quien debe realizar las tareas de mantenimiento, por ejemplo
usuarios, o un desarrollador.
 Especificación de cuando debe realizarse las tareas de mantenimiento. Por
ejemplo, generación de estadísticas de accesos semanales y mensuales.

Portabilidad
Especificación de atributos que debe presentar el software para facilitar su
traslado a otras plataformas u entornos. Pueden incluirse:
 Porcentaje de componentes dependientes del servidor.
 Porcentaje de código dependiente del servidor.
 Uso de un determinado lenguaje por su portabilidad.
 Uso de un determinado compilador o plataforma de desarrollo.
 Uso de un determinado sistema operativo.

Otros requisitos
[Inserte aquí el texto]
Cualquier otro requisito que no encaje en ninguna de las secciones anteriores.

Por ejemplo:
Requisitos culturales y políticos
Requisitos Legales