01 ERS Carga Lectiva

UNIDAD DE DESARROLLO, EVALUACIÓN Y MANTENIMIENTO
DE SISTEMAS DE INFORMACIÓN
Especificación de requisitos de software
Proyecto: Carga Lectiva y Horarios

Revisión [1.0]
Febrero del 2015

Ficha del documento
Fecha Revisión Autor Verificado por Coordinador.
Ing. Ninaquispe Matame

11/02/15 1.0
Humberto Angel
Fecha: ____/____/_________
Observaciones:
Documento validado por las partes en fecha:
Por la Unidad Por la Persona Operadora
Fdo. D./ Dña: Fdo. D./Dña:
Fecha: ____/____/_________ Fecha: ____/____/_________
Observaciones: Observaciones:
Especificación de requisitos de software Pág. 3
Módulo de Registro de Carga Lectiva
CONTENIDO
FICHA DEL DOCUMENTO 2
CONTENIDO 3
1 INTRODUCCIÓN 4
1.1 Propósito 4
1.2 Alcance 4
1.3 Personal involucrado 5
1.4 Definiciones, acrónimos y abreviaturas 5
1.5 Referencias 7
1.6 Resumen 7
2 DESCRIPCIÓN GENERAL 7
2.1 Perspectiva del producto 7
2.2 Funcionalidad del producto 7
2.3 Características de los usuarios 8
2.4 Restricciones 8
2.5 Suposiciones y dependencias 8
2.6 Evolución previsible del sistema 8
3 REQUISITOS ESPECÍFICOS 9
3.1 Requisitos comunes de los interfaces 9
3.1.1 Interfaces de usuario 9
3.1.2 Interfaces de hardware 9
3.1.3 Interfaces de software 9
3.1.4 Interfaces de comunicación 10
3.2 Requisitos funcionales 10
3.2.1 Requisito funcional 1 10
3.3 Requisitos no funcionales 14
3.3.1 Requisitos de rendimiento 14
3.3.2 Seguridad 14
3.3.3 Fiabilidad 14
3.3.4 Disponibilidad 15
3.3.5 Mantenibilidad 15
3.3.6 Portabilidad 15
3.4 Otros requisitos 15
4 ESPECIFICACIÓN DE REQUISITOS 16
4.1 Diagrama de Caso de uso del negocio 16
4.2 Definición de actores 16
4.3 Diagrama de Casos de uso del sistema 16
4.4 Diagramas de secuencia (Especificación de casos de uso) 17
UNIVERSIDAD NACIONAL DEL SANTA

Rectorado: Av. Pacífico Nº 508 – Urb. Buenos Aires
Campus Universitario: Av. Universitaria s/n – Urb. Bellamar
Central telefónica: (51)-43-310445 - Nuevo Chimbote – Ancash – Perú www.uns.edu.pe
1 Introducción
Este documento contiene la descripción detallada de los diferentes requisitos de software
que debe cumplir el modulo utilizado para el registro y control de la carga lectiva de los
docentes de la Universidad Nacional del Santa así como de los horarios de clases. El
modulo a desarrollar tomará las funciones básicas del SIIGAA (Sistema de Información
Integral de Gestión Administrativa y Académica) agregando una serie de nuevas
funcionalidades requeridas y mejorando las ya existentes en cuanto a la gestión de la
carga lectiva y horarios.
La presente Especificación de Requerimiento de Software (ERS) del módulo a construir
surge para documentar la información necesario que modo que sirva de ayuda a los
desarrolladores del software a analizar y entender todos los requisitos y requerimientos
que el usuario final desea; estos requerimientos son necesarios para el desarrollo e
implementación de la aplicación desktop para el Mantenimiento de la Carga Lectiva y
horarios.
1.1 Propósito
El propósito de este documento es presentar de manera formal la especificación de
requisitos de este módulo, para su discusión y aceptación, por parte de los usuarios
finales que utilizaran dicho modulo. En esta especificación se detallan los
requerimientos funcionales, las restricciones y los atributos de calidad que deberá
satisfacer el sistema.
El documento va dirigido en primera instancia al equipo de la UDEMSI, y en
segunda instancia a los usuarios directos de este módulo, es decir, al personal que
labora en la Oficina Central de Evaluación y Documentación Académica.
1.2 Alcance
Este módulo formará parte del SIIGAA en el ámbito académico
Modulo: Carga Lectiva
Objetivos del sistema:
 Permite la gestión de Asignaturas para el periodo académico y su potencial
