Flujo de trabajo de elicitación y entrevistas con usuarios clave
← RECURSOS

Técnicas de Elicitación: Entrevistas, Talleres JAD y Observación

Estrategias prácticas para descubrir necesidades de los interesados (stakeholders): entrevistas semiestructuradas, talleres JAD y observación en campo.

📌 En síntesis: Estrategias prácticas para descubrir necesidades de los interesados (stakeholders): entrevistas semiestructuradas, talleres JAD y observación en campo.

Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.


Especificación de requerimientos A continuación, profundizaremos en los tipos de requerimientos y una herramienta esencial para su gestión: la matriz de trazabilidad. Como futuros profesionales, su capacidad para identificar, clasificar y relacionar los requerimientos de un proyecto es fundamental. No se trata solo de listar lo que el software debe hacer, sino de entender los dolores del usuario y cómo se traducen en un sistema funcional y de calidad. Este documento teórico te proporcionará el conocimiento necesario para reconocer los distintos tipos de requerimientos en proyectos pequeños y analizar su documentación de manera efectiva. Exploremos cómo las necesidades de los usuarios se transforman en especificaciones técnicas y cómo podemos asegurar que cada parte de nuestro software cumple con su propósito original.


🚀 Introducción

Especificación de requerimientos


⚙️ Requerimientos de usuario vs. requerimientos de sistema

En cualquier proyecto de desarrollo de software, la comunicación es clave. Antes de hablar de tipos específicos, es fundamental distinguir entre la perspectiva del cliente o usuario y la perspectiva técnica del desarrollador. 1.1. Requerimientos de usuario Los requerimientos de usuario describen los servicios del sistema y sus restricciones desde la perspectiva de los usuarios. Están escritos en lenguaje natural (o lenguaje más cercano al negocio del cliente) e incluyen las metas y objetivos del sistema, tal como los perciben los stakeholders (personas interesadas) no técnicos. Tabla 1. Características principales requerimientos de usuario Fuente: OpenAI (2023) Características Lenguaje Lenguaje natural, diagramas intuitivos (ej. diagramas de caso de uso de alto nivel). Clientes, usuarios finales, gerentes, arquitectos de alto nivel. Comprender las necesidades del negocio y validar que el sistema propuesto las satisfaga. Son el “qué” del sistema. Audiencia Propósito Descripción Ejemplo: “Como estudiante, quiero poder buscar libros en la biblioteca por título y autor para encontrar rápidamente el material que necesito.”

