Lo que no deberíais hacer si redactáis requisitos. Caso práctico: el pliego de la web del senado

Para redactar el pliego de subcontratación de la nueva web del senado, hubiese sido de gran ayuda haber utilizado cualquier libro básico de ingeniería del software, el Presman, o el Code Complete, y su checklist de requisitos, u esta otra checklist de Construx que a mi me gusta especialmente. Hay decenas. E incluso, como poco, podría haberse utilizado la Wikipedia.
En cualquiera de los anteriores vienen bien claramente explicadas las cualidades mínimas que debe cumplir un buen requisito. Y en todos ellos nos hablan de que un requisito debe ser no ambiguo (preciso, única interpretación), simple y atómico, verificable, completo (contener la información necesaria). Y muchas otras cualidades más, pero, para el objetivo del post, con las anteriores es suficiente.
Ya comenté en su día que no hay datos suficientes para valorar si 500.000 € es mucho o poco para hacer la web del senado. Pero en lo que si quería aportar mi humilde ayuda es en las mejoras que podría haber tenido el pliego…

Srs. que hacen los pliegos públicos para subontratar desarrollos software: Los requisitos deben ser no ambiguos, atómicos, verificables y completos (si no luego pueden venir los problemas)

– “La página web finalmente obtenida deberá permitir que toda su funcionalidad esté disponible utilizando los principales navegadores del mercado, como Explorer, Firefox, Opera y Chrome.” (pág. 8)
– “La solución deberá ser multiplataforma, encontrándose certificada para plataformas Linux, AIX y Windows.” (pág. 9)
– “Dada la naturaleza de este sistema de información, es requisito indispensable que la solución trabaje en alta disponibilidad.” (pág. 11)
Los anteriores son sólo algunos ejemplos extraídos del pliego, sólo algunos ejemplos de requisitos ambiguos, no atómicos, difícilmente verificables y que no están completos. Por ejemplo:
– ¿Qué versión de Firefox o de los otros navegadores? ¿Qué versión  de “plataformas” Linux y demás? Porque de unas versiones a otras hay enorme diferencia.
– ¿Alta disponibilidad? ¿en qué  porcentaje de tiempo de funcionamiento / año? ¿un 90%? ¿98%? La diferencia es tremendamente enorme.
Los anteriores consejos debieran tenerse en cosideración para muchos otros requisitos, como, por ejemplo «Arquitectura escalable», «Solución orientada a servicios», «Servicios Web 2.0» o «Solución modular», entre otros muchos.

Srs. que hacen los pliegos: Es imprescindible especificar los requisitos de calidad software

Convendría recordar aquí la deuda técnica, los costes de la no calidad, o que al final la mala calidad alguien la paga, el cliente o el proveedor, o porque el estado debería ponerse en serio a controlar la calidad del software que subcontrata.
¿Qué mínimos deben cumplir los fuentes? Complejidad ciclomática, estilo de codificación, código repetido, etc. ¿Qué pruebas, verificaciones y validaciones se requerirán? ¿en qué cobertura? ¿Qué tiempos de respuesta? ¿capacidad?
También hubiese sido deseable acotar la calidad del proceso con el que se construirá el software. Costes de un mal proceso de desarrollo software. Si desarrollas mal estás perdiendo dinero
Pero en todo el pliego la palabra calidad aparece sólo una vez…. “fotos de alta calidad”.

Terminando…

No queriendo extender más el post, no he tocado otros temas tan importantes como la seguridad, etc.
Puede que quizás, yo no tengo la certeza, la idea era que fuese el proveedor quien terminase y especificase los requisitos. Lo digo a tenor de esta frase del pliego: ”El licitador incluirá […] el detalle de los requisitos funcionales”. Sí eso es así, no se que me da más miedo, si requisitos mal especificados o que sea el proveedor el que le hace los requisitos al cliente.
Ya sabes, comparte y tuitea, y me ayudas a compartir el conocimiento.