número de matriculados.
 Permite la gestión de docentes hábiles para obtener carga lectiva.
 Realiza la asignación de asignaturas a cada docente.
 Valida el total de hora de carga para cada docente.
 Permite el registro de los horarios de clases.
 Emite el informe de la carga lectiva

1.3 Personal involucrado

Nombre Ing. Humberto Angel Ninaquispe Matame
Rol Analista, diseñador, programador y gestor de proyecto
Categoría profesional Analista/Programador
Responsabilidades Análisis y especificaciones de requerimientos, diseño
de la base de datos, diseño de arquitectura, programar
modulo,
Información de contacto x100pre_anima@hotmail.com
Aprobación
1.4 Definiciones, acrónimos y abreviaturas

 DEFINICIONES
Actualización.- Insertar, eliminar, modificar los registros en la BD.
Almacenamiento.- En relación con ordenadores, cualquier dispositivo capaz de
almacenar información procedente de un sistema informático.
Backup.- Las copias de seguridad en un sistema informático tienen por objetivo
el mantener cierta capacidad de recuperación de la información ante posibles
pérdidas.
Base de Datos.- Cualquier conjunto de datos organizados para su
almacenamiento en la memoria de un ordenador o computadora, diseñado para
facilitar su mantenimiento y acceso de una forma estándar. La información se
organiza en campos y registros. Un campo se refiere a un tipo o atributo de
información, y un registro, a toda la información sobre un individuo.
Botón.- Es un objeto tangible que realiza un evento tras su activación.
Conexión.- Comunicación entre dos entes que tienen características similares de
comunicación.
Interfaz.- Medio que permite la comunicación entre el usuario y el sistema.
Internet.- interconexión de redes informáticas que permite a los ordenadores o
computadoras conectadas comunicarse directamente, es decir, cada ordenador
de la red puede conectarse a cualquier otro ordenador de la red. El término
suele referirse a una interconexión en particular, de carácter planetario y abierto
al público, que conecta redes informáticas de organismos oficiales, educativos y
empresariales.
Login.- Nombre o alias que se le da a una persona para permitirle el acceso al
sistema siempre y cuando estén registrados.
PASSWORD.- Contraseña o clave para autentificar el ingreso a un lugar o sitio.
Periférico.- En informática, término utilizado para dispositivos, como unidades
de disco, impresoras, módem que están conectados a un ordenador o
computadora y son controlados por su microprocesador.

Protocolo.- Señal mediante la cual se reconoce que puede tener lugar la

comunicación o la transferencia de información.
Servidor.- Computadora conectada a una red que pone sus recursos a
disposición del resto de los integrantes de la red. Suele utilizarse para mantener
datos centralizados o para gestionar recursos compartidos.
Sistema Operativo.- Software básico que controla una computadora. El sistema
operativo tiene tres grandes funciones: coordina y manipula el hardware del
ordenador o computadora, como la memoria, las impresoras, las unidades de
disco, el teclado o el mouse; organiza los archivos en diversos dispositivos de
almacenamiento, como discos flexibles, discos duros, discos compactos o cintas
magnéticas, y gestiona los errores de hardware y la pérdida de datos.
Sitio Web.- Se canaliza a través del URL o identificador único de cada página de
contenidos.
SQL- Lenguaje de consulta estructurado, en informática, un lenguaje utilizado en
bases de datos para consultar, actualizar y manejar bases de datos relacionales.
Tabla.- Entidad que posee campos físicos primarios secundarios
 ACRÓNIMOS
