DUOC UC - ESCUELA DE INFORMÁTICA Y TELECOMUNICACIONES

Especificación de Requisitos
de Software
Proyecto:
Revisión: [1.2]
[06-09-2024]

Integrantes:

Matias Ortega
Martín Hernández
Javier Muñoz
Claudio Candia

Especificación de Requisitos según estándar de IEEE 830.

 Especificación de Requisitos, estándar de IEEE 830

Contenido
FICHA DEL DOCUMENTO.....................................................................................................................................................................
1. INTRODUCCIÓN............................................................................................................................................................................
1.1. PROPÓSITO..................................................................................................................................................................................
1.2. ÁMBITO DEL SISTEMA....................................................................................................................................................................
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS.....................................................................................................................................
1.4. REFERENCIAS................................................................................................................................................................................
1.5. VISIÓN GENERAL DEL DOCUMENTO..................................................................................................................................................
2. DESCRIPCIÓN GENERAL..................................................................................................................................................................
2.1. PERSPECTIVA DEL PRODUCTO..........................................................................................................................................................
2.2. FUNCIONES DEL PRODUCTO............................................................................................................................................................
2.3. CARACTERÍSTICAS DE LOS USUARIOS.................................................................................................................................................
2.4. RESTRICCIONES.............................................................................................................................................................................
2.5. SUPOSICIONES Y DEPENDENCIAS......................................................................................................................................................
2.6. REQUISITOS FUTUROS....................................................................................................................................................................
3. REQUISITOS ESPECÍFICOS................................................................................................................................................................
3.1 REQUISITOS COMUNES DE LAS INTERFACES..........................................................................................................................................
3.1.1 Interfaces de usuario........................................................................................................................................................
3.1.2 Interfaces de hardware....................................................................................................................................................
3.1.3 Interfaces de software.....................................................................................................................................................
3.1.4 Interfaces de comunicación.............................................................................................................................................
3.2 REQUISITOS FUNCIONALES...............................................................................................................................................................
3.3 REQUISITOS NO FUNCIONALES..........................................................................................................................................................
3.3.1 Requisitos de rendimiento...............................................................................................................................................
3.3.2 Seguridad.........................................................................................................................................................................
3.3.3 Fiabilidad.........................................................................................................................................................................
3.3.4 Disponibilidad..................................................................................................................................................................
3.3.5 Mantenibilidad.................................................................................................................................................................
3.3.6 Portabilidad.....................................................................................................................................................................
3.4 OTROS REQUISITOS........................................................................................................................................................................

2
 Especificación de Requisitos, estándar de IEEE 830

Ficha del documento

Fecha Revisión Autor Modificación

Martin Hernandez

21/08/202 Claudio Candia

1.0 Creación del documento.
4 Matias Ortega

Javier Muñoz

01/09/202 Claudio Bastián Candia Se agregaron todo el apartado de

1.1
4 Pacheco 3.0

06/09/202 Claudio Bastián Candia Se corrigieron errores, remarcados

1.2
4 Pacheco en la pauta del sitio web.

Documento validado por las partes en fecha:

Por el cliente Por la empresa suministradora

3
 Especificación de Requisitos, estándar de IEEE 830

[Firma]

[Firma]

Sr./Sra. Sr./Sra.

1. Introducción

Este documento de Especificación de Requisitos Software (ERS) detalla los requerimientos para el
desarrollo de un sistema de cerradura inteligente, diseñado para incrementar la seguridad en zonas
vulnerables de Chile. El sistema permitirá el acceso a través de la cédula de identidad chilena, huella
digital y un botón de emergencia, integrando tecnología avanzada mediante el uso de Arduino y bases
de datos MongoDB.

Este documento está dirigido a los equipos de desarrollo, diseño, y pruebas, así como a los
stakeholders que intervienen en el ciclo de vida del producto, para asegurar que todos los requisitos
funcionales y no funcionales sean claramente definidos y comprendidos.

1.1. Propósito

El propósito de este documento ERS es establecer una base común de entendimiento entre los
stakeholders y el equipo de desarrollo sobre los requisitos del sistema de cerradura inteligente. Este
documento tiene como fin garantizar que todas las partes involucradas compartan la misma visión del
producto y los objetivos que se desean alcanzar. Está dirigido a desarrolladores, ingenieros de

4
 Especificación de Requisitos, estándar de IEEE 830

software, gerentes de proyecto, y otros profesionales involucrados en la implementación y el

mantenimiento del sistema.

1.2. Ámbito del Sistema

Nombre del sistema: KnockToolUs (KTU).

Descripción del sistema:

● Lo que hará: El sistema permitirá a los usuarios acceder a el hogar mediante la autenticación
con su cédula de identidad chilena, huella digital y un botón de emergencia en caso de que
exista una situación de peligro. Utilizará un Arduino como controlador central y MongoDB para
el almacenamiento seguro de los datos de acceso.

● Lo que no hará: No almacenará imágenes o videos de vigilancia, ni proporcionará seguimiento

en tiempo real de los usuarios fuera del perímetro protegido. Tampoco reemplazará sistemas
de seguridad completos, como cámaras o alarmas.

Beneficios, objetivos y metas:

