<Institución para quien se desarrolla la aplicación>

DERCAS - <Nombre del

proyecto>

Elaborado por:
<Nombre del consultor>
<Cargo>
<Institución o empresa para la que trabaja>
<Fecha mes y año>
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

Historial de Revisiones

Fecha Versión Descripción Autor

DD/MM/AAAA XX.XX Motivo de la realización del documento Persona encargada
y cambios realizados

Pág. 2
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

Tabla de Contenidos
1 Introducción 4
1.1 Objetivo general y objetivos especificos 4
1.2 Alcance 4

2. Descripción del Problema y Propuesta de Solución 4

2.1 Perspectiva y características del problema 4
2.2 propuesta de solución 4
2.2.1 esquema general de la solución 4
2.2.2 Políticas institucionales o reglamentarias a considerar. 5
2.2.3 Interacción e integración con otras aplicaciones. 5
2.2.4 Especificaciones y requerimientos técnicos generales 5

3. Descripción de CONTRAPARTE (Participantes en el Proyecto) y ACTORES 5

3.1 Resumen de CONTRAPARTE 6
3.2 Resumen de ACTORES 6
3.3 Perfil de la contraparte 6
- Para cada uno de las contrapartes, se debe llenar el siguiente cuadro 6
3.3.1 <Nombre de la contraparte> 6
3.4 Perfiles de los actores 6
- Para cada uno de los tipos de actores, se debe llenar el siguiente cuadro 6
3.4.1 <Nombre del tipo de actor> 7

4. Características Generales y Específicas de la Solución 7

4.1 Descripción de los procesos 7
4.2 Diagrama general del flujo de los procesos 7

5. Precedencia y Prioridad 8

6. Requisitos de Documentación 8
6.1 Manual de Usuario 8
6.2 Ayuda en Línea 9
6.3 Documentación de la base de datos 9
6.4 Guías de Instalación, Configuración, y Fichero Léame 9

7. Modelado UML 9
7.1 Casos de Uso 9
7.2 Diagramas de actividades 11
7.3 Diagramas de clases 11

8. Anexos 11
8.1 Definiciones, Acrónimos, y Abreviaciones 11

Pág. 3
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

DERCAS - <NOMBRE DEL PROYECTO>

1 INTRODUCCIÓN
[Breve descripción del propósito del presente documento, como puede ser servir de soporte a la
especificación de las características software y de los atributos de las mismas, por ejemplo. También
reflejar si el sistema que se modela está dividido en otros subsistemas o bien el propósito general de la
empresa]

1.1 OBJETIVO GENERAL Y OBJETIVOS ESPECIFICOS

1.2 ALCANCE
[Definición del alcance del presente documento, es decir, todo ámbito del que recoge
características o detalles]

2 DESCRIPCIÓN DEL PROBLEMA Y PROPUESTA DE SOLUCIÓN

2.1 PERSPECTIVA Y CARACTERÍSTICAS DEL PROBLEMA

[Cada una de las sentencias que define a cada uno de los problemas]

-¿Cuáles son los problemas?

-¿A quiénes afecta? Personas y áreas de responsabilidad
-¿Qué ventajas obtendrá la empresa al implantar el sistema?
-¿Qué ventajas obtendrán los usuarios del sistema al implantar el sistema?
-¿Quiénes son los que ingresarán los datos?
-¿Quiénes intervienen en el procesamiento de los datos?
-¿Quiénes usan la información para tomar decisiones?
-¿Cuál es el impacto asociado? Ej.: mejorar las decisiones, bajar los gastos, agilizar tiempos, etc.

2.2 PROPUESTA DE SOLUCIÓN

- ¿Para quién es el sistema? (Áreas y personas)
- ¿Quiénes usan el sistema?
- ¿Cuál es el nombre del producto?
-¿Para qué se va a usar el sistema?
-¿Existe algún sistema similar que estén utilizando?
-¿Cuáles serían los atributos relevantes? (Ej.: rapidez, sencillez, etc.)

