lunes, 8 de octubre de 2012

Especificación de Requerimientos Funcionales

Especificación de Requerimientos Funcionales

El administrador da de alta usuarios.

Precondición: El administrador ingresa al área de registro.

Flujo Primario.

1.    El sistema solicita datos al administrador.
2.    El administrador ingresa y envía sus datos en el sistema.
       
          Nombre (24) Alfabético
          Usuario (24) Alfanumérico
          Password ( 24) Alfanumérico
          Correo electrónico (30) Alfanumérico
          Número de empleado (30) Alfanumérico 
3.    El sistema registra al usuario.

Flujo Secundario Alta Usuarios.

1.    El sistema solicita información al administrador.
2.    El administrador ingresa su información.

3.    El sistema válida la información y la envía a la Base de Datos de lo contrario Flujo Alterno “Datos incorrectos”.
4.    La Base de Datos verifica inexistencia de usuario y lo almacena de lo contrario Flujo Alterno”Usuario Existente”.
5.    La Base de Datos informa del registro al sistema.
6.    El sistema informa del registro al administrador.

Flujo Alterno Datos Incorrectos.

1.    El sistema informa al administrador de un error en el tipo de datos.
2.    El sistema vuelve a solicitar información al administrador.

Flujo Alterno Usuario Existente.

1.    La Base de Datos informa al sistema de la existencia de un usuario con la misma información.
    2.    El sistema informa al administrador de la existencia de un usuario con la misma información. 



El administrador podrá dar de baja usuarios.

Pre condición: El administrador ingresa al área de bajas.

Flujo Primario. 

1.    El sistema solicita datos al administrador.
2.    El administrador ingresa y envía datos de usuario en el sistema.

        
               Usuario (24) Alfanumérico
               Password ( 24) Alfanumérico
      
3.    El sistema borra la información del usuario.


Flujo Secundario Baja Usuarios.

1.    El sistema solicita información al administrador.
2.    El administrador ingresa información del usuario a eliminar.
3.    El sistema válida la información y la envía a la Base de Datos de lo contrario Flujo Alterno “Datos incorrectos”.
4.    La Base de Datos verifica existencia de usuario y elimina información del usuario de lo contrario Flujo Alterno “Usuario Inexistente”.
5.    La Base de datos notifica de la eliminación del usuario al sistema.
6.     El sistema notifica de la eliminación del usuario al administrador.

 Flujo Alterno Datos Incorrectos.

1.    El sistema informa al administrador de un error en el tipo de datos.
2.    El sistema vuelve a solicitar información al administrador.

Flujo Alterno Usuario Inexistente.

1.    La Base de Datos informa al sistema de la inexistencia del usuario.
2.    El sistema informa al administrador de la inexistencia del usuario.




El administrador da de alta instrumentos.

Precondición: El administrador ingresa al área de registro de instrumentos.
Flujo Primario.
          Nombre (24) Alfabético
          Estado (24) Alfanumérico 
          Área (24) Alfanumérico
          Último usuario (30) Alfanumérico
          Cantidad (5) Numérico
3.    El sistema registra instrumento.



1.    El sistema solicita datos al administrador.
2.    El administrador ingresa y envía sus datos en el sistema.
       


Flujo Secundario Alta Instrumentos.

1.    El sistema solicita información al administrador.
2.    El administrador ingresa información del instrumento.
3.    El sistema válida la información y la envía a la Base de Datos de lo contrario Flujo Alterno “Datos incorrectos”.
4.    La Base de Datos verifica inexistencia de instrumento y lo almacena de lo contrario Flujo Alterno”Instrumento Existente”.
5.    La Base de Datos informa del registro al sistema.
6.    El sistema informa del registro al administrador.

Flujo Alterno Datos Incorrectos.

1.    El sistema informa al administrador de un error en el tipo de datos.
2.    El sistema vuelve a solicitar información al administrador.

