Define una aplicación a partir de una tarea real.

En el ejemplo, una persona solicita material y otra aprueba o rechaza la solicitud. El problema es que los mensajes se dispersan y nadie sabe qué está pendiente. El resultado buscado es poder registrar una petición y consultar su decisión.

Escribe una frase por función: quien solicita necesita consultar sus peticiones; quien aprueba necesita ver las pendientes. No atribuyas a ambas personas los mismos permisos por comodidad.

Petición de ejemplo: identificador SOL-01, material «cuaderno», cantidad 2 y estado «pendiente». Describe cómo se crea, quién la revisa y qué cambia tras una decisión. Añade el motivo cuando se rechaza.

Anota qué campos son necesarios y de dónde proceden. No pidas información solo porque podría resultar útil algún día. En este ejercicio basta con lo necesario para tramitar y localizar la solicitud.

Primera entrega: registrar, listar y decidir solicitudes. Posibles ampliaciones: gestionar proveedores, inventario y compras. Estas últimas quedan fuera del ejercicio para poder comprobar el recorrido principal de principio a fin.

Escribe también una excepción: si la cantidad está vacía, la petición no queda lista para revisión y se explica qué falta. Un brief que solo describe el caso ideal deja decisiones importantes sin resolver.

Copia estos campos: problema; personas usuarias; tarea principal; ejemplo de entrada; resultado; permisos por función; casos incompletos; alcance de la primera entrega; exclusiones; prueba de aceptación.

Pide a quien solicita y a quien aprueba que recorran el ejemplo. Si no coinciden en quién puede decidir o qué significa «aprobada», resuelve esa diferencia en el documento antes de convertirla en código.