DAVID GRADOS ALZAMORA

1. UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
Especificación de
Requerimientos del
Software (SRS)
Documento Base
2016 - 01
Integrantes:
 RenatoBarra
 DavidGrados Alzamora
 Andre Porles
 Tomas Ramirez
 BrendaYucra

2. 1
Tabla de contenido
1. Introducción ..............................................................................................................................................................2
1.1. Propósito..........................................................................................................................................................2
1.2. Alcance..............................................................................................................................................................2
1.3. Definiciones, Acrónimos y abreviaturas ..................................................................................................2
1.4. Referencias ......................................................................................................................................................2
1.5. Arquitectura......................................................................................................................................................3
2. Requerimientos Funcionales.................................................................................................................................4
2.1. Funcionalidad .................................................................................................................................................4
2.2. Modelo de Casos de Uso ...............................................................................................................................8
2.3. Resumen de Actores y Casos de Uso.........................................................................................................9
2.4. Reporte de Requerimientos ........................................................................................................................9
3. Requerimientos No Funcionales .........................................................................................................................9
3.1. Facilidad de Uso ...........................................................................................................................................10
3.2. Confiabilidad .................................................................................................................................................10
3.3. Desempeño ....................................................................................................................................................11
3.4. Soporte ...........................................................................................................................................................11
3.5. Restricciones de Diseño .............................................................................................................................11
3.6. Interfaces .......................................................................................................................................................12
3.6.1 Interfaces de Administradors ..............................................................................................................12
3.6.2 Interfaces de Hardware ..........................................................................................................................12
3.6.3 Interfaces de Software ............................................................................................................................12
3.6.4 Interfaces de Comunicación..................................................................................................................12
3.7. Documentación en Línea y Requerimientos de Ayuda del Sistema ...............................................12
3.8. Requerimientos de Licencia......................................................................................................................12
3.9. Componentes Adquiridos ..........................................................................................................................12

3. 2
Especificación de Requerimientos del Software
(SRS)
1. Introducción
En el documento de Especificación de Requerimientos del Software (SRS) se describen
los pasos que se van a desarrollar durante el proyecto de Mantenimiento de
Universidades. En este documento se incluye los Casos de Uso. que describirán todas las
interacciones que tendrán los administradors con el software. Se desarrollarán casos de
uso que son conocidos como requisitos funcionales y los requisitos no funcionales. Estos
últimos son restricciones en el diseño o la implementación, como lo son los estándares de
calidad.
1.1.Propósito
Describir de forma clara los requerimientos funcionales y no funcionales del producto de
software que permitirá al diseñador y al arquitecto definir correctamente la implementación
de la solución.
1.2.Alcance
Este documento detalla las características definidas del proyecto y requerimientos
funcionales y no funcionales del software a implementar.
1.3.Definiciones, Acrónimos y abreviaturas
● MysQL: Es un sistema de gestión de bases de datos relacional.
● RUP: Es un lenguaje gráfico para visualizar, especificar, construir y
documentar un sistema
● RUC: Dicho registro identifica a las empresas dentro del país en cuestión
● MyISAM: Es el mecanismo de almacenamiento de datos usada por
defecto por el sistema administrador de bases de datos
relacionales MySQL
1.4.Referencias
Los siguientes documentos referenciados son utilizados como base para elaborar el
presente documento.
● Plan de Desarrollo del Software
● Plan de Administración de Requerimientos

4. 3
1.5.Arquitectura
La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las
tareas se reparten entre los proveedores de recursos o servicios, llamados servidores,
y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el
servidor, quien le da respuesta.
Características generales son:
● El Cliente y el Servidor pueden actuar como una sola entidad y también
pueden actuar como entidades separadas, realizando actividades o tareas
independientes.
● Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o
en la misma plataforma.
● Cada plataforma puede ser escalable independientemente. Los cambios
realizados en las plataformas de los Clientes o de los Servidores, ya sean por
actualización o por reemplazo tecnológico, se realizan de una manera
transparente para el administrador final.
● La interrelación entre el hardware y el software están basados en una
infraestructura poderosa, de tal forma que el acceso a los recursos de la red
no muestra la complejidad de los diferentes tipos de formatos de datos y de
los protocolos.

