Redacción eficaz de documentos de requisitos: una visión general

En todo proyecto de diseño UX, la parte más importante es el proceso de recopilación de requisitos. Esta es una descripción general de algunos de los posibles métodos de recopilación de requisitos.

Un buen diseño tendrá en cuenta todos los requisitos comerciales, funcionales y de usuario e incluso a veces informará sobre nuevas funcionalidades y generará nuevos requisitos, en función de los comentarios y comentarios de los usuarios. Sin una especificación de requisitos hermética a partir de la cual trabajar, gran parte del diseño se deja a suposiciones y subjetividad. Los requisitos encarrilan un proyecto y proporcionan una base para el diseño. Un diseño robusto siempre se relaciona con sus requisitos en cada paso del proceso de diseño.

Aunque hay muchas formas de traducir los requisitos del proyecto, los casos de uso, las historias de usuario y los escenarios son los métodos más utilizados para capturarlos. Algunos proyectos elaborados pueden tener un Documento de Requisitos Comerciales (BRD) completo, que forma la base absoluta para todos los entregables de ese proyecto.

Profundizaré un poco más en qué consiste cada uno de estos y en qué contexto se utiliza cada uno...

¿Qué es un caso de uso?

Los casos de uso son una excelente manera de obtener, analizar y modelar los requisitos de interacción. Además, ayudan a generar requisitos relacionados para interfaces, datos, procesos y reglas de negocio. Los casos de uso describen la funcionalidad que explica cómo interactúan los usuarios con un sistema. Se escriben como texto y se dividen en secciones. Los casos de uso siguen un formato como este:

Nombre: Nombre del caso de uso

Description: Description of the Use Case

Actor principal: El usuario principal al que se dirige

Precondición: Lo que ya debe existir para que este caso de uso comience

Detonante: ¿Qué inicia este caso de uso?

Caudal básico: El flujo ideal de eventos

Flujo Alterno: Otros posibles flujos que pueden ocurrir

Condición de la publicación: El resultado del flujo que se llevó a cabo.

Puede haber uno o varios casos de uso por función del sistema, y un caso de uso puede referirse a otro caso de uso estableciendo una relación. Analizarlos en su conjunto, por ejemplo, a través de un diagrama de casos de uso o un diagrama de flujo que muestre sus relaciones, proporciona una base sólida de requisitos válidos para comenzar el proceso de diseño.

Después: Matt TerskiDominar el caso de uso Incluir relación

¿Qué es una historia de usuario?

A muchos equipos de desarrollo que están haciendo el cambio de Waterfall a Agile, les gusta usar historias de usuario. Mientras que un caso de uso está muy estructurado y enumera los pasos, la historia de usuario prepara el escenario al indicar la necesidad. Las historias de usuario suelen estar redactadas en frases cortas y en un lenguaje informal, como este: "Como profesor, me gustaría subir materiales de estudio al portal de la escuela, para que mi alumno pueda acceder a ellos y trabajar con ellos".

Después: Derek Huether ¿Qué es una historia de usuario calificada?

Las historias de usuario son excelentes como actividad para recopilar y priorizar las características de alto nivel. Son de naturaleza esquelética y necesitan más detalles incorporados. Sin embargo, aprender sobre esta tarea inicial del usuario es una forma sencilla de intentar identificar y priorizar todas sus necesidades. Estas historias de usuario se transformarán en los requisitos comerciales y los casos de uso.

¿Qué es un escenario?

Un escenario es una descripción narrativa de la interacción de una persona con un sistema. Por lo general, están vinculados a una persona de usuario que representa a un grupo de usuarios que exhiben patrones de comportamiento similares en sus decisiones de compra, uso de tecnología o productos, elecciones de estilo de vida, etc. Cuando los escenarios se crean en torno a un grupo objetivo de usuarios, ayuda a centrar los esfuerzos de diseño en las necesidades del usuario, que son distintas de los requisitos funcionales o empresariales. Los escenarios son similares a las historias de usuario, ya que ambos están escritos en un lenguaje informal y no técnico. Los escenarios suelen ser más largos y proporcionan información contextual adicional. El nivel de detalle que presentan los escenarios es comparable a los casos de uso, pero los escenarios carecen de la estructura formal que tienen los casos de uso. Esto puede hacer que sea engorroso resolver un escenario en sus partes relevantes. Sin embargo, a diferencia de los casos de uso, los escenarios pueden ser creados y comprendidos por personas que no tienen ninguna formación técnica.

After: Eric Schaffer  UI Design Newsletter , HFI

Los siguientes son ejemplos de las tres formas de describir las actividades diarias de un gerente de ventas:

Scenario

John quiere gestionar mejor su equipo de ventas. Para eso, necesita ver una lista de personas en su equipo. Quiere buscar por nombre de vendedor o ubicación geográfica o por cliente. Encuentra a Adán a través de su búsqueda. Quiere ver a los clientes de Adam y sus registros de ventas.

User Story

Como Gerente de Ventas, me gustaría iniciar sesión y buscar una lista de los miembros de mi equipo. Me gustaría una opción de búsqueda para buscar los miembros de mi equipo y los registros de ventas asociados a él.

Use Case

Nombre	Sales Person Lookup
Descripción	Este es un caso de uso que describe la actividad que realizaría un Gerente de Ventas para acceder a información sobre un vendedor específico de su equipo
Actor principal	Gerente de ventas
Precondition	Debe iniciar sesión con derechos de administrador
Trigger	El usuario ha accedido en el panel de control
Basic Flow	User	System
	El usuario accede a la región NE en el mapa de EE. UU.	Información de filtros del sistema en la página para NE US
	El usuario accede a una lista de todos los vendedores	El sistema muestra la lista completa de vendedores
	El usuario selecciona a Adam de la lista de vendedores	El sistema muestra la información y el registro de ventas de Adam
Alternate Flow	User	System
	El usuario utiliza un motor de búsqueda que utiliza "Adam" como cadena de búsqueda.	El sistema muestra una lista de resultados de búsqueda para todos los vendedores cuyo nombre o apellido contiene "Adam"
	El usuario selecciona 'Adam' en los resultados de búsqueda	El sistema muestra la información y el registro de ventas de Adam
Condición posterior	Cuando se cumplen todas las condiciones, el usuario ve los detalles del vendedor que buscó

Todas estas técnicas de redacción de requisitos son formas de consolidarlos y presentarlos de manera efectiva y no dictan ninguna forma específica de incluirlos en el diseño. Por ejemplo, la lista de búsqueda en este caso de uso se puede abordar en la interfaz de usuario como un menú desplegable o un cuadro de lista o una cuadrícula que depende del diseñador decidir ... Dicho esto, los requisitos solo piden un conjunto de habilidades que debe tener un usuario para llevar a cabo una tarea.

Personalmente, me gusta usar una combinación de casos de uso y escenarios para mis diseños. Hay excepciones a esto en las que he tenido que trabajar con informes verbales de clientes, que no tienen la experiencia o el tiempo y el interés para generar requisitos elaborados para un proyecto. Y luego hay situaciones en las que los clientes no siempre conocen sus requisitos detallados. No es un gran comienzo de proyecto para los diseñadores, pero ... La mejor manera de ayudar a estos clientes es guiarlos a través del proceso de diseño, utilizar la lluvia de ideas para generar ideas y luego traducir esas ideas en requisitos concretos, ¡en el camino!