📌 En síntesis: Fundamentos de la elicitación: ciclo de vida de requerimientos, diferencias críticas entre requerimientos funcionales y requisitos no funcionales (FURPS+).
Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.
Especificación de requerimientos
📌 1
📌 Aprendizaje esperado
📌 01
Analizar documentación de requerimiento asociada a proyectos de software pequeños, identificando el tipo de requerimiento en situaciones de baja complejidad.
Especificación de requerimientos En el área de desarrollo de software, la calidad y el éxito de un proyecto no solo dependen de la codificación y las tecnologías utilizadas, sino, y quizás lo más importante, de una comprensión profunda y precisa de lo que el cliente o usuario realmente necesita. Imaginen construir un edificio sin planos claros o sin saber para qué se utilizará. Sería un caos, ¿verdad? Lo mismo ocurre con el software. Si no definimos correctamente qué debe hacer un sistema, para quién lo hace, qué limitaciones tiene y qué esperamos de él, corremos el riesgo de construir algo inútil, costoso y que no satisfaga a nadie. En este documento, exploraremos los cimientos de la ingeniería de requerimientos, sentando las bases para que puedan analizar, identificar y documentar los pilares de cualquier proyecto de software. Se enfocarán en conceptos cruciales que les permitirán discernir entre lo que el usuario pide y lo que el sistema debe hacer, y cómo las limitaciones pueden influir en el proceso. El objetivo es que, al finalizar de esta semana, estén equipados con el conocimiento para reconocer y diferenciar los distintos tipos de requerimientos en proyectos de pequeña envergadura, desarrollando una mentalidad analítica, eficiente y proactiva en la resolución de problemas. ¡Prepárense para construir software con propósito! Introducción
Especificación de requerimientos 1. Dominio de aplicación y límites del sistema: delimitando el universo del software
🔹 1.1. Dominio de aplicación: el ecosistema de nuestro software
Antes de pensar en cualquier funcionalidad, es esencial entender el contexto en el que operará nuestro software. Aquí entran en juego dos conceptos clave: el dominio de aplicación y los límites del sistema.
Figura 1: Dominio de aplicación
📌 1
Los usuarios y sus roles ¿Quiénes interactuarán con el sistema? ¿Qué tareas realizan?
📌 3
Los procesos existentes ¿Cómo se hacen las cosas actualmente? ¿Qué flujos de trabajo hay?
📌 5
Otros sistemas o actores externos ¿Con qué otros sistemas o entidades deberá interactuar nuestro software?
📌 4
La terminología específica ¿Qué vocabulario técnico o de negocio se utiliza?
📌 2
Las reglas de negocio ¿Qué normativas o políticas rigen el funcionamiento del negocio? Comprender el dominio de aplicación implica conocer : Deben realizarse preguntas clave para delimitar adecuadamente el sistema.
Especificación de requerimientos ¿Por qué es importante? Si no comprendemos el dominio, es imposible desarrollar un software que sea relevante y útil. Por ejemplo, si estamos creando un sistema para una clínica, debemos entender cómo se gestionan las citas, los historiales médicos, la facturación, entre otros. Si no lo hacemos, podríamos diseñar algo que no se adapte a sus necesidades reales. 1.2. Límites del sistema: ¿hasta dónde llega nuestro control? Los límites del sistema definen qué partes de la funcionalidad o del entorno serán responsabilidad de nuestro software y cuáles quedan fuera de su alcance. Establecer límites es crucial para evitar la “deriva del alcance” (scope creep), en el cual el proyecto crece sin control, y para gestionar las expectativas. Imaginemos que estamos desarrollando una aplicación de gestión de inventario para una tienda.
-
Dentro de los límites del sistema podría estar: registrar entradas y salidas de productos, actualizar el stock, generar reportes de inventario.
-
Fuera de los límites del sistema podría estar: la gestión de la cadena de suministro con proveedores externos, la contabilidad completa de la empresa o la venta en línea (si no es el enfoque principal). Claves Descripción Claridad Debe ser explícito qué funcionalidades estarán dentro y fuera. Acuerdo Todos los stakeholders (clientes, usuarios, equipo de desarrollo) deben estar de acuerdo con los límites. Realismo Los límites deben ser alcanzables con los recursos y el tiempo disponibles. Tabla 1. Claves para delimitar el sistema Fuente: OpenAI (2023) La claridad, el acuerdo y el realismo son claves para delimitar el sistema.
Especificación de requerimientos En el desarrollo de software, no todo es lo que queremos que el sistema haga; también está lo que no puede hacer o cómo debe hacerlo bajo ciertas condiciones. Estas son las restricciones del sistema. Una restricción es una limitación en la forma en que el sistema puede ser diseñado, implementado o utilizado. Son condiciones que deben ser satisfechas por el sistema y que, a menudo, son impuestas por el cliente, el entorno o la tecnología. 2. Restricciones del sistema: las limitaciones del juego Ejemplo práctico: Pensemos en la aplicación Uber. Dominio de aplicación: transporte urbano, logística de pasajeros y conductores, pagos digitales. Incluye entender la dinámica de viajes, rutas, tarifas, disponibilidad de vehículos, etc. Límites del sistema: Dentro: conexión entre pasajeros y conductores, cálculo de tarifas, seguimiento de viajes, procesamiento de pagos dentro de la aplicación y sistema de calificación. Fuera: la fabricación de los vehículos, la regulación de taxis en cada ciudad (aunque el sistema deba adaptarse a ellas), el mantenimiento físico de los automóviles.
Especificación de requerimientos Tabla 2. Restricciones operacionales/ambientales Fuente: OpenAI (2023) Tabla 3. Restricciones de desarrollo/implementación Fuente: OpenAI (2023) 2.1. Tipos comunes de restricciones Restricciones Descripción Entorno de operación El software debe funcionar en Windows, Linux, Android, iOS. Rendimiento El sistema debe responder a una consulta en menos de 3 segundos. Confiabilidad El sistema debe estar disponible el 99.9 % del tiempo. Seguridad Solo los usuarios autorizados pueden acceder a ciertos datos. Debe cumplir con la GDPR (Reglamento General de Protección de Datos de la Unión Europea). Usabilidad La interfaz debe ser intuitiva y fácil de usar para personas mayores. Disponibilidad El sistema debe estar en línea las 24 horas del día, 7 días a la semana. Restricciones Descripción Tecnológicas El sistema debe ser desarrollado usando Java y la base de datos PostgreSQL. Presupuesto El costo total del desarrollo no debe exceder los $X. Plazo El software debe estar listo para producción en 6 meses. Personal Solo disponemos de tres desarrolladores para este proyecto. Interfaz con otros sistemas El sistema debe integrarse con el software de contabilidad existente.
2.2. Importancia de identificar restricciones Identificar las restricciones desde el principio es fundamental. En la Figura 2 explicamos las principales razones. Especificación de requerimientos Restricciones Descripción Leyes y regulaciones Cumplir con normativas de protección de datos (ej. GDPR, Ley de Protección de Datos Personales en Chile, entre otras). Estándares de la industria Adherirse a ciertos estándares de seguridad de la información (ISO 27001). Tabla 4. Restricciones regulatorias/legales Fuente: OpenAI (2023)
Figura 2: Importancia de identificar restricciones
Impactan el diseño: las restricciones tecnológicas o de rendimiento, por ejemplo, pueden obligar a elegir una arquitectura de sistema particular. Definen el alcance: una restricción de presupuesto o plazo puede limitar las funcionalidades que se pueden incluir en una primera versión. Evitan problemas futuros: no considerar una restricción importante puede llevar a rediseños costosos o a un sistema que no cumpla con las expectativas o la ley. Afectan los requerimientos: una restricción de seguridad puede generar requerimientos funcionales y no funcionales adicionales (ej., encriptación de datos, autenticación de dos factores). 1 2 3 4
Ahora que hemos definido el contexto y las limitaciones, es momento de hablar de lo que el software realmente debe hacer. Un requerimiento es una descripción de una necesidad o restricción que el sistema de software debe satisfacer para cumplir un objetivo o resolver un problema. Es la base sobre la cual se construye todo el sistema. Existen principalmente dos grandes categorías de requerimientos: funcionales y no funcionales. Especificación de requerimientos 3. Requerimientos: el corazón de lo que construimos Ejemplo práctico: Para un sistema de gestión de exámenes online para una universidad: Restricción de rendimiento: el sistema debe soportar 5000 conexiones simultáneas durante los periodos de exámenes sin degradación del rendimiento. Restricción de seguridad: los resultados de los exámenes deben ser confidenciales y solo accesibles por el estudiante y los profesores autorizados. Restricción tecnológica: debe ser compatible con la infraestructura de servidores Linux existente en la universidad. Restricción legal: debe cumplir con la normativa de accesibilidad web para estudiantes con discapacidad.
Especificación de requerimientos 3.1. Requerimientos de usuario vs. requerimientos de sistema A menudo, los requerimientos se describen a diferentes niveles de detalle, dependiendo de la audiencia: 3.1.1. Requerimientos de usuario (User Requirements) Son declaraciones, escritas en lenguaje natural y diagramas, que describen los servicios que el sistema debe proporcionar y las restricciones bajo las cuales debe operar. Son de alto nivel y están orientados a los stakeholders (clientes, usuarios finales, gerentes). Describen lo que el usuario quiere lograr. 3.1.2. Requerimientos de sistema (System Requirements) Son descripciones más detalladas de las funciones del sistema, los servicios y las restricciones operacionales. A menudo, se escriben como una especificación estructurada y son la base para el diseño y la implementación. Están orientados al equipo de desarrollo. Describen cómo el sistema debe comportarse para cumplir con los requerimientos de usuario. Ejemplo práctico: “Como estudiante, quiero ver mis calificaciones de todos los cursos en una única pantalla para no tener que revisar cada curso individualmente”. Características Comprensibles para no-técnicos, orientados al “qué” (qué problema se resuelve o qué valor se entrega), no especifican cómo se implementará.
Especificación de requerimientos Es crucial establecer una trazabilidad entre los requerimientos de usuario y los requerimientos del sistema, para asegurar que cada requerimiento de usuario de alto nivel se traduzca correctamente en uno o más requerimientos de los sistemas que lo implementen. 3.2. Requerimientos funcionales: ¿qué hace el sistema? Los requerimientos funcionales describen los servicios que el sistema debe proporcionar, cómo debe reaccionar a entradas particulares y cómo debe comportarse en situaciones concretas. En esencia, definen las funciones o características que el software debe tener para satisfacer las necesidades del usuario. Características: Detallados, precisos, verificables, orientados al “cómo” (cómo el sistema logrará el “qué”), pueden incluir notaciones más técnicas (UML, pseudocódigo). Ejemplo: “El sistema deberá consultar la base de datos de calificaciones (DB_Calificaciones) y la de cursos (DB_Cursos) para obtener la lista de todas las calificaciones de un ID_Estudiante dado, agrupadas por ID_Curso y presentadas en una tabla HTML en la vista Dashboard_Estudiante.”
Especificación de requerimientos 3.3. Requerimientos no funcionales: ¿cómo lo hace el sistema? Los requerimientos no funcionales definen las restricciones sobre los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo (ej. velocidad), restricciones en el proceso de desarrollo y estándares (ej. seguridad, usabilidad). En otras palabras, describen las cualidades o atributos de calidad del sistema. No se refieren a lo que el sistema hace, sino a cómo lo hace. A menudo, los requerimientos no funcionales son tan críticos como los funcionales, si no más, para la satisfacción del usuario y el éxito del proyecto. Un sistema que funciona, pero es lento o inseguro no será aceptado. ᵒ El sistema permitirá a los usuarios buscar libros por título, autor o ISBN. ᵒ El sistema permitirá a los usuarios registrarse y crear una cuenta. ᵒ El sistema permitirá a los bibliotecarios registrar la entrada y salida de libros. ᵒ El sistema permitirá a los usuarios reservar un libro que esté prestado. ᵒ El sistema enviará una notificación por correo electrónico al usuario cuando un libro reservado esté disponible. Ejemplos en un sistema de biblioteca:
Ejemplos de categorías de requerimientos no funcionales (y ejemplos concretos): Especificación de requerimientos Rendimiento o El sistema debe cargar la página principal en menos de 2 segundos. o La aplicación debe procesar 100 transacciones por segundo. Seguridad o El sistema debe proteger los datos personales de los usuarios mediante encriptación SSL. o El sistema solo permitirá el acceso a usuarios autenticados con doble factor. Usabilidad o La interfaz de usuario debe ser accesible para personas con daltonismo. o El sistema debe ser intuitivo y operable por un usuario sin experiencia previa en 15 minutos. Fiabilidad/confiabilidad o El sistema debe tener una tasa de fallos de menos de 1 en 1000 horas de operación. o El sistema debe poder recuperar los datos en menos de 30 minutos después de una falla de hardware. Mantenibilidad o El código fuente debe seguir los estándares de codificación IEEE 830. o El sistema debe ser modular para facilitar futuras actualizaciones.
Especificación de requerimientos Portabilidad o La aplicación web debe ser compatible con los navegadores Chrome, Firefox y Edge. o La aplicación móvil debe funcionar tanto en Android como en iOS. Escalabilidad o El sistema debe ser capaz de soportar un aumento del 50% de usuarios sin degradación de rendimiento. Legal/ético o El sistema debe cumplir con la Ley de Protección de Datos Personales. o El sistema debe obtener el consentimiento explícito del usuario antes de recolectar sus datos.
Especificación de requerimientos 3.4. Reconociendo requerimientos en proyectos pequeños En proyectos de baja complejidad, la clave para reconocer los requerimientos es la observación atenta y la comunicación efectiva con el cliente o usuario.
Figura 3: Requerimientos en proyectos pequeños
📌 3
Para requerimientos de usuario Presta atención a las frases que empiezan con “Yo necesito…”, “Quiero poder…”, “Sería genial si…”, o cuando el usuario describe una tarea que actualmente realiza manualmente. Para requerimientos de sistema Piensa en cómo la funcionalidad que el usuario desea se traduce en acciones o datos dentro del software. Utiliza verbos de acción para describir lo que el sistema “debe hacer”. Para requerimientos no funcionales Identifica las cualidades del sistema: “El sistema debe ser rápido (rendimiento)”, “Los datos deben estar seguros (seguridad)”, “La interfaz debe ser fácil de usar (usabilidad)”. A menudo, se expresan con adjetivos o condiciones de calidad. Para requerimientos funcionales Busca las acciones directas del sistema: “El sistema mostrará…”, “El sistema permitirá…”, “El sistema enviará…”.
📌 1
📌 2
📌 3
📌 4
Especificación de requerimientos
💡 Conclusión
En conclusión, completaste el primer paso fundamental en la Ingeniería de Requerimientos. Has aprendido a mirar más allá de la superficie de un problema para identificar su dominio, establecer sus límites, reconocer sus restricciones y, lo más importante, diferenciar entre los distintos tipos de requerimientos que darán forma a su software. Recuerda que:
-
El dominio de aplicación es el lienzo sobre el que pintaremos nuestro software, el ecosistema que debemos comprender a fondo.
-
Los límites del sistema son el marco que define nuestro cuadro, lo que nos permite enfocar nuestros esfuerzos y gestionar las expectativas.
-
Las restricciones son las reglas del juego, las condiciones ineludibles que el software debe cumplir para ser exitoso y viable.
-
Los requerimientos funcionales son las pinceladas que definen lo que el sistema “hace”, sus acciones y comportamientos.
-
Los requerimientos no funcionales son la calidad de la pintura y la solidez del lienzo, definiendo “cómo” el sistema se desempeña y bajo qué atributos de calidad.
Especificación de requerimientos Open AI. (2023 ). Chat GPT (Mar 14 version) [Modelo de lenguaje modelado]. Sommerville, I. (2011). Requerimientos de software. En Ingeniería del Software (pp. 91-131). Pearson Educación.
🚀 Potencia tus proyectos tecnológicos con Proyecto Luna
En Proyecto Luna desarrollamos arquitectura de software de alto rendimiento, optimización de bases de datos críticas y soluciones aplicadas de inteligencia artificial y automatización para empresas y profesionales.
- 💼 Soluciones de ingeniería: Conoce nuestras capacidades y casos de estudio en proyectoluna.com/work/.
- 🛡️ Seguridad y auditoría: Orientación técnica y respuesta ante incidentes en ¿Te han hackeado?.
- 📩 Contacto directo: Escríbenos a través de nuestro formulario de contacto o a
contacto@proyectoluna.com.
