Técnicas
Los equipos de proyecto pueden utilizar distintas técnicas para capturar y gestionar los requisitos. Los elementos de trabajo de Microsoft Azure DevOps y los problemas de GitHub se usan habitualmente para facilitar la colaboración al determinar los requisitos del equipo del proyecto. Además, se ofrecen herramientas que los equipos pueden utilizar y que se especializan en la gestión del trabajo pendiente y la hoja de ruta. Los requisitos se recopilarán en estas herramientas o en un documento de requisitos con un formato narrative ouser story.
Las historias de usuarios se centran en quién es el usuario, qué desea y por qué quiere que el sistema haga una determinada cosa.
Por ejemplo, "Como usuario de aplicaciones de ventas, quiero tener la posibilidad de enviar un descuento a mis clientes por correo electrónico."
Los requisitos a menudo se clasifican en un trabajo pendiente mientras están a la espera de que se les asigne una prioridad en un sprint/iteración de proyecto activo para la implementación. El trabajo pendiente debe considerarse una lista de ideas a la espera de implementación. Debe pensar en un sprint o iteración como un período definido de tiempo o trabajo que se ha agrupado para que el equipo del proyecto lo implemente en la solución.
Mientras planifica un sprint o iteración, es posible que se le pida que ayude a priorizar y estimar la cantidad de trabajo de un elemento de trabajo/problema en el trabajo pendiente. A la hora de estimar el nivel de esfuerzo, los diferentes equipos utilizan distintos enfoques. Algunos usan las horas, mientras que otros usan una referencia como la talla de camiseta. En esencia, a la hora de estimar un elemento, puede categorizarlo como pequeño, mediano o grande. Luego, los equipos usarán el tamaño para ayudar a agrupar los elementos para su implementación en un sprint o iteración.
Los requisitos deben poder implementarse y no han de ser demasiado grandes para completarlos en un solo sprint o iteración. Puede dividir los requisitos grandes en requisitos más pequeños que resulten más fáciles de procesar. Algunas metodologías se refieren al requisito grande como Epopeya, que hace referencia al requisito de alto nivel antes de dividirlo en partes más pequeñas.
Los requisitos a menudo se clasifican como funcionales o no funcionales. Los requisitos funcionales describen lo que debe hacer la solución o sus comportamientos. Los requisitos no funcionales se suelen utilizar para describir aspectos no relacionados con el comportamiento de la solución, como, por ejemplo, los requisitos de rendimiento. Para describir completamente lo que se espera de una nueva solución, debe haber tanto requisitos funcionales y como no funcionales.
Requisitos funcionales
Los requisitos funcionales deben centrarse en el quién, el qué y el por qué del requisito. Por ejemplo "Como representante del servicio al cliente, necesito poder buscar problemas de clientes similares resueltos para encontrar una solución al problema del cliente actual" describe un requisito funcional de Microsoft Dynamics 365 Customer Service.
La mayoría de sus requisitos funcionales provendrán de los usuarios de la solución finalizada.
Puede usar requisitos no funcionales para capturar temas que generalmente interesan a los usuarios, pero que además son importantes para el éxito de la solución. Estos tipos de requisitos suelen cubrir temas como el rendimiento de la solución, la capacidad, la privacidad, la seguridad y el cumplimiento.
Por ejemplo, "El sistema debe manejar 2500 informes de problemas entrantes simultáneos durante las interrupciones" describe un requisito no funcional de Dynamics 365 Customer Service.
Requisitos no funcionales
La mayoría de los requisitos no funcionales provendrán del personal de cumplimiento corporativo o de TI y no de sus usuarios finales.
Los requisitos no funcionales deben ofrecer información clara sobre cómo medir y determinar el éxito. A menudo, los requisitos no incluirán puntos iniciales y finales claros en las mediciones para medir con precisión el éxito. También es común incluir requisitos no funcionales que se escapan de su control, ya que es importante identificar estos requisitos y mitigar el riesgo con el cliente. Un ejemplo de este escenario podría ser un requisito de rendimiento de menos de un segundo en dispositivos móviles en el campo.
A la hora de determinar cómo cumplirlos, los requisitos no funcionales suelen ser responsabilidad del arquitecto de la solución. Sin embargo, un consultor debe conocer los requisitos no funcionales de la solución. En muchos casos, se le puede pedir que implemente un cambio que respalde el objetivo del requisito no funcional.
Es importante que dedique tiempo a asegurarse de que sus requisitos sean de alta calidad y que representen lo que ha acordado entregar. En muchos casos, esta garantía puede marcar la diferencia en el resultado de la implementación de Dynamics 365 tras haber implementado los requisitos.