Fase I del Proyecto

Requisitos Funcionales

  • Registro de Usuario

    Como usuario, necesito poder registrar una cuenta para iniciar sesión en la aplicación.

    Criterios de Aceptación:

    • Un usuario, sin cuenta registrada, inicia el registro en la aplicación.
    • El usuario selecciona el tipo de usuario correspondiente a su rol en la granja.
    • El usuario introduce un nombre de usuario con seis caracteres alfanuméricos, donde el primer carácter es una letra.
    • El usuario establece una contraseña de seis caracteres alfanuméricos, donde dos caracteres son dígitos, introduciéndola dos veces.
    • El usuario queda registrado en la aplicación.
  • Recuperación de Contraseña

    Como usuario, necesito poder recuperar la contraseña de mi cuenta.

    Criterios de Aceptación:

    • Un usuario registrado que no recuerda su contraseña inicia el proceso de recuperación.
    • El usuario introduce su nombre de usuario y una nueva contraseña dos veces.
    • El usuario inicia sesión con su nombre de usuario y su nueva contraseña.
  • Inicio de Sesión

    Como usuario, necesito poder iniciar sesión con mi cuenta para acceder a las funcionalidades de la aplicación.

    Criterios de Aceptación:

    • Un usuario registrado inicia sesión con su nombre de usuario y contraseña.
    • Tras la confirmación, el usuario accede a la aplicación y a las funcionalidades de su rol.
  • Baja de Usuario

    Como usuario, necesito poder eliminar mi cuenta para que no pueda acceder a la aplicación cuando no trabaje en la granja.

    Criterios de Aceptación:

    • Un usuario se da de baja de la aplicación.
    • Tras eliminarse su cuenta, no puede iniciar sesión.
  • Adición de Sensor

    Como gestor, necesito poder añadir un sensor nuevo de tipo CO2 o NH3 con su ubicación en la granja (precisión de 1 m²) para que el sensor empiece a operar.

    Criterios de Aceptación:

    • El gestor añade un sensor de tipo CO2 con su ubicación.
    • La aplicación empieza a recibir datos del sensor.
  • Eliminación de Sensor

    Como gestor, necesito poder eliminar un sensor activo para dejar de recibir sus datos.

    Criterios de Aceptación:

    • El gestor elimina un sensor activo.
    • La aplicación deja de recibir datos del sensor.
  • Operador Encargado de Sensores

    Como operador, necesito poder indicar los sensores de los que me encargo para recibir posibles incidencias.

    Criterios de Aceptación:

    • El operador indica que se encarga de dos sensores, uno de CO2 y otro de NH3.
    • El operador recibe información solo de esos sensores.
  • Operador Deja de Atender un Sensor

    Como operador, necesito poder dejar de atender un sensor para no recibir sus incidencias.

    Criterios de Aceptación:

    • El operador, que se encargaba de dos sensores (CO2 y NH3), deja de atender el de CO2.
    • El operador solo recibe información del sensor de NH3.
  • Aviso de Incidencias

    Como operador, necesito recibir avisos de incidencias para restablecer las condiciones óptimas de la granja.

    Criterios de Aceptación:

    • Un sensor de NH3 registra una incidencia (violación del Real Decreto 692/2010).
    • El operador recibe un aviso de la incidencia.
  • Informe de Incidencias

    Como operador, necesito poder realizar informes de incidencias para registrarlas y estimar su tiempo de resolución.

    Criterios de Aceptación:

    • El operador recibe el aviso de una incidencia de un sensor de NH3.
    • El operador informa de la incidencia (nombre del operador, sensor, ubicación).
    • El informe queda registrado en una traza de la sesión.

