¿Cuáles son las mejores prácticas/métodos/herramientas/técnicas para la identificación de conflictos en los requisitos?

Por el bien de esta discusión, requisitos = historias de usuarios (ya que no estoy diferenciando ningún proceso per se y me gustaría deshacerme de cualquier ambigüedad).

Es bastante común tener un conjunto de alrededor de 100-500 requisitos para sistemas pequeños y medianos. Es natural que a uno le lleve un tiempo darse cuenta de qué requisitos están en conflicto (más aún cuando hay más de 1 parte interesada involucrada). O se capturan usando Excel o fichas/post-its o tal vez en alguna herramienta de gestión de proyectos.

Entonces, ¿cómo se aborda la identificación de conflictos dentro de los requisitos? ¿Cuáles son las prácticas que ha empleado y encontrado útiles (tiempo/esfuerzo invertido y conflictos identificados)?

¿Merece la pena siquiera identificar el conflicto o es preferible resolverlo 'cuando llegues' ya que podría llevar a una mala gestión de expectativas si se resuelve más tarde?

NO estoy hablando de conflictos de -ilidad. Esos son pero obvios y deben aclararse antes de la OMI. Estoy hablando de conflictos entre varios requisitos funcionales junto con enfrentamientos funcionales frente a no funcionales.

Algunos ejemplos son:

  • Conflictos de terminología, es decir, diferentes términos utilizados para referirse al mismo concepto
  • Conflictos de estructura (el clásico es 'Fecha') denominado DD/MM/AA y DD/MM/AAAA en otro lugar
  • Conflictos directos: se sabrá que dar un requisito no satisface otro, por ejemplo, para una aplicación de calendario, los intervalos de tiempo de los participantes serán privados, mientras que el organizador de la reunión debería poder ver el tiempo de reunión de todos los participantes antes de decidir un horario de reunión.

El último (directo) puede o no ser negociable, pero identificarlo desde el principio valdrá la pena, en mi opinión.

Es bastante engorroso revisar cada requisito a la vez para identificar conflictos. Lo mejor es dividir el esfuerzo y acelerarlo. Otra estrategia es analizar los requisitos jerárquicamente, pero eso puede ocultar ciertos conflictos que ocurrirían en los 'nodos' inferiores (y esos son los que vienen a morderte más tarde en mi humilde opinión :)

No tengo conocimiento de ninguna herramienta/técnica/mejores prácticas que ayuden a identificar conflictos con una sobrecarga mínima de tiempo/esfuerzo y, por lo tanto, la pregunta. El paso manual anterior es el mejor que conozco. Sí, en un mundo ideal, sería genial que la herramienta arrojara posibles conflictos, pero no sé si alguna herramienta lo hace (o incluso un trabajo razonablemente bueno. ¿Ayuda?)

Entonces, en un mundo ideal (sin máquinas con capacidad de lenguaje natural :), ¿cuál es la mejor técnica para aplicar para la identificación de conflictos (suponiendo que sea intensiva en humanos) y cuál ha sido su experiencia al hacerlo? Si no vale la pena, explíquelo también.

Respuestas (3)

Los requisitos conflictivos o incoherentes no son solo parte de un proyecto de TI, sino que abarcan todo tipo de proyectos. Puede estar seguro, sin importar cuánto se esfuerce por no hacerlo, de que creará una línea de base de requisitos con una serie de requisitos inconsistentes o contradictorios. Además de eso, la solución derivada para cumplir con un requisito podría romper otra solución para otro requisito o hacer que un tercer requisito sea imposible.

No encuentro valor, es decir, dinero mal gastado, para intentar minimizar o eliminar este fenómeno. ¿La razón? Porque a medida que resuelve un conjunto de requisitos, está introduciendo otros conflictos o incoherencias en otro conjunto de categorías y clases de requisitos.

Los conflictos de requisitos son ciertos, y también lo es el cambio. Es por eso que cada proyecto debe tener un proceso de gestión de cambios, de modo que cuando surjan conflictos y el equipo se vuelva más inteligente, se pueda procesar y aprobar un cambio. Por lo tanto, a través de iteraciones y planificación progresiva, los requisitos se solucionan, se hacen consistentes o se eliminan y reemplazan.

Entonces, en lugar de tratar de desarrollar una capacidad para evitar estos conflictos, desarrolle una capacidad poderosa para lidiar con ellos cuando se materialicen.

Estoy de acuerdo: personalmente tenía dudas sobre cómo tratar con ellos en un nivel tan detallado.
Estoy de acuerdo, pero agregaría que para los casos más simples descritos en la pregunta (como formatos de fecha y terminología), se deben tomar decisiones que establezcan un estándar. Luego, este estándar debe documentarse, publicitarse y aplicarse. El valor de un léxico común para discutir cosas complicadas no se puede subestimar y los ahorros de costos de tomar una decisión una vez y ahorrarse la molestia de tener que repetirla constantemente se integran durante el ciclo de vida del producto.