Flujo Alterno Instrumento Existente.
1.    La Base de Datos informa al sistema de la existencia de un instrumento con la misma información.
    2.    El sistema informa al administrador de la existencia de un instrumento con la misma información. 

Administrador y usuarios podrán consultar inventario de instrumentos.


Flujo Primario.

1.    El usuario accede a la sección de consulta.
2.    El sistema solicita datos al administrador/usuario.
3.    El administrador/usuario ingresa y envía datos de/los instrumentos en el sistema.
4.    El sistema envía la información del/los instrumentos.

Flujo Secundario Consulta Instrumentos.

1.    El sistema solicita información al administrador/usuario
2.    El administrador/usuario ingresa información del/los instrumentos a consultar.
          
         Nombre (24) Alfanumérico
         Costo (6) Numérico 
          Marca (30) Alfabético
          Modelo (10) Alfanumérico

3.    El sistema válida la información y la envía a la Base de Datos de lo contrario Flujo Alterno “Datos incorrectos”.
4.    La Base de Datos verifica existencia de/los instrumentos y envía información del usuario de lo contrario Flujo Alterno “Instrumentos Inexistentes”.
5.    El sistema envía consulta al administrador/usuario.

Flujo Alterno Datos Incorrectos.

1.    El sistema informa al administrador/usuario de un error en el tipo de datos.
2.    El sistema vuelve a solicitar información al administrador/usuario.

Flujo Alterno Instrumentos Inexistentes.

1.    La Base de Datos informa al sistema de la inexistencia del/los instrumentos.
2.    El sistema informa al administrador/usuario de la inexistencia del/los instrumentos.




El usuario consulta la disponibilidad de instrumentos.

Flujo Básico
  1. El usuario solicita disponibilidad de instrumentos al sistema
  2. El sistema envía al usuario los instrumentos
  3. El usuario selecciona el instrumento que desea y se ejecuta flujo secundario “Consulta de Instrumentos”

Flujo Secundario 

Consulta de Instrumentos

  1. El sistema solicita al usuario el instrumento a consultar
  2. El usuario selecciona el instrumento y envía al sistema
  3. El sistema verifica la solicitud y envía a la Base de Datos de lo contrario flujo alterno “Escoja un instrumento”
  4. La Base de Datos verifica la existencia del instrumento
  5. La Base de Datos informa al Sistema la información del instrumento
  6. El Sistema informa al usuario la información del instrumento

Flujo Alterno
Escoja un Instrumento
  1. El sistema informa al usuario que no ha seleccionado ningún instrumento


El administrador cambia la disponibilidad de instrumentos.

Flujo Básico
  1. El administrador solicita la opción cambios al sistema
  2. El sistema envía al administrador la lista de instrumentos
  3. El administrador escoge el instrumento y envía al sistema y se ejecuta flujo secundario “Modificar Instrumentos”