5. 4
2. Requerimientos Funcionales
2.1.Funcionalidad
Esta sección describe los requerimientos funcionales del sistema, expresado en lenguaje
natural simple a un nivel de detalle suficiente que permita a los diseñadores realizar el diseño
de un sistema que satisfaga dichos requerimientos y a los testers probar que el sistema
satisface dichos requerimientos Esta sección podría organizarse en término de los
subsistemas funcionales en los que se descompondrá el producto software.
R001: Ingresar al Sistema
● Descripción:
Este caso de uso es iniciado por el jefe de mantenimiento, quien está a cargo de
hacer el mantenimiento universidad.
● Flujo Básico:
1. Iniciar Sesión
1.1. El administrador accede al sistema
1.2. El sistema muestra la interfaz de login, y solicita los siguientes
datos: Administrador y Contraseña
1.3. El administrador introduce su administrador y contraseña
1.4. El administrador presiona el botón iniciar sesión
1.5. El sistema valida que los datos ingresados estén correctos
1.6. El sistema muestra el menú principal donde se realiza el
mantenimiento de universidad.
2. Fin del caso de uso
● Flujo Alternativo
1. Campos Vacíos
Al presionar el botón iniciar sesión, el sistema detecta que falta completar
los campos requeridos para entrar al menú principal Mantenimiento
Universidad, por lo que el flujo básico se interrumpe y se muestra el
siguiente mensaje: “Completar los datos solicitados para el inicio de
sesión”
2. Datos ingresados no válidos
Al presionar el botón iniciar sesión, el sistema tuvo como resultado
después de la validación que el dato ingresado (administrador o
contraseña) son incorrectos, por lo que el flujo básico se interrumpe y se
muestra el siguiente mensaje: “Su administrador o Contraseña son
incorrectos, por favor ingrese de nuevo”
● Pre-condiciones:
El administrador Jefe de Mantenimiento debe haber sido creado
anteriormente para acceder al menú principal Mantenimiento Universidad.
.
● Post-condiciones:
El administrador Jefe de Mantenimiento logra acceder satisfactoriamente
al menú principal Mantenimiento Universidad.

6. 5
R002: Registrar Universidad
● Descripción:
Este caso de uso es iniciado por el jefe de Mantenimiento quien tiene la
responsabilidad de realizar el Mantenimiento Universidad.
● Flujo Básico:
1. Seleccionar función Registrar Universidad
1.1. El administrador presiona el botón Registrar Universidad del menú
Principal.
1.2. El sistema despliega la interfaz Registrar Universidad con un
formulario para realizar el registro de una universidad.
2. Llenar los campos solicitados
2.1. El administrador introduce los datos solicitados en la interfaz
desplegada.
2.1.1. El administrador introduce el nombre de la Universidad
2.1.2. El administrador selecciona la opción de acrónimo
2.1.3. El administrador introduce el acrónimo
2.1.4. El administrador introduce la dirección de la Universidad
2.1.5. El administrador selecciona el distrito de la Universidad.
2.1.6. El administrador le da check a la casilla de convenios
internacionales.
2.1.7. El administrador introduce en el campo texto el número
telefónico.
3. Enviar (Submit) Universidad
3.1. El administrador presiona el botón Registrar.
3.2. El sistema valida los datos ingresados y seleccionados del
formulario.
3.3. El sistema registra la Universidad en el Sistema.
3.4. El sistema muestra el siguiente mensaje: “Los datos ingresados
fueron registrados correctamente”
3.5. El administrador acepta el mensaje.
4. Actualizar Interfaz
4.1. El sistema actualiza la lista de universidades en la grilla.
4.2. El sistema limpia todos los campos del formulario
5. Salir del Registro de Universidad
5.1. El administrador pulsa salir del registro de Universidad.
5.2. El sistema muestra la interfaz del Menú Principal.
6. Fin del caso de uso
● Flujo Alternativo:
1. Datos ingresados no válidos
Si en el paso 3.2, al validar se encuentran uno o más errores en los datos
introducidos o no introducidos, el sistema generará un mensaje de error
indicando que no se ha podido registrar los datos. El mensaje a generarse
es el siguiente: “ La universidad no ha sido registrada, algunos campos se
encuentran incorrectos.”
2. Campos vacíos