DBA.- Es aquella persona que tiene el control central del sistema de base de
datos.
DBMS.- Sistema de Administración de base de datos, El software que permite la
creación, administración e implementación de la base de datos.
SIIGAA”.- Sistema de información integral de gestión académica y administrativa
GUI (Graphical User Interface).- En informática, tipo de entorno que permite al
usuario elegir comandos, iniciar programas, ver listas de archivos y otras
opciones utilizando las representaciones visuales (iconos) y las listas de
elementos del menú. Las selecciones pueden activarse bien a través del teclado
o con el ratón.
ODBC.- Herramienta que conecta la base de datos con la interfaz.
ERS.- Especificación de Requerimientos de Software (RSR: Software
Requeriments Specifications)
TCP/IP.- Acrónimo de Transmisión Control Protocol/Internet Protocol (protocolo
de control de transmisiones/protocolo de Internet), protocolos usados para el
control de la transmisión en Internet. Permite que diferentes tipos de
ordenadores o computadoras se comuniquen a través de redes heterogéneas.
URL.- Cadena de caracteres que identifica el tipo de documento, la
computadora, el directorio y los subdirectorios en donde se encuentra el
documento y su nombre.

 ABREVIATURAS
BD: Base de datos
HW: Hardware
SW: Software
Sr. Señor
Sra. Señora
Ing. Ingeniero(a)
1.5 Referencias
Referencia Titulo Ruta Fecha Autor
REF01 Carga lectiva 01/02/15 OCEDA
1.6 Resumen
El ERS está compuesto de la siguiente manera
Introducción: En ésta sección se detalla los objetivos que tiene el ERS y de nuestro
modulo en forma general.
Descripción General: Describe una perspectiva general del producto a
desarrollarse, como también las características del usuario y las limitaciones que
podría tener.
Requisitos Específicos: Muestra paso a paso todos los requerimientos que el
usuario desea en el producto final. Para el cual se ha utilizado el “Prototipo 2 del
Estándar IEEE 830”.
2 Descripción general
2.1 Perspectiva del producto
Este módulo es un producto que es parte del ámbito académico del SIIGAA. Debe
funcionar en cualquier computador que soporte los sistemas operativos Windows
(XP o superior). Así como también, que disponga de conexión a la red LAN de la
Universidad Nacional del Santa.
2.2 Funcionalidad del producto

 El modulo permite el registro de los docentes por cada departamento que
estarán habilitados para estar a cargo de una asignatura, así mismo cuando la
carga este pendiente de un docente por contratar solo se registrará en el
formato: contrato 01, contrato 02, etc.
 Debe permitir cargar las asignaturas ofertadas para matricula en un
determinado periodo académico, estas asignaturas están ligados a un
departamento.

 Debe permitir registrar el número de secciones para cada asignatura así como el
número de grupo de laboratorio por cada asignatura.
 Debe permitir que en todo momento se conozca la carga lectiva de un
determinado docente.
 Debe permitir modificar la carga lectiva de un determinado docente.
 Debe permitir el registro de los horarios de clases de cada especialidad.
2.3 Características de los usuarios

Tipo de usuario Técnico OCEDA
Formación Conocimiento en Sistemas de Información
Habilidades Manejo de computadoras y sistemas de información
Actividades Realizar el registro de la carga lectiva
2.4 Restricciones
El modulo será desarrollado en Power Builder 10.5, lenguaje orientado a objetos, el
motor de la base de datos es Adaptive Server Anyware (ASA 9.0) de tecnología
Objeto-Relacional, además de mantener los componentes de sistemas bajo
EAServer; la metodología para el desarrollo se basará en las mejores características
de las metodologías tradicionales agiles, la programación está orientado a modelo
distribuido.
2.5 Suposiciones y dependencias

