El principal objetivo de este proceso es determinar las necesidades de negocio del sistema/proyecto a desarrollar para el cliente.

Una vez determinado el tipo de artefacto a utilizar para recopilar los requisitos funcionales, casos de uso, historias, procesos o una combinación de los tres, pasa a elicitar lo requisitos funcionales del sistema.

Los requisitos no funcionales del proyecto también han de ser recopilados en este proceso. Los requisitos no funcionales se refieren a facilidad de uso, fiabilidad, rendimiento, soporte, interfaces, cuestiones legales o cualquier otra cosa.

Los siguientes son los roles participantes en este proceso:

Las principales técnicas para obtener los requisitos funcionales y no funcionales siguen siendo las entrevistas a los clientes, el estudio de sistemas anteriores y estudios de documentación asociada.

Para la realización de entrevistas con los clientes, expertos y usuarios convoca siempre reuniones con un orden del día preestablecido. Envíalo con suficiente antelación y atente a él durante la reunión. Una vez realizada la reunión elabora un acta y envíala a los asistentes para su aprobación.

Tal y como dijimos en el procedimiento de Determinar el alcance no hay que ceñirse exclusivamente a los expertos, aquí es todavía más importante involucrar a los usuarios del sistema y ten en cuenta que existirán distintos perfiles de usuarios.

OjO Por cada reunión, hay que dar en alta un JIRA, por cada participante con los siguientes datos e imputar las horas de trabajo una vez aprobada el acta:

El Jefe de Proyecto dará por cerrada la tarea una vez se apruebe el acta de la reunión.

Antes de elicitar los requisitos funcionales debes tener claro que tipos de artefactos vas a utilizar para recopilar los requisitos. Las opciones son:

• Casos de Uso
• Historias de Usuario
• Ambos

En cualquier caso debe estar claro en esta fase del proyecto. Las principales características de casos de uso e historias de usuario son:

Casos de Uso

Se trata de una descripción detallada de la interacción entre el usuario y el sistema. Enfocada en el funcionamiento visible de la aplicación a desarrollar.

Historia de usuario

Especifican de manera menos formal una funcionalidad, cualidad o característica del sistema a construir. Esta característica normalmente se refiere a algo que proporciona valor al negocio. Está escrita de manera corta y ha de ser complementada con una conversación posterior con el propietario de producto.

Regla nemotécnica: Una historia es una inversión (INVEST), en inglés

• Independiente
• Negociable
• Valiosa para el cliente
• Estimable (en esfuerzo)
• Small (De un tamaño abarcable)
• Testeable

Una vez que tienes claro las principales características de un tipo y otro de artefacto toma la decisión de cual de ellos vas a utilizar. Para tomar la decisión ten en cuenta las siguientes consideraciones:

• Los casos de uso están orientados a la interacción de un usuario con un determinado rol con el sistema. Las historias están orientadas a obtener valor para el negocio (añadir/mejorar las funcionalidades que ofrecen valor para el cliente).

• Para escribir casos de uso necesitas entrevistas previas con el usuario, un esfuerzo intelectual importante por su parte para “Imaginar” la apariencia y el funcionamiento de la aplicación.

• La utilización de casos de uso aconseja realizar prototipos de pantallas, si no de todas, sí al menos de las más significativas.

• Para utilizar historias necesitas una implicación importante por parte del usuario en las reuniones de planificación de sprint, aclarando a los programadores el contenido de la historia hasta que ellos tengan claro lo que el cliente necesita.

• La utilización de casos de uso conlleva que los programadores se limitan a codificar los requisitos especificados en los casos de uso.

• La utilización de historias conllevan una implicación importante de los programadores a la hora de establecer el funcionamiento de la aplicación. Esta implicación se materializa en las reuniones de planificación de sprint.

• La utilización de casos de uso conlleva una participación importante del cliente durante la fase de requisitos, pero menor durante la fase de desarrollo.

• La utilización de historias conlleva la participación del cliente durante toda la fase de desarrollo de manera más activa que cuando se utilizan casos de uso.

• La utilización de historias conlleva la especificación clara junto a los requisitos de criterios de aceptación de las historias, en las que se especifique claramente cual es el funcionamiento/resultado esperado en el software desarrollado.

MUY IMPORTANTE: En ningún caso puedes prescindir de la implicación del usuario a la hora de especificar los requisitos. Tampoco puedes obviar la necesidad de realizar un análisis y diseño previo a la codificación.

A continuación tienes una tabla comparativa entre Casos de Uso e Historias:

1. Apartado 4.5 del PP.

Especifica en el apartado 4.5 Ajustes del Plan de proyecto el tipo de artefacto de requisitos que vas a utilizar.

Para poder escribir los casos de uso necesitas tener múltiples reuniones con el usuario.

1. Convoca tantas reuniones como sea necesario. Envíale previamente el orden del día realizado con la plantilla Orden del día. Consulta las instrucciones acerca de cómo nombrar el documento de órden del día y dónde debes guardarlo.