7. 6
Si en el paso 3, el administrador no introdujo ninguno de los campos que
se solicita, el sistema generará un mensaje informativo de que los campos
no contienen los datos necesarios para registrar una universidad. El
mensaje a generarse es el siguiente: “La universidad no ha sido
registrada, todos los campos son obligatorios.”
● Pre-condiciones:
El administrador ha realizado correctamente el registro en el sistema
introduciendo el nombre de usuario y la contraseña
El Jefe de Mantenimiento ha ingresado satisfactoriamente al sistema
Mantenimiento Universidad.
● Post-condiciones:
El Jefe de Mantenimiento ha registrado satisfactoriamente una
Universidad en el Sistema.
R003: Actualizar Universidad
● Descripción:
Este caso de uso permite al Jefe de Mantenimiento actualizar la información sobre
las universidades (Nombre, Acrónimo, Dirección, Distrito, Convenio y Teléfono).
● Flujo Básico:
1. El sistema despliega la interfaz Mantenimiento de Universidades.
2. El Jefe de Mantenimiento selecciona en la sección de reportes la opción
Universidad.
3. El sistema muestra la lista de las Universidades registradas en una grilla
con las siguiente columnas: Código, Nombre, Acrónimo, Dirección,
Distrito, Convenio, Teléfono, y las operaciones ( Actualizar y Eliminar).
4. El Jefe de Mantenimiento presiona el botón Actualizar de la fila a
modificar.
5. El sistema habilitará el formulario con los datos de la universidad a
actualizar.
6. El Jefe de Mantenimiento modifica los campos.
7. El jefe de Mantenimiento presiona el botón actualizar.
8. El sistema valida los campos modificados.
9. El sistema muestra el siguiente mensaje: “Se actualizó correctamente la
Universidad”
10. Fin del Caso de Uso
● Flujo Alternativo:
1. Campos vacíos
Si en el pasos 6, si el Jefe de Mantenimiento deja uno o muchos campos
vacíos y presiona el botón actualizar, el flujo básico se interrumpe y el
sistema muestra el siguiente mensaje: “La universidad no ha sido
actualizada, todos los campos son obligatorios.”
2. Datos ingresados no válidos
Si en el paso 6, el Jefe de Mantenimiento llena uno o muchos campos con
un dato que no corresponde y presiona el botón actualizar, el flujo básico
se interrumpe y el sistema muestra el siguiente mensaje: “La universidad
no ha sido actualizada, algunos campos ingresados se encuentran
incorrectos”
● Pre-condiciones:

8. 7
El jefe de Mantenimiento ha ingresado satisfactoriamente al sistema
Mantenimiento Universidad.
● Post-condiciones:
El Jefe de Mantenimiento ha actualizado satisfactoriamente en el Sistema
la universidad seleccionada.
R003: Eliminar Universidad
● Descripción:
Este caso de uso permite al Jefe de Mantenimiento eliminar un registro de
universidad del Sistema.
● Flujo Básico:
1. El sistema despliega la interfaz Mantenimiento Universidad
2. El Jefe de Mantenimiento selecciona en la sección de reportes la opción
Universidad.
3. El sistema muestra la lista de las Universidades registradas en una grilla
con las siguiente columnas: Código, Nombre, Acrónimo, Dirección,
Distrito, Convenio, Teléfono, y las operaciones ( Actualizar y Eliminar).
4. El Jefe de Mantenimiento identifica la Universidad a eliminar.
5. El jefe de Mantenimiento presiona la opción eliminar de la fila identificada.
6. El sistema muestra el siguiente mensaje: “ ¿Desea eliminar la Universidad
“Nombre Universidad ” del Sistema? ”
7. El Jefe de Mantenimiento acepta el mensaje.
8. El sistema muestra el siguiente mensaje: “La universidad ha sido
eliminada satisfactoriamente”
9. El sistema elimina la Universidad del Sistema.
10. El sistema actualiza la interfaz Universidad.
11. El sistema muestra la interfaz Universidad actualizada.
12. Fin del Caso de Uso.
● Flujo Alternativo:
No posee
● Pre-condiciones:
○ El Jefe de Mantenimiento ha ingresado satisfactoriamente al sistema
Mantenimiento Universidad.
○ La grilla de lista de universidades, contiene al menos un ítem registrado
para realizar este caso de uso.
● Post-condiciones:
○ El administrador elimina todos los datos de la universidad identificada.

9. 8
R003: Listar Universidad
● Descripción:
Este caso de uso permite al Jefe de mantenimiento visualizar las universidades
registradas en el Sistema.
● Flujo Básico:
1. El Sistema despliega la interfaz Mantenimiento Universidad
2. El Jefe de Mantenimiento selecciona en la sección de reportes la opción
Universidad.
3. El sistema muestra la interfaz Universidad con la lista de universidades
registradas en el Sistema.
● Flujo Alternativo:
○ El usuario no visualiza las universidades registradas
○ Aparece un mensaje de error en la misma pantalla “No hay universidades
registradas”
● Pre-condiciones:
○ El Jefe de Mantenimiento ha ingresado satisfactoriamente al sistema
Mantenimiento Universidad.
○ La grilla de lista de universidades, contiene al menos un ítem registrado
para realizar este caso de uso.
● Post-condiciones:
○ El Jefe de Mantenimiento ha consultado la lista de universidades
registradas en el Sistema.
2.2.Modelo de Casos de Uso

