Taller de desarrollo de proyectos 2 – Marzo 2009

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.

– Entrevistas a usuarios– Cuestionarios– Brainstorming– Observación– Workshops de creación de user stories– Role Playing– Prototipos

Técnicas para identificarlos

– Con valor para usuarios o clientes– Estimable– Correcto– Sin ambigüedades– Completo– Consistente– Priorizable– Testeable– Modificables (Independientes)– Fácil de seguir (Traceable)

Características de los buenos requerimientos

– SRS (Software Requirement Specification)

– Caso de Uso– User Stories– UATs

¿Cómo podemos especificarlos?

Es importante expresar el ¿qué? y no el ¿cómo?

SRS

– 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:

1. El usuario selecciona la opción de reserva de turnos2. El sistema solicita nombre del médico que asistirá al paciente3. El usuario ingresa el nombre del médico del cuál se solicita

turno4. El sistema muestra los próximos 5 turnos disponibles del

médico5. El usuario selecciona alguno de los 5 turnos o pasa al flujo

alternativo 1.6. El sistema solicita datos paciente7. El usuario brinda datos paciente8. 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.

Ejemplo de Caso de Uso

– 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 Stories

User Story

Como un [rol]Quiero que [objetivo]para poder [valor de negocio]

Ejemplo:

Como un médico de la clínicaQuiero consultar historias clínicaspara poder dar un diagnóstico más acertado a mis pacientes

– 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)

User Acceptance Tests (UATs)

Gestión tradicional

Relevar

Validar

Aceptar el compromiso

Controlar los cambiosMantener la trazabilidad

Fin

Requerimientos acordados en la

preventa

XOR

Requerimientos detallados por el

cliente

Analizar

– 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”.

Gestión ágil

Cada nuevo PBI es priorizado y agregado al backlog

Cada iteración se implementa los PBI más prioritarios

Las prioridades pueden modificarse en cualquier momento

PBI menos detallados

PBI más detallados

Los PBI pueden ser removidos en cualquier momento

Alta Prioridad

Baja Prioridad

– 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.

Priorizando requerimientos

Referencias– “User Stories Applied” Mike Cohn– “Managing Software Requirements, A

Unified Approach” Dean Leffingwell, Don Widrig

– http://www.extremeprogramming.org– http://www.scrumalliance.org/