Especificación de requerimientos 1.2. Requerimientos de sistema (especificación de requerimientos de software - SRS) Los requerimientos de sistema, también conocidos como especificación de requerimientos de software (SRS por sus siglas en inglés), son una descripción más detallada de las funciones, servicios y restricciones operativas del sistema; son la interpretación de los requerimientos de usuario para el equipo de desarrollo. Tabla 2. Características principales requerimientos de sistema Fuente: OpenAI (2023) Características Lenguaje Lenguaje más formal, semi-estructurado o formal, notaciones de modelado (ej. UML, historias de usuario detalladas). Desarrolladores, testers, arquitectos de software, analistas. Servir como base para el diseño y la implementación del software. Son el “cómo” (o más bien, el “qué en detalle” para el equipo técnico). Audiencia Propósito Descripción Ejemplo (del requerimiento de usuario anterior “El sistema deberá tener una función buscarLibros(criterio) que acepte como parámetro una cadena de texto y que realice una consulta en la base de datos db_libros en las tablas libros.titulo y libros.autor, retornando una lista paginada de resultados.”

Especificación de requerimientos 2.1. Requerimientos funcionales de sistema Los requerimientos funcionales definen los servicios o funciones que el sistema debe proveer, describiendo el comportamiento del sistema bajo ciertas condiciones. Responden a la pregunta: “¿Qué debe hacer el sistema?”


⚙️ Tipos de requerimientos de sistema

Los requerimientos de sistema se clasifican comúnmente en dos grandes categorías, que ya hemos introducido: funcionales y no funcionales. La distinción y especificación correcta de ambos es vital para construir un sistema completo y de calidad. Tabla 3. Características requerimientos funcionales de sistema Fuente: OpenAI (2023) Núm. 1 Describen interacciones entre el sistema y su entorno. Se centran en las tareas que el sistema debe ejecutar. 2 Pueden ser calculados, servicios de información, flujos de trabajo, entre otros. 3 Su ausencia a menudo implica que el sistema está incompleto o no cumple con su propósito esencial. 4 Descripción

Especificación de requerimientos 2.2. Requerimientos no funcionales de sistema Los requerimientos no funcionales definen las restricciones y las cualidades o atributos del sistema. Describen cómo el sistema debe realizar sus funciones y las condiciones bajo las cuales debe operar. Responden a estas preguntas: “¿Cómo debe ser el sistema?”, “¿Qué tan rápido?”, “¿Qué tan seguro?”, “¿Qué tan fácil de usar?” Importancia Aunque a menudo se les presta menos atención inicial, los requerimientos no funcionales son cruciales para la satisfacción del usuario y el éxito del proyecto a largo plazo. Un sistema que funciona, pero es lento, inseguro o difícil de usar, no será exitoso. 2.2.1. Clasificación común de requerimientos no funcionales Requerimientos de usabilidad: relacionados con la facilidad de uso del sistema. Ejemplos comunes

El sistema debe permitir a los usuarios registrar una nueva cuenta.

El sistema debe validar las credenciales del usuario al iniciar sesión.

El sistema debe generar una factura al finalizar una compra.

El sistema debe enviar una notificación por correo electrónico al usuario cuando su contraseña haya sido restablecida.

El sistema debe mostrar el historial de transacciones de los últimos 6 meses.

El sistema debe permitir la búsqueda de productos por nombre, categoría o precio.

Especificación de requerimientos Requerimientos de rendimiento: relacionados con la velocidad, la capacidad de respuesta y la eficiencia del sistema. Ejemplos comunes

La interfaz de usuario debe ser intuitiva y fácil de aprender para usuarios principiantes.

El tiempo máximo para completar el proceso de registro no debe exceder los 2 minutos.

El sistema debe proporcionar mensajes de error claros y amigables. Ejemplos comunes

El tiempo de carga de la página principal no debe exceder los 3 segundos en una conexión estándar.

El sistema debe soportar un mínimo de 100 usuarios concurrentes (conectados al mismo tiempo) sin degradación significativa del servicio.

Una transacción de compra debe completarse en menos de 500 milisegundos. Requerimientos de seguridad: relacionados con la protección del sistema y los datos contra accesos no autorizados, ataques o pérdidas.

Especificación de requerimientos Requerimientos de confiabilidad/fiabilidad: relacionados con la capacidad del sistema para operar sin fallos durante un período de tiempo especificado. Requerimientos de escalabilidad: relacionados con la capacidad del sistema para manejar un aumento en la carga de trabajo o en el número de usuarios. Ejemplos comunes

Todas las comunicaciones entre el cliente y el servidor deben ser cifradas utilizando protocolos de seguridad como SSL (Secure Sockets Layer) /TLS (Transport Layer Security).

El sistema debe implementar un mecanismo de autenticación de doble factor.

El acceso a la base de datos debe ser restringido únicamente al personal autorizado. Ejemplos comunes

El sistema debe tener una disponibilidad del 99.9 % (tiempo de actividad).

El sistema debe ser capaz de recuperarse automáticamente de fallos de hardware en menos de 10 minutos.

La tasa de errores por cada mil transacciones no debe exceder el 0.01 %.

Especificación de requerimientos Requerimientos de mantenibilidad: relacionados con la facilidad con la que el sistema puede ser modificado, corregido o mejorado. Requerimientos de portabilidad: relacionados con la facilidad con la que el sistema puede ser transferido a diferentes entornos operativos (hardware, sistema operativo). Ejemplos comunes

El sistema debe poder escalar horizontalmente añadiendo más servidores para soportar un mayor número de usuarios.

El almacenamiento de datos debe ser capaz de crecer para acomodar 1 TB (Terabyte) de datos adicionales por año. Ejemplos comunes

El código fuente del sistema debe seguir los estándares de codificación PEP 8 (guía de estilo para escribir código Python, por ejemplo).

El sistema debe tener una arquitectura modular para facilitar futuras adiciones de funcionalidades. Ejemplos comunes

La aplicación debe ser compatible con iOS (versión X o superior) y Android (versión Y o superior).

  • El sistema debe ser capaz de desplegarse en diferentes proveedores de la nube (AWS, Azure, GCP).

Requerimientos operacionales/de soporte: relacionados con la forma en que el sistema será operado y soportado en su entorno de producción. Requerimientos legales/regulatorios/de cumplimiento: restricciones impuestas por leyes, regulaciones o políticas. Requerimientos de interoperabilidad: relacionados con la capacidad del sistema para intercambiar información con otros sistemas. Especificación de requerimientos Ejemplos comunes

El sistema debe generar registros (logs) detallados de todas las operaciones para fines de auditoría y depuración.

El sistema debe permitir la monitorización en tiempo real de su estado de salud. Ejemplos comunes

El sistema debe cumplir con la Ley de Protección de Datos Personales (Ley N° 19.628 en Chile).

El procesamiento de pagos debe adherirse a los estándares PCI DSS (conjunto de requisitos de seguridad que deben cumplir las empresas que procesan, almacenan o transmiten datos de tarjetas de crédito y débito).

Especificación de requerimientos Ejemplos comunes

El sistema debe integrarse con el ERP (Planificación de Recursos Empresariales) existente de la empresa para sincronizar el inventario.

El sistema debe poder exportar datos en formato CSV(Comma Separated Values) y PDF (Formato de Documento Portátil).de crédito y débito).

