1. Missing Requirements
Miguel Tomico

2. missing ['mɪsɪɳ] adjetivo
1 ausente
2 (persona) desaparecido,-a, dado por muerto/a
3 (objeto) perdido,-a
2

4. Origen de los ataques informáticos
Con respecto a la seguridad, utilizamos:
• Antivirus
• Firewalls
• Encriptación (SSL)
• Restringimos el acceso a los CPD
Sin embargo…
75% de los ataques están dirigidos a la capa web
4

5. Consecuencias de los ataques informáticos
• Robo o alteración de información
• Fuga de información
• Fraudes
• Deterioro de niveles de servicio
• Imposibilidad para entregar servicios
• Robo de identidades
Producen…
Pérdida de credibilidad o confianza (imagen), de ingresos
(finanzas), de oportunidades (posicionamiento) o
incumplimiento de regulaciones (legalidad)
5

6. Impacto de los defectos de seguridad
Actualmente existen:
• Guías de codificación de aplicaciones web
seguras (OWASP)
• Herramientas avanzadas de pruebas
automáticas de seguridad
A pesar de ello…
2/3 de las aplicaciones web son vulnerables!
6

7. ¿Por qué no se introducen técnicas y herramientas de seguridad?
Siendo el problema tan antiguo y tan crítico, existiendo técnicas y
herramientas eficaces y bien conocidas…
¿Por qué no se utilizan en los proyectos?
7

8. ¿Por qué no se introducen técnicas y herramientas de seguridad?
• Por presupuestos y plazos ajustados
• Por olvido o “dado por supuesto”
• Por no considerarse necesario
En definitiva…
Por requisitos ausentes o incompletos!
8

9. Tipos de requisitos No Funcionales
 Interfaz  Verificación
 Fiabilidad  Documentación
 Disponibilidad  Portabilidad
 Rendimiento  Operacional
 Mantenimiento  Pruebas
 Calidad  Seguridad
 Administración  Escalabilidad
 Arquitectura  Coste
 Accesibilidad  Recursos
 Cumplimiento de  Usabilidad
estándares
9

10. Principales motivo de fracaso de los proyectos
...el mayor motivo de fracaso de los proyectos es por:
Falta de
recursos Falta de apoyo
Falta de involucración
11% ejecutivo
del usuario Expectativas
9%
12% no realistas
10%
Requisitos
incompletos
13% Cambios de
reqs/especs
9%
Otros Ya no es necesario
20% Falta de planificación
8%
8%
Fuentes: Standish Group
www.rm2go.com
Scientific American
10

11. ¿Qué podemos hacer para mitigarlo?
11

12. Consejos para mitigar la ausencia de requisitos
• Identificar todos los stakeholders
• Utilizar repositorios compartidos
– Consultar los tipos de requisitos que suelen aparecer en proyectos
parecidos y revisar si todos ellos se han tenido en cuenta
– Utilizar plantillas. Checklists.
– Reutilización de requisitos
3. Conseguir una mayor implicación de los usuarios finales
– Cursos de concienciación sobre la importancia de hacer una buena
gestión de requisitos y el coste de no hacerlo
– Formar a los analistas en técnicas de comunicación
4. Establecer revisiones y compromisos
– Firma de baselines
12

13. Consejos para mitigar la ausencia de requisitos
1. Incluir el tiempo necesario para una correcta gestión de
requisitos en el plan del proyecto
– Considerar la elicitación como un proceso iterativo
2. Revisiones
– Con expertos en el dominio
– Por terceros ajenos al proyecto
– Peer reviews
3. Utilizar prototipos
– Como complemento a los requisitos
13

14. Hemos incluido todos los tipos de requisitos de manera completa.
¿Hemos terminado?
14

15. 15

16. Modelo en V
16

17. Consejos para mitigar la pérdida de requisitos
SI. Los requisitos se pueden perder.
– En sistemas críticos, Requisitos perdidos  Vidas perdidas!
• La solución: Trazabilidad
17

18. Consejos para mitigar la pérdida de requisitos
¿Y qué hay de los cambios en los requisitos? ¿Cómo asegurar
que no “se pierden”?
• La solución: Enlaces sospechosos
18

19. Consejos para mitigar la pérdida de requisitos
Existen otros mecanismos para detectar cambios en requisitos:
Comparación de la especificación completa (líneas base)
Comparación de versiones de requisitos individuales
Workflows y notificaciones
19

20. Conclusiones
 El mayor motivo de fracaso de los proyectos es por requisitos
incompletos o ausentes
 Evitarlo está en nuestra mano
 Dar a la fase de elicitación la importancia que merece
 Incluirla en el plan como un proceso iterativo
 Identificar todos los stakeholders e implicar a los usuarios
 Las herramientas pueden ayudarnos
 Utilizar plantillas. Crear catálogos de requisitos reutilizables
 Utilizar prototipos
 Hacer revisiones por expertos y por personal ajeno
 Una estricta trazabilidad asegura que no se “pierdan”
requisitos por el camino
 Utilizar técnicas y herramientas para detectar cambios en los
requisitos
 Enlaces sospechosos, comparación de baselines
20

21. Missing Requirements
Miguel Tomico