Gestión de requerimientos

Agenda Requerimientos SRS Use Cases User stories UATs Gestión de requerimientos

¿Que es un requerimiento? Una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe poseer un sistema o algún componente del mismo para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. Documentación.

¿Porque es tan dificil identificarlos? El síndrome del “si, pero...” El Síndrome de los “Requerimientos Ocultos” El Síndrome del “Usuario y Desarrollador”

Técnicas para identificarlos Entrevistas a usuarios Cuestionarios Brainstorming Observación Workshops de creación de user stories Role Playing Prototipos Brainstorming Es una técnica que nos ayuda a encontrar los “requerimientos ocultos”. Fomenta la participación de todas las partes presentes. Permite a los participantes el discutir las ideas de los demás. Fomenta la espontaneidad, eso es, no se está limitado por restricciones normales. Prototipos: Los prototipos se caracterizan básicamente en Desechables y Evolutivos

Características de los buenos requerimientos Con valor para usuarios o clientes Estimable Correcto Sin ambigüedades Completo Consistente Priorizable Testeable Modificables (Independientes) Fácil de seguir (Traceable) Correcto: Una conjunto de requerimientos es correcto si y solo si cada requerimiento definido representa algo requerido por el sistema a ser construido. No ambiguo: Un requerimiento es no ambiguo si y solo si puede ser sujeto a una única interpretación. La comunidad usuaria como el equipo de desarrollo pueden comprender completamente los requerimientos individuales y la funcionalidad agregada implícita por el conjunto. Completo: Un conjunto de requerimiento es completo si y solo si incluye los siguientes elementos: Todos todos los requerimientos de importancia para el usuario, Funcionales, No Funcionales y Restricciones de Diseño. Estar definidas las respuestas a todos las entradas al sistema. Tener en cuenta valores inválidos. Estar referenciadas todas las tablas, diagramas, etc. Y definidos todos los términos y unidades de medida. Consistente: Un conjunto de requerimientos es consistente si y solo si ningún subconjunto de requerimientos individuales descrito en el mismo entra en conflicto con algún otro. Testeable: Un requerimiento es verificable en forma global si y solo si cada uno de los componentes de requerimientos contenidos en el mismo es verificable. Los requerimientos son verificables si y solo si existe un proceso finito y estimable con el cual una persona o máquina pueda determinar que el software desarrollado cumple con el requerimiento. Si no puede determinarse su cumplimiento, debe reformularse o removerse. Rastreable: Un requerimiento es rastreable si y solo si el origen de cada uno de los componentes de requerimientos es claro y si existe un mecanismo que hace posible el referirse a ese requerimiento en futuros esfuerzos de desarrollo. Modificable: Un conjunto de requerimientos es modificable si y solo si su estructura y estilo son tales que cualquier cambio a los requerimientos puede ser realizado fácil, completa, y consistentemente, mientras se mantiene la estructura y estilo existente del conjunto.

¿Cómo podemos especificarlos? SRS (Software Requirement Specification) Caso de Uso User Stories UATs Es importante expresar el ¿qué? y no el ¿cómo?

SRS Basado en el standard IEEE Std 830-1998, Creado el 1984 y revisado en 1993 y 1998. Incluye: Prácticas recomendadas Diferentes alternativas para organizar una especificación de requerimientos. Descripción detallada de cada sección. Introducción Descripción General Requerimientos Específicos Funcionales, De interfaces externas, De performance, Restricciones de diseño, Atributos de calidad Otros requerimientos.

Ejemplo de Caso de Uso UC001 – Registro asignación turno Actores: Recepcionista Pre-condiciones: El usuario debe de estar registrado y loggeado Post-condiciones: El turno queda asignado en el sistema Flujo Principal: El usuario selecciona la opción de reserva de turnos El sistema solicita nombre del médico que asistirá al paciente El usuario ingresa el nombre del médico del cuál se solicita turno El sistema muestra los próximos 5 turnos disponibles del médico El usuario selecciona alguno de los 5 turnos o pasa al flujo alternativo 1. El sistema solicita datos paciente El usuario brinda datos paciente El sistema registra el turno Flujo Alternativo: “Ninguno de los 5 turnos disponibles es apropiado” El usuario informa que ninguno de los 5 turnos puede ser tomado El sistema muestra otros 5 turnos disponibles con un lapso no menor a una semana entre fecha y fecha de cada turno.

