Requisitos de la interfaz de usuario en las historias de usuario

No estoy seguro de si esto debería estar en el foro ux.stackexchange o aquí.

Como parte de un proyecto Uni, el cliente nos ha proporcionado un resumen de características obligatorias y opcionales, a partir de las cuales tenemos que construir historias de usuario. Uno de los requisitos obligatorios es que cada tipo de cuenta debe tener un diseño de interfaz de usuario diferente.

¿Cómo divide esto en una historia de usuario y funcionalidad antes de que comience el desarrollo? ¿Podría ser simplemente una historia de usuario de alto nivel que se desglosará más adelante? Si es así, estoy un poco confundido en cuanto a lo que diría el 'para que...'.

Vale la pena señalar que tenemos que seguir la estructura de historia de usuario convencional.

Posible duplicado, al menos vale la pena leerlo: pm.stackexchange.com/questions/20239/…
El enlace se refiere a las historias en descomposición, pero mis preguntas se centran en el tema de los requisitos de la interfaz de usuario y cómo capturar eso en una historia.
¿Hay un valor comercial asociado con cada tipo de cuenta que tiene un diseño de interfaz de usuario diferente?
@BarnabyGolden Solo lo requiere el cliente y realmente no ampliaron ningún valor comercial
Eso hace que sea difícil responder a la pregunta. La parte 'para que...' de una historia de usuario generalmente se refiere al valor que la empresa obtiene al completar la historia. Podría imaginar algo como: "Como usuario de un sitio web, quiero identificarme fácilmente. He iniciado sesión como superusuario para no eliminar accidentalmente una página". Pero sin saber lo que quiere el cliente es difícil completar la historia.
@BarnabyGolden para el ejemplo que acaba de dar, ¿no funcionaría eso solo si una persona tuviera dos niveles de acceso?
Supongo que es realmente culpa mía y de mi grupo no cuestionarlo.
Sí, solo funcionaría si tuvieran múltiples niveles de acceso. Puede ver por qué las historias generalmente las escriben los propietarios de productos o las partes interesadas en las organizaciones. Es difícil escribir historias centradas en el cliente sin mucho contexto sobre los requisitos.
Para ser honesto, escribí la mayoría de las preguntas ya que ciertos miembros del grupo realmente no entienden/ven el sentido de la recopilación de requisitos y no me di cuenta de ese requisito.
@BarnabyGolden Gracias de todos modos, le preguntaré a mi supervisor para ver si puedo obtener alguna función/contexto para esos

Respuestas (3)

Existen diferentes tipos de requisitos

  • Los requisitos funcionales describen las características o el comportamiento que el sistema debe admitir.
  • Los requisitos no funcionales describen las capacidades del sistema, como el rendimiento, la mantenibilidad, la seguridad, etc.
  • Las restricciones son requisitos que limitan su libertad de diseño, como requisitos sobre qué pila de tecnología usar o que debe ser una aplicación web.

Las historias de usuario son excelentes para capturar requisitos funcionales. Son mucho más difíciles de aplicar en requisitos no funcionales y absolutamente imposibles para restricciones. Esto se debe a que las restricciones y ciertos tipos de requisitos no funcionales afectan a todas las historias de usuario. No se pueden trabajar solos y nunca se puede decir que están "terminados".

El requisito de que los diferentes tipos de usuarios deben tener una apariencia diferente para su interfaz de usuario es un tipo de requisito de restricción, porque no describe algo que beneficie al usuario del sistema (a menos que haya otros requisitos que agreguen contexto para hacer los beneficios son claros), pero restringe su libertad en el diseño del sistema.

Como las restricciones no se prestan para el formato de historia de usuario, le aconsejo que etiquete claramente el requisito como una restricción y no intente volver a escribirlo como una historia de usuario.

Creo que esta respuesta muestra bien lo que podrías hacer. Primero hazte estas preguntas:

¿Esta historia, por sí sola, entrega valor?

¿Hay alguna manera posible de hacer algo menos y aún así ofrecer valor?

Si la respuesta a la primera es 'no', entonces lo has desglosado demasiado... o es algo en lo que no deberías estar trabajando en absoluto. Si la respuesta a la segunda es 'sí', entonces no la has desglosado lo suficiente.

Una vez que tenga una historia de tamaño mínimo que, por sí misma, proporcione valor, todo lo que necesita hacer es responder (y documentar en la historia) las siguientes dos preguntas:

¿A quién aporta valor esta historia?

¿Cómo aporta valor esta historia?

Si no puede responder ninguna de esas preguntas, es posible que desee volver a visitar la pregunta "¿Esta historia, por sí misma, entrega valor?".

Probablemente crearía historias de usuario separadas para capturar cada tipo de cuenta único y su diseño de interfaz de usuario relacionado, criterios de aceptación y dependencias. De esta manera, podría ejecutar cada historia por separado y realizar un seguimiento de la finalización exitosa de cada tipo de cuenta.

Si hay algunos artefactos de código comunes que cada historia puede usar y desarrollar, separe ese trabajo en su propia historia y ejecútelo primero.

Este desglose le permitiría a su equipo de control de calidad probar cada IU de tipo de cuenta único por separado y determinar si el trabajo está completo y cumple con los criterios de aceptación.

¿Están los criterios de aceptación vinculados a la definición de hecho?
Los criterios de aceptación son las cosas que se han pactado y deben exhibirse en la entrega final de la historia. Estos también pueden incluir requisitos negativos (cosas que se supone que el software no debe hacer). Los criterios de aceptación también pueden ser utilizados por su equipo de control de calidad y durante la demostración para la aceptación por parte del propietario del producto.
Requisitos de la interfaz de usuario en las historias de usuario
RespuestasAquíPolítica de privacidad1y, 0v