Especificación de requerimientos Características Clara y unívoca No debe haber lugar a interpretaciones ambiguas. Idealmente, describe una sola tarea o comportamiento. Aunque sea técnica, su propósito final debe ser claro para el usuario. Atómica Orientada al usuario Debe ser posible probar si la funcionalidad se implementó correctamente. Verificable Descripción 3.1. Identificación y descripción de funcionalidades Las funcionalidades se identifican a menudo a partir de los requerimientos de usuario y se detallan en los requerimientos de sistema. Se pueden organizar por módulos, roles de usuario o casos de uso.


⚙️ Funcionalidades del sistema

Las funcionalidades del sistema son el conjunto de acciones, procesos o tareas que el software está diseñado para realizar. Son la manifestación concreta de los requerimientos funcionales. Al describir las funcionalidades, estamos detallando los “verbos” del sistema: qué puede hacer por el usuario y para qué sirve. Para proyectos de software pequeños, describir las funcionalidades de manera clara y concisa es suficiente para que el equipo de desarrollo comprenda el alcance de lo que debe construir. Tabla 4. Características de una buena descripción de funcionalidad Fuente: OpenAI (2023)

Ejemplos de funcionalidades para proyectos pequeños En las siguientes figuras, se detallan algunos ejemplos de aplicación de funcionalidades en el sistema de gestión de clientes y en la aplicación de recordatorios personales. Especificación de requerimientos

Figura 1. Ejemplo sistema de gestión de clientes (CRM Básico) Figura 1. Ejemplo sistema de gestión de clientes (CRM Básico) (Fuente: OpenAI (2023))

Especificación de requerimientos Es importante recordar que cada una de estas funcionalidades deriva de uno o más requerimientos funcionales específicos y, a su vez, estará sujeta a los requerimientos no funcionales y las restricciones del sistema.

Figura 2. Ejemplo aplicación de recordatorios personales Figura 2. Ejemplo aplicación de recordatorios personales (Fuente: OpenAI (2023))

La matriz de trazabilidad es una herramienta fundamental en la gestión de requerimientos que permite establecer un vínculo bidireccional entre los requerimientos y otros artefactos del ciclo de vida del software (diseño, código, pruebas, casos de uso, entre otros). Su objetivo principal es asegurar que cada requerimiento sea implementado y probado, y que no se realicen cambios que afecten el alcance sin una comprensión clara de sus implicaciones. Especificación de requerimientos


📌 Matriz de trazabilidad

4.1. Propósito y beneficios

Visibilidad: proporciona una visión clara de cómo los requerimientos se relacionan con otros elementos del proyecto.

Gestión de Cambios: permite evaluar el impacto de un cambio en un requerimiento en otras partes del sistema o en las pruebas.

Validación: ayuda a asegurar que todos los requerimientos han sido cubiertos por el diseño, la implementación y las pruebas.

Análisis de Impacto: facilita la identificación de elementos afectados si un requerimiento es modificado o eliminado.

