Requisitos funcionales, requisitos de contenido y CUJ

Estoy trabajando en un proyecto para crear un nuevo sitio de documentación que albergará documentación sobre un servicio que mantenemos. Estamos creando este sitio de documentación desde cero y escribiendo la documentación de la API desde cero. Comencé tratando de definir los CUJ (recorridos críticos del usuario) y los requisitos para este proyecto.

Al principio, creé una lista de CUJ y, para cada CUJ, enumeré los requisitos relevantes bajo ese CUJ. Así por ejemplo:

  • CUJ 1: Como usuario, debería poder navegar/buscar entre todos los puntos finales de la API.

    • Requisito: el sitio debe proporcionar una lista exhaustiva de todos los puntos finales de la API como enlaces a sus páginas de documentación.
    • Requisito: el sitio debe proporcionar una entrada de texto de formato libre para buscar puntos finales de API por nombre.

  • CUJ 2: Como usuario, debería poder ver la documentación en un punto final de API.

    • Req: El sitio debe proporcionar el nombre del punto final.
    • Req: El sitio debe proporcionar una breve descripción del punto final.
    • Req: El sitio debe proporcionar un ejemplo de solicitud y respuesta.

Me di cuenta de que algunos de mis requisitos tienen que ver con la funcionalidad del sitio (es decir, aquellos dentro de CUJ 1) mientras que otros tienen que ver con el contenido del sitio (es decir, aquellos dentro de CUJ 2). Por ejemplo, el requisito funcional asociado para los requisitos de CUJ 2 podría ser "El sitio debe permitir que los mantenedores escriban documentación en los puntos finales de la API". Esta diferencia es algo confusa para los desarrolladores que solo se preocupan por los requisitos funcionales... ya que eso es específicamente lo que necesitan implementar para el sitio.

¿Otros han encontrado esto antes, y si es así, cómo lo manejó? ¡Gracias!

Respuestas (1)

No sé qué es CUJ (o FR), pero haré todo lo posible para responderte.

  1. Aprenda a escribir requisitos, en general. Ejemplo: "debería" no es una buena palabra para un requisito, se prefiere "deberá".
  2. En términos generales, hay muchos tipos de requisitos. Funcionales, arquitectónicos, relacionados con pruebas (sí, los casos de prueba son en realidad requisitos), requisitos legales (dictados por las leyes del país), reglamentos internos también generan requisitos, estándares nacionales e internacionales, requisitos comerciales, relacionados con el cronograma, etc.
  3. La primera fase, como ya notó, es una fase de lluvia de ideas. Por tanto, cualquier requisito “es un buen requisito”. En una fase posterior, comenzará a refinar, clasificar, agrupar y mejorar los requisitos. Y añadiendo muchos más requisitos.

Esta diferencia es algo confusa para los desarrolladores que solo se preocupan por los requisitos funcionales ...

Los desarrolladores, así como todos los que participan en el proyecto, deben estar capacitados sobre qué son los requisitos y cómo deben manejarse . Y "no me importa" suele ser una buena razón para perder un trabajo;)

En pocas palabras, no solo tendrá requisitos funcionales y requisitos no funcionales, sino que también debe tener requisitos de back-end, así como requisitos de front-end. Algunos de ellos serán incluso sobre la fiabilidad, la redundancia, la gestión de la actualización/ampliación del sistema (sitio)...

Muchas veces, el trabajo de escribir los requisitos es abrumador para una sola persona, y los grandes proyectos tienen equipos completos que se ocupan solo de los requisitos.

Le deseo suerte, ya que parece que su empresa aún no está realmente preparada para tal trabajo.

Lo sentimos, un CUJ es un "viaje de usuario crítico". Actualizaré mi pregunta. Gracias por la respuesta.
Y FR es "requisito funcional".
Requisitos funcionales, requisitos de contenido y CUJ
RespuestasAquíPolítica de privacidad1y, 0v