Historias de Usuario, Criterios de Aceptación y Principios INVEST

📌 En síntesis: Elicitación en entornos ágiles: estructura estándar de historias de usuario, escenarios con Given-When-Then y verificación con criterios INVEST.

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

📌

📌 Aprendizaje esperado

📌

Manejar a nivel básico las técnicas y herramientas usadas en el levantamiento de requerimientos de proyectos de desarrollo de software. Especiﬁcación de requerimientos

Especiﬁcación de requerimientos En las semanas anteriores, hemos comprendido la importancia crucial de la ingeniería de requerimientos en el desarrollo de software. Hemos explorado cómo los requerimientos deﬁnen lo que un sistema debe hacer y cómo se comportan sus usuarios. Sin embargo, tener requerimientos claros, completos y correctos no es una tarea sencilla; no aparecen por sí solos. De hecho, uno de los mayores desafíos en cualquier proyecto de software es la fase de levantamiento o elicitación de requerimientos. Este proceso implica descubrir, extraer y entender las necesidades de los usuarios y otros interesados, a menudo de fuentes diversas y a veces contradictorias o complementarias. La elicitación de requerimientos es, en esencia, el proceso de comunicación con los clientes, usuarios y otros stakeholders para descubrir los servicios que el sistema debe proporcionar y las restricciones bajo las cuales debe operar. No se trata de una simple recolección de información; es una actividad activa y compleja que requiere habilidades de comunicación, negociación y análisis. Una elicitación deﬁciente es una de las causas principales de proyectos fallidos, ya que conduce a la construcción de un software que no satisface las verdaderas necesidades del negocio. Esta clase se centrará en las diversas técnicas y herramientas que un analista de requerimientos puede emplear para llevar a cabo una elicitación efectiva. Exploraremos métodos que van desde la interacción directa con las personas hasta el análisis de la información existente, pasando por la creación de modelos visuales. Además, identiﬁcaremos los roles clave que participan en este proceso, comprendiendo sus responsabilidades y cómo su colaboración es vital para asegurar que los objetivos del proyecto se traduzcan adecuadamente en requerimientos de software. Manejar estas técnicas y comprender a los actores involucrados les permitirá levantar requerimientos de manera más eﬁciente en proyectos de alcance simple y con límites claros.

🚀 Introducción

Especiﬁcación de requerimientos El proceso de levantamiento de requerimientos no es una tarea solitaria; es una actividad colaborativa que involucra a diversas personas con diferentes perspectivas e intereses. Identiﬁcar y comprender el rol de cada participante es crucial para una elicitación exitosa.

🔹 El stakeholder: el corazón de las necesidades

Un stakeholder (o parte interesada) es cualquier persona o grupo que tiene un interés en el sistema, es afectado por él, o puede inﬂuir en su desarrollo y uso. Los stakeholders son la fuente principal de los requerimientos, y su involucramiento activo es indispensable. 1.1.1. Identiﬁcación y clasiﬁcación de stakeholders Es fundamental identiﬁcar a todos los stakeholders relevantes al inicio del proyecto. Ignorar a un stakeholder importante puede llevar a requerimientos incompletos o a la resistencia al cambio cuando el sistema sea implementado. En la Tabla 1 detallamos los actores que pueden ser considerados como stakeholders.

📌 Roles fundamentales en el proceso de elicitación

Especiﬁcación de requerimientos 1.1.2. La importancia de la gestión de stakeholders Una vez identiﬁcados, es vital gestionar las expectativas y la participación de los stakeholders. Esto implica:

