ANALISIS DE REQUISITOS DEL SISTEMA

Cliente: [Indicar organización cliente]

Proyecto: [Indicar nombre del proyecto]

Versión: [Versión del documento]

Autor: [Equipo o persona que genera el documento]

Documento de Toma de Requerimientos del Sistema

Pág. 1 de 6
Contenido

1 OBJETIVO ..............................................................................................................................................3

2 ALCANCE ...............................................................................................................................................3

2.1 ACTIVIDADES INCLUIDAS ......................................................................................................................3

2.2 ACTIVIDADES IDENTIFICADAS FUERA DEL ALCANCE ........................................................................3

3 SITUACIÓN ACTUAL ...............................................................................................................................3

4 REQUERIMIENTOS (REQUISITOS) ..........................................................................................................3

5 RECURSOS TECNOLÓGICOS ACTUALES ..................................................................................................3

6 MODELO DE PROCESO DE NEGOCIO .....................................................................................................4

7 REQUISITOS FUNCIONALES DEL SISTEMA ..............................................................................................4

8 INFORMES PREDEFINIDOS.....................................................................................................................5
8.1 INFORME 01 ...................................................................................................................................5

9 INTERFAZ DE USUARIO (INGRESO DE DATOS) .......................................................................................5

9.1 INTERFAZ DE USUARIO 01 ...............................................................................................................5

10 INTERFACES CON OTROS SISTEMAS ......................................................................................................5

11 PROCEDIMIENTOS. ................................................................................................................................5
11.1 ESTRATEGIA DE MIGRACIÓN DE DATOS ..........................................................................................5
11.2 CARGAS INICIALES ..........................................................................................................................6

12 GLOSARIO DE TÉRMINOS ......................................................................................................................6

13 ANEXOS .................................................................................................................................................6

Control de Versiones

Versión Responsable Fecha Descripción del cambio

Documento de Toma de Requerimientos del Sistema

Pág. 2 de 6
1 Objetivo
El documento tiene por objetivo, identificar la funcionalidad del sistema afectada por el proyecto.

Se destaca además, que el documento contiene informaciones fuera de la funcionalidad, que en su

conjunto sirven para realizar la valoración, previa necesaria para poder realizar un caso de negocio que
permita verificar la viabilidad del proyecto en cuestión.

2 Alcance
Delimitar el alcance del sistema a nivel general, detallando claramente las actividades que serán incluidas
y las actividades excluidas del proyecto.

2.1 Actividades incluidas

Se debe dejar claramente definido que actividades se incluyen en la propuesta de solución del
proyecto y a que áreas y responsables involucra y alcanza esta solución.

2.2 Actividades identificadas fuera del alcance

Enumerar todas aquellas actividades que quedan fuera del alcance del proyecto. Tiene suma
importancia, ya que delimita el alcance y le da un marco a las expectativas iniciales que tiene el
cliente

3 Situación Actual
Se debe definir en este apartado cual es la situación real o conflictiva que hace que el cliente posea la
necesidad de una nueva solución y realice la petición de un nuevo proyecto de solución.

4 Requerimientos (Requisitos)
Enumerar los requisitos del cliente con la finalidad que el cliente reconozca la información proporcionada
por él.

Se destaca que los Requisitos del Cliente no son características de la solución, sino una definición del
problema a resolver (cuáles son las necesidades del cliente, no como se implementarán los cambios)

5 Requerimientos no funcionales
Enumerar aquellos requerimientos que hay que atender pero no afectan a un caso de uso en cuestión. Son
restricciones técnicas a las funcionalidades definidas.

6 Recursos tecnológicos actuales

Enumerar la tecnología actual utilizada por el cliente.

Documento de Toma de Requerimientos del Sistema

Pág. 3 de 6
7 Modelo de Proceso de Negocio (BPM)
Adjuntar en la siguiente tabla, el/los documento/s, que se extraen de la herramienta corporativa de
modelado de procesos que posea la organización, que contiene los procesos de negocio vigentes o
actualizados, cuyas actividades se ven afectadas por el proyecto.

8 Requisitos Funcionales del Sistema

a. Casos de Uso
Los Requisitos Funcionales del Sistema se expresan mediante Casos de uso.
Se deben identificar aquellas actividades del proceso de negocio (BPM) que están afectadas por el
sistema
Las actividades deben asociarse a casos de uso, puede existir una relación de 1 a 1 (una actividad, un
caso de uso) o de 1 a N (una actividad, varios casos de uso)
Pueden existir requisitos funcionales que no estén asociados a ninguna actividad del proceso de
negocio, como por ejemplo, los mantenimientos de datos maestros, en estos casos, se define como un
caso de uso, sin actividad asociada.

