1. 12+1 cosas que nunca deberíamos de hacer
cuando trabajamos con Requisitos
Jordi Borja – jborja@visuresolutions.com

2. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2

3. 1.- Nunca creas que negocio no sabe lo que quiere
• Negocio SÍ sabe lo que quiere. Quizá no sepa explicarlo.
– Es nuestra responsabilidad…
‒ Conocer el negocio y sus procesos.
‒ Crear el “clima” conveniente para entender sus necesidades.
‒ Identificar correctamente a todos los involucrados
‒ Aplicar técnicas para ser capaces de “entender” lo que quiere negocio.
‒ “Hablar el mismo idioma” que ellos. Validar los requisitos.
‒ No tratar de convencerles de cuáles son sus problemáticas reales.
‒ Proporcionar soluciones factibles y certificadas a sus problemáticas.
‒ Aceptar cambios en los requisitos a medida que cambien las necesidades de negocio.
‒ Proporcionar estimaciones realista.
‒ Definir un proceso maduro de Gestión y Definición de Requisitos.
• Pero negocio también debe conocer sus responsabilidades.
– Facilitarnos el conocimiento del negocio.
– Seguir estrictamente el proceso de requisitos definido.
– Ser precisos cuando proporcionen información... y proporcionarla a tiempo.
– Priorizar de forma objetiva.
– Estar disponibles y ser participativos durante el ciclo de vida de requisitos.
– Revisar y proporcionar feedback.
• 4 factores clave: CULTURA, PROCESO, TÉCNICAS Y HABILIDADES
3

4. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
4

5. 2.- Nunca asumas que el rol del analista está claro
• Definir claramente la diferencia entre las actividades de Gestión de
Proyectos e Ingeniería de Requisitos.
– Diferenciemos entre:
‒ Seguimiento y Control del Proyecto.
‒ Entender las necesidades del sistema a construir y proponer una solución.
– El contacto con el negocio debe ser responsabilidad de ambos roles.
5

6. 2.- Nunca asumas que el rol del analista está claro
• Definir claramente la diferencia entre Analista de Negocio y Analista
de Sistema
– Problema vs. Solución.
– Lo que hay que hacer vs. lo que es más fácil de hacer.
– Primero definamos por completo el problema. Después, que el Analista de
Sistema proponga alternativas de solución a ese problema.
– El Analista de Negocio debe de comunicar a Negocio los pros y contras de cada
alternativa
6

7. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
7

8. 3.- Nunca esperes que el Usuario te de un buen requisito
• Los usuarios tienen que explicarnos cuál es el problema que
necesitan resolver… pero no son expertos en requisitos!
• ¿Qué debemos hacer?
– Conseguir la implicación del usuario.
– Aplicar técnicas para capturar el máximo de información.
– Mantener al usuario en el ámbito del problema.
– Diferenciar los que es necesario y opcional.
– Asegurarnos de que lo que se pide se puede probar y hay un criterio de
aceptación claro.
– Capturar las necesidades de todos los stakeholders.
– Verificar que no hay conflictos y en su caso, resolverlos.
– Validar constantemente con el usuario que la solución que proponemos
resuelve su problema.
8

9. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
9

10. 4.- Nunca ignores la parte social de los requisitos
• La comunicación usuario / analista es clave.
– Disponemos de técnicas para poder mejorar esa comunicación.
– Pero son necesarias también habilidades sociales para resolver los problemas de
comunicación, como…:
‒ Falta de motivación
‒ Falta de tiempo
‒ Tensiones y opiniones enfrentadas
‒ Generalización
‒ Selección
‒ Distorsión
‒ Falta de Liderazgo o Liderazgo imperante.
‒ Falta de confianza
‒ Sobrevaloración del conocimiento
‒ Alcance de acuerdos. Moderación.
‒ Falta de pensamiento analítico
‒ Comunicación oral y escrita
– Algunas de estas habilidades sociales incluyen:
‒ Escucha activa
‒ Asertividad
‒ Persuasión y negociación
‒ Motivación
‒ Empatía , credibilidad y obtención de la confianza.
‒ Colaboración
‒ Compromiso
‒ Comunicación
10

11. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
11