El modulo solo corre sobre Windows (XP o superior) y mantienen una conexión
constante con el servidor de Base de Datos (ASA) y el servidor de Aplicaciones
(EAServer)
2.6 Evolución previsible del sistema

Análisis y desarrollo del módulo Horarios.
Migración de gestor de base de datos (Oracle).
Implementación del entorno web para docentes.
3 Requisitos específicos
En este apartado se presentan los requisitos comunes de los interfaces, los funcionales y
no funcionales que deberán ser satisfechos por el modulo. Los requisitos aquí expuestos
están declarados en lenguaje natural.

3.1 Requisitos comunes de los interfaces

3.1.1 Interfaces de usuario
Las interfaces de usuario están relacionadas con las pantallas, ventas o
formularios que debe manipular el usuario para realizar una operación
determinada. Dicha manipulación el usuario la realizara por medio del
teclado y el mouse.
Es importante mencionar que las interfaces de usuario estarán basadas en
el framework del SIIGAA, por lo que su funcionalidad no le será desconocida
al usuario final, esta interfaz también abarca las ayudas correspondientes
en cada uno de los procesos que realice el modulo.
Estas interfaces incluyen: botones, menús desplegables, mensajes
informativos, mensajes de error, cuadros de dialogo, formularios de
mantenimiento de datos, así como de las operaciones comunes.
De otro lado también debe entenderse que todo usuario tiene y accede al
módulo a través de su cuenta de usuario.
3.1.2 Interfaces de hardware

La pantalla del monitor.- el software deberá mostrar información al usuario
a través de la pantalla del monitor.
Ratón.- el software debe interactuar con el movimiento del ratón y los
botones del ratón. El ratón activa las zonas de entrada de datos, botones de
comando y seleccione las opciones de los menús.
Teclado.- el software deberá interactuar con las pulsaciones del teclado. El
teclado realiza la entrada de datos en el área activa de la base de datos.
Impresora.- el software imprimirá los reportes en la impresora instalada.
3.1.3 Interfaces de software

El modulo debe interactuar con:
 Módulo de Planes Curriculares: en el cual se encuentra la
configuración de las asignaturas para cada especialidad, se utilizará
una interfaz de acceso a las asignaturas dictadas por un determinado
departamento.
 Módulo de Escalafón: nos permite obtener la relación de docentes
asignados a cada departamento, la interfaz a utilizar será capaz de
mostrarme todos los docentes asignados a este departamento y que
estén en estado activo.

3.1.4 Interfaces de comunicación

Debemos aclarar que la interfaz de comunicación es distribuida tanto
físicamente como la forma de programación; de esa manera tendremos la
capa de datos (Servidor de base de datos), capa de negocios (Servidor
EAServer) y la capa de presentación las mismas que tiene una
comunicación de red vía TCP/IP.
La interfaz de comunicación de datos entre el servidor de la aplicación
EAServer y la base de datos ASA se realiza mediante ODBC.
3.2 Requisitos funcionales

3.2.1 Requisito funcional 1
Número de requisito RF01
Nombre de requisito Habilitar plaza docente
Tipo Requisito Restricción
Fuente del requisito BD Tabla: esc_nombramientodoc, esc_contratodoc
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
INTRODUCCIÓN
El modulo debe permitir la habilitación de las plazas docentes (nombradas o
contratadas) en un determinado periodo académico, también debe permitir
inhabilitar una plaza docente, en caso que la plaza docente no tenga asignado a un
docente, se le debe crear como: Contrato 01, Contrato 02, etc.
ENTRADAS
Nombre, departamento, ámbito, periodo académico, directorio
PROCESOS
El Logeo del usuario se hace a través del framework de acceso del SIIGAA, en la cual
se identifica al usuario y su dependencia, luego del cual nos muestra los diferentes
módulos al que se tiene acceso y se seleccionara con doble click el modulo Carga
Lectiva.
El modulo nos mostrara el menú principal y escogemos habilitación plaza docente.
El sistema pedirá el ámbito, periodo académico y departamento luego verificara lo
que ya se ha guardado habilitándonos los botones de agregar, modificar, anular,
salir.
En caso de tener que agregar una nueva plaza nos pedirá nombre de la plaza
(Contrato 01, Contrato 02, etc.) y se guardará como plaza docente.
SALIDAS
Las salidas van dirigidas a: Administrador (Técnico OCEDA).
Mensaje de error en el caso de no haber llenado algún campo.
Mensaje de error en el caso de ingresar algún valor de búsqueda no existente.

