1. Ingeniería de Requisitos en
metodologías de desarrollo ágiles y
SCRUM
José Manuel Muñoz

2. Agenda
• Introducción
• Metodologías Ágiles
• Scrum
• Requisitos en Scrum
• Un ejemplo: Scrum en IRQA
2

3. La importancia de los requisitos
“The hardest single part of building a software system is deciding
precisely what to build.
No other part of the conceptual work is as difficult as establishing the
detailed technical requirements, including all the interfaces to people,
machines, and other software systems.
No other part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.”
-Fredrick P. Brooks (1986),
“No Silver Bullet – Essence and Accident in Software Engineering”
Proceedings of the IFIP Tenth World Computing Conference: 1069-1076
3

4. Problemas típicos de la ingeniería de requisitos
• El desarrollo y la gestión de los requisitos son un problema de
(versan sobre) comunicación
• Stakeholders y equipos de desarrollo no suelen tener un claro
entendimiento de los requisitos conforme son escritos
• La validación es tardía en el ciclo de vida
• Los usuarios ven el producto en los últimos estadios del proyecto
• Se tiende a “congelar” los requisitos demasiado pronto, lo que
muchas veces termina en que no se construirá lo que la gente
necesita, sino lo que inicialmente pensaban que querían
“No tiene por qué cambiar, la supervivencia no es obligatoria”
Edward Deming
4

5. Metodologías Ágiles
• “Para triunfar el solo planteamiento (planificación) es insuficiente, es
necesario improvisar”
Isaac Asimov - Fundación
• En el año 2001 un grupo de profesionales de la industria del SW
deja de lado los modelos predictivos y adoptan los principios de
agilidad identificados en la década de los 80 por Nonaka y Takeuchi
(The New New Product Development Game, 1986) creando el
llamado manifiesto Ágil (Agile Manifesto)
5

6. Agile Manifesto
http://agilemanifesto.org
Estamos descubriendo formas mejores de desarrollar software tanto
por nuestra propia experiencia como ayudando a terceros. A través
de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
6

7. Agile Manifesto
http://agilemanifesto.org
Estamos descubriendo formas mejores de desarrollar software tanto
por nuestra propia experiencia como ayudando a terceros. A través
de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
7

8. SCRUM
8

9. SCRUM
• Scrum es una metodología ágil que nos permite centrarnos en crear aquello
que aporte más valor al negocio en el mínimo tiempo posible.
• Equipos auto-organizados: El cliente, los usuarios y/o las necesidades del
negocio establece las prioridades. Los equipos se organizan para
determinar la mejor manera de producir las funcionalidades de mayor
prioridad.
• Iterativo: Nos permite rápida y repetidamente inspeccionar el
funcionamiento del software. Aproximadamente cada 2 semanas cualquiera
puede ver el software funcionando y decidir liberarlo o continuar
mejorándolo durante otro sprint.
• Número reducido de artefactos: Los requisitos se capturan en el “product
backlog”.
• Comenzar más tarde: La ingeniería de requisitos no ocurre exclusivamente
al inicio del proyecto sino que es un proceso continuo.
• Número reducido de roles (product owner, scrum master, equipo).
9

10. Requisitos en SCRUM
• Software funcionando sobre documentación extensiva.
• La documentación sigue siendo necesaria (así como los requisitos)
• En SCRUM los requisitos se representan por medio del “product
backlog” y el “sprint backlog”
– Product backlog: Una lista priorizada de funcionalidades con tiempos
estimados para su implementación. Se sitúan en el dominio del
problema Requisitos de Usuario
– Sprint backlog: Lista de tareas definidas por el equipo para un sprint. Se
sitúa en el dominio de la solución. Requisitos de Sistema.
10

11. User Stories
• Es una representación de un requisito de software escrito en una o dos
frases utilizando el lenguaje común del usuario
• Se deben identificar el quién, el qué y el por qué.
– Como (rol) quiero (algo) para poder (beneficio)
• Los User Stories no son por tanto un conjunto de requisitos altamente
documentados sino mas bien un recordatorio para colaborar sobre una
funcionalidad (feature) concreta
• Si bien generalmente recogen funcionalidad pueden también recoger
elementos no funcionales
– Como visitante de la página, quiero poder volver a la página de inicio rapida y
facilmente.
11

12. Requisitos vs User Stories
• Requisitos tradicionales (“shall” statements)
– The system shall provide a user configurable interface for all user and
system manager functions
– The user interface shall be configurable in the areas of:
‒ Screen layout
‒ Font
‒ Background and text color
• User Story correspondiente
– Como un usuario del sistemas o administrador del sistema,
– Quiero poder configurar la interfaz de usuario incluyendo el layout, la
fuente, el color del fondo y el color del texto,
– Para poder usar el sistema de la forma más cómoda posible
12

13. Casos de Uso vs User Stories
• Mientras que un Caso de Uso esta fuertemente estructurado y
cuenta una “historia”, los User Stories describen someramente una
funcionalidad o una necesidad.
• Un User Story podría considerarse como el preludio de un Caso de
uso, enunciando la necesidad antes de que el caso de uso nos
cuente una historia.
• Los User Stories son muy útiles para recoger y priorizar las
funcionalidades de alto nivel.
• Las User Stories pueden evolucionar a casos de uso o requisitos
una vez que se tenga más nivel de detalle
13

14. Resumen
“Software funcionando sobre documentación extensiva“
• Los requisitos siguen siendo necesarios (¿Cómo sabremos si no
que tenemos que hacer?).
• Generalmente recogidos en forma de User Stories en el Product
Backlog.
• Más enfocados a la comunicación.
• Más dinámicos y cambiantes (aunque no durante el sprint).
Y ahora… ¿Cómo podríamos dar soporte a Scrum en IRQA?...
14

15. Scrum en IRQA
15

16. Scrum en IRQA – Product Backlog
16

17. Scrum en IRQA – CU y Pruebas
17

18. Scrum en IRQA – Sprint Backlog
18

19. Informes – Burn Down Chart
19

20. Informes – Burn Down Chart
20

21. Despedida y Cierre
Gracias por su Atención
21

22. Despedida y Cierre
22