Los puntos a abordar en el órden del día vendrán determinados por los requisitos identificados previamente en el Documento de Visión. En el proceso Determinar el Alcance se indica cómo rellenar este documento. Los requisitos vienen identificados en el Documento de visión con el prefijo VIS. Incluye en el órden del día los requisitos VIS con los que vas a trabajar.

1. Elabora las actas de las reuniones utilizando la plantilla acta. Consulta las instrucciones para nombrar el acta y dónde guardarla. Envíala a los participantes para su aprobación.

Recuerda que cada caso de uso corresponde a un requisito funcional en el que se especifica la interacción hombre/máquina. Cada uno de los Casos de Uso tendrá un documento independiente.

Por cada participante en esa escritura, crea una una tarea en el JIRA, con los siguientes datos:

Iniciar la creación de un nuevo Caso de Uso.

Sigue las instrucciones de nombrado de Casos de Uso

- Rellena la tabla de cabecera del caso de uso, especificando el proyecto, subsistema si existiese, la fecha en que se está rellenando, la versión del software y el autor.

- Lleva un control de cambios sobre el documento. OjO no confundas el control de los cambios en el documento con las versiones del documento que debe coincidir con la versión del software.

1. Apartado 1.1 del CUS, Breve descripción

Introduce una breve descripción. Importante especificar el usuario, en términos de rol de usurio en la aplicación, por ejemplo, La secretaría del departamento. Redacta este apartado indicando funcionalidad.

1. Apartado 1.2 del CUS, Actores

Especifica el rol del usurio principal ejecutor del caso de uso. Si hay roles secundarios que puedan ejecutar el caso de uso especifícalos, distinguiéndolos del primario.

1. Apartado 2 del CUS, Precondiciones

Especifica en qué estado ha de encontrarse el sistema para poder ejecutar el caso de uso. Por ejemplo. Para poder matricular al alumno el alumno debe estar admitido en la lista de preinscripción.

1. Apartado 3.1 del CUS, Flujo básico

El flujo básico se iniciará siempre por un usuario, pero identificado con el rol que desempeña en el sistema. Se escribirá como un dialogo entre usuario y sistema. Especifica que sucede en el sistema, pero no como. También es importante especificar cual es la información que el usuario introduce en el sistema –nombres, apellidos, direcciones- y cual es la información que devuelve el sistema.

Cuando los flujos alternativos sean muy simples se incluirán en esta zona, pero cuando sean un poco más complicados se incluirán en una sección aparte, la 3.2 del CUS.

Descripciones de tipo gráfico no solo están permitidas, sino que se recomiendan, por ejemplo interfaces gráficas, flujos de procesos, diagramas de flujo, pero recuerda que los usuarios y expertos deben ser capaces de entenderlos

Las acciones realizadas por el usuario y el sistema se escribirán como una lista numerada. Los flujos alternativos, tanto si están escritos junto al flujo principal, como si están en otro apartado harán referencia al punto de la lista en que se desvía el flujo

1.El usuario realiza una primera acción sobre el sistema

2.El sistema le responde de una determinada manera

2.1.Si el sistema ha respondido 1 el usuario hace esto

2.2.Si el sistema ha respondido 2 el sistema hace esto otro

3.El sistema hace esto otro ….

1. Apartado 4 del CUS, Postcondiciones

Especifica en qué estado se encontrará el sistema tras ejecutar el caso de uso. Por ejemplo. Al anular la matrícula fuera del plazo establecido los recibos ya emitidos quedarán pendientes de pago..

1. Apartado 5 del CUS, Requisitos especiales

Un requisito especial es un requisito no funcional específico de un caso de uso, pero que no se puede especificar de manera natural en el flujo de eventos del caso de uso. Ejemplos de requisitos especiales incluyen requisitos legales, estándar de aplicaciones, atributos de calidad, incluyendo usabilidad, fiabilidad, rendimiento o requisitos de soporte.

1. Apartado 6 del CUS, Puntos de extensión

Un caso de uso puede ser extendido por otro que refina su funcionamiento. Por ejemplo, El cliente paga puede ser exendido mediante los casos de uso pago con tarjeta, pago en metálico, etc. En este apartado especificaremos en qué punto de los especificados en el apartado 3.1 o 3.2 se extiende el comportamiento del caso de uso.

La descripción de la extensión puede hacerse aquí si es lo suficientente breve o en un documento de caso de uso aparte.

OJO Finalmente incluye cada documento de Caso de Uso en el documento maestro de Requisitos.

OjO Crea una tarea en Jira para la escritura Historias (Como la escritura de historias es mucho más rápida que la escritura de casos de uso podemos utilizar una sóla tarea para varias historias), por cada participante en la escritura de historias:

Identifica las historias que tienes que desarrollar a partir del Documento de Visión obtenido en el proceso Determinar el Alcance. En el caso en que trabajemos con Historias no existe una conexión tan directa entre requisitos de visión e historias, pero puede servir de guía. La lista de historias del proyecto debe ser revisada por el cliente.