Puedes abordar este tipo de situaciones de la siguiente manera:

  • Conflictos relacionados con procesos como la capacidad de realizar una acción en el sistema. Necesitas estructurar y agrupar tus requisitos o historias de forma lógica.

    => Puede estructurar sus historias en varios niveles: por ejemplo, por área funcional (p. ej., funcionalidad de calendario) y área de proceso (p. ej., creación de citas y reuniones). Esto le permite cortar y trocear sus historias para identificar conflictos.

    => También debe mapear sus procesos, ya que esto le permite recorrer su historia de principio a fin: de esta manera puede identificar conflictos pero también refinar/aclarar historias. En su ejemplo, " los intervalos de tiempo de los participantes serán privados " podría ser " mi tiempo se mostrará solo como disponible o no disponible para otros, con detalles de mis citas y reuniones privadas ", y para " el organizador de la reunión debería poder ver el la hora de la reunión de todos los participantes antes de decidir el horario de la reunión "podría ser en su lugar" como organizador de la reunión, puedo ver la "disponibilidad " de los participantes). Esto también ayudará a facilitar las decisiones sobre reglas comerciales cuando surjan tales conflictos (aquí, ¿la disponibilidad de las personas es pública o no?).

  • Conflictos relacionados con información o datos de referencia , como términos y definiciones, formatos de datos (p. ej., números, monedas, fechas, números de teléfono, etc.) o lista de valores (p. ej., listas desplegables, valores predeterminados, etc.): cree un diccionario de datos de referencia (RDD) que actúa como un documento centralizado y socialízalo entre tu equipo. Cada vez que se identifica un nuevo requisito/historia, si se trata de datos de referencia, el RDD es su punto de control para asegurarse de que no haya conflictos entre una historia y otra (como la que menciona). Tenga en cuenta que el RDD es un documento en evolución, por lo que debe actualizarlo y completarlo a medida que construye las historias. También es un documento muy importante para los desarrolladores cuando codifican el sistema y para la capacitación de los usuarios.
  • Nota : es probable que aún tenga conflictos que pueden persistir y solo se vuelven evidentes cuando codifica o prueba el sistema, pero lo anterior abordaría la mayoría de ellos y, lo que es más importante, los grandes conflictos que deben resolverse antes de comenzar a codificar la historia.
Todavía no tengo claro cómo ayudaría la estructuración jerárquica si los conflictos son entre jerarquías (es decir, el mismo nivel pero diferentes subárboles, por así decirlo). Estructuramos nuestros requisitos de esta manera, pero a veces identificar conflictos entre subárboles se vuelve problemático
¿Podría por favor dar más detalles sobre la estructuración de las historias? Dio un ejemplo de cómo estructurarlos por área funcional y de proceso: ¿se refiere a ambas? No estoy seguro de haber entendido el enfoque de reconciliación que sugirió. ¿Podrías aclararlo por favor?
  • Conflictos de terminología: esto se puede resolver creando un diccionario para el proyecto. Ponerlo a disposición de todas las partes interesadas.
  • Conflictos de estructura (fechas): ignore los requisitos desde la perspectiva del sistema y/o agregue un requisito para permitir que las fechas sean configurables. Tener diferentes formatos de fecha mostrados al usuario realmente no es tan importante... lo que podría ser un gran problema es tener múltiples formatos en el backend de su sistema. Los detalles de implementación no deben estar en los requisitos, así que haga que las cosas tengan sentido en las áreas del sistema en las que tiene control.
  • Conflictos directos: la suposición clave de esta pregunta parece ser que todos los requisitos deben conocerse y corregirse desde el principio. La realidad es que alrededor de 500 requisitos necesitarán perfeccionarse con el tiempo por una variedad de razones. Es posible que ni siquiera termine implementando algunas de esas características que pueden entrar en conflicto, así que ¿realmente tiene sentido preocuparse por ellas ahora? "Fijar" los requisitos de forma incremental no solo hará que sea más fácil analizarlos, sino que también dibujará una línea en la arena, creando un punto de referencia para refinar los requisitos futuros. Elija primero los requisitos de alto valor y diseñe el sistema teniendo en cuenta la modificabilidad de las características que corren un alto riesgo de conflicto/desplazamiento de los requisitos (la buena gestión de riesgos juega un papel clave aquí). Trate de mantenerse una iteración por delante con el análisis de requisitos,
¿Cómo sabría qué requisitos tienen un alto riesgo de conflicto ? ¿Simplemente no sabe qué requisito futuro entrará en conflicto con qué requisito? Todo podría ser arriesgado, por así decirlo, haciendo que la gestión de riesgos sea trivial o redundante. No estoy seguro de lo que estás sugiriendo. ¿Podría por favor dar un ejemplo?
@Nupul, mira, no puedes predecir el futuro, así que no te preocupes tanto. Su enfoque debe estar en entregar valor a su cliente hoy. Los requisitos futuros deberán ser examinados a medida que se introduzcan. No hay una respuesta mágica para esto: alguien de su equipo tendrá que asumir la responsabilidad de "apropiarse" de los requisitos, de conocerlos por dentro y por fuera. En términos de gestión de riesgos, "todo podría ser riesgoso", pero no lo es. Busque un enfoque de gestión de riesgos como el paradigma de gestión continua de riesgos de software de SEI para obtener más información sobre cómo identificar y gestionar los riesgos.
¿Cuáles son las mejores prácticas/métodos/herramientas/técnicas para la identificación de conflictos en los requisitos?
RespuestasAquíPolítica de privacidad1y, 0v