Priorizar: no todos los stakeholders tienen la misma inﬂuencia o el mismo nivel de necesidad. Es importante categorizarlos (ej., por poder e interés) para enfocar los esfuerzos de elicitación.
Comunicación constante: mantenerlos informados sobre el progreso y los cambios. Tabla 1. Stakeholders Fuente: OpenAI (2023) Stakeholders Descripción Usuarios ﬁnales Aquellos que interactuarán directamente con el sistema (ej., clientes de una aplicación móvil, empleados que usarán un sistema de gestión). Clientes Quienes pagan por el sistema y deﬁnen sus objetivos de negocio. Gerentes Aquellos que supervisan el proyecto o la operación del negocio y tienen metas especíﬁcas. Expertos en el dominio Personas con conocimiento profundo sobre el área de negocio que el sistema abordará. Reguladores Entidades que imponen normas o leyes que el sistema debe cumplir. Desarrolladores y testers Aunque no son fuentes primarias de requerimientos de negocio, sus capacidades y restricciones inﬂuyen en la viabilidad técnica. Proveedores externos Si el sistema interactúa con otros sistemas o servicios.

Especiﬁcación de requerimientos

Resolución de conﬂictos: a menudo, los stakeholders tienen necesidades contradictorias. El analista debe facilitar la negociación y ayudar a encontrar soluciones que satisfagan a la mayoría, o escalar los conﬂictos a la gerencia.

🔹 El project manager: orquestador del proyecto

El project manager (gerente de proyecto) es el responsable general de la planiﬁcación, ejecución y cierre del proyecto. Aunque su rol principal no es elicitar requerimientos directamente, es una ﬁgura clave en el proceso de ingeniería de requerimientos. A continuación, se detallan sus funciones principales: En resumen, el project manager crea el entorno adecuado para que los analistas puedan llevar a cabo su trabajo de elicitación de manera efectiva.

Figura 1: Roles del project manager

Facilitador y gestor de recursos Asegura que el equipo de requerimientos (analistas) tenga los recursos necesarios (tiempo, personal, acceso a stakeholders) y que el proceso de elicitación se alinee con el plan general del proyecto. Gestor de expectativas Trabaja de cerca con el analista para gestionar las expectativas del cliente y los stakeholders respecto al alcance, el presupuesto y el cronograma del proyecto. Resolución de conﬂictos y toma de decisiones Interviene para mediar en conﬂictos entre stakeholders o cuando se requieren decisiones importantes que afectan los requerimientos o el alcance. Comunicación de alto nivel Es el punto de contacto principal con los altos directivos y asegura que la importancia de la fase de requerimientos sea comprendida y apoyada a nivel organizacional.

Especiﬁcación de requerimientos El levantamiento de requerimientos no es una actividad de “talla única”. Existen diversas técnicas, cada una con sus propias fortalezas y debilidades, que se aplican según el contexto del proyecto, los stakeholders involucrados y la información disponible. Una aproximación efectiva a menudo implica el uso combinado de varias de estas técnicas. 2.1. Entrevistas: conversaciones dirigidas Las entrevistas son una de las técnicas más tradicionales y directas para elicitar requerimientos. Consisten en una conversación estructurada o semiestructurada con los stakeholders para obtener información sobre sus necesidades, expectativas, problemas y los procesos de negocio. 2.1.1. Tipos y preparación En la Tabla 2 se especiﬁcan cuáles son los tipos de entrevistas.

📌 Técnicas de levantamiento de requerimientos:

🛠️ herramientas del analista

Tabla 2. Tipos y preparación de entrevistas Fuente: OpenAI (2023) Tipos Descripción Estructuradas Siguen un guion de preguntas predeﬁnidas. Útiles cuando se necesita información muy especíﬁca o se entrevista a muchas personas. Semiestructuradas Tienen un conjunto de preguntas principales, pero permiten ﬂexibilidad para explorar temas inesperados. Son las más comunes. No estructuradas Conversaciones abiertas, útiles al inicio del proyecto para entender el panorama general.

Especiﬁcación de requerimientos Preparación: 1. Deﬁnir objetivos: ¿qué información se busca obtener? 2. Identiﬁcar entrevistados: ¿quiénes tienen la información clave? 3. Preparar preguntas: abiertas y cerradas. 4. Organizar la logística: hora, lugar y duración. 5. Investigar al entrevistado: conocer su rol y área de experiencia. 2.1.2. Ventajas y desafíos Te invitamos a explorar la Figura 2 para comprender las ventajas y desafíos de las entrevistas.

