You are on page 1of 40

Informe de Requerimientos

Consutal

Integrantes:
Diego Arévalo
Enrique Concha
José Luís Del Solar
Profesor:
Víctor Santander

1

Índice
Introducción …………………………………………………………………… 3
Requisitos funcionales ………………………………………………………… 4
Modelado organizacional I*…………………………………………………… 8
Requerimientos no funcionales ……………………………………………….. 10
Casos de uso …………………………………………………………………... 12
Diagrama casos de uso ………………………………………………………... 27
Diagrama de clases ……………………………………………………………. 28
Anexos ………………………………………………………………………… 30
Conclusiones …………………………………………………………………... 37
Evaluación de equipo ………………………………………………………….. 38

2

Introducción
El Departamento de Cobranzas de la Universidad de Talca, dependiente de la
Vicerrectora de Administración y Finanzas, se encuentra ubicado en Casa Central 2
Norte 685, Talca.
Como requerimiento principal y necesidad del Jefe del departamento de cobranzas
estaba el poder tener un programa que pudiese mostrar los pagares de los alumnos
digitalizados de los alumnos. Estos pagares deben ser buscados por rut principalmente
y de esta forma el programa debe mostrar los datos del alumno y desplegar una lista
con los años en que el alumno tiene el pagare en PDF. De esta forma el cliente podrá
ver los pagares en PDF, imprimir los datos del alumno, exportar estos datos y poder
calcular la deuda del alumno.
Todos los privilegios y requerimientos podrán ser ejecutados por el Jefe del
departamento de cobranzas, este podrá dar los privilegios que estime conveniente a
los a alumnos ayudantes.
Este informe detallará los requerimientos que son básicos para el ayudante y los
requerimientos propios del Jefe del departamento de cobranzas. Tanto funcionales
como no funcionales.

3

Modelo organizacional I*
El modelado organizacional nos permite darnos cuenta de quienes son los actor que
interactuaran y los que no interactuan con nuestro software en la empresa.
Cancelar
deuda
Alumno

Administrar
ayudante

Jefe de
departamento
de cobranza
Obtener
pagare

Modificar
privilegios

Buena
atencion
ISA

Obtener RUT

Sistema
Según privilegios
dados

Calcular
deuda

Visualizar
pagare
Ayudante
Administrar
Carreras

Administrar
alumnos

Pagare

Fácil de
usar
Buena
atencion

Modelo de dependencias estratégicas
Este nos permite ver que actor se interrelacionara con otras partes ya sea del sistema u
otro actor.
El jefe de departamento en nuestro caso es el Administrador del sistema, lo que
implica que éste tiene acceso a todo el sistema. El ayudante en un principio tendría
acceso a casi todas las funcionalidades excepto las relacionadas con la edición de los
ayudantes, pero eso dependerá de los privilegios otorgados por el jefe de
departamento. El alumno no tiene acceso al sistema, ya que sólo tiene comunicación
con el ayudante o el jefe de departamento.

4

Alumno Obtener RUT Ayudante Buena atencion Obtener pagare Cancelar deuda Según privilegios dados Calcular deuda Visualizar pagare Administrar Carreras Administrar alumnos Fácil de usar Seguridad Jefe de departamento de cobranza ISA Pagare Ingresar Modificar privilegios Sistema Mostrar estado de duda Consultar Obtener datos Administrar ayudante Pagare Privilegios Pagare Gestionar pagare Borrar Mostrar en pantalla Obtener datos Impreso Alumno Modificar Actualizar base de datos Alumno Carrera Ingresar Obtener datos Borrar Base de datos Actualizar base de datos Ingresar Ingresar Actualizar base de datos Modificar Actualizar base de datos Modificar Ayudante Carrera Consultar Obtener datos Consultar Obtener datos Borrar Borrar 5 .

Nos permite establecer seguridad en el sistema. además de tener la posibilidad de exportar desde Excel. Requerimientos no funcionales Rendimiento Confiable And And And Rapidez Or Fácil Manutención Fácil de Usar And Espacio Seguridad Some + Some - And Acces And And Or Teclas Rápidas Or Restricción de privilegios And And Interfaz Gráfica And manual de usuario Some Login . 6 .Razones Estratégicas Aquí vemos con más detalles las tareas y funciones del diagrama de dependencias estratégicas el diagrama de razones estratégicas no es mas que una extensión de el diagrama anteriormente visto con una mayor especificación por tareas y/o funciones. Login: Permite al usuario establecer una contraseña y de esta manera restringir los privilegios sobre la información manejada.Net C# Java SQL Server Operacionalizaciones del producto Formas de llevar a cabo los requisitos no funcionales Access: Se utilizara Access como base de datos relacional. por lo que la rapidez. espacio y seguridad utilizado estará ligado a la eficiencia de está base de datos.

Net C#: El lenguaje elejido es C# y el entorno de desarrollo es . además debe contar con el espacio suficiente para almacenar la base de datos (pueden llegar a 500 MB incluyendo los pagares) con los datos que se irán guardando a medida que se los alumnos y las carreras. cuando se necesita agregar o retirar información que se encuentra en la base de datos. Interfaz Grafica: La interfaz esta diseñada con el objetivo de lograr que el usuario navegue y utilice el programa de manera intuitiva. Seguridad: El sistema valida el password para que el usuario pueda entrar a su sesión. Fácil de usar: El sistema es fácil de usar para el cliente. Esto es decir que disminuya los tiempos de espera de los clientes (alumnos) para poder pagar y recibir su comprobante.Net. 7 . El sistema debe contar con el NFR framework más actual para pode ejecuta el programa. Teclas Rápidas: Estos son comandos que optimizan el tiempo del usuario. de esta manera la información esta restringida a los privilegios que tenga cada usuario. Rapidez: El software debe mostrar rapidez una vez que se realicen operación de búsqueda. El usuario si no cuenta con este kit puede descargarlas gratuitamente.. Espacio: El espacio debe ser óptimo (no mas de 50 MB sin contar la base de datos) para que el sistema pueda ser instalado y funcione correctamente. En la actualidad esto tarda alrededor de 10 minutos. accediendo así de manera más rápida a la opción que el desea. El sistema cuente con la seguridad necesaria para que este sea lo suficientemente confiable. dado que se utiliza un vocabulario por el conocido y una interfaz amigable e intuitiva.NET ambos de microsoft. y esperamos que con la implementación del software se realice en menos de 5 minutos.Es la tecnología utilizada para programar el sistema. Además debe presentar rapidez cuando se requiera validar el passsword del usuario y sobre todo en la búsqueda e impresión del pagare. Requerimientos no funcionales del Proceso Rendimiento: Se espera que el software tenga un rendimiento adecuado a lo que el cliente espera y necesita. Confiable: El software esta programado en . Le sistema contara también con un manual de ayuda para facilitar el entendimiento del programa. Estas busquedas no deben tardar más de 1 segundo.

