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:
Rol | Tareas que interviene |
---|---|
Jefe de Proyecto | |
MDA-TR-1.0-REQ-Definir tipos de requisitos funcionales | |
Ingeniero de Requisitos | |
MDA-TR-1.0-REQ-Escribir casos de uso | |
MDA-TR-1.0-REQ-Escribir historias | |
MDA-TR-1.0-REQ-Escribir requisitos no funcionales |
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:
Tipo | Fecha de Entrega | Sumario | Disciplina | Proceso | Label | Version Fijada |
---|---|---|---|---|---|---|
Tarea | Fecha de la reunión | Motivo reunión | Requisitos | REQ-Elicitar Requisitos | REUNION | [Versión del proyecto] |
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:
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
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:
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:
Casos de uso | Historias de Usuario |
---|---|
Necesidad de determinar requisitos de manera precisa antes del comienzo de la codificación | Posibilidad de determinar requisitos durante todo el ciclo de vida del proyecto |
El usuario tiene capacidad de abstracción suficiente para imaginar pantallas y comportamientos precisos de la aplicación | El usuario no es capaz o no necesita una especificación detallada de la apariencia de la aplicación |
El usuario es capaz de definir pantallas y comportamientos | El usuario no está preocupado especialmente por la apariencia final de las pantallas |
El usuario sólo estará disponible un tiempo limitado en el proyecto | El usuario estará disponible durante todo el proyecto |
Los programadores no se van a implicar en el diseño de la aplicación | Existe disponibilidad de los programadores para participar en el diseño de la aplicación |
NOTA: Recuerda que es posible combinar ambos tipos de artefactos en el mismo proyecto. |
---|
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.
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.
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:
Tipo | Sumario | Disciplina | Proceso | Label | Version Fijada | ||
---|---|---|---|---|---|---|---|
Tarea | Escribir Casos de Uso del Sistema | Requisitos | REQ-Elicitar Requisitos | CUS | [Versión del proyecto] |
Nota: | Puedes crear un sólo Jira para todos los casos de uso o un Jira por caso de uso. Eso dependerá del nº de casos de uso, del nº de personas que intervengan en la escritura de los casos de uso y de la dificultad -tiempo que se tarde en escribir- cada caso de uso. Si hay varios jiras, en uno de ellos se debe incluir el trabajo de hacer el documento maestro de Requisitos |
---|
Iniciar la creación de un nuevo Caso de Uso.
Plantilla del Artefacto | SIGLAS | Nomenclatura | Ubicación | ||
---|---|---|---|---|---|
CasoUso | CUS | XXX-CUS-1.2.3-NombreDelCasoDeUso | 2.Requisitos/2.1.Funcionales |
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.
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.
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.
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.
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 ….
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..
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.
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:
Tipo | Sumario | Disciplina | Proceso | Label | Version Fijada | ||
---|---|---|---|---|---|---|---|
Tarea | Escribir Historias | Requisitos | REQ-Elicitar Requisitos | HST | [Versión del proyecto] |
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:
Opción 1. Escribir cada historia en un documento
- Crea una nueva Historia.
Plantilla del artefacto | Siglas | Nomenclatura | Ubicación | Nota |
---|---|---|---|---|
Historia | HST | XXX-HST-1.2.3-Nombre de la historia | 2.Requisitos/2.1.Funcionales |
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.
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.
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.
Artefacto | Siglas | Nomenclatura | Ubicación | Nota |
---|---|---|---|---|
Historias | HST | XXX-HST-1.2.3-Historias | 2.Requisitos/2.1.Funcionales |
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.
Plantilla del Artefacto | SIGLAS | Nomenclatura | Ubicación | ||
---|---|---|---|---|---|
DocumentoDeVisión | VIS | XXX-VIS-1.2.3-DocumentoDeVision | Proyecto/Documentacion/2.Requisitos. |
Plantilla del artefacto | Siglas | Nomenclatura | Ubicación | Nota |
---|---|---|---|---|
DocumentoDeRequisitos | DRQ | XXX-DRQ-1.2.3-DocumentoRequisitos | Proyecto/Documentacion/2.Requisitos | Si el documento maestro de requisitos todavía no existe, crea un nuevo, descargando el modelo, y guardándolo con el nombre adecuado, según estas instrucciones de nombrado. Para más información, puedes visitar la página sobre documentos maestros |
CasoDeUso | CUS | XXX-CUS-1.2.3-NombreCasoUso | Proyecto/Documentacion/2.Requisitos/2.1.Funcionales | Dentro del NombreCasoUso puedes utilizar codificaciones propias de tu grupo si lo consideras necesario, como localización en los menús o cualquier otra codificación. |
Historia | HST | XXX-HST-1.2.3-NombreHistoria | Proyecto/Documentacion/2.Requisitos/2.1.Funcionales | |
RequisitosNoFuncionales | RNF | XXX-RNF-1.2.3-NombreRequisitoNoFuncional | Proyecto/Documentacion/2.Requisitos/2.2.NoFuncionales | |
OrdenDelDía | ORD | XXX-yyyymmdd-ORD-Descripción | /Proyecto/Documentacion/1.GestionProyecto/1.2.OrdenesYactas | |
Acta | ACT | XXX-yyyymmdd-ACT-Descripción | Proyecto/Documentacion/1.GestionProyecto/1.2.OrdenesYactas |
Herramienta | Version | Utilizada en | Descarga | ||
---|---|---|---|---|---|
OpenOffice Writer | 3.3 | Todas | Novell |
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.
NOTA: Todos los tiempos se miden en horas, salvo que se indique expresamente lo contrario. |
---|
Pulsa el botón Search
Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.
Pulsa el botón Search
Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.
NOTA: Si a una determinada reunión van tres personas debemos sumar el tiempo de las tres personas que asistieron. Si todas las personas que asistieron a la reunión introdujeron sus horas en Jira, obtendremos esta métrica correctamente. |
---|
Pulsa el botón Search
Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.
Pulsa el botón Search
Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.
Pulsa el botón Search
Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.