Figura 2: Ventajas y desafíos de las entrevistas

Ventajas y desafíos de las entrevistas Ventajas Desafíos

Permite explorar temas en profundidad.
Facilita la construcción de relaciones con los stakeholders.
Permite observar lenguaje corporal y emociones (información valiosa).
Ideal para obtener información sobre excepciones y “reglas no escritas”.
Requiere mucho tiempo y recursos.
La calidad de la información depende de la habilidad del entrevistador.
Pueden surgir sesgos (del entrevistador o del entrevistado).
Los entrevistados pueden olvidar información o tener diﬁcultades para articular sus necesidades.
Pueden surgir conﬂictos entre stakeholders si no hay acuerdo.

Especiﬁcación de requerimientos 2.1.3. Ejemplo de entrevista A continuación, puede encontrar un ejemplo de una entrevista, con aquello datos que deben registrase y preguntas tipo, considerando registrar siempre lo que el cliente necesita: Fuente: elaboración propia Entrevista con cliente – Proyecto: ‘App Cafetería Móvil’ Fecha: 15/04/2025 Entrevistado: Carlos Díaz, dueño de Cafetería Aroma Express. Entrevistador: Paula Méndez, Analista de Requerimientos. P1: ¿Qué funcionalidades considera esenciales en esta primera versión de la aplicación? R1: Lo principal es que el cliente pueda revisar el menú con fotos, hacer pedidos para retiro o entrega y elegir el método de pago. Me interesa que el proceso sea rápido. P2: ¿Qué métodos de pago quiere habilitar inicialmente? R2: Transferencia, tarjeta de crédito/débito y también efectivo. Me interesa que el sistema registre cuál fue el método usado. P3: ¿Desea controlar el stock desde la app? R3: No por ahora, pero sí que el menú pueda indicar si un producto está agotado. Observaciones: - Requerimientos funcionales identiﬁcados: menú digital, pedidos, selección de pago. - Restricciones no funcionales: rapidez, disponibilidad de productos visibles. - Considerar interfaz amigable y adaptable a dispositivos móviles de gama baja.

Especiﬁcación de requerimientos 2.2. Historias de usuario: requerimientos ágiles y centrados en el valor Las historias de usuario son una técnica de elicitación y especiﬁcación de requerimientos muy popular en metodologías ágiles como Scrum y Kanban. Se centran en la perspectiva del usuario y describen una pequeña pieza de funcionalidad que entrega valor. 2.2.1. Estructura y propósito Una historia de usuario se expresa generalmente en el formato: “Como un [Tipo de Usuario], quiero [una funcionalidad], para [un beneﬁcio/razón]”. 2.2.2. Principios INVEST Una buena historia de usuario debe cumplir con los principios INVEST (por Bill Wake - consultor y coach de desarrollo ágil de software,): Ejemplo: “como un cliente, quiero poder buscar productos por categoría, para encontrar fácilmente lo que necesito.” o Fomentar la conversación entre el equipo de desarrollo y el cliente. o Mantener los requerimientos concisos y enfocados en el valor. o Facilitar la priorización y planiﬁcación iterativa del trabajo. Propósito

2.2.3. Diferencias con casos de uso Aunque ambos describen funcionalidades desde la perspectiva del usuario, las historias de usuario son más ligeras y menos detalladas que los casos de uso. Un caso de uso puede descomponerse en varias historias de usuario, o una historia de usuario muy grande (Épica) puede subdividirse en varias historias más pequeñas, y su implementación podría involucrar varios casos de uso detallados. Las Historias de usuario se enfocan más en el “qué” y el “por qué” de una funcionalidad, mientras que los casos de uso profundizan más en el “cómo” interactuar con el sistema (ﬂujos, pre/post condiciones). 2.2.4. Ejemplo de Historia de Usuario En el ámbito informático, existen estructuras documentales que permiten crear Historias de usuario, a continuación, se presenta un ejemplo: Especiﬁcación de requerimientos

Figura 3: Principios INVEST

📌 I