Mensaje de error en el caso de querer agregar a un docente que ya está habilitado

(se supone que en lista no debe aparecer un docente ya habilitado)
Mensaje de error en casos de ingresar incorrectamente los datos es decir que el
formato de los datos sea incorrecto.
Mensaje de error en caso de ingresar un nombre ya existente.

Nombre de requisito Habilitar Asignaturas
Fuente del requisito BD Tabla: apc_periodo_asignatura, cur_asignatura
INTRODUCCIÓN
El modulo debe permitir la habilitación de las asignaturas en un determinado
periodo académico y por departamento, también debe permitir conocer el número
aproximado de alumnos con posible matrícula para poder proyectar e ingresar el
número de secciones para teoría y grupos de laboratorio, además deberá permitir
la modificación de estos datos
ENTRADAS
Ámbito, departamento, periodo académico, asignatura, nro. de secciones, nro. de
laboratorios, tipo de carga (0: Teoría 1: Laboratorio), nro. de carga.
PROCESOS
Lectiva.
El modulo nos mostrara el menú principal y escogemos habilitación Asignaturas. El
sistema pedirá el ámbito, periodo académico y departamento luego verificará lo
que ya se ha guardado habilitándonos los botones de agregar, modificar, anular,
salir.
En caso de habilitar una nueva asignatura ofertada para este periodo académico
debemos ingresar el número total de secciones hábiles y el número total de
laboratorios hábiles.
SALIDAS
Mensaje de error en el caso de no haber llenado algún campo.
Mensaje de error en el caso de querer agregar a una asignatura que ya está
habilitado (se supone que en lista no debe aparecer una asignatura ya habilitada)
Mensaje de error en casos de ingresar incorrectamente los datos es decir que el

formato de los datos sea incorrecto.

Nombre de requisito Registrar carga lectiva
Fuente del requisito BD Tabla: crl_asignatura, crl_plazaDocente
INTRODUCCIÓN
El modulo debe permitir el registro de la carga lectiva de cada docente, de manera
que permita saber el número total de horas a la semana de labor docente.
ENTRADAS
Id plaza, id asignatura, sección, grupo
PROCESOS
Lectiva.
El modulo nos mostrara el menú principal y escogemos Registrar Carga Lectiva. El
sistema pedirá el ámbito, periodo académico y departamento nos mostrará la lista
de plazas hábiles para este periodo académico y este departamento, debemos
seleccionar un docente, luego debemos elegir una asignatura de la lista de
Asignaturas hábiles las cuales esta diferenciadas por el tipo (Teoría, Laboratorio) y
con su número de tipo, luego se procede a guardar dicho registro.
SALIDAS
Mensaje de error en el caso de no haber seleccionado ninguna asignatura.
Mensaje de error en el caso de querer agregar a un docente una asignatura ya
elegida por el mismo y otro docente (se supone que en lista no debe aparecer una
asignatura ya seleccionada)
Mensaje de error en el caso de que un docente nombrado tenga menos de 16
créditos salvo tenga jefatura.

Nombre de requisito Registrar horario de clases

Fuente del requisito BD Tabla: crl_carga, hro_horariocab, hro_horariodet