El sistema debe permitir consultar los datos de un alumno ya ingresado. apellidos. El sistema debe permitir agregar un nuevo alumno.Requisitos Funcionales [RF01] Ingresar Alumno Prioridad: Alta. Cobranzas. Cobranzas. El sistema debe permitir desplegar en la pantalla un pagaré previamente seleccionado y buscado. nº de matricula. El sistema debe permitir consultar los datos de un alumno ya ingresado. Cobranzas. Solicitante/Fuente: Jefe Depto. 8 . mediante el nº de matricula del alumno. [RF05] Consultar alumno por nombre Prioridad: Baja. Solicitante/Fuente: Jefe Depto. carrera a la que pertenece. mediante el Rut del alumno. [RF02] Borrar Alumno Prioridad: Media. Cobranzas. Solicitante/Fuente: Jefe Depto. El sistema debe permitir consultar los datos de un alumno ya ingresado. [RF04] Consultar Alumno por Rut Prioridad: Media. El sistema debe permitir borrar un alumno mediante el ingreso del Rut del alumno o el nº de matricula. Cobranzas. recibiendo los datos de sus nombres. Cobranzas. [RF-06]Consultar alumno por nº matricula Prioridad: Baja. año de ingreso. El sistema debe permitir editar los datos de un alumno especifico. Solicitante/Fuente: Jefe Depto. Solicitante/Fuente: Jefe Depto. [RF03] Editar Alumno Prioridad: Media. ingresando el Rut del alumno o el nº de matricula. Rut. Cobranzas. Solicitante/Fuente: Jefe Depto. [RF07] Mostrar Pagaré Prioridad: Media. dirección. Solicitante/Fuente: Jefe Depto. mediante el nombre del alumno.

[RF09] Buscar pagaré de un alumno por Rut Prioridad: Alta. apellidos. contraseña. Cobranzas. nickname. El sistema debe permitir al usuario modificar sus datos personales como su nombre y apellido. correo electrónico. Cobranzas. Solicitante/Fuente: Jefe Depto. El sistema debe permitir mostrar todos los pagares correspondientes a un año especifico. [RF13] Agregar Ayudante Prioridad: Baja. [RF11] Buscar pagarés de un año específico Prioridad: Media. Cobranzas.[RF08] Imprimir Pagaré Prioridad: Alta. Solicitante/Fuente: Jefe Depto. El sistema debe permitir buscar todos los pagares de un alumno a partir de su Rut. [RF10] Buscar pagaré de un alumno por nº matricula Prioridad: Baja. nombre de ayudante. El sistema debe permitir buscar todos los pagares de un alumno a partir de su numero de matricula. correo electrónico. Solicitante/Fuente: Jefe Depto. Cobranzas. El sistema debe permitir imprimir un pagare seleccionado. Solicitante/Fuente: Jefe Depto. Cobranzas. [RF14] Modificar datos de un usuario (ayudante y jefe de departamento de cobranza) Prioridad: Baja. recibiendo los datos de sus nombres. Cobranzas. El sistema debe permitir mostrar todos los pagares correspondientes a una carrera especifica. Rut. contraseña. Solicitante/Fuente: Jefe Depto. dirección y Rut. dirección. Cobranzas. Solicitante/Fuente: Jefe Depto. 9 . [RF12] Buscar pagarés de una carrera especifica Prioridad: Baja. Solicitante/Fuente: Jefe Depto. El sistema debe permitir agregar un nuevo ayudante. etc.

Cobranzas. El sistema debe permitir borrar un ayudante mediante el ingreso del Rut de este o el nickname. Cobranzas. [RF20] Ingreso al sistema Prioridad: Baja. Solicitante/Fuente: Jefe Depto. Solicitante/Fuente: Jefe Depto. Solicitante/Fuente: Jefe Depto. haciendo más o menos permisible el acceso al sistema de un ayudante u otro.[RF15] Recuperar contraseña usuario (ayudante y jefe de departamento de cobranza) Prioridad: Media. Cobranzas. El sistema debe permitir modificar los privilegios de acceso al sistema que posee cada ayudante. 10 . El sistema debe permitir ingresar al sistema (jefe depto o ayudante) ingresando su login y su contraseña. Solicitante/Fuente: Jefe Depto. [RF19] Modificar privilegios de los ayudantes Prioridad: Baja. El sisteme debe permitir consultar los datos de un ayudante ya ingresado. mediante el Rut de este. [RF18] Consultar Ayudante por nombre Prioridad: Baja. Solicitante/Fuente: Jefe Depto. Cobranzas. Solicitante/Fuente: Jefe Depto. El sistema debe permitir agregar uno o más (sin limites) pagarés a un alumno seleccionado. Cobranzas. [RF16] Borrar ayudante Prioridad: Baja. [RF21] Agregar pagaré a un alumno existente Prioridad: Alta. [RF17] Consultar Ayudante por Rut Prioridad: Baja. Cobranzas. El sisteme debe permitir consultar los datos de un ayudante ya ingresado. El sistema envía en un correo electrónico la contraseña del usuario y el nickname en el caso de que se le halla olvidado. mediante el nombre o nickname de este. Solicitante/Fuente: Jefe Depto. Cobranzas.