Independiente: se puede desarrollar por sí misma.

📌 N

Negociable: no es un contrato, se puede discutir y adaptar.

📌 V

Valiosa: entrega valor al usuario o al negocio.

📌 E

Estimable: se puede estimar su esfuerzo de desarrollo.

📌 S

Suﬁcientemente pequeña (small): puede ser completada en una iteración.

📌 T

Testeable: se puede veriﬁcar su funcionamiento correcto.

2.2.5. Ejemplo de Evaluación INVEST De acuerdo con el estándar INVEST, se evalúa la Historia de usuario del ejemplo 2.2.4 presentado: Especiﬁcación de requerimientos Fuente: elaboración propia ID HU002 Título Pago seguro en línea Como Cliente de la cafetería Quiero Pagar mi pedido con tarjeta de crédito desde el celular Para Evitar ﬁlas y ahorrar tiempo Criterios de aceptación - La app debe ofrecer al menos dos opciones de pago en línea. - Debe notiﬁcar si el pago fue aprobado o rechazado. - El pago debe registrarse junto al número de pedido. No depende de otras Historia de usuario Permite la discusión y la negociación entre el equipo y los stakeholders para realizar cambios o mejoras Deﬁne claramente el aporte para el cliente ﬁnal Proporciona toda la información necesaria para el desarrollador Es una historia deﬁnida, única y pequeña para tener solo una iteración Claros criterios de aceptación para hacer las pruebas T - Testeable S - Small E - Estimable V - Valiosa N - Negociable I - Independiente

Especiﬁcación de requerimientos 2.3. Prototipos: concretando la visión Los prototipos son modelos preliminares o versiones simpliﬁcadas del software o de una parte de él. Son herramientas visuales y tangibles que ayudan a elicitar requerimientos al permitir a los stakeholders interactuar con una representación del sistema antes de que esté completamente construido. 2.3.1. Tipos de prototipos (ﬁdelidad y propósito)

Figura 4: Tipos de Prototipos

Tipos de prototipos Baja ﬁdelidad (wireframes, maquetas en papel): dibujos simples, bocetos, maquetas en papel. Rápidos de crear y modiﬁcar, ideales para explorar ideas y ﬂujo básico. No se parecen mucho al producto ﬁnal. Media ﬁdelidad (mockups interactivos): diseños gráﬁcos más elaborados, a menudo digitales, que simulan la interfaz de usuario con cierto nivel de detalle y permiten navegación básica. Alta ﬁdelidad (prototipos funcionales): se parecen mucho al producto ﬁnal, con interactividad y detalles de diseño avanzados. Pueden ser difíciles y costosos de crear y modiﬁcar. Desechables (throwaway prototypes): se construyen rápidamente para explorar ideas, obtener retroalimentación y luego se descartan. Su propósito es ayudar a elicitar requerimientos, no ser parte del producto ﬁnal. Evolutivos (evolutionary prototypes): se construyen con la intención de ser mejorados y reﬁnados hasta convertirse en el sistema ﬁnal. Más arriesgados si los requerimientos cambian mucho. Según la ﬁdelidad Según el propósito

Especiﬁcación de requerimientos 2.4. Análisis de documentos: aprendiendo del pasado El análisis de documentos implica revisar la documentación existente relacionada con el sistema actual, el negocio o los procesos que el nuevo software busca mejorar o reemplazar. Es una técnica no intrusiva y a menudo es un excelente punto de partida antes de interactuar directamente con las personas. 2.3.2. Ventajas y limitaciones

Figura 5: Ventajas y limitaciones de los Prototipos

Ventajas y limitaciones de los prototipos Ventajas Limitaciones

Facilitan la elicitación de requerimientos no explícitos o que son difíciles de articular.
Permiten a los usuarios “ver y tocar” el sistema, lo que genera una retroalimentación más rica y temprana.
Ayudan a validar y reﬁnar requerimientos de interfaz de usuario.
Reducen la ambigüedad y los malentendidos.
Permiten identiﬁcar problemas de usabilidad tempranamente.
Pueden generar expectativas poco realistas en los usuarios sobre la funcionalidad o el tiempo de desarrollo.
Los prototipos de alta ﬁdelidad pueden ser costosos y requerir mucho tiempo.
Riesgo de que el cliente piense que el prototipo es el producto ﬁnal y se resista a cambios o descartes.