Recuerda que las historias aportan valor al negocio del cliente y funcionalidad completa (puede abarcar más de una pantalla). Cada historia tendrá un documento independiente.

A partir de aquí existen 2 maneras de ejecutar esta tarea:

1. Escribiendo cada historia en un documento e incorporarlas más tarde a Jira
2. Escribir cada historia directamente en Jira e incorporarlas más tarde al documento maestro de Requisitos

Opción 1. Escribir cada historia en un documento

- Crea una nueva Historia.

Sigue las instrucciones para rellenarlo.

El nombre de la historia debe ser lo suficientemente clara para que se comprenda aproximadamente de qué estamos hablado y suficientemente clara para distinguirla de las otras historias. Normalmente, 2 a 10 palabras son suficientes.

- Rellena la tabla de cabecera de la historia, especificando el proyecto, subsistema si existiese, la fecha en que se está rellenando, la versión del software y el autor. El campo Código se usa para tener la trazabilidad en Jira. Cuando des de alta la historia en Jira, anota aquí el código de la historia que Jira le ha dado automáticamente.

- Lleva un control de cambios sobre el documento. OjO no confundas el control de los cambios en el documento con las versiones del documento que debe coincidir con la versión del software.

- Apartado 1 del HST, Notas

Recuerda que una historia es una oportunidad de conversación con el cliente, anota aquellos puntos relevantes que debas comentar con el cliente para aclarar la historia. Más adelante, anota en el apartado 3 los resultados de esas conversaciones. Los detalles vendrán recogidos en el apartado 2, en las especificaciones de las pruebas a las que ha de ser sometido el software.

- Apartado 2 del HST, Cómo Probarlo

Incluye una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Esta descripción puede usarse como pseudo-código para los tests funcionales.

1. Apartado 3 del HST, A tener en cuenta

Tras la conversación ya detallada con el usuario, anota aquí los aspectos relevantes y a tener en cuenta para el desarrollo del software de esta historia.

OJO Finalmente incluye cada documento de Historia en el documento maestro de Requisitos.

Opción 2. Escribir cada historia directamente en Jira

- Crea una nueva Historia en Jira

La descripción de la historia debe ser lo suficientemente clara para que se comprenda aproximadamente de qué estamos hablado y suficientemente clara para distinguirla de las otras historias. Normalmente, 2 a 10 palabras son suficientes.

En el campo requisito introduce el código del requisito de visión del que deriva la historia para mantener la trazabilidad.

En el caso en que introduzcas la historia directamente en Jira, ten en cuenta que debes incluir información relativa a las notas de la historia, el cómo probarlo y cuestiones a tener en cuenta. Introduce toda esta información en la Descripción.

1. Notas: Recuerda que una historia es una oportunidad de conversación con el cliente, anota aquellos puntos relevantes que debas comentar con el cliente para aclarar la historia. Más adelante, anota los resultados de esas conversaciones. Los detalles vendrán recogidos en el apartado en que se recojan las pruebas a las que ha de ser sometido el software.
2. Cómo Probarlo: Incluye una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Esta descripción puede usarse como pseudo-código para los tests funcionales.
3. A tener en cuenta: Tras la conversación ya detallada con el usuario, anota aquí los aspectos relevantes y a tener en cuenta para el desarrollo del software de esta historia.

Una vez introducidas todas las historias haz una query en el Navegador de incidencias para obtener todas las historias introducidas

project = ClaveProyecto AND issuetype = Historia AND created >= yyyy-mm-dd AND created <= yyyy-mm-dd

Selecciona, a la derecha del Navegador de incidencias la Opción Vistas → Word. Esto generará un fichero con todas las incidencias en Word. Guarda ese documento en el mismo lugar y con el mismo nombre que las historias.

OJO Finalmente incluye el documento de Historias en el documento maestro de Requisitos.

Para poder escribir los Requisitos no funcionales, al igual que en los casos de uso, necesitas tener reuniones con el usuario.

Sigue las siguientes instrucciones:

- Rellena la sección “4. Requisitos NO Funcionales” del Documento de Requisitos Maestro.

1. Apartado 4.1: Restricciones de Diseño. Aquí se incluyen aquellas restricciones de diseño que puedan imponerse por estándares, limitaciones hardware, etc.
2. Apartado 4.2: Requisitos Técnicos. Aquí se especifican los requisitos numéricos estáticos y dinámicos colocados en el software o en interacciones de los humanos dentro del software completo.

• Diagrama de Casos de Uso

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja REQ.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Cuenta el número de reuniones realizadas

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos
• Label = REUNION

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos
• Label = CUS

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos
• Label = HST

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Elicitar Requisitos
• Label = RNF

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Entra en el Documento Maestro de Requisitos. En la opción de menú Archivo → Propiedades … → Estadísticas. Réstale 4 páginas al valor que te resulte. Esto es por las páginas de portada que son las mismas siempre.

1. Resultante a partir de las métrica anteriores. Se calcula automáticamente.