Requisitos de software: presupuesto, equipo y aceptación

«Queremos una plataforma fácil, rápida y segura» expresa una preferencia, pero no permite decidir qué construir ni cuándo aceptar el trabajo. Un documento de requisitos útil conecta una tarea de negocio con comportamientos observables, fija límites y explica qué evidencia se entregará. Puede ser breve, siempre que las decisiones difíciles estén escritas.

Imaginemos una empresa que encarga una herramienta para aprobar solicitudes de proveedores. El ejemplo es hipotético y no representa un proyecto de Opruvo. El método también sirve para un portal interno, una aplicación de clientes o un sistema operativo especializado.

Empieza por la persona, la tarea y el resultado: «Un responsable revisa una solicitud completa y la aprueba o la devuelve con un motivo». Añade cómo se trabaja hoy y qué dificultad se quiere resolver. Incluye una solicitud con datos ficticios para que todas las personas hablen de los mismos campos y estados.

Separa el primer lanzamiento de las posibilidades posteriores. Si no incluye alta de proveedores, ejecución de pagos o conciliación contable, indícalo. De lo contrario, «aprobar una solicitud» puede significar cosas distintas para dirección, administración y desarrollo. El límite debe aclarar el encargo, sin ocultar una parte esencial del proceso.

El documento puede convertirse en un anexo técnico del acuerdo, pero definir comportamientos no sustituye la revisión de condiciones jurídicas y comerciales. Mantén una terminología común: «aprobado» no puede significar una revisión previa para una persona y una decisión definitiva para otra.

Asigna identificadores que sobrevivan a cambios de título. En cada requisito, registra actor, condiciones previas, acción, estado esperado, excepciones y evidencia necesaria. Separa comportamientos que puedan aceptarse de forma independiente, conservando sus relaciones. En el ejemplo hipotético de proveedores, rechazar una solicitud incompleta y impedir una aprobación sin permiso necesitan comprobaciones distintas.

La guía de GOV.UK sobre historias de usuario relaciona actor, necesidad y objetivo con criterios de aceptación. Un registro breve permite seguir esa relación:

La fila describe una prueba propuesta, no un resultado. Vincular la evidencia con una referencia estable permite revisar cambios posteriores sin declarar terminados otros comportamientos.

Para cada operación, define quién puede ejecutarla, desde qué estado y con qué resultado. Añade qué ocurre cuando faltan condiciones. Aprobar una solicitud pendiente no es el mismo caso que intentar aprobar otra rechazada anteriormente.

Esta tabla es un ejemplo de aceptación que debe adaptarse al proyecto:

El resultado de negocio y el efecto visual deben comprobarse por separado. Un mensaje verde no acredita que la base de datos se haya actualizado ni que el destinatario haya recibido la notificación.

Identifica la fuente autorizada de cada campo importante. Explica si la aplicación puede cambiarlo o solamente consultarlo. Utiliza identificadores estables para personas, solicitudes y proveedores; el nombre mostrado no basta como referencia de integración. Decide qué sucede si el registro externo no existe, cambia o aparece duplicado.

Si hay migración, incorpora al alcance el mapeo, los archivos de muestra, las validaciones y un informe de conciliación. Una hoja de cálculo no contiene necesariamente adjuntos, relaciones o decisiones históricas. Designa a alguien del negocio para resolver registros ambiguos; el equipo técnico no debería adivinar cuál es el dato correcto.

Enumera sistemas externos, documentos, accesos y decisiones del cliente necesarios para entregar. Asigna a cada dependencia un responsable y un estado: disponible, pendiente de confirmación o sujeta a investigación. En una integración, identifica operación permitida, entrada, salida esperada y respuesta ante error; «conectar el sistema» deja demasiado sin confirmar.

Una capacidad incierta requiere una investigación definida y una decisión posterior, no una promesa incondicional de entrega. Si se excluye la migración histórica completa, describe qué se importará y cómo se tratará la información restante dentro del alcance acordado.

Prepara datos de prueba permitidos que permitan restaurar el mismo estado inicial sin afectar a operaciones reales. Registra entorno, rol y responsable de revisión, y vincula cada salida o captura con su criterio. Distingue «no probado» de «fallido» cuando una dependencia impida ejecutar la comprobación. Así una demostración parcial se entiende y otra persona puede repetirla.

«Rápido» necesita un recorrido, un entorno, un conjunto de datos y un método de medición. Acuerda un objetivo después de entender el uso y la infraestructura. Copiar una cifra de otra aplicación aporta poco: buscar en una demostración pequeña y consultar años de información son pruebas diferentes.

OWASP ASVS aporta requisitos verificables de seguridad. Selecciona los que procedan y documenta su versión y evidencias, en lugar de escribir «cumple OWASP» sin comprobaciones. Cuando exista una API, la guía REST de OWASP ayuda a plantear controles de acceso, validación y errores. La elección final depende de la aplicación.

Determina también qué dispositivos se usarán, quién necesita operar con teclado y qué debe seguir disponible si falla una dependencia. Estas decisiones forman parte del encargo cuando afectan a la aceptación; no conviene descubrirlas el último día.

Entrega a los candidatos los mismos escenarios, datos permitidos y criterios de aceptación. Compara entregables, exclusiones, dependencias, pruebas, documentación, propiedad del repositorio y soporte; separa pagos únicos y costes recurrentes. Pide que expliquen quién analiza, desarrolla, revisa y mantiene cada parte. Una demostración acotada con datos ficticios permite revisar cómo trabajan, pero no acredita por sí sola experiencia anterior ni resultados futuros. Conserva por escrito las diferencias antes de comparar importes.

Acuerda quién controla el repositorio y las cuentas, qué código y documentación se entregan y quién mantiene la aplicación. Solicita un procedimiento de despliegue, un inventario de configuración sin secretos y una recuperación que pueda ensayarse. Delimita el soporte frente a las nuevas funciones.

Para cada requisito, conserva un estado: pendiente, demostrado, fallido o aceptado con una limitación documentada. Adjunta entorno y evidencia. Si cambia la necesidad, actualiza el caso de aceptación y valora el efecto en coste y dependencias antes de incorporarlo al alcance original.

Versiona el anexo cuando cambie el alcance. Registra requisito afectado, motivo, impacto y decisión autorizada, conservando la versión anterior. Distingue primero un comportamiento acordado que no se ha cumplido de una capacidad realmente nueva; después actualiza juntos el caso de aceptación, los ejemplos y la documentación de entrega. Cambiar solo la lista comercial deja instrucciones contradictorias.

El documento está preparado cuando otra persona puede explicar qué resultado se acepta y detectar uno incorrecto. Opruvo ofrece desarrollo de software a medida comenzando por proceso, requisitos y arquitectura. Ese trabajo permite preparar un presupuesto según el alcance y la viabilidad técnica.