Guía de Análisis

Objetivo

Especificar un estándar básico para el proceso de análisis de requerimiento a nivel departamental.

Adquirir conocimiento a alto nivel de lo que se necesita construir.

Lluvia de modelos

En esta actividad haga un sketch de un recurso que le ayudará a explorar una posible solución para una US, que está sujeto a cambios. Se sugiere que realice lo siguiente:

• Diseñar bocetos mano para mostrar la estructura visual de la o las páginas. Los bosquejos deben incluir la distribución de información, los espacios tentativos asignados para texto o imágenes, posible tamaño de texto y localización de botones o inputs. Se busca un boceto mínimo pero suficiente para proporcionar un acercamiento visual a la solución.

Ejemplo:

• Diagramas de casos de uso.

Es posible guardar los documentos tomando fotografías y adjuntandolas (si aplica), no se requiere digitalizarlos.

Path donde se guardará la foto:

Semestre i > [Carpeta de proyecto] > Construction phase > [numero de iteracion] > [Codigo de US] > Analisis

Definición de criterios de aceptación

Los criterios de aceptación son características que indican cuando se culmina una historia de usuario. Se presentan como preguntas que pueden se contestan con “sí” o “no”. Dichos criterios no necesariamente responden si las funcionalidades se cumplen, al terminar el desarrollo de una historia de usuario, más bien si tienen la calidad esperada o se ejecutan de una manera deseada.

        Por ejemplo, para la historia de usuario de iniciar sesión, la pregunta “¿Puedo iniciar sesión?” es un criterio de aceptación, a pesar de que en realidad responde a un requisito fundamental. La pregunta “¿Puedo ver mi nombre en la barra lateral al iniciar sesión?” también es un criterio de aceptación, pero responde más a un caso de prueba. Las preguntas que contemplan requisitos no funcionales como “¿El inicio de sesión es rápido?”, “¿La sesión permanece al navegar entre páginas?” y “¿El inicio de sesión es a prueba de ataques tipo inyección de SQL?”, responden a criterios más allá de la funcionalidad básica. Si no se cumplen, la historia de usuario debería seguir siendo funcional, pero no satisfacería al cliente. ¿Al cliente le sirve mucho un login que sí inicia sesión pero se tarda 5 minutos en cargar? Eso es un criterio de aceptación.

Adicional a los criterios de aceptación que defina, agregue los criterios de esta lista explícita. La función de la lista explícita es especificar criterios de aceptación que todas las historias de usuario deben cumplir:

1. La historia de usuario pasa todos los casos de prueba.
2. El cliente quiere utilizar la solución propuesta.

Para que una historia de usuario se considere terminada, debe cumplir tanto con los criterios de aceptación individuales como los de la lista explícita.

Verificación de análisis

Entre los participantes de la fase de análisis de la historia de usuario se debe verifiquen que se han seguido los pasos aquí descritos. Podrían participar otras personas ajenas al desarrollo de la historia de usuario si se considera necesario.

1. Lluvia de modelos considerando:

1. Los documentos/diagramas hechos sirven para entender la user story.
2. Foto de la lluvia de modelos en la documentación de la US.

2. Criterios de aceptación

1. Tienen que satisfacer las necesidades del cliente
2. Definen cuando la user story ya está terminada
3. El cliente puede definir los criterios para que la solución a la historia de usuario cumpla con sus expectativas
4. Contiene los requisitos de explicit list
5. Describe los quality attributes que se deben considerar

Validación de análisis

Consulte con el Product Owner si el análisis se ajusta a las necesidades del cliente. Es posible agregar como un un punto más al checklist.