Especiﬁcación de requerimientos 2.4.2. Ejemplo de Análisis de Documentos Las fuentes primerias y secundarias de información, en informática, permiten obtener elementos valiosos, establecidos, y que reﬂejan el modelo del negocio del cliente o stakeholders. A continuación, se muestra un ejemplo de análisis de documento. Contenido observado: - Menú incluye más de 40 productos con precios, pero sin fotos. - No se indican ingredientes ni advertencias para personas alérgicas. - Algunos combos no están claramente separados del menú regular. Requerimientos derivados: - RF03: Cada producto debe incluir imagen, descripción y categoría. - RNF04: El sistema debe permitir aplicar ﬁltros por tipo (vegano, sin gluten). - RNF05: El menú digital debe ser accesible desde dispositivos con conexión 3G. Tabla 3. Fuentes comunes de los documentos Fuente: OpenAI (2023) Fuentes Descripción Documentación de sistemas existentes Manuales de usuario, especiﬁcaciones técnicas, diagramas de ﬂujo de datos, código fuente. Documentos de negocio Informes ﬁnancieros, planes estratégicos, manuales de procedimiento, políticas internas, formularios y descripciones de puestos de trabajo. Regulaciones y leyes Normativas gubernamentales o de la industria que el sistema debe cumplir. Análisis de la competencia Documentación pública o estudios de mercado. 2.4.1. Fuentes comunes de documentos

Especiﬁcación de requerimientos 2.4.3. Qué buscar y cómo aplicar El analista debe buscar: Aplicación:

Iniciar con una revisión general para obtener una visión amplia.
Luego, una lectura más detallada, buscando puntos especíﬁcos.
Documentar los hallazgos y validar con los stakeholders en entrevistas posteriores. 2.5. Diagramas de contexto: delimitando el sistema Los diagramas de contexto son una herramienta visual sencilla, pero poderosa, a menudo utilizada al inicio de la fase de análisis de requerimientos. Proporcionan una vista de alto nivel del sistema, mostrando cómo interactúa con su entorno.

Figura 6: Qué debe buscar el analista

📌

Requerimientos funcionales implícitos: funcionalidades que el sistema actual maneja y que no son explícitamente mencionadas por los usuarios.

📌

Reglas de negocio: restricciones, cálculos y políticas que rigen la operación.

📌

Restricciones no funcionales: requisitos de rendimiento, seguridad, cumplimiento legal, entre otros.

📌

Glosario de términos: lenguaje especíﬁco del dominio de negocio.

📌

Flujos de trabajo: cómo se realizan las tareas actualmente.

Especiﬁcación de requerimientos 2.5.2. Cómo se relaciona con la elicitación El diagrama de contexto es una herramienta apropiada para iniciar discusiones de elicitación:

Ayuda a veriﬁcar con los stakeholders si se han identiﬁcado todas las fuentes y destinos de información.
Fuerza al equipo a pensar en las interfaces del sistema desde el principio.
Previene el “crecimiento del alcance” al tener un acuerdo visual sobre lo que el sistema debe y no debe hacer.
Sirve como base para la identiﬁcación de actores y casos de uso más detallados. 2.5.1. Propósito y componentes Tabla 4. Qué debe buscar el analista Fuente: OpenAI (2023) Propósito Componentes Deﬁnir los límites del sistema: claramente muestra qué está dentro y qué está fuera del alcance del proyecto. Sistema central: representado por un único proceso o un óvalo/círculo en el centro. Es el sistema que se va a desarrollar. Identiﬁcar entidades externas: quién o qué interactúa con el sistema. Entidades externas (actores): cuadrados o rectángulos que representan personas, organizaciones o sistemas externos que interactúan con el sistema central. Mostrar ﬂujos de datos: qué información entra y sale del sistema. Comunicación: fácil de entender para todos los stakeholders, facilita las discusiones sobre el alcance. Flujos de datos: ﬂechas que indican el movimiento de información entre el sistema central y las entidades externas.