10. 9
2.3.Resumen de Actores y Casos de Uso
Caso de Uso Descripción
CUS1: Login El sistema permite acceder al sistema de los
administradors registrados
CUS2: Registrar
Universidad
El sistema permite registrar universidades llenando toda
su información
CUS3: Actualizar
Universidad
El sistema permite editar los atributos de la universidad
seleccionada
CUS4: Listar Universidad El sistema permite buscar y listar las universidades
registradas en la base de datos y mostrarlo en pantalla.
CUS5: Eliminar
Universidad
El sistema permite eliminar la universidad de la base de
datos.
2.4.Reporte de Requerimientos
Matriz Caso de Uso y Actor:
CUS1:
Login
CUS2:Registrar
Universidad
CUS3:
Modificar
Universidad
CUS4:
Listar
Univers
idad
CUS5:
Eliminar
Universi
dad
ACT1: Jefe
mantenimie
nto
(administra
dor)
X X X X X
3. Requerimientos No Funcionales
Esta sección describe todos los requerimientos del tipo no funcional descritos a un nivel de detalle
suficiente que permita a los diseñadores realizar el diseño de un sistema que satisfaga dichos
requerimientos y a los testers probar que el sistema satisface dichos requerimientos. Estos se
pueden tipificar siguiendo la estructura propuesta

11. 10
a. Plataforma
✓ Sistema Operativo
El sistema operativo para el servidor de aplicación y para el servidor del
motor base de datos será:
- Linux Red Hat última versión o Windows Server, y
- Las estaciones de trabajo cuentan con el Windows XP.
✓ Motor de Base de Datos
- El manejador de base de datos será Mysql
- El motor de base de datos será MyISAM
✓ Lenguaje de Programación
- El lenguaje de programación Java para Windows y JSP para las
páginas WEB, la interface gráfico para la programación será
JDeveloper de Oracle.
b. Arquitectura
✓ El motor de la base de datos (MySQL) estará instalado en el servidor
✓ La programación estará orientada a objetos.
✓ La seguridad deberá ser de doble nivel. Aplicación y por base de datos.
✓ Sistema se conectará a la aplicativo desde cualquier Terminal de red, esto
permitirá realizar los procesos de datos en cualquier ubicación.
✓ Para el acceso se requiere una clave autorizada y un perfil con permisos
de acceder o grabar por cada módulo.
c. Metodología
✓ RUP – UML
3.1.Facilidad de Uso
● RNF001:
La interfaz gráfica debe permitir comprensión intuitiva al momento del uso y en
consecuencia éste no requiera un mayor esfuerzo para recordar su
funcionamiento.
● RNF002:
El Sistema hará uso de mensajes de error y confirmación.
3.2.Confiabilidad

12. 11
● RNF003:
La duración promedio de una reparación del Sistema no debe ser mayor de dos
(02) horas.
● RNF004:
El Sistema debe estar disponible a los administradors en un porcentaje cercano al
100% durante el horario requerido y llevar a cabo el mantenimiento respectivo y a
tiempo completo deberá cubrirse al 95%.
3.3. Desempeño
● RNF005:
El tiempo de respuesta de la aplicación para cualquier tarea debe ser de dos (02)
segundos aproximadamente.
● RNF006:
Al momento de realizar una operación, Este no debe de sobre pasar el 25% del
uso del CPU.
3.4.Soporte
● RNF007:
El sistema deberá ser elaborado en Java. Es una de las mejores herramientas de
código libre para desarrollar plataformas webs, a su vez es un lenguaje de alto
nivel orientado objetos.
● RNF008:
El sistema utilizara base de datos MySQL para manejar las entidades de sistema.
El uso del Sistema de gestión de bases de datos relacionales más utilizado en el
mundo ofrece ventajas como la de permitir a muchos administradors acceder a las
bases de datos al mismo tiempo. Además en el futuro puede colocarse en la nube.
3.5.Restricciones de Diseño
● RNF007:
El Sistema debe ser capaz de instalarse y posteriormente ejecutarse en la
configuración estándar de los equipos disponibles.
● RNF008:
El Sistema deberá ser desarrollado íntegramente en el lenguaje Java.

13. 12
● RNF009:
La base de datos debe estar diseñada en Mysql
3.6.Interfaces
3.6.1 Interfaces de Administradors
● El diseño de interfaz nativa de Windows.
● Tendrá varias interfaces como login, registrar, eliminar, listar,
modificar
● El logotipo de la empresa como ícono en las ventanas del sistema.
● El tipo de letra general será Arial de tamaño 10.
● Las dimensiones de las interfaces será de 900 x 650.
3.6.2 Interfaces de Hardware
No Aplica
3.6.3 Interfaces de Software
No Aplica
3.6.4 Interfaces de Comunicación
No Aplica
3.7.Documentación en Línea y Requerimientos de Ayuda del Sistema
No Aplica
3.8.Requerimientos de Licencia
● No se necesita porque Mysql es OpenSource.
● Java es código libre
3.9.Componentes Adquiridos
No Aplica