GFPI-F-135GuiadeAprendizaje JIRA VALIDACIÓN DE REQUERIMIENTOS 003
GFPI-F-135GuiadeAprendizaje JIRA VALIDACIÓN DE REQUERIMIENTOS 003
2. PRESENTACIÓN
GFPI-F-135 V02
Objetivo
Motivar al trabajo autónomo y sistemático a través de tecnicas de
storytelling.
GFPI-F-135 V02
• Prioridad (elegir de una lista)
• Fecha Límite (fecha)
• Módulo Afectado (lista desplegable)
• Descripción (campo de texto)
• Haz clic en Crear.
GFPI-F-135 V02
2. Crear un Proyecto para tu Producto:
• Accede a Proyectos > Crear Proyecto.
• Ingresa un nombre para el proyecto, como "Nombre del Producto".
• Selecciona Scrum como metodología.
• Elige el tipo de incidencia "Requisito" creado anteriormente.
• Haz clic en Crear.
GFPI-F-135 V02
4. Gestionar los Requerimientos:
• Puedes ordenar, filtrar y buscar las incidencias de requisitos.
• Puedes asignar las incidencias a miembros del equipo.
• Puedes agregar comentarios y discutir los requisitos.
• Puedes cambiar el estado de las incidencias a medida que se avanza en su desarrollo.
• Puedes utilizar el panel de control para obtener una vista general del progreso de los requisitos.
GFPI-F-135 V02
Tema 2: Prioriza las funcionalidades con MoSCoW: Una vez que tienes una lista de funcionalidades, es
hora de priorizarlas. Puedes utilizar técnicas como MoSCoW (Must have, Should have, Could have, Won't
have) para ayudarte a clasificarlas por importancia.
Must have (Debe tener): Son los requisitos o funcionalidades críticas y fundamentales para el éxito
del proyecto. Estos elementos son imprescindibles y deben ser implementados en la primera
iteración del desarrollo.
Should have (Debería tener): Son los requisitos o funcionalidades importantes pero no críticas. Si es
posible, deben ser implementados después de los elementos "Must have", pero antes que los
"Could have". Estos elementos pueden esperar un poco, pero se consideran esenciales para el éxito
final del proyecto.
Could have (Podría tener): Son los requisitos o funcionalidades deseables pero no esenciales. Estos
elementos son opcionales y pueden ser considerados para futuras versiones del producto si el
tiempo y los recursos lo permiten.
GFPI-F-135 V02
Won't have (No debería tener): Son los requisitos o funcionalidades que se han decidido
explícitamente no incluir en el proyecto actual. Estos elementos pueden ser considerados para
futuras versiones, pero no son prioritarios en el contexto actual del proyecto.
Tema 3: Construye las historias de usuario a través del storytelling en las tareas del backlog
Ya contamos con el listado de requerimientos ahora vamos a definir las historias de usuario para validar
internamente cada una de ellas, este insumo nos servirá para exponer todo nuestro trabajo directamente al
Interesado
GFPI-F-135 V02
Historia de Usuario 1: Como usuario nuevo, quiero poder
registrarme en TaskMaster para comenzar a gestionar mis
tareas.
Y como uso el Storytelling adicional para tareas importante, técnica de contar historias, puede ser una
herramienta poderosa no solo para crear historias de usuario, sino también para comunicar la importancia
y el impacto de ciertas tareas dentro del desarrollo de software. Aquí te presento cómo podrías aplicar el
storytelling para destacar tareas importantes:
Las tareas más importantes, que requieren de varios criterios de aceptación contarán con un escenario
especifico así:
Escenario:
María es una usuaria activa de nuestra red social. Ella quiere compartir una foto
de sus vacaciones recientes con sus amigos y seguidores. María inicia sesión en
la aplicación y accede a su perfil. Luego, hace clic en el botón "Publicar" y
selecciona la opción de "Subir Foto". Después de seleccionar la foto de sus
vacaciones en la galería de su teléfono, María escribe un breve título y una
descripción para acompañar la foto. Finalmente, hace clic en el botón "Publicar"
para compartir la foto con sus amigos y seguidores
Escenario 2:
En un soleado día de verano, María, una estudiante universitaria, escucha sobre
una nueva aplicación llamada TaskMaster que puede ayudarla a organizar sus
tareas académicas. Emocionada por la perspectiva de una mayor productividad,
María busca la aplicación en la tienda de aplicaciones de su teléfono. Al
encontrarla, se le presenta la opción de registrarse como nuevo usuario. María
completa el proceso de registro con facilidad, proporcionando su nombre,
GFPI-F-135 V02
dirección de correo electrónico y una contraseña segura. Una vez registrado,
María está lista para comenzar a utilizar TaskMaster y mejorar su gestión del
tiempo.
Criterios de Aceptación:
GFPI-F-135 V02
Planning POCKET:
Tarea DA1: El sistema debe permitir a los usuarios iniciar sesión utilizando su dirección de correo
electrónico y contraseña. PUNTOS 3.
Verificación: Los usuarios pueden ingresar su dirección de correo electrónico y contraseña en los campos
correspondientes y acceder con éxito al sistema.
Tarea DE2: La función de búsqueda debe devolver resultados relevantes basados en la ubicación del
usuario y sus preferencias de comida. PUNTOS 5.
Verificación: Al realizar una búsqueda en la aplicación, los resultados mostrados deben estar geográficamente
cercanos al usuario y deben incluir opciones que se ajusten a sus preferencias de comida.
4. ACTIVIDADES DE EVALUACIÓN
Evidencias de Aprendizaje Criterios de Evaluación Técnicas e Instrumentos
de Evaluación
Desarrollo del Backlog - El estudiante puede identificar y describir - Revisión del backlog
las funcionalidades necesarias para el desarrollado por el
producto. estudiante.
GFPI-F-135 V02
- El estudiante puede priorizar las
funcionalidades de acuerdo a su - Listado de requerimientos
importancia. minimo 50 RF y 20 RNF
5. GLOSARIO DE TÉRMINOS
Backlog: Definición: En el desarrollo de software, un backlog es una lista dinámica de todas las tareas,
funcionalidades, mejoras y correcciones que deben realizarse para completar un proyecto. Estas tareas se
organizan en orden de prioridad y se utilizan como referencia durante el proceso de planificación y
desarrollo del proyecto.
MoSCoW: es una técnica de priorización utilizada en el desarrollo de software para clasificar los requisitos
o funcionalidades en cuatro categorías: Must have (debe tener), Should have (debería tener), Could have
(podría tener) y Won't have (no debería tener). Esta técnica ayuda a establecer claridad sobre qué
funcionalidades son críticas para el éxito del proyecto y cuáles pueden ser pospuestas o excluidas.
GFPI-F-135 V02
Historia de Usuario: En el desarrollo ágil de software, una historia de usuario es una descripción breve y
específica de una funcionalidad o característica del sistema desde la perspectiva del usuario final. Estas
historias se utilizan para capturar los requisitos del cliente y ayudar al equipo de desarrollo a comprender
qué debe hacer el sistema para satisfacer las necesidades del usuario.
Criterios de Aceptación: Los criterios de aceptación son condiciones específicas y objetivas que deben
cumplirse para considerar una tarea o una historia de usuario como completada satisfactoriamente. Estos
criterios definen las expectativas y los estándares que deben alcanzarse para que el trabajo realizado sea
considerado exitoso y aceptable.
6. REFERENTES BIBLIOGRÁFICOS
Construya o cite documentos de apoyo para el desarrollo de la guía, según lo establecido en la guía de
desarrollo curricular
Autor (es)
GFPI-F-135 V02