INTRODUCCIÓN
El modulo debe permitir el registro de los horarios de clases, de manera que
permita saber la distribución horaria de clases de una determinada especialidad.
ENTRADAS
Id de la carga, ambiente, día, hora inicio, número de horas
PROCESOS
Lectiva.
El modulo nos mostrará el menú principal y escogemos Registrar Horario de clases.
El sistema pedirá el periodo académico, la especialidad, el ciclo y nos mostrará la
relación de asignaturas a distribuir, se deberá colocar el día y hora de cada
asignatura (carga lectiva de docente) así como el ambiente en el cual se dictará la
asignatura de manera que el modulo pueda validar el cruce de horas entre
asignaturas y el uso de los ambientes.
SALIDAS
Mensaje de error en el caso de no haber seleccionado ninguna asignatura.
Mensaje de error en el caso de querer agregar colocar más de una asignatura en el
mismo día y horas.
Mensaje de error en el caso de que el ambiente designado ya esté en uso.
3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento
La infraestructura de red, así como sus terminales deben cumplir con
normas según la IEEE en la forma de conexión a los equipos, para tener
tiempos de respuesta mínimos.
Número de terminales a manejar:
Se contará con un servidor de base de datos en la matriz de la UNS.
Número de usuarios simultáneos:
El número de usuarios que interactuaran simultáneamente con nuestro
modulo solo será 1 (técnico OCEDA).
Número de transacciones a manejar dentro de ciertos periodos de
tiempo:

Se estima que se manejará alrededor 150 transacciones durante el día,

tomando en cuenta que el técnico realiza aproximadamente 50 operaciones
diarias, como habilitación de asignaturas, habilitación de plazas y registro
de carga lectiva. Pero esto solo se hace a inicios del semestre académico, es
decir 2 veces al año en solo 3 días como máximo.
El servidor de base de datos, deberá tener un respaldo apropiado, así como

personal técnico listo para cualquier eventualidad.
3.3.2 Seguridad
La seguridad del módulo es por:
 Uso de contraseñas para el usuario (técnico OCEDA), esto permitirá
que tengan acceso al sistema solo las personas que tienen
autorización.
 Registros de ingreso al módulo contemplados en las tablas del módulo
de pasaporte.
 Registro en el log de la base de datos de todas las transacciones, así
como en el log del EAServer del paso de cada componente.
 Creación de contexto y grupos así como la asignación a cada usuario
por su dependencia y funcionalidad.
3.3.3 Fiabilidad
Debido a que el modulo es solo un registro de carga lectiva, accede a
información ya registrada por otros módulos (Escalafón, Plan Curricular) por
lo que su fiabilidad dependerá de estos dos módulos. Así mismo este
registro será una copia fiable de los documentos entregados por cada
departamento.
El modulo controla todo tipo de transacción para el registro de la carga
lectiva, una vez que tiene sus parámetros de ingreso, y está apto para
responder a todo tipo de incidentes.
3.3.4 Disponibilidad
El modulo ha sido desarrollado tomando en cuenta las necesidades,
requerimientos, reglas, políticas, y objetivos de la unidad, por lo que se
encuentra disponible al 100% de día, siempre y cuando el servidor de
aplicaciones y de base de datos se mantengan disponible.

3.3.5 Mantenibilidad
Para los casos de cambios en el negocio el mantenimiento del módulo
estará a cargo de la UDEMSI, este mantenimiento es solo correctivo.
Para los casos de mantenimiento de la información estará a cargo del
técnico de OCEDA.
3.3.6 Portabilidad
El modulo es de uso solo dentro de las instalaciones de la UNS.
Todos los componentes dependen del servidor de aplicaciones (EAServer).
Todas las transacciones a la base de datos dependen del servidor de base
de datos (ASA)
El modulo solo corre bajo Windows (XP o superior)
El modulo usa una programación distribuida en Power Builder 10.5
3.4 Otros requisitos