Flujo Secundario
Modificar Instrumentos
  1. El usuario selecciona el instrumento y envía al sistema
  2. El Sistema solicita al usuario el instrumento a modificar
  3. El sistema solicita al usuario los datos del producto
          Nombre (24) Alfanumérico
          Costo (6) Numérico 
          Marca (30) Alfabético
          Modelo (10) Alfanumérico 
     
     4.    El usuario ingresa información y envía al sistema 
     5.    El sistema valida la información y envía a la Base de Datos de lo contrario flujo alterno   “Datos inválidos” 
     6.    La Base de Datos verifica la inexistencia de los datos modificados y almacena la información de lo contrario flujo alterno “Datos ya existentes” 
     7.    La Base de Datos informa al sistema el cambio de la información del instrumento 
     8.    El sistema informa al usuario la modificación del instrumento


    Flujo alterno
    Datos Inválidos
    1. La Base de Datos informa al sistema que los datos introducidos no son válidos
    2. El sistema envía mensaje de datos inválidos
    Datos ya existentes
    1. La Base de Datos informa al Sistema que los datos introducidos ya existen
    2. El Sistema informa al Administrador que los datos ya existen


    Flujo Básico “Consulta de Usuarios”

    1. El administrador accede al sistema, este envíaun formulario de entrada.
    2. El usuario envía los datos :
      1. Nombre de usuario varchar(24)
      2. Password varchar(24)
    3. El sistema envía los datos a la base de datos
    4. La base de datos verifica que el usuario exista y este a su vez coincida con la contraseña  de lo contrario se ejecuta flujo secundario “Datos Incorrectos”.
    5. El sistema loguea al usuario.
    6. El usuario envía al sistema una petición de una consulta general.
    7. El sistema envía una petición a la base de datos.
    8. La base de datos verifica si hay registros de usuarios y enviara los registros en los campos de nombre, departamento y especialidad al sistema, de no haber registros, se enviara  “Registro vacio”.
    9. El sistema desplegara en pantalla ya sean los datos de los usuarios o bien “Registros Vacios”.



    Flujo Básico “Conociendo MonoSoft”

    1. El usuario entra al sitio.
    2. El usuario hace click en la pestaña Conócenos y se envía una petición al sistema.
    3. El sistema recibirá la petición y desplegara en pantalla la visión, la misión y algunos datos relevantes e informativos de nuestra empresa.

    Flujo Básico  “Cambio de Datos”

    1. El administrador accede al sistema y envía al sistema los datos del usuario que necesite que sus datos sean modificados, bastara con el nombre y/o  el Ip para encontrar al usuario.
    2. El sistema envía estos datos a la base de datos.
    3. La base de datos verifica si existe algún registro que coincida con alguno de estos datos y enviara los datos del usuario.
    4. De lo contrario se ejecuta el flujo “Datos incorrectos o usuario no encontrado”.
    5. El usuario puede cambiar los datos que sean necesarios los cuales pueden ser:
      1. Nombre (24) Alfabético
      2. Apellido (12) Alfabético
      3. Correo Electrónico (48) Alfanumérico
    6. El administrador envía los nuevos datos al sistema.
    7. El sistema manda los datos ya validados a la base de datos.
    8. La base de datos rescribelos datos del usuario.

    Flujo Secundario “Datos incorrectos o usuario no encontrado”

    1. La base de datos envía la excepción al sistema.
    2. El sistema despliega en pantalla la leyenda Favor de verificar que los datos sean correctos.
    3. El sistema regresa a la página donde se ingresaban los datos.

    El usuario consulta su bandeja de instrumentos.


    Flujo Básico
    1. El usuario solicita Información de  la Bandeja de instrumentos al sistema
    2. El sistema envía al usuario la Información de los Instrumentos
    Flujo Secundario
    1. El Usuario solicita al Información de  la Bandeja de instrumentos al sistema
    2. El sistema solicita a la base de datos información de los instrumentos
    3. La Base de Datos verifica si la bandeja contiene Instrumento de lo contario flujo alterno “bandeja vacía”
    4. La Base de Datos envía al Sistema la información de los instrumentos
    5. El Sistema despliega al usuario la información de los instrumento
    Flujo Alterno

    “Bandeja vacía”
    1.    La base de datos informa al sistema que la bandeja no contiene instrumentos
    2.   El sistema informa al usuario “bandeja vacia”

    lunes, 1 de octubre de 2012

    Requerimientos cafeteria


    Requerimientos Funcionales Cafetería
    • Atender en tiempo y forma a los clientes
    • Entregar en tiempo y forma de productos.
    • Dar mantenimiento a las áreas de uso de clientes.
    • Atender a tiempo para evitar congestionamientos.
    • Conseguir y acomodar los productos.
    • Realizar pagos a trabajadores
    • Solicitar producto a proveedores.
    • Pagar proveedores.

    viernes, 7 de septiembre de 2012

    Documento de Requerimientos


    Introducción

    Este proyecto se elabora  con la finalidad de resolver la problemática social de la administración de la entrada, salida y ubicación de material y/o instrumentos quirúrgicos.

    Nuestro proyecto pretende atacar el problema social de la atención de pacientes, ayudando a la agilización del transporte de material y/o utensilios, mejorando su atención y aumentando la probabilidad de éxito durante una situación médica.

    El proceso que se lleva a cabo actualmente en el hospital se realiza consite en que una persona (almacenista) se encarga de registrar tanto la salida como la entrada de los instrumentos que la\el enfermera(o) solicitan haciendo que el almacenista anote uno por uno dichos instrumentos previamente solicitados así como el nombre del solicitante, la ubicación a la que se llevará(n) el\los instrumento(s), obteniendo así un proceso tardado, una difícil e inexacta ubicación de los instrumentos y un impreciso control de los mismos instrumentos.

    Se planea solucionar estos problemas mediante el diseño e implementación de un sistema distribuido que permita el control del material utilizado en el campo médico.

    Definición de Requerimientos

    Los requerimientos/requisitos de un sistema describen los servicios que ha de ofrecer el sistema y las restricciones asociadas a su funcionamiento.

    Requerimientos funcionales:


    Expresan la naturaleza del funcionamiento del sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su estado y funcionamiento).

    Requerimientos no funcionales:


    Restricciones sobre el espacio de posibles soluciones.



    Requerimientos Funcionales
    ·         El administrador de sistema da de alta y de baja usuarios.
    ·          Justificación: Por motivos de seguridad y control es necesario que los usuarios no realicen ninguna de estas acciones para evitar el mal uso del sistema.

    ·         El administrador de sistema consulta usuarios.
    ·          Justificación: Dado que el administrador se encargará del alta, baja y modificación de los datos de usuarios es necesario que pueda conocer esta información.

    ·         El administrador de sistema da de alta instrumentos.
    ·          Justificación: Para poder realizar todos los demás módulos en cuanto a instrumental es necesario que sean dados primero de alta.

    ·         Administrador y usuarios pueden consultar almacén.
    ·          Justificación: Dado que tanto el administrador y los usuarios en algún momento necesitarán consultar los instrumentos es necesario que este se encuentre disponible a su acceso.

    ·         El usuario consulta información de la empresa.
    ·          Justificación: Por motivos de posibles quejas y/o sugerencias es necesario que los usuarios del sistema tengan acceso a la información de la empresa para poder atenderlos.

    ·         El usuario consulta la disponibilidad de instrumentos.
    ·          Justificación: Dado que los usuarios del sistema son los que realizarán acciones con los instrumento es necesario que pueden conocer la disponibilidad de estos.

    ·         El administrador cambia la disponibilidad de instrumentos.
    ·          Justificación: Dado que el administrador es el encargado del control del sistema, es necesario que éste pueda modificar el estado de los instrumentos.

    ·         El usuario consulta su bandeja de instrumentos.
    ·          Justificación: Por motivos de control los usuarios solo podrán tener una cierta cantidad de instrumentos, por lo tanto es necesario que el usuario sepa cuantos instrumentos tiene en su poder.

    ·         El usuario controla su sesión.
    ·          Justificación: Dado que los datos de los usuarios serán almacenados y que el sistema solamente podrá ser accesado por usuarios registrados es necesaria la existencia de una sesión.

    ·         El usuario solicita modificar su contraseña
    ·          Justificación: Por motivos de seguridad el usuario podrá solicitar un cambio de contraseña para su mayor comodidad. 

    ·         El administrador puede modificar los datos del usuario.
    ·          Justificación: Por motivos de control y seguridad el administrador será el encargado de la modificación de los usuarios. 


    Requerimientos No Funcionales
    1.       El sistema tendrá un diseño adecuado para la lectura de información.

    Justificación: Es necesario que el sistema sea fácil y entendible para los usuarios.

    Métrica: El usuario podrá comprender la información presentada en la aplicación sin necesidad de una explicación previa.

    2.       Existirán solamente 7 tipos de usuarios: Enfermera, médico/cirujano, administrador de sistema, administrador de almacén,  agente externo.

    Justificación: Dado que se manejará información e instrumental privado, es necesario tener delimitado el personal que podrá acceder al sistema.

    Métrica: La detección de un agente externo al sistema debe de ser en un lapso muy corto de tiempo.

    3.       La página estará disponible todo el tiempo.

    Justificación: Dado que el sistema será implementado en el área médica donde se atienden emergencias es necesario que el sistema se encuentre disponible en cualquier momento.

    Métrica: El acceso a la aplicación web no dependerá del momento en el que se accese al mismo.

    4.       La página será confiable y segura.

    Justificación: Dado que se maneja información de los usuarios y del hospital es necesaria que ésta no pueda ser utilizada con fines distintos a los requeridos.

    Métrica: La restricción de acceso hacia la información confidencial deberá ser permanente y continua a menos de que el propietario de dicha información sea la persona que desee acceder a ella.

    5.       La página funcionará en cualquier navegador.  

    Justificación: Debido a la gran variedad de navegadores que existen es necesario que el programa funcione en cualquiera de ellos para comodidad del cliente. 

    Métrica: Las funciones de la aplicación web funcionarán en tiempo y forma sin importar el navegador que se emplee.

    6.       La página tendrá soporte para dispositivos móviles.

    Justificación: Dado que el sistema será implementado en un área en la que los usuarios se encuentran en constante desplazamiento es necesaria que la página pueda ser consultada desde cualquier lugar.

    Métrica: Las funciones de la aplicación se podrán realizar de la misma manera en un dispositivo móvil que en un dispositivo fijo.

    7.       El acceso al sistema será restringido solo para el personal de la empresa.

    Justificación: Por cuestiones de seguridad y para evitar filtros de información se requiere que el acceso sea restringido.

    Métrica: La detección del usuario que desea acceder deberá ser un lapso muy corto de tiempo y en caso de un intento de acceso a usuarios desconocidos el sistema deberá de negar cualquier operación.

    8.                  El sistema tendrá una interfaz sencilla y entendible.

    Justificación: Dado que el sistema será implementado para agilizar el control de instrumentos es necesario que este sea fácil de entender.

    Métrica: El usuario aprenderá a utilizar el sistema en un lapso muy corto de tiempo y de buena manera.

    9.        El sistema estará conectado a una base de datos en MySQL.

    Justificación: Es necesaria la existencia de una base para poder tener un control de usuarios e instrumentos y su control.

                      Métrica: La información será almacenada solamente en caso de la existencia de una base de datos, en caso contrario será notificada su inexistencia.

    10.    El sistema estará formado por una aplicación web.
    Justificación: Es necesario que el sistema se encuentre en una plataforma que permita el uso de bases de datos y servlets.
      
    Métrica: Bastará con la existencia de un navegador para poder tener acceso a la aplicación.

    Requerimientos del Sistema 

    Justificación: Es necesario ya que implementaremos módulos en este lenguaje.

    * Navegador Web

        Google Chrome https://www.google.com/intl/es/chrome/browser/?hl=es
       Mozilla Firefox http://www.java.com/es/download/
       Opera http://www.opera.com/
        
    Justificación: Es donde se visualizará la página web.

    * Apache Tomcat instalado
    Justificación: Es necesario ya que se ocuparan servlets. 

    * MySQL     http://www.mysql.com/

    Justificación: Ya que es necesario almacenar datos en una base de datos.

    * Microsoft Windows 7/Xp o Vista 

    Justificación: Es el sistema operativo más común y accesible para los usuarios.

    Diagrama de Casos de Uso