Ejercitación Práctica Especificación en Ingeniería de Requerimientos
Objetivos específicos esperados Lograr una especificación formal, clara y verificable de requerimientos funcionales y no funcionales, con foco en su utilidad profesional y continuidad en Ingeniería de Software. Caso: Una organización de bicicletas compartidas quiere desarrollar una aplicación móvil para que los usuarios puedan: Registrarse y autenticarse. Ver estaciones disponibles en un mapa. Reservar una bicicleta por 15 minutos. Reportar daños en las bicicletas. Ver su historial de viajes. El sistema debe asegurar que no haya doble reserva de una misma bicicleta y que se pueda usar offline para ver el mapa sin reservar. Además, debe enviar una notificación al usuario cuando finaliza el tiempo de reserva. Consignas: 1. Requerimientos funcionales (RF) Redactar al menos 3 RF utilizando el formato: [RFxx] El sistema debe + verbo en infinitivo + objeto + condiciones (si aplica). 2. Requerimientos no funcionales (RNF) Redactar al menos 2 RNF utilizando criterios verificables o medibles. 3. Detección y corrección de ambigüedades Leer los siguientes requerimientos,mal redactados, identificar los problemas y escribí una versión corregida de cada uno: El sistema debe tener buena seguridad. Los usuarios deben poder hacer reservas sin problemas. Tiene que mostrar las estaciones como sea. Se debe poder usar el mapa cuando no hay conexión. Debe permitir el acceso a la cuenta. 4. Mini glosario Elaborar un glosario de al menos 3 términos usados en los requerimientos, para garantizar comprensión compartida.
REQUERIMIENTOSGRUPALENTREGAS
Joaquin Midón, Matias Salinas, Milena Mercado, Angelo Perrotta
9/19/20251 min read
1 .
a. El sistema debe mostrar estaciones disponibles en el mapa si las hay
b. El sistema debe permitir al cliente ver su historia de viajes
c. El sistema debe permitir registrar y autorizar a los usuarios
2.
a. El sistema debe cargar el mapa de estaciones en menos de 3 segundos en condiciones de conexión estable.
b. El sistema debe funcionar en modo offline para visualizar el mapa, almacenando en caché la información de estaciones más recientes.
c. El sistema debe proteger las credenciales de usuario mediante cifrado de información y garantizando la confidencialidad de los datos.
3.
a. Mal redactado: El sistema debe tener buena seguridad. Problema: "Buena seguridad" El sistema debe cifrar las credenciales de usuario con un algoritmo de seguridad estándar.
b. Mal redactado: Los usuarios deben poder hacer reservas sin problemas. Problema: "Sin problemas" El sistema debe permitir a los usuarios realizar reservas de bicicletas en un máximo de 3 pasos de interacción en la aplicación.
c. Mal redactado: Tiene que mostrar las estaciones como sea. Problema: "Como sea"
d. Mal redactado: Se debe poder usar el mapa cuando no hay conexión. Problema: No especifica limitaciones ni alcance. El sistema debe permitir visualizar el mapa de estaciones en modo offline, usando la última versión descargada mientras haya estado en línea en las últimas 24 horas.
e. Mal redactado: Debe permitir el acceso a la cuenta. Problema: No aclara el método de acceso.El sistema debe permitir a los usuarios acceder a su cuenta mediante correo electrónico y contraseña registrados.
4.
Reserva: Acción de apartar una bicicleta disponible por un tiempo limitado antes de su uso.
Estación: Punto físico donde se encuentran bicicletas y anclajes para retiro o devolución.
Modo offline: Funcionalidad que permite usar ciertas características de la aplicación (como ver el mapa) sin conexión a internet, utilizando datos almacenados en caché. El sistema debe mostrar en un mapa interactivo todas las estaciones disponibles, indicando cantidad de bicicletas y anclajes libres.