Cumplimiento: en entornos regulados, es crucial para demostrar que se ha cumplido con todas las especificaciones. 4.2. Estructura básica de una matriz de trazabilidad Una matriz de trazabilidad suele ser una tabla (en una hoja de cálculo, una base de datos o una herramienta especializada) en la cual las filas representan los requerimientos (o un tipo de artefacto) y las columnas representan los artefactos con los que se trazan (o viceversa).

Especificación de requerimientos Elementos Id del requerimiento Descripción del requerimiento Identificador único del requerimiento (ej., RF-001, RNF-005, RU-003). Una breve descripción del requerimiento. Si se traza desde RU a RS. Casos de uso asociados Los casos de uso que implementan este requerimiento. Casos de prueba asociados Los casos de prueba que verifican que el requerimiento se ha implementado correctamente. Estado El estado actual del requerimiento (propuesto, aprobado, implementado, probado, obsoleto). Elementos de diseño asociados Partes del diseño (diagramas de clases, diseño de base de datos) que lo cubren. Módulos de código / clases asociados Las secciones de código que implementan el requerimiento. Requerimiento de Usuario (RU) a sociado A qué parte del sistema pertenece. Módulo / Componente afectado Descripción Tabla 5. Elementos comunes en una matriz de trazabilidad Fuente: OpenAI (2023)

4.3. Implementación en proyectos pequeños En proyectos pequeños, la matriz de trazabilidad no necesita ser excesivamente compleja. Puede ser una hoja de cálculo simple. Lo importante es que sea útil y mantenible. Un enfoque pragmático es centrarse en la trazabilidad de los requerimientos clave (aquellos que son críticos para el negocio o que tienen un alto riesgo) hacia los casos de prueba, para asegurar que todo lo importante se verifique. Especificación de requerimientos

Hemos recorrido un camino crucial en la ingeniería de requerimientos. Comprender la diferencia entre requerimientos de usuario y de sistema es el primer paso para una comunicación efectiva. La habilidad para identificar y clasificar los requerimientos en funcionales (lo que el sistema hace) y no funcionales (cómo lo hace y en qué condiciones) es una competencia indispensable para cualquier analista o desarrollador. Finalmente, la matriz de trazabilidad es una herramienta importante, incluso en proyectos pequeños, para mantener el control sobre la evolución de los requerimientos y asegurar que cada pieza de software que construimos tiene un propósito claro y es adecuadamente verificada. Dominar estos conceptos les permitirá no solo analizar y documentar requerimientos de manera efectiva, sino también contribuir significativamente al éxito de cualquier proyecto de desarrollo de software, asegurando que lo que se construye es realmente lo que el cliente necesita y espera.


💡 Conclusión

Especificación de requerimientos

Especificación de requerimientos



🚀 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.

📚 Fuentes y lecturas recomendadas

Open AI. (2023). Chat GPT (Mar 14 version) [Modelo de lenguaje modelado].

Sommerville, I. (2011). Requerimientos de software. En Ingeniería del Software. Pearson Educación. https://elibro.net/es/lc/santotomas/titulos/37857

CONTINÚA EXPLORANDO

ARTÍCULOS SUGERIDOS

Dilema ético en la toma de decisiones tecnológicas e informáticasInformática

Actos Humanos, Libertad y Dilemas Éticos en la Tecnología

Análisis de decisiones éticas: actos del hombre vs actos humanos voluntarios, consentimiento, privacidad de datos y dilemas en algoritmos de IA.

Representación conceptual de la dignidad de la persona y la ética del trabajoInformática

Dignidad de la Persona, Ética de las Virtudes y Excelencia Profesional

La persona como centro de la actividad técnica: dignidad intrínseca, virtudes cardinales y búsqueda de la excelencia en el ejercicio del trabajo.

Representación simbólica de la balanza de la justicia y la éticaInformática

Fundamentos de la Ética: Moral, Leyes y Responsabilidad Social

Distinción conceptual entre ética y moral: el origen de las normas de convivencia, relación con el ordenamiento jurídico y responsabilidad ciudadana.

VER TODOS LOS RECURSOS →

HABLEMOS DE TU CASO

¿Necesitas ayuda? Contáctanos y te contestamos!

SERVICIOS →