Dificultades para Definir los Requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Prácticas Sugeridas para Escribir Requerimientos con Calidad

• Mantener sentencias y párrafos cortos. Utilizar voz activa. Utilizar gramática apropiada, ortografía y signos de puntuación. Utilizar términos consistentemente y definidos en un glosario o diccionario de datos.
• Ver si una sentencia de requerimiento está suficientemente bien definida, leída desde la perspectiva del desarrollador.
• Los autores de requerimientos a menudo batallan en encontrar el nivel correcto de granularidad. Evitar largos párrafos de relatos que contienen varios requerimientos. Una guía de granularidad útil es escribir requerimientos que sean probados individualmente. Si usted puede pensar un número pequeño de pruebas relacionadas para verificar la implementación correcta de un requerimiento, está escribiendo probablemente en el nivel correcto del detalle. Si imagina muchos tipos de pruebas diferentes, quizás varios requerimientos han sido agrupados y deben ser separados.
• Tenga cuidado con varios requerimientos que han sido agregados dentro de una simple sentencia. Conjunciones como "y" y "o" en un requerimiento sugiere que varios requerimientos han sido combinados. Nunca utilizar "y/o" en una sentencia de requerimiento.
• Escribir los requerimientos en un nivel consistente de detalles a lo largo del documento. He visto especificaciones de requerimientos que varían ampliamente en su alcance. Por ejemplo, "Un código de color válido será R por rojo" y "Un código de color válido será G por verde" se puede dividir como requerimientos separados, mientras que "El producto responderá a directivas de edición introducidas por voz" describe un subsistema completo, no un requerimiento funcional simple.
• Evitar declarar requerimientos redundantes. Mientras incluir el mismo requerimiento en varios lugares puede hacer al documento más fácil de leer, también hace el mantenimiento del documento más difícil. Las múltiples instancias del requerimiento todas tienen que ser actualizadas al mismo tiempo, no sea una inconsistencia influenciada.