Requisitos No Funcionales

  • Usabilidad

    Como desarrollador, necesito diseñar pantallas con máximo siete elementos funcionales para facilitar el uso.

    Criterios de Aceptación:

    • Ninguna pantalla supera los cinco elementos.
    • Se registra el número de veces que un usuario retrocede en menos de dos segundos tras aceptar una opción.
    • El número de equivocaciones se reduce a prácticamente cero.
  • Confiabilidad

    Como desarrollador, necesito guardar información en ficheros con estructuras de datos de Java para garantizar la persistencia.

    Criterios de Aceptación:

    • Se usan estructuras de datos de Java para la persistencia.
    • La aplicación recibe información simultánea de usuarios y sensores.
    • La información se almacena en un fichero único.
    • El fichero mantiene la información en el tiempo.
  • Rendimiento

    Como desarrollador, necesito mantener una tasa de procesamiento estable para asegurar una respuesta rápida.

    Criterios de Aceptación:

    • Se calcula el tiempo de procesamiento con una y diez incidencias simultáneas.
    • El tiempo de procesamiento es similar en ambos casos.
  • Espacio

    Como desarrollador, necesito almacenar la información en un fichero único para ahorrar espacio.

    Criterios de Aceptación:

    • Se utiliza un fichero único para la información persistente.
    • Toda la información relevante se guarda en este fichero.
  • Entrega

    Como desarrollador, necesito documentar las funcionalidades principales.

    Criterios de Aceptación:

    • Las funcionalidades se documentan en un manual.
    • Un operador sin experiencia puede usar la aplicación con el manual.
  • Implementación

    Como desarrollador, necesito usar Swing de Java para la entrada/salida.

    Criterios de Aceptación:

    • La entrada/salida se implementa con Swing.
    • Las pruebas de entrada/salida son positivas.
  • Estándares

    Como desarrollador, necesito registrar todas las alteraciones detectadas para cumplir con el Real Decreto 629/2010.

    Criterios de Aceptación:

    • Se registra una incidencia de un sensor de NH3.
    • Tras resolverse, la incidencia se guarda en un fichero.
    • El fichero registra todas las alteraciones.
  • Ética

    Como desarrollador, necesito atender todas las incidencias para el seguimiento de la calidad de la carne.

    Criterios de Aceptación:

    • Se recibe una incidencia de un sensor de CO2.
    • El operador informa de la ubicación del sensor y el tiempo estimado de resolución.
    • La incidencia se registra en la sesión.
  • Privacidad

    Como desarrollador, necesito restringir el acceso a datos personales mediante Row Level Security.

    Criterios de Aceptación:

    • Se implementa Row Level Security.
    • Un operador no puede acceder a datos de un gestor u otro operador.
  • Seguridad

    Como desarrollador, necesito proteger las contraseñas con cifrado simétrico.

    Criterios de Aceptación:

    • Se usa cifrado simétrico por bloques.
    • El sistema resiste ataques de diccionario y fuerza bruta.

Escenario: Mi Granja Avícola

Actores Participantes

Principales

  • Gestor: Añade y elimina sensores, indicando su ubicación.

  • Operador: Se encarga de sensores, recibe incidencias e informa del tiempo de resolución, sensor y ubicación.

Secundarios

  • Sensor de Amoníaco (NH3)
  • Sensor de Dióxido de Carbono (CO2)

Flujo de Eventos

  1. Adición de Sensor de CO2

    • El gestor indica la ubicación, valores máximos y mínimos del sensor.
    • La aplicación registra los datos del sensor.
  2. Baja del Gestor

    El gestor se da de baja de la aplicación.

  3. Operador a Cargo de Sensores

    • El operador se encarga de tres sensores (dos de CO2 y uno de NH3).
    • La aplicación registra esta asignación.
  4. Operador Deja de Atender Sensor

    • El operador deja de atender un sensor de CO2.
    • La aplicación registra el cambio.
  5. Detección de Incidencia

    • El sensor de NH3 detecta una alteración.
    • La aplicación recibe la información y avisa al operador.
  6. Resolución de Incidencia

    • El operador informa de la incidencia y el tiempo estimado de resolución.
    • El operador resuelve la incidencia.
    • La incidencia y su resolución se registran en la sesión y en un fichero.

Condiciones de Entrada

  • Aplicación activa.
  • Sensores de NH3 y CO2 instalados, activos y registrando datos.
  • Gestor y operador registrados e iniciada su sesión.

Condiciones de Salida

  • Nuevo sensor de CO2 funcionando.
  • Operador encargado de tres sensores (uno de NH3 y dos de CO2).
  • Operador deja de encargarse de un sensor de CO2.
  • Incidencia detectada por el sensor de NH3 y aviso al operador.
  • Incidencia resuelta e informada por el operador.
  • Información de la incidencia almacenada en la sesión y en un fichero.

Requisitos No Funcionales

  1. Usabilidad: Diseño de pantallas con máximo siete elementos.
  2. Confiabilidad: Almacenamiento persistente en un fichero con estructuras de datos de Java.
  3. Rendimiento: Tasa de procesamiento estable.
  4. Espacio: Almacenamiento en un fichero único.
  5. Entrega: Documentación de funcionalidades.
  6. Implementación: Uso de Swing de Java para la entrada/salida.
  7. Estándares: Registro de todas las incidencias (Real Decreto).
  8. Ética: Atención de todas las incidencias para seguimiento de la calidad.
  9. Privacidad: Row Level Security para restringir el acceso a datos.
  10. Seguridad: Cifrado simétrico de contraseñas.