Técnicas de Elicitación y Priorización de Requisitos
Elicitación de Requisitos
Prototipado de interfaz (mockups o wireframes interactivos). Esta técnica permite que el cliente visualice cómo funcionará el sistema, incluyendo la validación de datos en tiempo real, sin necesidad de tener el sistema ya desarrollado. Es especialmente útil cuando el cliente no logra expresar claramente qué espera o cómo debe comportarse el sistema.
Entrevistas (estructuradas o semiestructuradas) con usuarios o responsables del área de atención al cliente. Las entrevistas permiten aclarar dudas específicas directamente con los expertos del proceso, garantizando que el formulario recoja los datos correctos desde el inicio. Son especialmente útiles cuando los requerimientos no están bien definidos y es necesario obtener detalles precisos del dominio funcional.
Observación directa. Esta técnica permite ver de primera mano las acciones, los flujos de trabajo y las interacciones de los inspectores, lo que ayuda a identificar los requisitos reales de la aplicación. También permite captar detalles que podrían pasarse por alto en entrevistas o encuestas, y proporciona una mejor comprensión de los puntos de dolor y las expectativas de los usuarios.
Se podría aplicar Análisis de documentación legal o Entrevistas con expertos legales o institucionales. Estas técnicas permiten identificar y comprender de manera confiable los requisitos legales que el sistema debe cumplir, evitando omisiones que podrían derivar en incumplimientos o sanciones. Además, combinan el análisis directo de fuentes formales con la interpretación de especialistas, lo cual da solidez a los requerimientos resultantes.
Priorización de Requisitos
Priorización con el método MoSCoW. La técnica MoSCoW permite tomar decisiones colaborativas y estructuradas cuando hay muchas expectativas y recursos limitados. Evita conflictos al hacer visibles las prioridades y ayuda a alinear las expectativas de todos los involucrados respecto al alcance de la primera versión del producto.
Selección de Metodologías de Desarrollo de Software
Para el desarrollo del sistema de gestión de actas para un juzgado, donde el cliente tiene requisitos claros, pero con posibles cambios significativos durante el desarrollo, se requiere documentación formal y controles de avance, y se desean entregas parciales por módulos, la metodología más adecuada es el modelo incremental tradicional.
Como solo se tiene una idea general del producto y las funcionalidades se ajustarán según el uso, es necesario un enfoque que permita adaptarse rápidamente a cambios, priorizar el aprendizaje temprano y validar hipótesis de negocio constantemente. Por esto, se podría aplicar Scrum, ya que permite desarrollar el producto por partes funcionales (incrementos), priorizando lo más valioso para el usuario en cada Sprint.
El Modelo Cascada es adecuado porque el proyecto tiene requisitos bien definidos y estables, lo que permite diseñar una solución completa desde el principio sin esperar cambios significativos. Además, la necesidad de alta calidad en la documentación y un fuerte control del avance se ajustan bien al enfoque secuencial y estructurado de Cascada.
Buenas Prácticas y Eventos Clave en Scrum
Manejo de Historias de Usuario Grandes
Si en el desarrollo del sistema de reservas el equipo detecta que algunas historias de usuario son demasiado grandes para completarlas en el Sprint, el Scrum Master debe tomar acciones que faciliten la mejora del proceso de refinamiento y planificación, asegurando que el equipo trabaje con ítems bien preparados, pequeños y claros. Entre esas acciones se debería:
- Fomentar el refinamiento del Product Backlog para que se analicen, entiendan y dividan las historias grandes en historias más pequeñas que aporten valor y puedan completarse en un Sprint.
Propósito de la Sprint Review
No es adecuado centrar la Sprint Review en discutir cambios a funcionalidades futuras que aún no se han desarrollado. La Sprint Review tiene como objetivo inspeccionar el incremento entregado durante el Sprint que termina y adaptar el Product Backlog si es necesario. Sus objetivos principales son:
- El equipo de desarrollo presenta las funcionalidades terminadas que cumplen con la «Definition of Done».
- Recibir retroalimentación: Stakeholders y Product Owner participan para comentar si lo entregado satisface las necesidades del negocio, identificar oportunidades de mejora o ajustes.
La Sprint Retrospective y la Definición de Terminado (DoD)
Cuando en una retrospectiva Scrum se detecta que muchas tareas quedaron en estado de «casi terminado», el equipo debe revisar de forma crítica y colaborativa su Definition of Done, su planificación del Sprint y su forma de trabajar durante el Sprint. La Sprint Retrospective es una reunión al final del Sprint cuyo objetivo es:
- Inspeccionar cómo fue el trabajo en el Sprint e identificar qué funcionó bien y qué no.
- Acordar acciones concretas de mejora continua para el próximo Sprint.
Asignación de Tareas y Autogestión
No es una buena práctica en Scrum que las historias de usuario o tareas se asignen sin consenso ni que el Scrum Master intervenga directamente en la asignación de trabajo. Esta forma de proceder contradice los principios fundamentales de Scrum sobre autogestión, transparencia y colaboración.
- Scrum promueve equipos autogestionados: El equipo de desarrollo es responsable de organizarse por sí mismo para lograr los objetivos del Sprint.
- El Scrum Master no es un jefe de proyecto: Su rol es facilitar el proceso Scrum, eliminar impedimentos y fomentar buenas prácticas, pero no debe asignar tareas ni dirigir el trabajo del equipo.
- El funcionamiento de la asignación de tareas es: Durante la planificación del Sprint (Sprint Planning), el equipo selecciona y se compromete con las tareas.
Responsabilidades del Product Owner
El Product Owner puede cancelar un Sprint si el objetivo del Sprint deja de tener sentido, por ejemplo, debido a cambios en las prioridades del negocio.
El Product Owner es responsable de priorizar el Product Backlog. Para hacerlo, debe tener en cuenta factores como el valor que cada ítem aporta al negocio, la urgencia de los requisitos, la complejidad técnica y la disponibilidad de recursos. La prioridad debe estar alineada con los objetivos de negocio y la visión del producto.
Manejo de Funcionalidad Incompleta
La funcionalidad debe considerarse no terminada y volver al Product Backlog. En la retrospectiva se debería analizar por qué se planificó una tarea sin la información suficiente para implementarla y mejorar el refinamiento y la planificación en el futuro.
Evaluación de la Calidad de los Requisitos de Software
Requisito 1: Compatibilidad Móvil
«El sistema debe ser compatible con dispositivos móviles Android y iOS.»
- Tipo de Requisito
- No Funcional. Este requerimiento no describe una funcionalidad específica que el sistema deba realizar, sino que se refiere a una característica de calidad relacionada con la compatibilidad de la plataforma.
- No ambiguo
- Sí. El requerimiento es claro en cuanto a la compatibilidad deseada: Android y iOS. No da lugar a múltiples interpretaciones.
- Correcto
- Sí. Es un requerimiento válido, especialmente para una aplicación móvil.
- Completo
- No. No especifica si la compatibilidad debe incluir todas las versiones de Android e iOS, ni si debe considerarse compatibilidad con diferentes tamaños de pantalla, sistemas operativos específicos o dispositivos específicos.
- Factible
- Sí. Es factible, pero dependerá de las herramientas disponibles.
- Verificable
- Sí. Se puede verificar si la aplicación es accesible y funcional en dispositivos Android e iOS.
- Consistente
- Sí. No presenta contradicciones, y es consistente con los objetivos de una aplicación móvil.
Redacción alternativa mejorada
«… (versiones 12.0 y superiores), y debe adaptarse correctamente a pantallas de diferentes tamaños y resoluciones.»
Requisito 2: Listado de Productos con Bajo Stock
«El sistema debe permitir listar los productos con poco stock»
- Tipo de Requisito
- Es un requerimiento funcional; describe una funcionalidad específica del sistema: listar productos con poco stock. Indica qué debe hacer el sistema.
- No ambiguo
- No cumple. El término «poco stock» es vago. No se especifica si se trata de un umbral fijo, variable o configurable.
- Correcto
- Sí cumple. La intención es válida dentro del contexto del sistema.
- Completo
- No; no se detalla cómo se determina el «poco stock», ni si el listado incluye filtros, orden u otros criterios.
- Factible
- Sí. Técnicamente es posible implementar esta funcionalidad, suponiendo que se cuenta con información de stock mínimo o umbral.
- Verificable
- No. No se puede verificar si el requerimiento fue cumplido sin definir exactamente qué significa «poco stock».
- Consistente
- Sí. No entra en conflicto con otros requerimientos (al menos no se detecta contradicción en forma aislada).
Redacción alternativa mejorada
«… cuyo stock actual sea menor al stock mínimo definido para cada producto en el catálogo.»