● Beneficios: Incremento de la seguridad en zonas residenciales y comerciales, reducción de

robos y allanamientos.
● Objetivos: Implementar un sistema seguro y fácil de usar que integre varias capas de
autenticación.
● Metas: Desplegar el sistema en 20 ubicaciones piloto en Santiago, con un 90% de satisfacción
del usuario.

1.3. Definiciones, Acrónimos y Abreviaturas

ERS: Especificación de Requerimientos de Software.

KTU: KnockToolUs (Sistema de seguridad mediante cédula de identidad o huella digital).

Arduino: Plataforma de hardware libre basada en una placa con un microcontrolador y un entorno de
desarrollo integrado.

MongoDB: Base de datos NoSQL orientada a documentos.

5
 Especificación de Requisitos, estándar de IEEE 830

1.4. Referencias
En esta subsección se mostrará una lista completa de todos los documentos referenciados en la ERS.

Guía de Scrum (Scrum Guide)

 Autor: Ken Schwaber y Jeff Sutherland

 Fecha de Publicación: 2020
 Fuente: Scrum.org

Manual de Desarrollo de Requisitos del Proyecto KnockToolUs

 Autor: Equipo de Desarrollo del Proyecto X

 Fecha de Publicación: Agosto 2024
 Fuente: Documentación interna del proyecto

Actas de Reuniones de Planificación de Sprints

 Fecha de las Actas: Agosto - Septiembre 2024

 Fuente: Registros de reuniones del equipo Scrum

Normas Técnicas para Sistemas de Información

 Autor: IEEE
 Fecha de Publicación: 2021
 Fuente: IEEE Standards

Documentación de Stakeholders

 Título: Informe de Requerimientos del Cliente

 Fecha de Publicación: Agosto 2024
 Fuente: Proporcionado por el cliente

1.5. Visión General del Documento

En esta subsección se describe brevemente los contenidos y la organización del resto de la ERS.

6
 Especificación de Requisitos, estándar de IEEE 830

Este documento consta de un área de definición del negocio, un área de especificación de requisitos,
se proporciona el detalle de los requerimientos a través de formularios de caso de uso como anexos.

7
 Especificación de Requisitos, estándar de IEEE 830

2. Descripción General

2.1. Perspectiva del Producto

La cerradura para puertas con identificación mediante carnet es un sistema de control de acceso
diseñado para mejorar la seguridad en entornos residenciales, comerciales o industriales. Este sistema
se integra con la infraestructura existente de control de accesos o se puede implementar como una
solución independiente. La cerradura reconoce tarjetas únicas identificadoras, como carnets o DNIs y
en el caso de que las anteriormente mencionadas falle debido a diversos motivos, se pedirá huella de
forma de identificación, permite o deniega el acceso basándose en la validez de la tarjeta o huella.

2.2. Funciones del Producto

● Autenticación de Usuarios: Verifica la identidad de una persona mediante la lectura de su
carnet o DNI.
● Control de Acceso: Permite o deniega el acceso a una puerta dependiendo de la validez del
método de acceso (Cédula de identidad o Huella).
● Registro de Accesos: Opcionalmente, el sistema puede registrar las entradas y salidas, creando
un historial de accesos.
● Notificaciones: El sistema puede enviar alertas o notificaciones en caso de intentos de acceso
no autorizados.

2.3. Características de los Usuarios

Existirán 2 tipos de perfiles de usuarios, usuario dueño del recinto y usuario visitante del recinto.

Ambos tipos de usuario deben poseer un carnet con el cual se puedan identificar.

El usuario dueño del recinto puede agregar usuarios visitantes al sistema.

2.4. Restricciones
● Compatibilidad con Carnets/DNIs existentes: El sistema debe ser compatible con los
estándares de carnet y DNI actuales.
● Compatibilidad con tipos de huella digital: El sistema deberá ser compatible con la mayoría de
los tipos de huellas digitales, incluyendo huellas de diferentes dedos de una misma mano y de
ambas manos. Esto implica que el sistema debe ser capaz de reconocer y autenticar huellas
digitales con variaciones en tamaño, forma, y características distintivas, asegurando un alto
nivel de precisión en la identificación del usuario.

8
 Especificación de Requisitos, estándar de IEEE 830

● Seguridad de los datos: Se debe garantizar la protección de la información personal de los

usuarios conforme a las leyes de protección de datos.
● Energía: La cerradura debe ser energéticamente eficiente para minimizar el consumo eléctrico,
y podría requerir una fuente de energía de respaldo en caso de fallos.

2.5. Suposiciones y Dependencias

Se usará la base de datos MongoDB para contener la información tanto del usuario como de los Carnet
o DNI y huella.

Se usará el microcontrolador Arduino Uno para controlar el software y los agregados (RFID o
Reconocimiento de huella).

Se utilizará el hardware de RFID para reconocimiento de tarjeta y Hardware de reconocimiento de

huella.

Se asume que todos los usuarios disponen de un dispositivo móvil para poder manipular de mejor
manera los permisos de la cerradura.

Se asume que todos los usuarios disponen de un carnet o DNI válido, huella de identidad y que estos
serán los únicos medio de autenticación.

