BASE DE DATOS
¿Cómo preparar un documento de requisitos para software de comercio electrónico?
Tabla de Contenidos — Español
¿Qué información se necesita antes de empezar?
Deben conocerse la estructura de productos y variantes, los grupos de clientes, el flujo de pedidos y los sistemas externos en uso. Hay que identificar a las personas de los equipos de operaciones, ventas y técnico que conocen el proceso. El responsable del documento se encarga de recopilar las decisiones y de que las personas implicadas resuelvan las contradicciones; no se espera que genere él solo todas las reglas de negocio.
Primero observe el flujo actual. Registre cómo se recibe un pedido, quién lo revisa y en qué situación se detiene. Las reglas que las personas conocen desde hace años pero que no están escritas son especialmente importantes. El software no puede adivinar estas reglas por sí mismo.
¿En qué orden se redacta un requisito?
1. Defina el rol del usuario y la tarea que quiere realizar. La frase "Un especialista de operaciones puede corregir la dirección de entrega de un pedido que no ha sido enviado" describe la tarea.
2. Indique la precondición. Por ejemplo, el pedido todavía no debe haberse transferido al sistema de envíos. "No enviado" y "etiqueta de transporte no generada" pueden ser situaciones distintas; aclare la definición.
3. Escriba la regla de negocio y el resultado. El registro de cambios debe conservar el valor anterior y el nuevo, quién realizó la operación y cuándo. Si la transferencia al sistema externo ya ha comenzado, puede ser necesario un proceso de corrección diferente.
4. Añada el comportamiento ante el fallo. Un usuario sin autorización no debe poder hacer el cambio; en un pedido que no cumpla la condición debe mostrarse un mensaje explicativo.
5. Registre los ejemplos de aceptación. La operación debe tener éxito en un pedido elegible, ser rechazada en uno ya transferido a envíos y quedar bloqueada para un rol sin autorización.
¿Cómo se concreta una prueba de aceptación?
En lugar de "La gestión de stock debe funcionar", escriba "Cuando lleguen dos pedidos simultáneos para una variante con una unidad de stock vendible, debe cumplirse la política definida de exceso de stock". Si la política no permite que el stock sea negativo, se espera que solo se cree una reserva con éxito. Si se permiten los pedidos anticipados, el resultado es distinto; el equipo técnico no debe dar por supuesta la decisión de negocio.
¿Cómo se añaden la prioridad y las dependencias?
Asigne un identificador a cada requisito, como R-001, R-002. Distinga entre obligatorio, fase posterior y opcional. Si un requisito depende de otro modelo de datos o del acceso a un servicio externo, indíquelo. La asignación de stock no se considera completa hasta que se determinen los identificadores de producto.
Registre de forma explícita el trabajo que queda fuera del alcance. Si la primera versión no tendrá varios idiomas ni reembolsos parciales, esta decisión debe ser visible. Los puntos abiertos deben tener un responsable y una fecha de respuesta. Una pregunta sin respuesta no debe convertirse silenciosamente en un requisito aprobado.
¿Cómo se comprueba la usabilidad del documento?
Pida a un desarrollador y a un responsable de pruebas que lean un requisito por separado. Si ambos pueden describir cómo se verificará el mismo resultado, el texto es lo bastante claro. Si surgen interpretaciones diferentes, añada datos de ejemplo y excepciones. Gestione el documento no como una entrega única, sino como un registro compartido con historial de cambios.
El resultado debe constar de identificador del requisito, tarea, precondición, regla de negocio, excepción, ejemplo de aceptación, prioridad y responsable. Esta estructura conecta el alcance de la propuesta, el desarrollo y las pruebas de aceptación de usuario.
¿Cuáles son las preguntas frecuentes?
¿Cuál es el siguiente paso?
Redacte con esta estructura sus tres primeros requisitos críticos; evalúe el alcance y los ejemplos de aceptación con PROJX Digital.