Cobranzas. [RF24] Crear arancel carrera Prioridad: Media. El sistema calcula la deuda total de un alumno sumando el arancel de la carrera de cada año en el cual tenga un pagaré. el valor está determinado en pesos chilenos. Solicitante/Fuente: Jefe Depto. para realizar la consulta se debe ingresar el nombre de la carrera. Solicitante/Fuente: Jefe Depto. El sistema debe permitir ingresar al sistema una nueva carrera. Solicitante/Fuente: Jefe Depto. Se debe ingresar el nombre de la carrera para poder consultarla. [RF27] Consultar nombres de las carreras con un cierto valor de arancel y el año. Cobranzas. 11 . Solicitante/Fuente: Jefe Depto. Solicitante/Fuente: Jefe Depto. [RF28] Ingresar Carrera nueva Prioridad: Media. Cobranzas. El sistema debe permitir agregar un nuevo valor (de un nuevo año) a una carrera existente. El sistema debe permitir eliminar el arancel de una carrera ya ingresada. [RF25] Borrar arancel carrera Prioridad: Media.[RF22] Calcular deuda de un alumno Prioridad: Media. Solicitante/Fuente: Jefe Depto. El sistema debe permitir visualizar los nombres de las carreras y el arancel correspondiente a un año en especifico. Cobranzas. Cobranzas. Prioridad: Baja. Solicitante/Fuente: Jefe Depto. El sistema debe permitir modificar el arancel de una carrera. [RF23] Modificar Arancel Carrera Prioridad: Media. Cobranzas. El sistema debe permitir ver el arancel de la carrera. con todos los datos correspondientes a esta. [RF26] Consultar arancel carrera por el nombre de la carrera y el año Prioridad: Media. Cobranzas.