CUXX – Nombre Cuxx = Código de Caso de Uso

Descripción Enunciar la finalidad del caso de uso
Actores que intervienen Enumeración de los actores que intervienen en el caso de uso
Precondición La precondición está formada por el conjunto de condiciones que se tienen que cumplir
para que se pueda iniciar un caso de uso. En muchos casos supone la ejecución de casos
de uso previos.
Resumen de la Se espera que en este apartado se explique de manera tecnológica que es lo que debe
funcionalidad resolver la funcionalidad a alto nivel y que reglas de negocio se deben aplicar para poder
implementar la misma.
Dicha descripción debe indicar claramente para cada uno de los actores definidos en
dicha funcionalidad que tareas realiza cada uno de ellos de manera parcial o general
dentro de la misma.
Postcondición La postcondición refleja el estado en que se queda el sistema una vez ejecutado el caso
de uso.
Observaciones

b. Tabla de relación entre BPM y CU

Completar la siguiente matriz que indica la relación entre actividad de proceso de negocio /actividad y caso de
uso. La misma está vinculada a lo definido en el apartado 3 de este documento

Diagrama Actividad Caso de Uso

Código – Nombre Código – Nombre [Enumere el/los casos de uso que se relacionan con la
Diagrama de Actividad actividad de proceso de negocio]
Procesos

Documento de Toma de Requerimientos del Sistema

Pág. 4 de 6
9 Informes predefinidos
Se deberán identificar los informes predefinidos más importantes, así como particularidades asociadas a los
mismos, bien por su dificultad o por considerar que no cumplen los estándares.

9.1 Informe 01
Detalle del informe

10 Interfaz de usuario (ingreso de datos)

Incluir un esquema preliminar de la interfaz de usuario de la aplicación. Se recomienda aclarar que la interfaz de
usuario descrita en este documento no representa el aspecto definitivo que tendrá el sistema, sino que puede
variar a medida que se avance con la especificación detallada de los requisitos funcionales.

10.1 Interfaz de usuario 01

Detalle de la interfaz de usuario

11 Interfaces con otros sistemas

Enumerar las interfaces que existen con otros sistemas, e incluir aquella información disponible que pueda ser
de utilidad a efectos de realizar una estimación de esfuerzo, pero teniendo en cuenta que se trata de
documentación funcional que debe ser validada por los usuarios, por lo que en este documento no se deben
mencionar detalles de diseño técnico de las interfaces.

Aplicación Origen Aplicación Destino Breve descripción de la interfaz Responsible

(propósito, datos a intercambiar)

12 Procedimientos.
12.1 Estrategia de migración de datos
En caso de requerirse la migración de datos desde otros sistemas o desde una versión anterior del
sistema a desarrollar, describir en este apartado el procedimiento previsto, teniendo en cuenta que
se trata de documentación funcional que debe ser validada por los usuarios (omitir consideraciones
técnicas, ya que estas serán documentadas en fase de Diseño Técnico). Indicar qué datos se van a
migrar y cuáles son los orígenes de dichos datos. Indicar también, a nivel funcional, si es necesario
algún tipo de transformación, depuración o filtrado previo a la migración, y enunciar a alto nivel la
estrategia a seguir (ej. migración completa antes de la puesta en marcha, migraciones incrementales
durante un período de tiempo, etc.) Mencionar también los interlocutores y/o responsables de los
orígenes de datos a migrar.

Documento de Toma de Requerimientos del Sistema

Pág. 5 de 6
 12.2 Cargas iniciales
En caso de requerirse una carga inicial de datos para poder comenzar a operar con el sistema,
describir en este apartado, a alto nivel, el procedimiento previsto para efectuar dichas cargas. Indicar
qué datos requieren carga inicial y de dónde se obtienen. Distinguir también aquellos datos cuya
carga inicial se debe hacer manualmente de aquellos que requieren algún tipo de proceso de carga
automático. Indicar un interlocutor o responsable de la validación de los datos que conforman la
carga inicial.

13 Glosario de términos
Enumerar aquellos términos que se consideren importantes, para el entendimiento por parte del cliente

14 Anexos
Se adjunta toda la documentación de soporte que sea necesaria.

Documento de Toma de Requerimientos del Sistema

Pág. 6 de 6