Buenos y malos requerimientos

Una manera de realizar una buena obtención de requerimientos implica la utilización de técnicas repetibles y sistemáticas para asegurar que los requerimientos del sistema sean completos, consistentes, relevantes, etc.

También implica cubrir las actividades relacionadas con el descubrimiento, documentación y mantenimiento de los requerimientos.

Los atributos individuales a considerar para un buen requerimiento serían:

Correcto. Cualidad que sólo puede ser asegurado por el cliente o usuario.

Posible (factible). Cualidad que requiere conocimiento de parte del área de desarrollo, herramientas disponibles, técnicas, gente y presupuesto que posibilite la satisfacción final del requerimiento.

Necesario. Cualidad que puede ser determinada entre el cliente y el desarrollador en la obtención de requerimientos, con la finalidad de establecer los requerimientos a entregarse para esa versión.

Priorizado. Cualidad determinada entre usuario y desarrollador para establecer en cada requerimiento un nivel de prioridad como: muy importante, absolutamente necesario, importante para la siguiente liberación y opcional.

Claro. Cualidad que se refiere a que sólo puede tener un significado; fácil para leer y entender.

Conciso. Que contenga la información necesaria para continuar con el desarrollo. Asociando historia, costos, programación, tareas, productos, etc.

Verificable (probado, medido). Cualidad que significa que una persona o máquina puede revisar si el software cubrió los requerimientos.

Como conjunto, la especificación de requerimientos de software debería de contar con las siguientes características:

Completo. Cualidad que puede ser asegurada por el cliente revisando que todos los requerimientos significativos se encuentran incluidos (funcionales, desempeño, externos, etc).

Consistente. Cualidad que el desarrollador asegura entre los documentos internos.

Modificable. El cambio en los requerimientos es algo normal.

Rastreable. Cualidad compartida entre cliente y desarrollador en la que el requerimiento establecido puede seguirse desde su establecimiento hasta su entregable como software.

Fuente: Apuntes de Ingeniería del Software de la FCA de la UNAM