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