User Stories Describe la funcionalidad que será de valor para un usuario o comprador de un sistema o software. Tienen información sobre: Quien? (rol del usuario) Que? (Objetivo) Porqué? (justificación)

User Story Como un [rol] Quiero que [objetivo] para poder [valor de negocio] Ejemplo: Como un médico de la clínica Quiero consultar historias clínicas para poder dar un diagnóstico más acertado a mis pacientes

User Acceptance Tests (UATs) Son usados para expresar detalles que resultan de una conversación entre clientes y desarrolladores Documentan supuestos sobre la funcionalidad Determinan si la funcionalidad está completamente implementada Deberían ser escritas por el cliente en vez de por el desarrollador (o al menos en conjunto) Son escritas antes de que el desarrollador codee. Si es posible los desarrolladores deben automatizar el testing (ej. FIT & FitNesse)

Gestión tradicional Relevar En base a los requerimientos acordados en la preventa, recopilar más información del cliente, identificando requerimientos funcionales y no funcionales y el fundamento de cada uno de ellos. Analizar El equipo de proyecto (Líder de proyecto + analistas funcionales) evalúa la factibilidad técnica de los requerimientos y en caso de necesitar un mayor detalle puede ser necesario iterar hasta lograr la formalización de los requerimientos acordados con el cliente y usuarios finales. Validar En el caso de requerimientos detallados por el cliente (por ejemplo en el caso de una Licitación) asegurarse que la información suministrada por el cliente es realmente representativa de sus requerimientos y los de los usuarios finales. Esto se logra revisando los requerimientos con los stakeholders, involucrándolos y facilitando los acuerdos entre ellos. Aceptar el compromiso El propósito es establecer la Línea base de requerimientos. Esto implica el acuerdo con el cliente y la aceptación del equipo de proyecto sobre lo que se hará, quien debe hacer cada tarea, cuándo, fechas de entrega. Esta actividad también incluye alcanzar el acuerdo en los criterios de aceptación del producto A partir de esta instancia todo nuevo requerimiento o cualquier modificación a los acordados deberá seguir el procedimiento de Gestión de Cambios. Mantener la Trazabilidad Asegurar la trazabilidad bidireccional entre los requerimientos y los productos de trabajo. Es particularmente necesaria para evaluar el impacto de los cambios a los requerimientos en las actividades y artefactos del proyecto. La trazabilidad debe establecerse desde los requerimientos fuente a los requerimientos de menor nivel y viceversa. Esto permite determinar si todos los requerimientos han sido considerados y relacionar los requerimientos menores con una fuente válida. La trazabilidad también puede cubrir las relaciones con otras entidades como productos de trabajo intermedios y finales, cambios en la documentación del diseño y planes de test. Puede cubrir relaciones tanto horizontales, por ejemplo a través de interfaces, como verticales.

Gestión ágil El involucramiento activo de los usuarios es imperativo Los requerimientos evolucionan a medida que se desarrolla el software La cooperación, colaboración y comunicación entre equipos es esencial. Los requerimientos ágiles son “justos y necesarios”. Alta Prioridad Cada iteración se implementa los PBI más prioritarios Cada nuevo PBI es priorizado y agregado al backlog PBI más detallados Las prioridades pueden modificarse en cualquier momento PBI menos detallados Los PBI pueden ser removidos en cualquier momento Baja Prioridad

Priorizando requerimientos Los requerimientos pueden ser priorizados por: Su valor de negocio Su riesgo Su impacto en otros requerimientos El deseo de utilizarlos La cohesión con otros requerimientos Permiten confirmar que el sistema o componente cumple su propósito.

Referencias “User Stories Applied” Mike Cohn “Managing Software Requirements, A Unified Approach” Dean Leffingwell, Don Widrig http://www.extremeprogramming.org http://www.scrumalliance.org/