Requisitos Legales
 Cumplimiento de la Ley universitaria
 Cumplimiento del Estatuto de la UNS

4 Especificación de requisitos
4.1 Diagrama de Caso de uso del negocio
Figura 1. Caso de uso del negocio
4.2 Definición de actores del modulo

ACT-01 Técnico OCEDA
Este actor representa al personal designado por OCEDA para el registro de
la carga lectiva de los docentes, basándose en los documentos aprobados
Descripción según oficio de Vicerrectorado Académico de la carga lectiva designado por
cada departamento. Este actor es el responsable de las actividades del
ámbito académico de pre grado de la UNS.
Símbolo
4.3 Diagrama de Casos de uso del sistema

4.4 Diagramas de Actividad (Especificación de casos de uso)

4.4.1 CU Registrar Carga Lectiva

4.4.2 CU Registrar Horarios de Clases
4.4.3 CU Gestionar Reporte


01 ERS Carga Lectiva

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 ERS Carga Lectiva

Cargado por

Copyright:

Formatos disponibles

UNIDAD DE DESARROLLO, EVALUACIÓN Y MANTENIMIENTO

Especificación de requisitos de software

Proyecto: Carga Lectiva y Horarios

Febrero del 2015

Fecha Revisión Autor Verificado por Coordinador.

Ing. Ninaquispe Matame

Documento validado por las partes en fecha:

Por la Unidad Por la Persona Operadora

Fdo. D./ Dña: Fdo. D./Dña:

Fecha: ____/____/_________ Fecha: ____/____/_________

UNIVERSIDAD NACIONAL DEL SANTA

UNIVERSIDAD NACIONAL DEL SANTA

1.3 Personal involucrado

1.4 Definiciones, acrónimos y abreviaturas

UNIVERSIDAD NACIONAL DEL SANTA

Protocolo.- Señal mediante la cual se reconoce que puede tener lugar la

UNIVERSIDAD NACIONAL DEL SANTA

2.2 Funcionalidad del producto

UNIVERSIDAD NACIONAL DEL SANTA

2.3 Características de los usuarios

2.5 Suposiciones y dependencias

2.6 Evolución previsible del sistema

UNIVERSIDAD NACIONAL DEL SANTA

3.1 Requisitos comunes de los interfaces

3.1.2 Interfaces de hardware

3.1.3 Interfaces de software

UNIVERSIDAD NACIONAL DEL SANTA

3.1.4 Interfaces de comunicación

3.2 Requisitos funcionales

UNIVERSIDAD NACIONAL DEL SANTA

Mensaje de error en el caso de querer agregar a un docente que ya está habilitado

3.2.2 Requisito funcional 2

Mensaje de error en casos de ingresar incorrectamente los datos es decir que el

3.2.3 Requisito funcional 3

3.2.4 Requisito funcional 4

UNIVERSIDAD NACIONAL DEL SANTA

Fuente del requisito BD Tabla: crl_carga, hro_horariocab, hro_horariodet

3.3 Requisitos no funcionales

UNIVERSIDAD NACIONAL DEL SANTA

Se estima que se manejará alrededor 150 transacciones durante el día,

El servidor de base de datos, deberá tener un respaldo apropiado, así como

UNIVERSIDAD NACIONAL DEL SANTA

3.4 Otros requisitos

UNIVERSIDAD NACIONAL DEL SANTA

Figura 1. Caso de uso del negocio

4.2 Definición de actores del modulo

4.3 Diagrama de Casos de uso del sistema

UNIVERSIDAD NACIONAL DEL SANTA

4.4 Diagramas de Actividad (Especificación de casos de uso)

UNIVERSIDAD NACIONAL DEL SANTA

4.4.2 CU Registrar Horarios de Clases

4.4.3 CU Gestionar Reporte

UNIVERSIDAD NACIONAL DEL SANTA

También podría gustarte

Fecha: //_ Fecha: //_____