12 . de cobranzas). Cobranzas. son exportado a Word (por peticion del jefe del depto. Solicitante/Fuente: Jefe Depto. Cobranzas.[RF29] Modificar nombre Carrera Prioridad: Media. [RF30] Eliminar una Carrera Prioridad: Media. [RF32] Exportar datos de un alumno Prioridad: Baja. [RF31] Exportar lista alumnos no morosos Prioridad: Media. El sistema debe permitir exporta los datos de un alumno seleccionado a Word (por peticion del jefe del depto. Cobranzas. Solicitante/Fuente: Jefe Depto. El sistema debe permitir exporta una lista de todos los alumnos que tienen deuda cero. El sistema debe permitir modificar en el sistema el nombre de una carrera. Cobranzas. Solicitante/Fuente: Jefe Depto. El sistema debe permitir eliminar en el sistema una carrera. Solicitante/Fuente: Jefe Depto. de cobranzas) para especificar que deben ser borrados de la base de datos de la universidad.

Casos de Uso Los casos de uso presentes en nuestro sistema consutal se agrupan en 5 tipos de casos: -Los casos de uso relacionados con el manejo de alumnos en el sistema. -Los casos de uso relacionados con el manejo de las carreras (aranceles y nombres). -Los casos de uso relacionados con el manejo de los ayudantes. lo que implica que debe poder agregarse varios ayudantes (se puede contar con más de un ayudante). Los dos primeros tipos de casos de uso son de alta prioridad. Lo relacionado con las carreras es de media prioridad. debido a que son una expansión del sistema. ya que son funcionalidades extras del sistema (son útiles. 13 . Nuestro cliente (el jefe de cobranzas) tiene alumnos ayudantes que son remunerados por la universidad. -Los casos de uso relacionados con el manejo de los pagarés. recuperar contraseña). debido a que son los esenciales para que el sistema sea útil. -Los casos de uso de la seguridad del sistema (ingreso al sistema. En un principio el software será usado por un único ayudante. pero no le son de primera prioridad al cliente). pero a futuro puede ser usado por diversos ayudantes. Los relacionados con los ayudantes son de baja prioridad.

El sistema retorna un mensaje de error. Suceso no Esperado: No se puede ingresar el alumno al sistema. -2. de cobranzas ó Ayudante. Actor Principal: Jefe de Depto. Prioridad: Alta. Faltan datos importantes por ingresar del alumno. Prioridad: Alta. -2. Se envía un mensaje. -3. Actor Principal: Jefe de Depto.El alumno fue ingresado con anterioridad al sistema. Escenario Principal de suceso: -1.El alumno a modificar no se encuentra en la base de datos. si desea ingresar el alumno como nuevo alumno (<<extend>> Caso uso 1). el sistema manda un mensaje de error (<<extend>> Caso uso 4). Extend: -1. Escenario Principal de suceso: -1. (<<include>> Caso uso 4) -3.El usuario ingresa los datos del alumno.El sistema agrego al alumno. (<<include>> Caso uso 4).El usuario ingresa el Rut o Matricula del alumno.Se modifican los datos que se requieran. Suceso Esperado: Se logra modificar los datos del alumno satisfactoriamente Suceso no Esperado: No se pueden modificar los datos del alumno en el sistema. de cobranzas ó Ayudante. -2.El sistema modifica los datos del alumno. 14 . -4. Suceso Esperado: Se logra ingresar al alumno satisfactoriamente.El sistema verifica la existencia del alumno.El sistema verifica la no existencia del alumno.Caso de uso 1: Ingresar Alumno Descripción: Agregar un alumno al sistema Precondición: El alumno no debe haber sido registrado con anterioridad en el sistema. Caso de uso 2: Modificar Alumno Descripción: Modifica los datos de un alumno al sistema Precondición: El alumno debe haber sido registrado con anterioridad en el sistema. Extend: -1.

Suceso Esperado: El sistema retorna los datos del alumno.Se eliminan todos los pagarés existentes referente al alumno (<<include>> caso uso 9) -4. Suceso Esperado: Se logra eliminar al alumno satisfactoriamente Suceso no Esperado: No se puede eliminar el alumno del sistema.El usuario ingresa el Rut. 15 . Matricula o nombre del alumno.El alumno no ha podido ser encontrado. Actor Principal: Jefe de Depto. Escenario Principal de suceso: -1. El sistema retorna un mensaje de error. Extend: -1. Extend: -1.El sistema realiza una búsqueda del alumno. Suceso no Esperado: No se pueden encontrar los datos del alumno en el sistema.Caso de uso 3: Borrar Alumno Descripción: Un alumno presente en el sistema es eliminado Precondición: El alumno debe haber sido registrado con anterioridad en el sistema. -3. Prioridad: Alta. Actor Principal: Jefe de Depto. Matricula o nombre del alumno. Prioridad: Alta. de cobranzas ó Ayudante. Cobranzas Ayudante. Se encuentran los datos del alumno y son mostrados en pantalla.El alumno que se quiere eliminar del sistema no esta presente en el sistema. -2. -2. Escenario Principal de suceso: -1.Consultar alumno a eliminar (<<include>> Caso uso 4) -3. El sistema retorna un mensaje de error. Precondición: El alumno debe haber sido registrado con anterioridad en el sistema. El alumno es eliminado satisfactoriamente.El usuario ingresa el Rut. Caso de uso 4: Consultar alumno Descripción: Busca los datos de un alumno en el sistema.

Precondición: debe haber al menos un pagaré agregado en el sistema para poder ser desplegado. o sus datos no han podido ser exportados. Escenario Principal de suceso: -1. Ejemplo Word. Suceso no Esperado: No se ha podido encontrar pagarés de un alumno o no se ha podido abrir el pagaré del alumno. de cobranzas ó Ayudante. El sistema retorna el pagaré seleccionado. Suceso Esperado: El sistema muestra el pagaré del alumno.Caso de uso 5: Exportar datos de un alumno Descripción: Permite exportar los datos de un alumno seleccionado a otro formato. Suceso no Esperado: No se ha podido encontrar un alumno en el sistema. El usuario busca el pagaré a mostrar del alumno correspondiente (<<include>> Caso uso 8). Caso de uso 6: Mostrar Pagaré Descripción: Muestra un pagaré seleccionado. El sistema retorna un mensaje de error. Extend: -1. -2. Escenario Principal de suceso: -1.El alumno no ha podido ser exportado.El pagaré no ha podido ser desplegado. Prioridad: Baja. Actor Principal: Jefe de Depto. Precondición: debe haber al menos un alumno agregado en el sistema para poder ser exportado. El sistema retorna un mensaje de error. Prioridad: Alta. Actor Principal: Jefe de Depto. 16 . Extend: -1. El sistema exporta los datos del alumno a formato Word. El usuario selecciona el alumno a exportar desde una lista (<<include>> Caso uso 4). -2. Suceso Esperado: El sistema exporta todos los datos del alumno. de cobranzas ó Ayudante.

Suceso Esperado: El sistema imprime el pagaré del alumno. de cobranzas ó Ayudante. Escenario Principal de suceso: -1. Suceso no Esperado: No se ha podido encontrar pagarés de un alumno o el alumno no existe. Prioridad: Alta.Caso de uso 7: Imprimir Pagaré Descripción: Imprime un pagaré seleccionado. El sistema retorna un mensaje de error. Suceso Esperado: El sistema retorna en una lista los pagarés de un alumno seleccionado. Actor Principal: Jefe de Depto. 17 . El sistema retorna un mensaje de error. de cobranzas ó Ayudante. El sistema imprime el pagaré seleccionado. Caso de uso 8: Buscar Pagaré Descripción: Busca los pagaré de un alumno seleccionado y despliega una lista con los pagarés. El usuario busca el alumno que se desea buscar los pagarés (caso de uso include: Consultar Alumno). Extend: -1. Precondición: El alumno debe tener agregado al menos un pagaré al sistema. -2. El sistema retorna un mensaje de error. Actor Principal: Jefe de Depto.No se han podido encontrar pagarés de ese alumno. -2. El sistema despliega una lista con todos los pagarés existentes del alumno. Prioridad: Alta. El usuario selecciona el pagaré a imprimir a partir de una lista (<<include>> Caso uso 8). Suceso no Esperado: No se ha podido encontrar pagarés de un alumno o no se ha podido abrir el pagaré del alumno.No existe el alumno al cual se deseaba buscar el pagaré. -2. Escenario Principal de suceso: -1.El pagaré no ha podido ser impreso. debido a que no tiene pagarés registrados en el sistema. Precondición: debe haber al menos un pagaré agregado en el sistema para poder ser impreso. Extend: -1.

debido a que no tiene pagarés registrados en el sistema. -2.Habiendo comprobado que no existe se agrega el ayudante. Prioridad: Baja.Caso de uso 9: Borrar Pagaré Descripción: Elimina uno o mas pagarés de un alumno en particular. ingresa el Rut del ayudante.El jefe de Depto. -2. Escenario Principal de suceso: -1. Extend: -1. Actor Principal: Jefe Depto. Precondición: El alumno debe tener agregado al menos un pagaré al sistema. El sistema retorna un mensaje de error. El usuario busca los pagarés de un cierto alumno a borrar (<<include>> Caso uso 8) -2. El sistema retorna un mensaje de error. Actor Principal: Jefe de Depto. Faltan datos importantes por ingresar del ayudante. Escenario Principal de suceso: -1.Hay un error de solo lectura con el pagaré seleccionado. de cobranzas ó Ayudante. 18 .Se revisa que el ayudante no este ingresado (<<include>> Caso uso 13 -3. de cobranzas. Prioridad: Alta. Suceso no Esperado: No se ha podido eliminar los pagarés de un alumno o el alumno no tiene pagarés. Se seleccionan los pagarés a eliminar. -3. Los pagarés seleccionados son eliminados del sistema.El ayudante fue ingresado con anterioridad al sistema. -2. Suceso Esperado: Se logra ingresar al ayudante satisfactoriamente Suceso no Esperado: No se puede ingresar el ayudante al sistema.No se han podido encontrar pagarés de ese alumno. Suceso Esperado: El sistema elimina los pagarés de un alumno seleccionado. Caso de uso 10: Agregar Ayudante Descripción: Agregar un ayudante al sistema Precondición: El ayudante no debe haber sido registrado con anterioridad en el sistema. el sistema manda un mensaje de error. El sistema retorna un mensaje de error. Extend: -1.

El ayudante que se quiere eliminar del sistema no esta presente en el sistema.Consultar ayudante para ver si existe el ayudante a modificar (<<include>> Caso uso 13) -3. el sistema pregunta si desea ingresar el ayudante como nuevo ayudante (<<extend>> Caso uso 10). Actor Principal: Jefe Depto. Suceso Esperado: Se logra eliminar al ayudante satisfactoriamente Suceso no Esperado: No se puede eliminar el ayudante del sistema. -2. ingresa el Rut del ayudante. Prioridad: Baja. ingresa el Rut del ayudante.El ayudante a modificar no se encuentra en la base de datos.El jefe de Depto. de cobranzas.Se modifican los datos del ayudante. de cobranzas. Escenario Principal de suceso: -1. Escenario Principal de suceso: -1. 19 . Actor Principal: Jefe Depto. Suceso Esperado: Se logra modificar los datos del ayudante satisfactoriamente Suceso no Esperado: No se pueden modificar los datos del ayudante en el sistema. Prioridad: Baja. Extend: -1. -2. Caso de uso 12: Borrar Ayudante Descripción: Un ayudante presente en el sistema es eliminado Precondición: El ayudante debe haber sido registrado con anterioridad en el sistema.Él o los ayudantes son eliminados satisfactoriamente. Extend: -1.Consultar ayudante a eliminar (<<include>> Caso uso 13) -2.E jefe de Depto.Caso de uso 11: Modificar Ayudante Descripción: Modifica los datos de un ayudante en particular Precondición: El ayudante debe haber sido registrado con anterioridad en el sistema. El sistema retorna un mensaje de error.

Suceso no Esperado: No se pueden encontrar los nicknames de los ayudantes del sistema. -2. Precondición: El ayudante debe haber sido registrado con anterioridad en el sistema. Caso de uso 14: Modificar Privilegios ayudantes Descripción: Se modifican los privilegios de acceso al sistema de un ayudante.Se modifican los privilegios del ayudante. Escenario Principal de suceso: -1. ingresa el Rut del ayudante. -3. de cobranzas Suceso Esperado: El sistema retorna el nickname del ayudante.El jefe de Depto. Actor Principal: Jefe Depto. Precondición: El nickname del ayudante debe haber sido registrado con anterioridad en el sistema.El ayudante a modificar no se encuentra en la base de datos. El sistema retorna un mensaje de error.El sistema realiza una búsqueda del ayudante. Extend: -1. Actor Principal: Jefe Depto. de cobranzas.El ayudante no ha podido ser encontrado en la base de datos del sistema.Consultar ayudante para ver si existe el ayudante (<<include>> Caso uso 13) -3. Suceso Esperado: Se logra modificar los privilegios del ayudante satisfactoriamente Suceso no Esperado: No se pueden modificar los privilegios del ayudante en el sistema. Prioridad: Baja. Extend: -1. Prioridad: Baja. El sistema retorna un mensaje de error.Caso de uso 13: Consultar ayudante Descripción: Busca los nicknames de uno o mas ayudantes. 20 .Se encuentran los nicknames de los ayudantes.El jefe de Depto. ingresa el Rut del ayudante. Escenario Principal de suceso: -1. debido a que no estaba registrado en el sistema. -2.

por lo cual no se puede enviar el correo. Actor Principal: Jefe de Depto.No hay conexión a Internet. El sistema retorna un mensaje de error. Suceso no Esperado: No se puede enviar el correo al usuario. Se agrega el(los) pagaré(s) seleccionado al alumno. Escenario Principal de suceso: -1. Precondición: El usuario debe haber sido registrado con anterioridad en el sistema. Suceso no Esperado: No se logra adjuntar el(los) pagaré(s) al alumno seleccionado. -3.El usuario que intentaba loguearse no existe en la base de datos. Prioridad: Alta.Caso de uso 15: Recuperar contraseña de usuario Descripción: Se envía el nickname y la contraseña de un usuario particular. -2.. El usuario olvida su contraseña. Actor Principal: Jefe de Depto. El sistema retorna un mensaje de error.Primero se busca el alumno al cual se desea adjuntar el(los) pagaré(s) desde una lista (<<include>> Caso uso 4). El usuario intenta ingresar al sistema pero falla (<<include>> Caso uso 26) -2. -2. El sistema envía la contraseña y el login al correo electrónico definido en sus datos personales. -2. Extend: -1. de cobranzas ó Ayudante. Suceso Esperado: Se logra enviar el correo al usuario. 21 . Prioridad: Baja. Escenario Principal de suceso: -1. Extend: -1. por lo cual no se puede enviar el correo.El pagaré no puede ser adjuntado.El usuario ingresa el Rut del alumno. Caso de uso 16: Agregar pagarés alumno Descripción: Se agrega uno o más pagarés a un alumno existente en la base de datos Precondición: El alumno debe haber sido registrado con anterioridad en el sistema. de cobranzas ó Ayudante. Suceso Esperado: Se logra adjuntar el(los) pagaré(s) al alumno seleccionado. debido a un error de lectura.

pero no tiene arancel. Actor Principal: Jefe de Depto. -2. Prioridad: Media. por los pagarés agregados de cada año. 22 . Escenario Principal de suceso: -1. -2.Se consulta el arancel de la carrera en los respectivos años de los pagarés (<<include>> Caso uso 21). Suceso Esperado: Se logra calcular la deuda al alumno seleccionado. -3. Prioridad: Media.El alumno no tiene pagarés adjuntados. El sistema nos pregunta si queremos ingresar el arancel de la carrera (<<extend>> Caso uso 19). Se consultan los pagarés del alumno seleccionado (<<include>> Caso uso 4).Se modifica el arancel satisfactoriamente Extend: -1. -4. El sistema genera un mensaje de error.No existe la carrera a la cual queríamos modificar su arancel.Caso de uso 17: Calcular deuda de un alumno existente Descripción: Se calcula la deuda total de un alumno seleccionado. el sistema retorna que tiene una deuda de cero pesos.La carrera que fue consultada para ser modificado su arancel si existe. Suceso Esperado: Se logra modificar el arancel de la carrera seleccionada.Se suman todos los aranceles y el sistema retorna el resultado. Suceso no Esperado: No se logra modificar el arancel de la carrera seleccionada. Precondición: El alumno debe haber sido registrado con anterioridad en el sistema (si no tiene pagarés es deuda igual a cero) Actor Principal: Jefe de Depto. Extend: -1. de cobranzas ó Ayudante. -2. Suceso no Esperado: No se logra calcular la deuda al alumno seleccionado. de cobranzas ó Ayudante.No existe el alumno al cual se le quiere calcular la deuda.Primero se busca el alumno al cual se desea calcular la deuda (caso de uso include: Consultar Alumno). multiplicando el arancel de cada año. -3.Primero se busca la carrera cual se desea modificar el arancel (<<include>> Caso uso 25). El sistema genera un mensaje de error. Precondición: La carrera debe haber sido ingresada al sistema con anterioridad. -2. Escenario Principal de suceso: -1.El usuario ingresa el Rut del alumno. -2. Caso de uso 18: Modificar arancel de una carrera Descripción: Se modifica el arancel de una carrera preseleccionada.El usuario ingresa el nombre de la carrera.

Prioridad: Media. pero ya tiene un arancel.La carrera que fue consultada para ser modificado su arancel si existe.No existe la carrera a la cual queríamos borrar el arancel. El sistema genera un mensaje de error. Se agrega satisfactoriamente el arancel a la carrera. El sistema genera un mensaje de error. 23 . Extend: -1. La carrera que fue consultada para ser modificado su arancel si existe. Suceso no Esperado: No se logra eliminar el arancel de la carrera seleccionada. -2.Se elimina satisfactoriamente el arancel a la carrera.Se busca la carrera cual se desea eliminar el arancel (<<inlcude>> Caso uso 25).El usuario ingresa el nombre de la carrera. -2. -4. Extend: -1. El sistema genera un mensaje de error.El usuario ingresa el nombre de la carrera. -2. Prioridad: Media. Suceso Esperado: Se logra eliminar el arancel de la carrera seleccionada. El sistema nos pregunta si queremos modificar el arancel anterior de la carrera (<<include>> Caso uso 18) -2.Se busca la carrera cual se desea agregar un arancel (<<include>> Caso uso 25). Escenario Principal de suceso: -1.Caso de uso 19: Crear arancel de una carrera Descripción: Se crea el arancel de una carrera preseleccionada. -3. Escenario Principal de suceso: -1. de cobranzas ó Ayudante. Caso de uso 20: Borrar arancel de una carrera Descripción: Se elimina el arancel de una carrera preseleccionada. -2. Precondición: La carrera debe haber sido ingresada al sistema con anterioridad. Actor Principal: Jefe de Depto. de cobranzas ó Ayudante. Actor Principal: Jefe de Depto. Precondición: La carrera no debe haber sido ingresada al sistema con anterioridad. Suceso Esperado: Se logra crear el arancel de la carrera seleccionada. pero no tiene un arancel.No existe la carrera a la cual queríamos agregar un arancel. Suceso no Esperado: No se logra crear el arancel de la carrera seleccionada.El sistema revisa si la carrera tiene arancel(<<include>> Caso uso 21).

Suceso no Esperado: No se logra modificar la carrera seleccionada.El usuario ingresa el nombre de la carrera. El sistema genera un mensaje de error. -2. -2. El sistema nos pregunta si queremos ingresar la carrera como una carrera nueva (<<extend>> Caso uso 23) 24 .Se busca la carrera cual se desea consultar el arancel (<<include>> Caso uso 25).No existe la carrera a la cual queríamos consultar el arancel. de cobranzas ó Ayudante. La carrera que fue consultada existe. La carrera que fue consultada para ser modificada no existe. Prioridad: Media. Actor Principal: Jefe de Depto. pero no tiene un arancel agregado.Caso de uso 21: Consultar arancel de una carrera Descripción: Se consulta arancel de una carrera ingresando el nombre y el año del cual se desea saber el arancel. Suceso no Esperado: No se logra consultar el arancel de la carrera seleccionada. Suceso Esperado: Se logra modificar la carrera seleccionada. -2. de cobranzas ó Ayudante. Escenario Principal de suceso: -1. Suceso Esperado: Se logra consultar el arancel de la carrera seleccionada. Extend: -1. Caso de uso 22: Modificar una carrera Descripción: Se modifica una carrera preseleccionada. El sistema pregunta si acaso la queremos agregar (<<include>> Caso uso 19) -2. Prioridad: Media. El usuario debe ingresar el nombre y/o el año de una carrera (si ingresa uno de los dos aparece una lista donde el usuario selecciona la carrera y el año que buscaba). Actor Principal: Jefe de Depto. -2. Se consulta satisfactoriamente el arancel a la carrera. -3. Precondición: La carrera debe haber sido ingresada al sistema con anterioridad.Se busca la carrera cual se desea modificar (<<include>> Caso uso 25). Precondición: La carrera debe haber sido ingresada al sistema con anterioridad. Se modifica la carrera satisfactoriamente. Escenario Principal de suceso: -1.El usuario ingresa el nombre de la carrera. Extend: -1.

Escenario Principal de suceso: -1. de cobranzas ó Ayudante. Precondición: La carrera no debe haber sido ingresada al sistema con anterioridad. Escenario Principal de suceso: -1. El sistema genera un mensaje de error. -3. Precondición: La carrera debe haber sido ingresada al sistema con anterioridad. El sistema nos pregunta si queremos modificar los datos de la carrera (<<exted>> Caso uso 22).El sistema elimina los aranceles de la carrera de todos los años. Extend: -1. Suceso Esperado: Se logra crear la carrera seleccionada. Suceso no Esperado: No se logra eliminar la carrera seleccionada.El usuario ingresa el nombre de la carrera.Se elimina satisfactoriamente la carrera.Se agrega satisfactoriamente el arancel a la carrera. La carrera que quiere crear el usuario ya existe. -2. Actor Principal: Jefe de Depto. si la carrera tiene aranceles en algún año(<<include>> Caso uso 20) -4. La carrera que se quiere eliminar no existe. Suceso no Esperado: No se logra crear la carrera seleccionada. Extend: -1.Caso de uso 23: Crear una carrera Descripción: Se crea una carrera nueva. -2.Se busca si es que no existe la carrera (<<include>> Caso uso 25).Se busca la carrera que se desea eliminar (<<include>> Caso uso 25). Actor Principal: Jefe de Depto. -3. Caso de uso 24: Borrar una carrera Descripción: Se elimina una carrera preseleccionada. 25 .El usuario ingresa los datos de la carrera. Prioridad: Media. Suceso Esperado: Se logra eliminar la carrera seleccionada. Prioridad: Media. de cobranzas ó Ayudante.

-3. Suceso Esperado: Se logra consultar la carrera seleccionada. El usuario ingresa el Login y la contraseña para validar su sesión.Caso de uso 25: Consultar carrera Descripción: Se consulta una carrera ingresando el nombre de una carrera. de cobranzas ó Ayudante. de cobranzas ó Ayudante.El usuario ingresan los datos de la carrera (nombre de la carrera. El sistema le pregunta al usuario si desea recuperar su contraseña. El sistema genera un mensaje de error. 26 . El sistema genera un mensaje de error. Precondición: La carrera debe haber sido ingresada al sistema con anterioridad. Suceso Esperado: Se logra ingresar al sistema. El usuario ingresa satisfactoriamente al sistema. Extend: -1. Escenario Principal de suceso: -1. Suceso no Esperado: No se logra ingresar al sistema. Se ingresa satisfactoriamente la carrera. Caso de uso 26: Ingreso al sistema Descripción: Un usuario ingresa al sistema para identificarse como un ayudante o el jefe departamento cobranzas. -2. Suceso no Esperado: No se logra consultar la carrera seleccionada. Prioridad: Alta. Actor Principal: Jefe de Depto. Extend: -1.No existe el usuario. Precondición: El usuario debe haber sido previamente ingresado al sistema.Contraseña errónea. (<<extend>> Caso uso15). Actor Principal: Jefe de Depto. Prioridad: Media. o parte de él.No existe la carrera a la cual queríamos consultar. Escenario Principal de suceso: -1. años impartiendo la carrera) -2. Se comprueba la existencia del usuario y la concordancia de sus datos con la base de datos. -2.

de cobranzas ó Ayudante.No existen alumnos. Prioridad: Media. Extend: -1. El sistema genera un mensaje de error.No hay alumnos sin deuda. Precondición: Los alumnos deben haber sido previamente ingresado al sistema. Suceso Esperado: Se logra exportar la lista. Actor Principal: Jefe de Depto.Se calcula la deuda del alumno (<<include>> Caso uso 17). Suceso no Esperado: No se logra exportar la lista.Se consultan los alumnos que tiene deuda igual a cero (<<include>> Caso uso 25) -2. El sistema genera un mensaje de error. -2. 27 . Escenario Principal de suceso: -1.Caso de uso 27: Exportar lista de los alumnos no morosos Descripción: Exporta la lista de los alumnos que retiraron sus pagares y tienen deuda cero.

representa un resumen visual de lo que expusimos anteriormente en formato de texto.(para que se pueda comprender de una mejor manera también hemos agregado mini diagramas en los anexos. debido a que el diagrama es muy grande y un poco complicado de entender) 28 .Diagrama casos de uso Éste es el diagrama de casos de uso completo del sistema.

debido a que necesitábamos relacionar estas características en común. 29 . muestra la estructura o el esqueleto de las clases del sistema a ser desarrollado. Los ayudantes y el alumno heredan de persona. Jefe de departamento de cobranzas también es un descendiente de persona. A continuación detallaremos las clases y sus vínculos Clase Persona: Da la estructura de una persona. aunque no directamente.Diagrama de clases Éste es el diagrama de clases del sistema.

tiene una relación de agregación con pagaré debido a que ambos son parte de una misma cosa. Los aranceles son todos de una carrera. Puede tener cero o más alumnos a registrar. Hereda de la clase persona. Clase Carrera: Clase que sirve para modelar a una carrera en el sistema.Clase Alumno: Clase que sirve para modelar a un alumno en el sistema. Clase Jefe departamento cobranzas: Clase que sirve para modelar al jefe de departamento de cobranzas en el sistema. Hereda de persona. pero tiene más privilegios. 30 . Representan los aranceles de una carrera en diversos años. Representan los pagarés de un alumno en los diversos años que lleva en la carrera. Clase Arancel: Clase que sirve para modelar un arancel de una carrera en el sistema. Representa las carreras existentes en el sistema. tiene una relación de agregación con arancel debido a que ambos son parte de una misma cosa. Clase Ayudante: Clase que sirve para modelar a un ayudante en el sistema. pero como tiene uno o más decidimos agregarlo como clase. pero como tiene uno o más decidimos agregarlo como clase. Representa las mismas relaciones que el ayudante. Un alumno puede tener cero o más pagarés. cero o más aranceles y carreras a registrar. Los pagarés son todos de un alumno. Clase Pagaré: Clase que sirve para modelar a un pagaré en el sistema. es el padre de la clase jefe departamento cobranzas. debido a que el jefe de departamento cobranzas puede hacer todo lo que los ayudantes hacen. cero o más pagarés a registrar.

los subdividimos en 5 tipos de casos de uso para su mayor comprensión.Anexo: Mini casos de uso Debido a que el diagrama de casos de uso es muy grande. Tipo 1: Diagrama Casos de uso del alumno 31 . Mostraremos los diagramas de cada uno de los tipos de casos de uso con sus casos de uso correspondientes.

Tipo 2: Diagrama Casos de uso de los pagarés 32 .

Tipo 3: Diagrama Casos de uso de las carreras 33 .

Tipo 4: Diagrama Casos de uso de la seguridad del sistema Tipo 5: Diagrama Casos de uso de los ayudantes 34 .

4. ¿Es posible que existan alumnos sin pagares en la base de datos? Si. ¿De que forma usted recibe los datos del alumno de la base de datos de la Universidad? Todos los datos del alumno se me entregan en una planilla de Excel. 6. 7. 1. Por esto necesito que la base 35 . cada año cambian los aranceles de la carrera. 5. seria bueno para poder ver los alumnos que tienen una mayor deuda. con eso seria suficiente. ¿Cual es la cantidad promedio de alumnos a los que usted entrega los pagares por haber cancelado toda su deuda? La cantidad de alumnos a la cual se le entregan sus pagare mensualmente no es mucha. el SAFI muestra deuda cero en los estados de deuda del alumno. nuestro principal usuario. y es en esta planilla en donde trabajo con los datos de los alumnos. ¿Entonces necesita una lista con los alumnos que tienen deuda cero. pueden ser 2 a 15 mensualmente. como en el caso de los alumnos nuevos. ¿Necesita calcular el estado de deuda. dependiendo de los pagares que tiene el alumno sin pago? A pesar de que SAFI ya calcula la deuda de los alumnos. ya que los pagares se están ingresando de apoco a la base de datos. 3. no es mucha. ¿Qué requiere del sistema para poder actualizar la base de datos de la universidad con los alumnos que ya cancelaron su deuda? Una vez que cancela toda la deuda. no es necesario que todos los alumnos tengan pagares. 2. no se les aplica el arancel correspondiente a ese año. a los alumnos que llevan mas de un año en la universidad se les reajusta el arancel en un porcentaje. para poder agregar el cometario a la base de datos de la universidad? Claro.Anexo 2: Recopilación de entrevistas realizada al jefe del Departamento de Cobranzas. ¿El arancel tiene un costo que cambia o es fijo desde el ingreso del alumno a la carrera? Dependiendo del año de ingreso del alumno se establece el arancel anual. por lo que necesitamos que el sistema (Consutal) nos muestre cuales son los alumnos a los que ya se les entrego el pagare para poder agregar a la base de datos de la universidad el cometario que los pagares ya fueron entregados. depende del mes la cantidad de personas que tienen cancelada su deuda a totalidad. por ende así se puede visualizar cuales son los alumnos que tienen mayor cantidad de pagares impagos.

No es imprescindible. ¿Qué datos son ocupados para calcular el estado de deuda de un alumno? Se necesita saber que año ingreso a la carrera. este debería poder agregar. ya que para actualizar y manejar en el futura la base de datos del software me es conocido y fácil de usar. 36 . A este monto se le aplica un porcentaje por interés en el caso que el alumno tenga deuda pendiente.de datos este en Access. me gustaría poder imprimir los datos de alumno y reportar estos datos a un archivo Word para mandar información del alumno. y cuantos años lleva en la universidad. editar o borrar carreras. Anexo 3: Estructura organizacional Universidad de Talca. del tiempo que yo tenga o la confianza que existan con el ayudante. cual es su carrera. 9. 10. ¿Necesita de un reporte o datos exportados para utilizarlos en otra actividad? Si. pero seria bueno que yo pueda designar los privilegios al ayudante según estime yo conveniente. ¿Que privilegios con respecto a los ayudantes. deben tener estos en lo relacionado con el estado de deuda? Dependiendo de la persona. 8.

Además de Administrar. El departamento cuenta con una dotación de Personal de 6 personas. 37 . Esporádicamente el departamento cuenta con el apoyo de alumnos ayudantes que realizan distintas actividades dentro del departamento. principal usuario del sistema a desarrollar. Javier Rojo.El Software a Desarrollar es para el departamento de Cobranzas de la Universidad de Talca. identificación y registro de todo deudor de la Universidad. Estos ayudantes por orden del jefe del departamento podrán usar el Software y tener los privilegios que este estime convenientes. Este departamento tiene por jefe al Sr. las cuales realizan actividades relacionadas con la obtención. gestionar y ejecutar los procesos de cobranza por deuda de los alumnos.

Una vez establecidos los casos de uso dependientes a cada usuario se procedió a utilizar UML para modelar los casos de uso. diagramas de clases y la interacción entre el usuario y el sistema.Conclusiones Posteriormente al estudio de viabilidad ya realizado. A medida que realizábamos entrevistas obteníamos los requerimientos que debían ser implementados y funcionales en el software. se definió la alternativa más viable para la empresa. Para modelar los requisitos no funcionales del sistema se utilizo la técnica NFRFramework. con esto ya concluido comenzamos con la extracción de los requerimientos funcionales y no funcionales que necesitara el sistema. Para modelar el entorno organizacional de la empresa se utilizo la técnica i* para modelar las dependencias y razones estratégicas. 38 . De esta forma obtuvimos una visión completa y clara de cómo debían ser desarrollados los requerimientos necesarios para implementar el Software.

Formulario de Reporte del Equipo Nombre % Esfuerzo Diego Arévalo 333% Enrique Concha 333% José Luís Del Solar 333% Firma 39 .

40 .