12. 5.- Nunca consideres los requisitos …
• “Completos”
– Asegúrate de que todos los stakeholders han sido consultados.
– Utiliza la técnica adecuada según el contexto.
– Pregunta lo mismo de diferentes formas.
– No te olvides de los requisitos no funcionales
– Separa lo necesario de lo deseable.
• “Aceptados”
– No confíes en que alguien ha revisado un documento.
– Utiliza la técnica adecuada de validación según el contexto.
– Resuelve los conflictos y consigue el consenso
• “Estables”
– Si algo puede cambiar, va a cambiar.
– El cambio no es malo. Lo importante es saber gestionarlo.
– Proporciona información para poder analizar la conveniencia del cambio.
12

13. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
13

14. 6.- Nunca confundas pruebas con calidad
• No hay peor percepción de calidad que un sistema no haga lo
deseado.
• Pruebas = Cumplimiento de una especificación.
– ¿Pero qué ocurre si la especificación no es correcta?
• Es posible probar los requisitos antes de construir los
sistemas
– Técnicas de validación
• Es posible mejorar la calidad del sistema mejorando la calidad
de los requisitos.
– Ambigüedad
– Verificabilidad
– Justificación
– Contradicción / Consistencia
– Atomicidad.
– ….
14

15. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
15

16. 7.- Nunca subestimes la Definición de Requisitos. Ni la Gestión.
16

17. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
17

18. 8.- Nunca gestiones documentos. Gestiona requisitos.
• Los documentos hacen difícil…
– Acceso concurrente a diferentes partes del mismo.
– Versionado individual de los requisitos.
– Acceder siempre a la última versión de la específicación
– Filtrado, reordenación, clasificación.
– Trazabilidad. Análisis de impacto y de cobertura.
– Control de acceso.
– Discusiones individuales sobre requisitos.
– Uso de atributos
– Workflows individuales de los requisitos.
– Obtención de métricas e indicadores.
– Reutilización
– …
• Además, incentivan…
– Requisitos no atómicos.
– Sobre especificación.
18

19. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.
19

20. 9.- Nunca creas que con CMMI ya vas a tener éxito en requisitos.
Process
Contexto Asset
Actual y legislativo Library
Modelos
Madurez Adecuación de procesos
(3.1)
Mejora
Desarrollo de la solución Continua
Fase 3 Fase 5
Requirements
Capability
Model
Evaluaciones Technical Visure
Asset University
Library
20

21. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.
10. Nunca creas que con desarrollos ágiles los requisitos no son
importantes.
21

22. 10.- Nunca creas que con desarrollos ágiles los requisitos no son importantes.
• Los requisitos son el cimiento sobre el
que se construye cualquier sistema.
• Independientemente de la metodología
que usemos, los requisitos son el factor
clave de éxito.
22

23. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.
10. Nunca creas que con desarrollos ágiles los requisitos no son
importantes.
11. Nunca hagas dos veces el mismo trabajo.
23

24. 11.- Nunca hagas dos veces el mismo trabajo.
• Define un proceso para crear catálogos de requisitos reutilizables.
– Los requisitos no funcionales pueden ser un buen comienzo.
– Los requisitos funcionales pueden reutilizarse en…
‒ Componentes reutilizables.
‒ Familias de producto y variantes.
• Mantén trazadas al catálogo de requisitos las pruebas asociadas.
– Los procesos de certificación se basan en ello!
• Reutiliza GRUPOS de requisitos, no requisitos individuales.
– El copy/paste o la referencia no son suficientes
24

25. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.
10. Nunca creas que con desarrollos ágiles los requisitos no son
importantes.
11. Nunca hagas dos veces el mismo trabajo.
12. Nunca compres una herramienta si no tienes proceso. Ni al revés!
25

26. 12.- Nunca compres una herramienta si no tienes proceso. Ni al revés!
26

27. Agenda
1. Nunca creas que negocio “no sabe lo que quiere”.
2. Nunca asumas que el rol del analista está claro.
3. Nunca esperes que el usuario te de un buen requisito.
4. Nunca ignores la parte social de los requisitos.
5. Nunca consideres los requisitos “completos”, “aceptados” o “estables”.
6. Nunca confundas pruebas con calidad.
7. Nunca subestimes la Definición de Requisitos. Ni la Gestión.
8. Nunca gestiones documentos. Gestiona requisitos.
9. Nunca creas que con CMMI ya vas a tener éxito en requisitos.
10. Nunca creas que con desarrollos ágiles los requisitos no son
importantes.
11. Nunca hagas dos veces el mismo trabajo.
12. Nunca compres una herramienta si no tienes proceso. Ni al revés!
12+1. Nunca creas que un mundo mejor no es posible…
27

28. 12+1.- Nunca creas que un mundo mejor no es posible…
28

29. 29