Se asume que el entorno en el que se instalará la cerradura es seguro frente a manipulaciones físicas.

2.6. Requisitos Futuros

Requisitos futuros, una mayor seguridad o pulir mas la seguridad(ya que al momento de perder/robar
el carnet significa que podrían utilizarlo para poder entrar a tu casa,bloquear el carnet no es una
opción muy viable ya que al cliente le seria un tramite y lo ideal es que todo sea cómodo para el
cliente).

Hacer una app de celular acompañada a la base de datos de la KnockToolUs siendo posible poder abrir
la puerta con tu celular o carnet de identidad.

otras de las posibles mejoras seria que no solo sea con el carnet que se pueda entrar/salir si no que
también un anillo con un microchip posible de dar el acceso a la vivienda.

añadir una cámara a la KnockToolUs que apunte al rostro de la persona, asi se podra saber quien esta
tratando de abrir tu puerta, y que te notifique si la cámara vio movimiento.

9
Especificación de Requisitos, estándar de IEEE 830

10
 Especificación de Requisitos, estándar de IEEE 830

3. Requisitos Específicos
Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los
diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo
requisito aquí especificado describirá comportamientos externos del sistema, perceptibles por parte
de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS.
Deberán aplicarse los siguientes principios:

• El documento debería ser perfectamente legible por personas de muy distintas formaciones e
intereses.

• Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los
requisitos.

• Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de
numeración adecuado.

• Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las
siguientes características:

− Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será
implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica que
el sistema implementado será el sistema deseado.
− No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad
inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o
notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de una
interpretación, se definirán con precisión en el glosario.
− Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas
las posibles respuestas del sistema a los datos de entrada, tanto válidos como no válidos.
− Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorio no es implementable.
− Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos
pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad
(cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear
excesivos recursos en implementar requisitos no esenciales.
− Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables. Un requisito
es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema
cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como
a veces, bien, adecuado, etc. Introducen ambigüedad en los requisitos. Requisitos como “en
caso de accidente la nube tóxica no se extenderá más allá de 25Km" no es verificable por el
alto costo que conlleva.

11
 Especificación de Requisitos, estándar de IEEE 830

− Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los

cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La utilización
de herramientas automáticas de gestión de requisitos facilitan enormemente esta tarea.
− Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia
de cada requisito a los componentes del diseño y de la implementación. La trazabilidad hacia
atrás indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia
delante de un requisito R indica que componentes del sistema son los que realizan el requisito
R.

3.1 Requisitos comunes de las interfaces

3.1.1 Interfaces de usuario

La interfaz de usuario del sistema se desarrollará exclusivamente como una aplicación móvil disponible
para dispositivos iOS y Android. La aplicación permitirá a los administradores gestionar usuarios y
monitorear el sistema de cerraduras de manera eficiente y segura desde sus dispositivos móviles.

Estilo y Colores:

● Estilo: Diseño moderno y minimalista, optimizado para una experiencia táctil en dispositivos
móviles.
● Paleta de Colores:
○ Color Primario: Azul (#007BFF), utilizado para botones principales y encabezados.
○ Color Secundario: Blanco (#FFFFFF) para el fondo de las pantallas.

Navegación:

● Menú Inferior: La aplicación contará con un menú en la parte inferior de la pantalla con iconos
que representen las principales secciones: "Inicio", "Usuarios", "Historial", "Configuraciones", y
"Perfil".
● Gestos: La navegación entre secciones podrá realizarse mediante gestos táctiles, permitiendo
una interacción fluida.

Pantalla Principal:

● Inicio: Esta sección mostrará un resumen de las estadísticas clave, como accesos recientes,
usuarios activos, y alertas de seguridad.
● Gestión de Usuarios: Aquí se podrán agregar, modificar o eliminar usuarios. Los
administradores podrán utilizar la cámara del dispositivo para escanear carnets o DNIs,
facilitando la entrada de datos.
● Historial de Accesos: Mostrará un registro detallado de los accesos, incluyendo fecha, hora, y
resultados (permitido o denegado).

12
 Especificación de Requisitos, estándar de IEEE 830

● Alertas y Notificaciones: La aplicación enviará notificaciones push en tiempo real en caso de

intentos de acceso no autorizados o eventos críticos.

Integración con la Cámara:

● Escaneo de Documentos: Los administradores podrán usar la cámara del móvil para escanear
carnets o DNIs al agregar nuevos usuarios, lo que automatiza el proceso de entrada de datos y
mejora la eficiencia.

Interactividad:

● Feedback Visual: La aplicación proporcionará retroalimentación visual inmediata (cambios de

color, animaciones) para indicar la respuesta del sistema a las acciones del usuario.
● Notificaciones: Los usuarios recibirán notificaciones push personalizadas para eventos como
intentos de acceso no autorizados, nuevas autorizaciones de usuarios, o problemas de
conectividad.

Este diseño asegura que la aplicación móvil sea intuitiva y fácil de usar, ofreciendo a los
administradores todas las herramientas necesarias para gestionar el sistema de cerraduras
directamente desde sus dispositivos móviles.

3.1.2 Interfaces de hardware

La cerradura para puertas con identificación mediante carnet o DNI interactúa con varios componentes
de hardware, incluyendo la unidad de control de la cerradura, el lector de tarjetas, y los mecanismos
de apertura y bloqueo. Esta sección detalla las interfaces y características lógicas para cada
componente del sistema.

Lector de Tarjetas

● Interfaz de Comunicación:
○ Tipo de Comunicación: Comunicación serial (UART) o protocolo específico del lector
(por ejemplo, Wiegand o I2C).
○ Formato de Datos: El lector debe transmitir datos en un formato estandarizado (como
ASCII o hexadecimal) que sea compatible con la unidad de control.

● Características del Lector:

○ Tipo de Tarjeta Compatible: El lector debe ser compatible con el tipo específico de
carnet o DNI utilizado (por ejemplo, tarjetas RFID, tarjetas magnéticas).

13
 Especificación de Requisitos, estándar de IEEE 830

○ Alcance de Lectura: Rango de lectura especificado para asegurar la correcta detección

de las tarjetas.
● Configuración:
○ Parámetros Configurables: Configuración de la frecuencia de lectura, el rango de
operación, y el tipo de tarjetas aceptadas, accesible desde la aplicación móvil.
○ Conexiones: Terminales para conexión con la unidad de control y la fuente de
alimentación.

Fuente de Alimentación

● Interfaz de Comunicación:
○ Tipo de Comunicación: Alimentación eléctrica con especificaciones de voltaje y
corriente.
○ Requisitos: Voltaje y corriente necesarios para alimentar la unidad de control, el lector
de tarjetas y el mecanismo de bloqueo.
● Características de Configuración:
○ Fuente de Alimentación Principal: Debe proporcionar la potencia necesaria para el
funcionamiento continuo del sistema.
○ Fuente de Alimentación de Respaldo: Batería de respaldo para asegurar el
funcionamiento durante cortes de energía, con capacidad especificada (por ejemplo, 4
horas de funcionamiento continuo).

Conectividad y Configuración

● Interfaz de Configuración:
○ Configuración Inicial: La configuración de la unidad de control y los componentes de
hardware se realizará mediante una aplicación móvil que permite la configuración
remota.
○ Diagnóstico: Herramientas de diagnóstico integradas para verificar el estado de las
conexiones y el funcionamiento de los componentes.
● Manual de Configuración:
○ Documentación: Manual detallado para la instalación y configuración de los
componentes de hardware, incluyendo esquemas de conexión y procedimientos de
calibración.

3.1.3 Interfaces de software

El sistema de cerradura con identificación mediante carnet o DNI interactuará con la aplicación móvil
que permite gestionar usuarios y configurar el sistema. Además, podría haber otros componentes de

14
 Especificación de Requisitos, estándar de IEEE 830

software involucrados, como bibliotecas de comunicación para el hardware y servicios de backend

para almacenar datos.

Aplicación Móvil

● Descripción del Producto de Software:

○ Nombre: KnockToolUs (KTU).
○ Plataforma: Disponible para dispositivos iOS y Android.
○ Propósito: Permite a los administradores gestionar usuarios, configurar parámetros
del sistema, y monitorear el historial de accesos.
● Propósito del Interfaz:
○ Interfaz de Usuario: Ofrecer una interfaz gráfica para la gestión del sistema de
cerradura, incluyendo funcionalidades como agregar o eliminar usuarios, ver el
historial de accesos y recibir notificaciones.
○ Interfaz de Comunicación: Sincronizar datos entre la aplicación móvil y la unidad de
control de la cerradura.
● Definición del Interfaz:
○ Contenido:
■ Datos de Configuración: Parámetros del sistema como tiempos de apertura,
umbrales de seguridad, etc.
■ Datos de Usuario: Información de los usuarios, incluyendo identificadores de
tarjetas y permisos.
■ Historial de Accesos: Registros de eventos de acceso.
○ Formato:
■ Comunicación: API RESTful con solicitudes y respuestas en formato JSON para
la sincronización de datos.
■ Protocolos: HTTPS para la seguridad de la comunicación.
■ Métodos: Métodos HTTP (GET, POST, PUT, DELETE) para la interacción con el
backend.

Servicio de Backend

● Descripción del Producto de Software:

○ Nombre: Servicio de Backend de Gestión de Datos.
○ Propósito: Almacenar y procesar datos relacionados con usuarios, accesos y
configuraciones del sistema de cerradura.

● Propósito del Interfaz:

○ Interfaz de Comunicación: Facilitar la interacción entre la aplicación móvil y la base de
datos del sistema, asegurando que la información esté disponible y actualizada en
tiempo real.

15
 Especificación de Requisitos, estándar de IEEE 830

● Definición del Interfaz:

○ Contenido:
■ Base de Datos: Información sobre usuarios, registros de accesos, y
configuraciones del sistema.
■ APIs: Interfaces para la comunicación con la aplicación móvil.
○ Formato:
■ Comunicación: API RESTful con datos en formato JSON.
■ Protocolos: HTTPS para asegurar la transmisión de datos.
■ Métodos: Métodos HTTP (GET, POST, PUT, DELETE) para gestionar la
información en la base de datos.

Biblioteca de Comunicación para Hardware

● Descripción del Producto de Software:

○ Nombre: Biblioteca de Comunicación para Arduino.
○ Propósito: Facilitar la comunicación entre la aplicación móvil y la unidad de control de
la cerradura mediante el hardware de Arduino.
● Propósito del Interfaz:
○ Interfaz de Comunicación: Permitir que la unidad de control de la cerradura interprete
comandos y datos recibidos desde la aplicación móvil.
● Definición del Interfaz:
○ Contenido:
■ Comandos: Instrucciones para controlar el mecanismo de bloqueo y realizar
lecturas del lector de tarjetas.
■ Datos: Información sobre el estado de la cerradura y los resultados de la
autenticación.
○ Formato:
■ Comunicación Serial: Protocolo de comunicación serial (UART) o I2C con datos
en formato binario o ASCII.
■ Protocolos: Configuración específica del protocolo de comunicación del
hardware de Arduino.

Sistema de Notificaciones

● Descripción del Producto de Software:

○ Nombre: Servicio de Notificaciones Push.
○ Propósito: Enviar notificaciones a la aplicación móvil para alertar a los administradores
sobre eventos importantes.
● Propósito del Interfaz:
○ Interfaz de Comunicación: Permitir el envío de notificaciones en tiempo real desde el
backend a la aplicación móvil.
● Definición del Interfaz:

16
 Especificación de Requisitos, estándar de IEEE 830

○ Contenido:
■ Notificaciones: Mensajes de alerta sobre eventos como accesos no
autorizados o problemas del sistema.
■ Configuración: Parámetros para el tipo y frecuencia de notificaciones.
○ Formato:
■ Comunicación: Servicios de notificaciones push (como Firebase Cloud
Messaging para Android y Apple Push Notification Service para iOS).
■ Protocolos: Protocolos de notificación push específicos de la plataforma móvil.

3.1.4 Interfaces de comunicación

El sistema de cerradura debe comunicarse de manera efectiva con otros sistemas para realizar
funciones como la gestión de usuarios, el monitoreo de accesos y el envío de notificaciones. A
continuación se detallan los requisitos y protocolos de comunicación para cada tipo de interfaz.

Comunicación entre la Aplicación Móvil y el Servicio de Backend

● Requisitos de Comunicación:
○ Propósito: La aplicación móvil debe enviar y recibir datos del servicio de backend para
gestionar usuarios, configurar el sistema y obtener el historial de accesos.
○ Frecuencia: Comunicación continua y en tiempo real para garantizar la sincronización
de datos y la actualización inmediata de la información.
● Protocolos de Comunicación:
○ Protocolo: HTTP/HTTPS para garantizar la seguridad en la transmisión de datos.
○ Formato de Datos: JSON para el intercambio de datos estructurados entre la
aplicación móvil y el backend.
○ Métodos HTTP:
■ GET: Para recuperar datos (por ejemplo, historial de accesos, lista de
usuarios).
■ POST: Para enviar nuevos datos (por ejemplo, agregar un usuario, actualizar
configuraciones).
■ PUT: Para modificar datos existentes.
■ DELETE: Para eliminar datos (por ejemplo, eliminar un usuario).

Comunicación entre la Aplicación Móvil y la Unidad de Control de la Cerradura

17
 Especificación de Requisitos, estándar de IEEE 830

● Requisitos de Comunicación:
○ Propósito: La aplicación móvil debe enviar comandos a la unidad de control para
activar o desactivar la cerradura y recibir datos de estado.
○ Frecuencia: Comunicación bajo demanda, principalmente cuando se realizan
operaciones de control o se actualiza el estado del sistema.
● Protocolos de Comunicación:
○ Protocolo: Comunicación Serial (UART).
○ Formato de Datos: Datos en formato binario.

Comunicación entre la Unidad de Control de la Cerradura y el Lector de Tarjetas o Huella

● Requisitos de Comunicación:
○ Propósito: La unidad de control debe recibir datos del lector de tarjetas o huella para
verificar la identidad del usuario y determinar si se debe permitir el acceso.
○ Frecuencia: Comunicación continua durante la lectura de tarjetas o huellas para
garantizar una respuesta rápida.
● Protocolos de Comunicación:
○ Protocolo: Comunicación Serial (UART).
○ Formato de Datos: Datos en formato binario.

3.2 Requisitos funcionales

Definición de acciones fundamentales que debe realizar el software al recibir información, procesarla y
producir resultados.

Requerimiento funcional 1: Verificación de Acceso

Actores: Usuario Final, Sistema de Cerradura
Descripción: El sistema debe verificar el número de carnet de identidad presentado por el usuario
contra los datos almacenados en MongoDB para autorizar o denegar el acceso.

● Comprobación de validez de las entradas: El sistema debe validar que el número de carnet de
identidad ingresado por el usuario sea un número válido y esté registrado en la base de datos.
● Secuencia exacta de operaciones: El sistema recibe el número de carnet, lo compara con los
datos en MongoDB, y luego autoriza o deniega el acceso según la coincidencia.
● Respuesta a situaciones anormales: En caso de un carnet no válido o no registrado, el sistema
debe denegar el acceso y generar una alerta para revisión.
● Parámetros: Número de carnet de identidad.
● Generación de salidas: Resultado de la verificación (acceso autorizado o denegado).
● Relaciones entre entradas y salidas: La entrada (número de carnet) se relaciona directamente
con la salida (autorización o denegación de acceso).
● Especificación de los requisitos lógicos para la información almacenada: El número de carnet
y los detalles del usuario relacionados deben estar almacenados en MongoDB.

18
 Especificación de Requisitos, estándar de IEEE 830

Requerimiento funcional 2: Registro de Usuarios

Actores: Administrador del Sistema
Descripción: El sistema debe permitir al administrador registrar nuevos usuarios en la base de datos
MongoDB, almacenando el número de carnet de identidad y los detalles relevantes.

● Comprobación de validez de las entradas: El sistema debe verificar que los datos ingresados
(como el número de carnet y detalles personales) sean válidos y no duplicados.
● Secuencia exacta de operaciones: El administrador ingresa los datos del usuario, el sistema
valida la información, y luego la almacena en MongoDB.
● Respuesta a situaciones anormales: Si se detectan errores en la entrada de datos o
duplicaciones, el sistema debe notificar al administrador para corregirlos antes de continuar.
● Parámetros: Número de carnet de identidad, detalles del usuario (nombre, dirección, etc.).
● Generación de salidas: Confirmación de que el usuario ha sido registrado correctamente.
● Relaciones entre entradas y salidas: Los datos ingresados se reflejan directamente en la base
de datos, confirmando el registro exitoso.
● Especificación de los requisitos lógicos para la información almacenada: Los datos del
usuario, incluyendo el número de carnet, deben ser almacenados en MongoDB con todos los
detalles relevantes.

Requerimiento funcional 4: Reconocimiento de carnet

Actores: Administrador del Sistema, Usuario Autorizado
Descripción: El sistema debe reconocer el carnet de identidad presentado por los usuarios autorizados
para permitir el acceso.

● Comprobación de validez de las entradas: El sistema debe validar que el carnet de identidad
escaneado esté registrado y sea válido.
● Secuencia exacta de operaciones: El usuario presenta el carnet, el sistema lo escanea, valida
los datos y permite o deniega el acceso.
● Respuesta a situaciones anormales: Si el carnet no es reconocido, el sistema debe denegar el
acceso y notificar al administrador.
● Parámetros: Datos del carnet de identidad.
● Generación de salidas: Autorización de acceso o denegación.
● Relaciones entre entradas y salidas: La información del carnet se compara con la base de
datos para determinar el resultado.
● Especificación de los requisitos lógicos para la información almacenada: Los datos del carnet
deben ser almacenados de manera segura y estar disponibles para la verificación.

19
 Especificación de Requisitos, estándar de IEEE 830

Requerimiento funcional 5: Reconocimiento de huella digital

Actores: Administrador del Sistema, Usuario Autorizado
Descripción: El sistema debe reconocer la huella digital del usuario para permitir el acceso.

● Comprobación de validez de las entradas: El sistema debe validar que la huella digital
escaneada coincida con la registrada en la base de datos.
● Secuencia exacta de operaciones: El usuario coloca su huella digital en el escáner, el sistema la
compara con las huellas almacenadas y autoriza o deniega el acceso.
● Respuesta a situaciones anormales: Si la huella digital no coincide, el sistema debe denegar el
acceso y registrar el intento fallido.
● Parámetros: Datos biométricos de la huella digital.
● Generación de salidas: Autorización de acceso o denegación.
● Relaciones entre entradas y salidas: La huella digital escaneada se compara con los registros
existentes para determinar el resultado.
● Especificación de los requisitos lógicos para la información almacenada: Las huellas digitales
deben ser almacenadas de forma encriptada en la base de datos para su seguridad.

3.3 Requisitos no funcionales

Requerimiento no funcional 1: Seguridad de la Base de Datos

Actores: Administrador del Sistema, Sistema de Cerradura
Descripción: Los datos almacenados en MongoDB deben estar protegidos con medidas de seguridad
adecuadas, incluyendo autenticación, autorización y cifrado, para proteger la información sensible.

● Comprobación de validez de las entradas: Las configuraciones de seguridad, como

contraseñas y claves de cifrado, deben ser validadas para cumplir con los estándares de
seguridad.
● Secuencia exacta de operaciones: Al registrar o modificar datos en la base de datos, el sistema
debe aplicar las medidas de seguridad necesarias automáticamente.
● Respuesta a situaciones anormales: En caso de una brecha de seguridad, el sistema debe
activar mecanismos de contención y alertar al administrador.
● Parámetros: Claves de cifrado, configuraciones de autenticación.
● Generación de salidas: Registros de seguridad y notificaciones en caso de intentos de acceso
no autorizados.
● Relaciones entre entradas y salidas: Las configuraciones de seguridad deben ser
implementadas en todas las operaciones de la base de datos.
● Especificación de los requisitos lógicos para la información almacenada: La información
sensible debe estar encriptada y accesible solo a usuarios autorizados.

20
 Especificación de Requisitos, estándar de IEEE 830

Requerimiento no funcional 2: Interfaz de Usuario Responsiva

Categoría: Usabilidad
Actores: Usuario Final
Descripción: La interfaz de usuario del sistema debe ser responsiva, adaptándose automáticamente a
diferentes tamaños de pantalla y dispositivos.

● Comprobación de validez de las entradas: No aplica directamente para este tipo de requisito.
● Secuencia exacta de operaciones: Al acceder al sistema desde diferentes dispositivos (móviles,
tabletas, computadoras de escritorio), la interfaz debe ajustar su diseño y disposición de
elementos automáticamente para proporcionar una experiencia de usuario óptima.
● Respuesta a situaciones anormales: Si la interfaz no se ajusta correctamente a un dispositivo,
el sistema debe permitir al usuario reportar el problema y ajustar manualmente el diseño si es
posible.
● Parámetros: Resoluciones de pantalla, tipos de dispositivos (móviles, tabletas, escritorios).
● Generación de salidas: Interfaz adaptada al dispositivo y tamaño de pantalla.
● Relaciones entre entradas y salidas: Las características del dispositivo (tamaño de pantalla,
orientación) determinan la disposición y el diseño de la interfaz de usuario.
● Especificación de los requisitos lógicos para la información almacenada: No aplica
directamente para este tipo de requisito.

3.3.1 Requisitos de rendimiento

Requerimiento no funcional 1: Rendimiento en Baja Conectividad

● Nombre del Requerimiento: Rendimiento en Baja Conectividad

● Categoría: Rendimiento
● Actores Relacionados: Usuario Final
● Descripción: El sistema debe ser capaz de operar de manera eficiente incluso en condiciones
de baja conectividad o anchos de banda limitados.
● Especificación:
○ El sistema debe mantener una funcionalidad completa con un ancho de banda de al
menos 256 Kbps.
○ El tiempo de respuesta para operaciones críticas no debe exceder los 5 segundos bajo
condiciones de baja conectividad.
○ El sistema debe ser capaz de manejar hasta 100 usuarios simultáneamente sin
degradar significativamente su rendimiento en condiciones de baja conectividad.

21
 Especificación de Requisitos, estándar de IEEE 830

Requerimiento no funcional 2: Optimización de Recursos

● Nombre del Requerimiento: Optimización de Recursos

● Categoría: Rendimiento
● Actores Relacionados: Administrador del Sistema
● Descripción: El sistema debe optimizar el uso de recursos, como CPU y memoria, para evitar
sobrecargas y garantizar un rendimiento eficiente.
● Especificación:
○ El uso de CPU por parte del sistema no debe exceder el 70% en condiciones normales
de operación con hasta 500 usuarios simultáneos.
○ El uso de memoria debe mantenerse por debajo del 75% de la capacidad total en todo
momento.
○ El sistema debe poder liberar automáticamente recursos no utilizados para optimizar
el rendimiento, especialmente durante picos de demanda.

Requerimiento no funcional 3: Tiempo de Respuesta

● Nombre del Requerimiento: Tiempo de Respuesta

● Categoría: Rendimiento
● Actores Relacionados: Usuario Final
● Descripción: El sistema debe garantizar un tiempo de respuesta máximo de 2 segundos para
cualquier operación crítica.
● Especificación:
○ El 95% de todas las transacciones deben completarse en menos de 2 segundos bajo
condiciones normales de operación.
○ El tiempo de respuesta para consultas a la base de datos no debe exceder los 1.5
segundos en promedio.
○ En caso de alta demanda, el sistema debe poder mantener un tiempo de respuesta no
mayor a 3 segundos para operaciones críticas.

3.3.2 Seguridad
Requerimiento no funcional 1: Seguridad de la Base de Datos

● Nombre del Requerimiento: Seguridad de la Base de Datos

● Categoría: Seguridad
● Actores Relacionados: Administrador del Sistema, Sistema de Cerradura

22
 Especificación de Requisitos, estándar de IEEE 830

● Descripción: Los datos almacenados en MongoDB deben estar protegidos con medidas de
seguridad adecuadas, incluyendo autenticación, autorización y cifrado, para proteger la
información sensible.
● Especificación:
○ La autenticación debe requerir múltiples factores (MFA) para el acceso de
administradores y usuarios privilegiados.
○ El acceso a la base de datos debe estar restringido mediante políticas de autorización
que limiten los permisos a nivel de roles.
○ Se deben realizar auditorías de seguridad trimestrales para asegurar el cumplimiento
de las políticas de seguridad.

Requerimiento no funcional 2: Seguridad de Datos

− Nombre del Requerimiento: Seguridad de Datos

− Categoría: Seguridad
− Actores Relacionados: Administrador del Sistema, Usuario Final
− Descripción: El sistema debe garantizar la protección de datos sensibles mediante encriptación
en tránsito y en reposo.
− Especificación:
o Todos los datos sensibles transmitidos entre el cliente y el servidor deben estar
protegidos mediante TLS 1.2 o superior.
o Se debe implementar un sistema de monitoreo que alerte al administrador ante
cualquier intento no autorizado de acceso o modificación de los datos.
o Las copias de seguridad también deben estar cifradas y almacenadas en ubicaciones
seguras.

Requerimiento no funcional 3: Protección contra Ataques DDoS

● Nombre del Requerimiento: Protección contra Ataques DDoS

● Categoría: Seguridad
● Actores Relacionados: Administrador del Sistema
● Descripción: El sistema debe incluir mecanismos de protección contra ataques de denegación
de servicio distribuidos (DDoS).
● Especificación:
○ El sistema debe ser capaz de detectar y mitigar ataques DDoS utilizando tecnologías
como firewalls de aplicaciones web (WAF) y servicios de mitigación DDoS en la nube.
○ En caso de un ataque DDoS, el sistema debe ser capaz de continuar operando con al
menos el 80% de su capacidad normal.
○ Deben implementarse políticas de rate limiting para limitar el número de solicitudes
permitidas por IP en un período de tiempo definido.
○ Se debe mantener un sistema de monitoreo activo que pueda identificar y responder
automáticamente a patrones de tráfico sospechoso.

23
 Especificación de Requisitos, estándar de IEEE 830

3.3.3 Fiabilidad
R.37 Resiliencia ante Fallo

● Descripción: El sistema debe ser capaz de recuperarse automáticamente de fallos y continuar

operando sin pérdida significativa de datos.
● Requisito: El sistema debe ser capaz de recuperarse de fallos críticos en un tiempo máximo de
30 segundos, con una tasa de recuperación exitosa del 99% en pruebas de simulación de fallos.
Además, no debe permitir más de 2 fallos críticos por año en operaciones normales.

R.41 Tolerancia a Errores

● Descripción: El sistema debe ser tolerante a errores, permitiendo continuar operando con
funcionalidad limitada en caso de fallos menores.
● Requisito: El sistema debe continuar operando al menos al 80% de su capacidad funcional
durante fallos menores, con una tasa de recuperación al 100% de la funcionalidad dentro de
los 60 segundos. No más de 3 errores menores deben ser permitidos durante cualquier sesión
de uso normal.

3.3.4 Disponibilidad
R.33 Escalabilidad

Tipo: No funcional

Clasificación: Funcional de sistema

Actores Relacionados: Administrador del Sistema

Descripción: El sistema debe ser escalable para soportar un incremento en la cantidad de usuarios y
transacciones sin degradar el rendimiento. Esto incluye la capacidad de mantener una disponibilidad
del 99.9% durante el proceso de escalado, garantizando que los servicios no se vean interrumpidos
durante el aumento de la carga.

R.51 Alta Disponibilidad

Tipo: No funcional

Clasificación: Funcional de sistema

24
 Especificación de Requisitos, estándar de IEEE 830

Actores Relacionados: Administrador del Sistema

Descripción: El sistema debe estar diseñado para asegurar una disponibilidad del 99.95% durante el
horario de operación, con un tiempo de inactividad planificado no superior a 4.38 horas al año. Esto
implica la implementación de redundancia en componentes críticos y la capacidad de realizar
mantenimiento sin afectar la operación del sistema.

3.3.5 Mantenibilidad
R.46 Actualización del Sistema

Tipo: Funcional

Clasificación: Funcional de sistema

Actores Relacionados: Administrador del Sistema

Descripción: El sistema debe permitir actualizaciones de software sin afectar la disponibilidad del
servicio, mediante implementaciones en caliente. Las actualizaciones deben ser aplicables sin
necesidad de reiniciar el sistema, asegurando una interrupción mínima del servicio y permitiendo
actualizaciones regulares cada dos semanas para corregir errores y mejorar la funcionalidad.

R.52 Generación de Reportes de Mantenimiento

Tipo: Funcional

Clasificación: Funcional de sistema

Actores Relacionados: Administrador del Sistema

Descripción: El sistema debe generar reportes de mantenimiento automáticamente de forma mensual

y trimestral. Estos reportes deben incluir estadísticas de uso, fallos registrados, y detalles sobre el
rendimiento del sistema. Los reportes deben ser accesibles a través del panel de administración del
sistema y utilizados para planificar y realizar tareas de mantenimiento preventivo y correctivo.

3.3.6 Portabilidad
R.31 Soporte Multiplataforma

● Tipo: No funcional

● Clasificación: Funcional de sistema

● Actores Relacionados: Usuario Final

● Descripción: El sistema debe ser compatible y funcionar de manera óptima en diferentes

plataformas, incluyendo Windows, macOS, Linux, iOS, y Android. La portabilidad debe

25
 Especificación de Requisitos, estándar de IEEE 830

asegurar que el sistema se ejecute correctamente en al menos las versiones más recientes de
estos sistemas operativos y que el rendimiento sea comparable en cada uno de ellos.

R.53 Código Independiente de la Plataforma

Tipo: No funcional

Clasificación: Funcional de sistema

Actores Relacionados: Desarrollador

Descripción: El sistema debe utilizar un lenguaje de programación y herramientas de desarrollo que

minimicen la dependencia de la plataforma específica. El porcentaje de código que es dependiente de
la plataforma no debe superar el 10%. Además, el sistema debe estar diseñado para facilitar la
migración a nuevas plataformas con cambios mínimos en el código base. El uso de tecnologías como
Java o frameworks multiplataforma contribuirá a la facilidad de portabilidad.

26