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/