lunes, 24 de junio de 2013

SMART y MoSCoW: Redactando y priorizando requisitos

La calidad de un producto software asienta sus bases en una correcta toma de requisitos (tanto funcionales como no funcionales). Como ya comenté en un artículo anterior, el coste de la resolución de defectos en la fase de requisitos es mucho menor que en fases posteriores. Y lo que es mejor, en esta fase es posible prevenir muchos defectos en producción.

Existen varios listados de características que tienen que tener los requisitos. Quizás el más famoso es el criterio SMART:
  • Specific (Específico): Los requisitos deben ser claros y precisos y no deben dar lugar a interpretaciones. Los requisitos deben revisarse para eliminar toda ambigüedad en su redacción. Además, cada requisito debe tener un identificador único que permita referirse a él de forma unívoca.
  • Measurable (Medible): Un requisito del tipo "La página web debe ser visulamente atractiva y fácil de manejar" no es un requisito válido porque describe una característica subjetiva y que por tanto no se puede medir.
  • Attainable (Alcanzable): Un requisito debe ser accesible, realista y técnicamente posible.
  • Relevant (Relevante): Cada requisito debe contribuir a alcanzar los objetivos globales del proyecto y debe estar en consonancia con el resto de requisitos.
  • Time-bound (Acotado en el tiempo): La realización de cada requisito debe tener una fecha máxima de entrega; es decir, deben ser realizables dentro de unos márgenes de tiempo acotados. Esta "T" de SMART también podría significar "Trazable" o incluso "Testable".

Compartir