Mejorar los requisitos
Idealmente, todos los requisitos serían perfectos e implementables, pero la realidad es que algunos necesitarán perfeccionarse, consolidarse o eliminarse para que tenga un conjunto sólido de requisitos. Al evaluar cada requisito, puede buscar áreas de mejora.
Durante la evaluación, considere plantearse las siguientes preguntas:
¿Los requisitos son claros y completos?
¿Existen brechas que usted sabe que deberán abordarse pero que no están capturadas en los requisitos?
¿Se han incluido todas las necesidades regulatorias y de cumplimiento?
¿Este requisito es un duplicado de otro y debería consolidarse?
¿El requisito incluye componentes que están fuera del ámbito?
¿El requisito incluye diseño o implementación específicos?
¿El requisito especifica cómo el sistema heredado gestionaba el problema, no el problema comercial real?
Los requisitos están destinados a explicar el problema que debe resolverse, no cómo resolverlo. La resolución del problema ocurre al examinar todos los requisitos y asignarlos a una solución como parte del proceso de diseño. Los usuarios que proporcionan los requisitos no deberían necesitar saber cómo se resolverá el problema cuando proporcionen información sobre un requisito.
Ejemplo: incluye detalles de diseño
Este ejemplo describe un requisito que incluye detalles de diseño.
El administrador de la cuenta del cliente recibirá una notificación por correo electrónico desde un flujo de Microsoft Power Automate que se activa en la creación de un nuevo caso en Dynamics 365 cuando es el propietario de la fila de la cuenta en Microsoft Dataverse.
Este requisito podría haberse expresado de manera más simple, por ejemplo: Como administrador de cuentas de clientes, quiero recibir una notificación cuando mi cliente haya abierto un nuevo caso.
Cuando sea posible, trate de llevar el requisito a qué, quién y por qué, y evite incluir cómo se hará en la nueva solución. Al elevar la discusión a la necesidad empresarial, obtendrá una comprensión más clara del problema que debe resolverse. En muchos casos, podría estar disponible una mejor manera de implementar el requisito que la forma en que se hizo en el sistema heredado.
Ejemplo: faltan detalles
Este ejemplo describe un requisito al que le faltan detalles.
Las cuentas no tendrán un límite de crédito alto durante su primer año como cliente.
Tal como está escrito, este requisito no se puede implementar porque no se sabe cuál es el límite y qué se considera alto. Además, este aspecto haría que el requisito no fuera comprobable. El requisito real para un límite podría ser tan simple como un valor fijo de 2 millones USD, o podría ser más complejo, como un límite para cada región. Esto último hace que la complejidad general del requisito sea mayor. Si bien este ejemplo es simple, imagine que si fuera un requisito más complejo. La falta de claridad puede afectar al ámbito y los recursos del proyecto.