La recopilación de requisitos se interrumpe cuando el tiempo para la recopilación de requisitos es demasiado largo

Ya sea que esté haciendo un proyecto grande o pequeño, su enfoque debería ser algo como esto:

• Descubre lo que quieren los usuarios (ir a hablar con ellos, por ejemplo)

• Cree una versión más pequeña de eso (por ejemplo, sin administración de usuarios, solo con datos ficticios, etc.) y solicite su opinión

• Si les gustó, comience a trabajar para mejorar la funcionalidad (agregue lo que necesite para que esté listo para la producción)

• Si no les preguntaran por qué y qué podría mejorarlo

Repita hasta que el "proyecto" esté terminado.

PD Nunca tendrá requisitos completos antes de haber mostrado algo a sus usuarios varias veces. Es por eso que generalmente es una mala idea tener una "fase de requisitos" más de una semana o dos antes de comenzar a construir. Y al menos el 50% de los requisitos que recibe de los usuarios al principio cambiarán. El porcentaje también puede ser superior a 100 (lo que significa que incluso los requisitos modificados cambiarán)

Nunca tendrá toda la información de los requisitos, así que...

Para este pequeño proyecto puede proponer construir la mejor solución que pueda con los recursos (información, presupuesto y tiempo) disponibles. Cuando la situación evolucione, también lo harán sus opciones.

Si esa no es una opción, es posible que lo estén configurando para fallar.

¿Es esta una práctica común si los requisitos no se pueden recopilar durante un período determinado?

Sin embargo, podría suceder, si no sabes algo, lo adivinarás o lo ignorarás. Si esto es importante para el usuario, es probable que no esté contento a menos que su suposición sea correcta. Las personas que conocen bien un negocio en particular a veces pueden adivinar detalles menores basados ​​en la experiencia previa. Incluso esto puede no funcionar siempre. Por ejemplo, cada banco tiene su propia política cuando evalúa a un nuevo cliente para un préstamo. Si te saltas las reglas o usas los criterios de otro banco, esto no ayuda.

Si no puede cumplir con todos los requisitos, es porque los usuarios no saben cómo responder sus preguntas o porque su equipo no puede hacer las preguntas correctas. En cualquier caso, el proyecto estaría en riesgo. Ciertos requisitos pueden incorporarse gradualmente a una versión futura como sugirió. Sin embargo, esto puede ser arriesgado en algunos casos. Por ejemplo, en un proyecto que usa una base de datos relacional, la falta de una relación de muchos a muchos entre dos tablas requiere trabajo en la base de datos y puede requerir un cambio en la GUI. Un enfoque práctico es:

1. Identifica lo que falta.
2. Identifique por qué no se ha finalizado.
3. Si el problema está en tu equipo, arréglalo.
4. Si el problema es el equipo usuario, identifique claramente el riesgo y el posible costo asociado. Quizás pida un cambio en el equipo de usuarios. Utilice procedimientos de escalada para que el pez gordo se dé cuenta.
5. Si hace suposiciones, documente estas suposiciones cuidadosamente.
6. Obtenga una aprobación de todo el esfuerzo de análisis: las partes buenas y las partes malas del análisis.
7. Recuerde siempre que un análisis incompleto o incorrecto podría acabar fácilmente con cualquier proyecto.

Esto puede ser relevante: Tratar con requisitos incompletos