2.2.1 ESQUEMA GENERAL DE LA SOLUCIÓN

- Mapa

Ejemplo:

Pág. 4
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

2.2.2 POLÍTICAS INSTITUCIONALES O REGLAMENTARIAS A CONSIDERAR.

- Si se tienen estas políticas

2.2.3 INTERACCIÓN E INTEGRACIÓN CON OTRAS APLICACIONES.

¿Cómo se va a integrar, que tecnología se va a usar?

2.2.4 ESPECIFICACIONES Y REQUERIMIENTOS TÉCNICOS GENERALES

- Arquitectura. Eje: cliente – servidor, móviles, de escritorio
- Lenguaje de programación a usar, con sus respectivos framework o librerías si las usa
- Que motor de bases de datos usaría el sistema
- Requisitos mínimos de los equipos

3 DESCRIPCIÓN DE CONTRAPARTE (PARTICIPANTES EN EL

PROYECTO) Y ACTORES
Para proveer de una forma efectiva productos y servicios que se ajusten a las necesidades de
los usuarios, es necesario identificar e involucrar a todos los participantes en el proyecto como
parte del proceso de modelado de requerimientos. También es necesario identificar a los
usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto los
representa adecuadamente. Esta sección muestra un perfil de los participantes y de los usuarios
involucrados en el proyecto, así como los problemas más importantes que éstos perciben para
enfocar la solución propuesta hacia ellos.

Pág. 5
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

3.1 RESUMEN DE CONTRAPARTE

- Como mínimo se debe tener una contraparte informática y un profesional en el área
especifica

Nombre Descripción Responsabilidades

Nombre completo Quien es la persona y Seguimiento del desarrollo del proyecto.
de la persona porqué se seleccionó Aprueba requisitos y funcionalidades
Realizar pruebas de funcionalidad del
sistema

3.2 RESUMEN DE ACTORES

Tipo de actor Descripción Contraparte

Nombre del tipo [Descripción de responsabilidades del Nombre de la persona a quien

de actor tipo de actor] se reporta
Ejemplo: Ejemplo:
Administrador Encargado de crear y administrar
usuarios.
[Nombre de otro [Descripción de responsabilidades del XXX XXX
tipo de actor del tipo de actor]
sistema]

-¿Quiénes serían los usuarios del sistema y cuáles son sus actividades (describa las mismas)?

3.3 PERFIL DE LA CONTRAPARTE

4 Para cada uno de las contrapartes, se debe llenar el siguiente cuadro

4.1.1 <NOMBRE DE LA CONTRAPARTE>

Descripción Representante Global de la Empresa Deportes LSI 03.

Tipo o cargo Experto de Sistemas.
Responsabilidad En que actividades tendrá participación
es
Comentarios Ninguno

4.2 PERFILES DE LOS ACTORES

5 Para cada uno de los tipos de actores, se debe llenar el siguiente cuadro

5.1.1 <NOMBRE DEL TIPO DE ACTOR>

Descripción
Tipo o cargo
Responsabilidad
es

Pág. 6
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

Grado de [Alta, Media o Baja]

participación
Comentarios
Contraparte Nombre de la persona a quien se reporta

- Las personas que van a usar el sistema ¿Qué responsabilidades tienen? ¿En qué área se
desempeñan?
-Las personas que van a utilizar el sistema, van a ingresar datos, van a definir reglas para el
funcionamiento o van a ver el resultado final?

6 CARACTERÍSTICAS GENERALES Y ESPECÍFICAS DE LA

SOLUCIÓN

6.1 DESCRIPCIÓN DE LOS PROCESOS

- Para cada uno de los procesos se debe llenar estos campos

- Descripción narrativa paso a paso lo que hace el sistema

2.1.1 FICHA TÉCNICA

Nombre del proceso