Especiﬁcación de requerimientos 2.5.3. Ejemplo de Diagrama de Contexto Los Diagramas de Contexto utilizan u esquema visual, con elementos deﬁnidos, a continuación, se presenta un ejemplo, basado en la Historia de usuario presentada antes:

Figura 7: Diagrama de contexto

Administrador App Proceso de pago Cliente Actualización Datos de pago Pedido/conﬁguración Flujo Descripción Cliente ⇄ App El cliente envía pedidos y recibe conﬁrmaciones. Es un ﬂujo de entrada y salida. Administrador → App El administrador actualiza productos, precios, y controla la disponibilidad. Es un ﬂujo de entrada. App → Pasarela de Pago La app envía los datos de pago para ser procesados por un sistema externo. Es un ﬂujo de salida. Tabla 5. Flujo del diagrama de contexto

Es importante destacar que ninguna técnica de elicitación es perfecta por sí sola. Para proyectos reales, el enfoque más efectivo es una combinación estratégica de varias de ellas. La elección y combinación de técnicas dependerá de factores como la naturaleza del proyecto, el nivel de conocimiento de los stakeholders, el tiempo y los recursos disponibles y la metodología de desarrollo (ágil o tradicional) que se esté empleando. Un buen analista de requerimientos sabe cuándo y cómo aplicar cada técnica para obtener la información más completa y precisa posible. Por ejemplo:

Se puede comenzar con el análisis de documentos y la creación de un diagrama de contexto para obtener una comprensión inicial y delinear el alcance.
Luego, se pueden realizar entrevistas con stakeholders clave para profundizar en sus necesidades y validar los hallazgos iniciales.
Las historias de usuario pueden ser usadas para capturar requerimientos funcionales en un formato ágil y facilitar la priorización.
Los prototipos se utilizarían para visualizar la interfaz, obtener retroalimentación temprana sobre la usabilidad y validar las expectativas del usuario. Especiﬁcación de requerimientos

🛠️ Integración de técnicas y herramientas:

📌 una aproximación holística

El levantamiento de requerimientos es, sin duda, una de las fases más complejas pero gratiﬁcantes del ciclo de vida del software. No se trata de un proceso lineal, sino de una actividad iterativa que requiere empatía, habilidades de comunicación y un kit de herramientas bien deﬁnido. Hemos explorado técnicas clave como las entrevistas, las historias de usuario, el uso de prototipos, el análisis de documentos y la construcción de diagramas de contexto. Cada una de estas herramientas tiene su propósito y momento óptimo de uso, y su combinación estratégica es lo que realmente potencia la efectividad del analista. Comprender los roles de los stakeholders y del Project Manager en este proceso es igualmente vital. Son las personas que nos proporcionan la información y el contexto necesario, y gestionar sus expectativas y su participación activa es tan importante como aplicar las técnicas correctas. Al dominar estas habilidades, ustedes estarán mejor preparados para traducir las necesidades del negocio en requerimientos claros y precisos, sentando las bases para el diseño y desarrollo de software de calidad. Reconocer la importancia de cada requerimiento, asociarlo a los objetivos del proyecto y saber levantarlo con dirección en proyectos simples son pasos cruciales hacia su desarrollo como profesionales competentes en el campo de la ingeniería informática. Recuerden que un requerimiento bien elicitado es el primer paso hacia un proyecto exitoso.

💡 Conclusión

Especiﬁcación de requerimientos

Sommerville, I. (2011). Ingeniería del Software (9ª ed.). Pearson Educación. https://elibro.net/es/lc/santotomas/titulos/37857 Pressman, R. S., y Maxim, B. R. (2020). Ingeniería del Software: Un Enfoque Práctico (9ª ed.). McGraw-Hill Education.

🚀 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

Especiﬁcación de requerimientos