La propiedad más importante de una especificación de requerimientos es que sirva como canal de comunicación entre los participantes en el proceso de ingeniería de requerimientos. Para ello, es necesario pensar en la audiencia a la que van dirigidos los requerimientos, de forma que para comunicarse con los clientes y usuarios los mejor es utilizar requerimientos-C
y para hacerlo con los desarrolladores lo mejor es usar requerimientos-D.Las propiedades deseables de los requisitos son:
- Correcta: Una especificación de requerimientos es correcta sí y sólo sí todo requerimiento contenido en ella representa alguna propiedad requerida por el sistema a desarrollar.
- No ambigua: Una especificación de requerimientos es no ambigua sí y sólo sí todo requerimiento contenido en ella tiene una sola interpretación: glosario de términos.
- Completa: Una especificación de requerimientos es completa si cumple las siguientes propiedades:
- Todo lo que se suponga que deba hacer el sistema a desarrollar está incluido en la especificación.
- Todas las respuestas del sistema a entradas tanto válidas como inválidas están especificadas.
- Todas las páginas, figuras y tablas están numeradas, todas las unidades de medida están definidas, todas las referencias externas son comprobables y no hay elementos por determinar.
- En el caso de que haya elementos por determinar, es necesario conocer la causa de su no determinación y quién es responsable de su solución.
- Es conveniente que los requerimientos estén priorizados por el cliente para considerar una especificación como completa.
- No debe omitirse ningún requerimiento.
- El cliente ha validado el conjunto de requerimientos.
- Si no se especifican todos los requerimientos se incrementa el riesgo de acabar desarrollando sistemas que no satisfagan las necesidades reales de clientes y usuarios.
- Consistente: Una especificación de requerimientos es consistente sí y sólo sí todo requerimiento contenido en ella no está en conflicto con otros documentos de nivel superior. Es consistente internamente sí y sólo sí no existen conflictos entre los requerimientos que contiene. Los conflictos entre requerimientos pueden ser de los siguientes tipos:
- Conflictos de conducta: Dos o más requerimientos especifican conductas distintas del sistema para las mismas condiciones y el mismo estimulo externo.
- Conflictos de términos: Se utilizan términos distintos para referirse al mismo concepto.
- Conflictos de característica: Dos o más requerimientos especifican aspectos contradictorios para la misma característica del sistema.
- Conflictos temporales: Dos o más requerimientos exigen características temporales contradictorias al sistema.
- Especificación internamente consistente: Necesidad de un mismo nivel de detalle y de un mismo estilo de redacción y de presentación de los requerimientos. Otra propiedad relacionada con la consistencia interna es la necesidad de que la especificación esté limitada, es decir, que el ámbito y el contexto en el que se definen los requerimientos esté claramente identificado.
- Verificable: Una especificación de requerimientos es verificable sí y sólo sí existe un proceso finito y de costo razonable por el que una persona o una máquina pueda comprobar que el sistema cumple la especificación de requerimientos. Los procedimientos de observación para comprobar que el sistema cumple los requerimientos son la base para las pruebas de aceptación del sistema por parte del cliente.
- Modificable: Una especificación de requerimientos es modificable sí y sólo sí su estructura y estilo de redacción permite que los cambios se pueda realizar fácil, completa y consistentemente. Para conseguir esta propiedad, la especificación debe estar organizada coherentemente y debe contar con los índices y las tablas de referencias cruzadas oportunas, no debe ser redundante y los requerimientos deben expresarse individualmente y no de forma conjunta. También se considera la necesidad de mantener las distintas versiones de la especificación que se vayan produciendo debido a los cambios, es decir, que la especificación sea configurable.
- Rastreable: Una especificación de requerimientos es rastreable sí y sólo sí para cada requerimiento contenido en ella se conoce y puede referenciarse como origen en posteriores documentos durante el desarrollo, es decir, cada requerimiento puede rastrearse hacia atrás y hacia adelante. Una condición necesaria para que un requerimiento pueda rastrearse hacia adelante es que pueda referenciarse de manera única, normalmente mediante algún tipo de código.
- Anotada con importancia y estabilidad: Para ello, cada requerimiento está anotado con la importancia que tiene su cumplimiento para clientes y usuarios y la estabilidad que se espera del requerimiento, es decir, la probabilidad de que cambie durante el desarrollo. Esto permite en que orden implementarlos en el caso de que se haya acordado entregar versiones sucesivas del producto. Por otro lado, la estabilidad permite a los diseñadores conocer qué grado de flexibilidad deben introducir en el sistema para soportar futuros cambios.
- Independiente del diseño y la implementación: Una especificación de requerimientos es independiente del diseño y de la implementación sí y sólo sí no especifica una determinada descomposición del sistema (arquitectura) ni ningún aspecto de su posible implementación. Sólo deben admitirse requerimientos que limiten la libertad de los diseñadores y programadores en el caso de que el cliente lo solicite explícitamente.
