¿Cómo muestra a sus clientes/empleadores que usted comprende sus requisitos?Cómo demostrar que comprende los requisitos del proyecto
¿Qué recomienda utilizar? Diagramas de casos de uso? Diagramas de flujo? Data-Flow-Diagrams? ¿Árboles de decisión?
No estoy realmente pidiendo una respuesta muy detallada. Simplemente algo simple para ayudarme a comunicarme con la persona que escribió los requisitos y para ver si ambos están en la misma página.
Normalmente pongo un mazo de PowerPoint bastante temprano en un proyecto, dando una visión general de alto nivel del proyecto, junto con algunos diagramas arquitectónicos (cuanto más simple, mejor) y maquetas de pantalla/mallas metálicas. Luego tengo una reunión de "inicio" para la revisión de los requisitos y hablar sobre el problema comercial y la solución propuesta.
Los diagramas de flujo tienden a confundir a algunas personas no técnicas (es decir, clientes), así como a diagramas de flujo de datos. Los Casos de uso son buenos y comprensibles, así como los requisitos comerciales y la documentación de Requisitos técnicos, es posible que se trate de algún tipo de bocetos de alambre.
Simplemente explico los requisitos en mi propio idioma, proporcionando mis suposiciones y agregando limitaciones.
El requerimiento puede ser "botón se ilumina en verde cuando se hace clic"
pediría "Ok, así que cuando el usuario hace clic en el botón, el color de fondo del botón se ilumina en verde, pero el texto sigue siendo el mismo color ? "
Básicamente provocando que la persona que presenta los requisitos explique cómo ELLOS lo visualizan funcionando.
Realmente depende de qué requisitos está usted hablando.
Pero de todos modos, tenga en cuenta y explique al cliente que el requisito CAMBIARÁ durante la fase de desarrollo y que siempre será una discusión y un compromiso entre costo y funcionalidad. Siendo honesto, brinde más confianza a su cliente.
Creo que la mejor manera de demostrar que realmente entiendes la idea del cliente es construir prototipos.
Por cierto, estuve presente en la última edición de la conferencia de ingeniería de requisitos y en uno de los talleres (MERE), Siemens mostró un software interesante basado en componer un video de la idea del cliente (era para proyectos no limitado al software) solo para garantizar que todos los requisitos se entiendan por completo.
De todos modos, la cosa es que algunas veces es mejor una forma creativa de mostrarlos. No se limite a los diagramas estándar.
Mi función reúne muchos requisitos. La mejor manera que encuentro es un enfoque de dos frentes, hablar a través de una presentación de PowerPoint que lo mantenga todo simple y de alto nivel, y mostrar una Prueba de concepto o una maqueta. Caminar y hablar con el cliente los verá respondiendo con muchos "qué pasaría si" como "¿Puedo arriesgar el color?" esto les da a todos una idea amplia de lo que están obteniendo. Si puede obtener algo con lo que los usuarios pueden tocar y jugar, eso funciona muy bien para descubrir lo oculto.
Luego, vuelva a este nivel alto con requisitos muy detallados de bajo nivel. Deletrea la "i" con puntos y cruza la "t". Haga que los usuarios lean y firmen antes de nada más de lo que el POC está hecho. En general, las palabras con muchas capturas de pantalla funcionan bien.
A menos que los usuarios puedan traer UML y diagramas de flujo de datos, no los use en nada que el cliente vea o firme. Si está firmado por el cliente y usted tuvo que registrar el back-end para cumplir con un "qué pasaría si", tiene que renunciar totalmente a todo.
Lo último es asegurarse de que los clientes puedan hablar con sus propias palabras acerca de sus requisitos y deletrear lo que están obteniendo. Una forma de hacerlo es sentarse en cualquier venta de administración media a la alta gerencia.
No intente engañar al cliente, si quiere que algo cambie en el último momento, explique cuál será el costo, en tiempo y dinero, y pregúntele si esto es totalmente necesario. Hacer esto, a menudo evitará que las personas realicen cambios triviales, y los obligará a pensar por qué quieren el cambio.
Los requisitos son obtener lo que el cliente necesita de lo que dicen que quieren.
Edit- Hasta el punto de mostrar capturas de pantalla temprano, esto a veces requiere un buen PM para que el cliente sepa las escalas de tiempo y dónde está todo. Si el PM ayuda a establecer marcos de tiempo y expectativas decentes, los clientes no se entusiasmarán. Lo bueno de los POC y las capturas de pantalla es que las personas obtienen una imagen de cómo podría ser y, a menudo, eso puede funcionar dentro de sus mentes.
Si desea evitar las capturas de pantalla haga una apariencia de marco de alambre o use una pizarra blanca y 20 minutos de dibujo. Solo recuerde guardar la pizarra como una foto antes de que la limpie.
El pizarrón (y el buen viejo OHP) puede ser una bendición para reunir los requisitos: desarrollar un buen estilo de dibujo claro puede ahorrar horas en los talleres.
He tenido buenas experiencias con la creación de un vocabulario simple, con términos del dominio y sus significados y relaciones, y luego lo reviso y me aseguro de que todos estén de acuerdo en todo.
Escribir y debatir el vocabulario te obliga a pensar, en lugar de solo pensar que "ya lo veremos".
No es una bala de plata, por supuesto, y se debe utilizar junto con otros medios como una especificación de requisitos funcionales y posiblemente un prototipo.
Si les muestra capturas de pantalla desde el principio, ¿cree que el cliente piensa que la mayor parte del trabajo está hecho y se impacienta mientras construye la funcionalidad real? –