Descripción
Actores
Documentos de entrada Instrumentos
Documentos de salida Reportes
Alcance Niveles: Regional, País, Local, establecimiento
Especificación funcional - Lógica del negocio
- Listado variables
- Validaciones necesarias

6.2 DIAGRAMA GENERAL DEL FLUJO DE LOS PROCESOS

- No es un diagrama por cada uno de los procesos, solo es un diagrama en donde se refleja el
orden en que se llevan los procesos

EJEMPLO:

Pág. 7
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

7 PRECEDENCIA Y PRIORIDAD
- Se definirá el orden de prioridades en el que se desarrollaran los módulos o secciones del
software.
- ¿Qué cosas tiene uno que tener antes para poder realizar la operación?*

8 REQUISITOS DE DOCUMENTACIÓN
8.1 MANUAL DE USUARIO
-¿Desea contar con un Manual para el Usuario?*

8.2 AYUDA EN LÍNEA

- Poder descargar el manual en PDF
- Manual online con links interactivos

Pág. 8
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

8.3 DOCUMENTACIÓN DE LA BASE DE DATOS

2.1.2 DIAGRAMA ENTIDAD – RELACIÓN

2.1.3 DICCIONARIO DE DATOS

8.4 GUÍAS DE INSTALACIÓN, CONFIGURACIÓN, Y FICHERO LÉAME

-¿Desea contar con Guías de Instalación, Configuración, y Fichero Léame?*

9 MODELADO UML
9.1 CASOS DE USO
Para cada uno de los casos de uso se debe presentar los dos siguientes ítems.
2.1.4 DIAGRAMA
EJEMPLO:

Pág. 9
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

2.1.5 Narrativo
CASO DE USO
Iniciar sesión en el sistema
Actor(es)
primario(s)
Meta en el
contexto
Condiciones
previas
Activador
Escenario
Excepciones
(Escenarios
alternos)

ejemplo:
CASO DE USO
Iniciar sesión en el sistema
Actor(es) Usuario registrado: pertenece a un grupo específico y a una
primario(s) institución; CAUS.
Meta en el Garantizar que ingresen al sistema únicamente usuarios
contexto registrados.
Condiciones El usuario posee una cuenta habilitada desde la Consola de
previas Administración de Usuarios.
Activador El usuario desea ingresar al sistema SISVIG
Escenario 1) El usuario ingresa a la página de Login.
2) El sistema solicita el username y la contraseña del
usuario.
3) El SISVIG consulta los usuarios registrados en la Consola
de Administración de Usuarios.
4) El sistema autentica el ingreso del usuario y obtiene sus
privilegios por medio del CAUS.
5) El sistema determina a qué módulos puede acceder el
usuario.
6) El SISVIG determina a qué instituciones de salud tiene

Pág. 10
 DERCAS - <Nombre del proyecto>
Institución Versión Fecha
<Nombre de la institución para la cual se desarrolla el software> <Mes y año>

acceso el usuario.
7) El usuario es direccionado a la página principal.
Excepciones - El usuario no pasa la autenticación.
(Escenarios a. El sistema solicita el reingreso del username y

alternos) contraseña.
b. El usuario es autenticado y logra ingresar al
sistema.
- El usuario olvida su contraseña.
a. El sistema solicita los datos del usuario.
b. El sistema envía un e-mail con las instrucciones
necesarias.
- El usuario no tiene asignada una institución.
a. El sistema pide que se comuniquen con el
departamento de informática encargado e
informe de esta situación.

9.2 DIAGRAMAS DE ACTIVIDADES

9.3 DIAGRAMAS DE CLASES

10 ANEXOS
[Instrumentos primarios (formularios), todo documento que considere importante en la fase de
análisis y diseño del sistema]

10.1 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES

RUP: Son las siglas de Rational Unified Process. Se trata de una metodología para describir el
proceso de desarrollo de software.

Pág. 11