La Ingeniería de Requisitos (I)

Hace mucho tiempo, en un despacho muy muy lejano...un grupo de investigadores informáticos se cansó de hacer las cosas sin pensar, y dijeron: ¿porqué no pensamos? entonces nació la ingeniería de requisitos.

Bromas a parte, la ingeniería de requisitos es una parte muy compleja y con una relevancia extrema en el desarrollo software, siendo un pilar fundamental en ciertas metodologías, como el desarrollo de modelo en cascada (las metodologías ágiles no tienen requisitos, tienen historias de usuario, pero eso es otro cantar).

Realmente lo que hace es definir un proceso y su objetivo es facilitar la comprensión de lo que el cliente quiere, porque ¿el cliente sabe lo que quiere? lamentablemente en un gran porcentaje, el propio cliente va desarrollando sus ideas iniciales a medida que nos va contando como sería su aplicación o peor aún (y con más frecuencia) según vamos desarrollándola.  Básicamente la ingeniería de requisitos nos intenta dar una idea de lo quiere:

- Analizando sus necesidades: es altamente importante y urgente que desde el día uno hablemos con el cliente, dejando negro sobre blanco lo que quiere y dando nuestro feedback sobre cada una de sus peticiones.

- Confirmando su viabilidad: a veces nos piden cosas imposibles o que si pudieran implementarse realmente no tendrían un buen rendimiento.

- Negociando la solicitud: la pasta. Ellos tienen que saber lo que les va a costar cada segundo de nuestro tiempo y hay que ser honestos, porque sino los tiempos de desarrollo se salen de madre y luego vienen los lamentos, que por cierto esta es una técnica muy utilizada (la de adelgazar presupuestos) por las empresas cuando hay un concurso o una licitación de un proyecto software. Así pasa luego que no cumplen el contrato, se salen de tiempo y caen horas extras y lo peor de todo, es que ya estaba planificado.

- Especificando la solución sin ambigüedad: hay que ser claros, no podemos andarnos por las ramas cuando estemos realizando el requisito porque esto puede influir en toda la cadena hasta llegar al programador. Las cosas tienen que quedar muy bien redactadas y documentadas.

- Validando y Gestionando requisitos para que el sistema pueda ser operativo: lógicamente hay que gestionar los requisitos como elementos individuales, espaciados en el tiempo y bajo unas directrices específicas. No podemos dejarlo todo para el último día antes del desarrollo, tenemos que saber cuando ejecutarlos de manera precisa.

Hasta aquí la primera entrega de la Ingeniería de Requisitos. Saber un poquito más sobre este área es bueno desde todas las escalas cuando se desarrolla software porque obtienes una visión global del sistema y sus procesos, nos vemos en la siguiente.