14.1 Fundamentos de la validación de requerimientos
La validación de los requerimientos es un proceso que llevan a cabo el cliente o los stakeholders. Su principal objetivo es confirmar la idoneidad de los requerimientos en relación a los resultados esperados por el software. Si existe controversia o algún problema de interpretación se deben realizar los ajustes necesarios antes de proseguir con las siguientes etapas del desarrollo.
“ La validación de requerimientos es importante porque los errores en un documento de requerimientos puede conducir a grandes costos de retrabajos cuando estos problemas se descubren durante el desarrollo o después de que el sistema se encuentra en servicio ”
(Sommerville, 2011)
El retrabajo tiene que ver con ajustes que se tendrían que realizar al diseño y al código, además de pruebas que se tienen que volver a hacer. Cualquier error detectado en etapas posteriores en el desarrollo será más costoso.
Pohl y Rupp (2011) proponen los siguientes conceptos en relación a la validación de requerimientos:
Haz clic en los siguiente conceptos para ver su información
Verificación de los requerimientos no funcionales:
Los requerimientos no funcionales suelen ser más difíciles de validar por lo que es importante que en su redacción incluya la forma en la que se puede confirmar o rechazar su cumplimiento mediante un valor cuantitativo.
Así, por ejemplo, se debe especificar la medida de los requerimientos que expresen las siguientes propiedades:
Propiedad |
Medida |
Rapidez |
Transacciones por segundo. |
Tamaño |
Cantidad de kilobytes, megabytes o gigabytes. |
Fiabilidad |
Tiempo promedio entre fallas. |
Robustez |
Probabilidad de corromper los datos después de una falla. |
Portabilidad |
Número de sistemas. |
Facilidad de uso |
Tiempo de capacitación. |
Firma de Validación
Todo documento de requerimientos debe establecer un mecanismo de aprobación de su contenido, puede ser mediante una firma autógrafa o digital de parte del cliente o de cada uno de stakeholders involucrados en la definición de requisitos del sistema. El documento debe contar también con la firma del equipo de desarrollo.
Es recomendable explicar al cliente o los stakeholders la importancia que tiene su firma en este documento, ya que confirman que los requerimientos están completos y claros, válidos, consistentes, reales y verificables. Es parecido a un contrato que incluye varias cláusulas, en el que se le solicita al cliente la firma de cada hoja con el fin de identificarlo y declarar que está de acuerdo con su contenido.
Este ejercicio le da un sentido de formalidad al desarrollo y obliga al usuario a realizar un ejercicio de revisión de los requerimientos con detenimiento.
El equipo de desarrollo también debe participar en este proceso de validación, ya que permite aclarar cualquier duda o imprecisión en la redacción de los requerimientos. Necesita determinar la factibilidad técnica del documento y establecer con claridad aquellos que no serán parte del desarrollo o que requieren una negociación por el impacto en tiempo o presupuesto.
14.2 Técnicas de validación
Sommerville (2011) propone tres técnicas para validar los requerimientos:
Haz clic en los siguiente conceptos para ver su información
14.3 Negociación de Requerimientos
El objetivo de la negociación de requerimientos es llegar a un común acuerdo entre los stakeholders y el equipo de desarrollo sobre los requerimientos innecesarios, conflictivos o inviables en el proyecto. Es una actividad que debe llevarse a cabo durante toda la etapa de la ingeniería de requerimientos.
Imagen obtenida de http://www.ctr.unican.es/asignaturas/is1/is1-t03-trans.pdf Sólo para fines educativos.
A continuación se describen algunas situaciones en las es necesario negociar los requerimientos que deben ser incluidos o excluidos de un proyecto de desarrollo de software:
- Requerimientos en conflicto:
La definición de los requerimientos puede entrar en conflicto cuando no existe un consenso entre los stakeholders o entre el cliente y el equipo desarrollador, ya sea porque tienen diferentes expectativas de lo que debe hacer el sistema o porque existen requerimientos que impactan directamente el tiempo de entrega o el costo estimado.
Por ejemplo, un usuario puede considerar que para evitar corromper la información de la base de datos el sistema deje de funcionar después de una falla, mientras que otro piensa que ante cualquier falla el sistema debe restablecer
Estas posturas típicas en cualquier proyecto de software generan acaloradas discusiones sobre lo que se consideran puntos que se deben negociar, es decir, llegar a un punto de acuerdo en el que todos ganen.
Cualquier requerimiento al sistema implica un costo y en cualquier proyecto el presupuesto es limitado. Algunos implicarán mayores gastos pues dependerán de más tiempo de implementación e infraestructura tecnológica. Esto se traduce en una limitante: ¿Qué requerimiento debe considerarse dentro del presupuesto?
Considera por ejemplo la postura que pueden tomar las siguientes personas en el desarrollo de un mismo sistema: El cliente desea que el sistema abarque el 100% de sus requerimientos y a la vez que su implementación sea de bajo costo y en corto tiempo. La empresa desarrolladora prefiere obtener mayores ganancias con un esfuerzo menor y con el tiempo suficiente para generar el producto que espera el consumidor.
Estrategias de negociación de requerimientos Algunas estrategias que puede llevar a cabo el ingeniero de requerimientos son las siguientes:
Información / Debate / Resolución
Consiste en los siguientes pasos.
- Información: Recopilar toda la información en relación a los requerimientos a negociar con el objetivo de aclarar los pros y contras del problema.
- Debate: Se exponen las posturas tanto a favor como en contra.
- Resolución: Se llega a un acuerdo consensuado entre los stakeholders o se lleva la problemática a niveles superiores en la organización para que se tome una decisión.
Dividir el proyecto en fases
En la práctica, los proyectos de desarrollo rara vez incluyen el 100% de todos los requerimientos sugeridos por el cliente, una forma de negociar es dividirlos por fases. En la primera se considera incluir los requerimientos críticos o indispensables, mientras que los menos importantes se pueden transferir a una o varias posteriores.
Cada fase se considera un proyecto independiente, por lo que al terminar una, la siguiente inicia como uno nuevo, en el que se vuelven a revisar los requerimientos y se establecen sus propios criterios de evaluación.
