Requisits de programari: pressupost, equip i acceptació

«Necessitem una aplicació fàcil, ràpida i segura» expressa una expectativa, però no permet decidir si el lliurament està acabat. Per preparar un encàrrec útil cal convertir aquestes qualitats en situacions observables: qui fa una acció, amb quines dades, què ha de passar i com es comprovarà.

No cal decidir cada detall tècnic abans de parlar amb un equip de desenvolupament. Sí que convé documentar el procés de negoci i les condicions que faran acceptable la primera versió. El document pot evolucionar, sempre que els canvis quedin visibles i tinguin un efecte acordat sobre abast, calendari i pressupost.

Aquest és un exemple hipotètic d’encàrrec per a una eina interna. No és un cas de client ni una proposta comercial de Opruvo.

L’equip comercial necessita preparar sol·licituds de descompte i enviar-les al responsable. El comercial pot editar una sol·licitud mentre sigui esborrany. Després d’enviar-la, només el responsable assignat pot aprovar-la o rebutjar-la. La decisió ha de quedar registrada amb data i motiu. La primera versió no aplicarà el descompte al sistema de facturació.

Aquest paràgraf ja defineix actors, estats i una exclusió. Encara queden preguntes: què passa si el responsable està absent, si una sol·licitud té dades incompletes o si es prem dues vegades el botó d’enviament? Les respostes formen part de l’encàrrec perquè afecten el comportament que s’ha de construir.

El document pot convertir-se en un annex tècnic de l'acord, però definir comportaments no substitueix la revisió de condicions jurídiques i comercials. Mantén una terminologia comuna: «aprovat» no pot significar una revisió prèvia per a una persona i una decisió definitiva per a una altra.

Assigna identificadors que es mantinguin encara que canviï el títol. A cada requisit, registra actor, condicions prèvies, acció, estat esperat, excepcions i evidència necessària. Separa comportaments que es puguin acceptar independentment i conserva'n les relacions. En l'exemple hipotètic de descomptes, impedir l'enviament sense motiu i impedir l'aprovació d'un comercial sense permís necessiten comprovacions diferents.

La guia de GOV.UK sobre històries d'usuari relaciona actor, necessitat i objectiu amb criteris d'acceptació. Un registre breu permet seguir aquesta relació:

La fila descriu una prova proposada, no un resultat. Vincular l'evidència a una referència estable permet revisar canvis posteriors sense declarar acabats altres comportaments.

Una manera pràctica d’escriure un criteri és descriure situació inicial, acció i resultat. Evita condicions com «funciona correctament», que obliguen a negociar el significat quan el treball ja està lliurat. El criteri ha de permetre repetir la prova amb les dades acordades.

La taula és una proposta de treball per a aquest exemple. No demostra que el producte ja compleixi els criteris, i cal adaptar-la a l’arquitectura i les regles reals.

Els camps necessiten significat, format i responsable. «Import» pot ser una quantitat amb impostos, sense impostos o en una moneda diferent. Un petit diccionari evita interpretar el mateix nom de maneres incompatibles. També s’ha de definir com es tracten registres antics, valors buits i canvis de format.

Si el temps de resposta és rellevant, acorda l’operació que es mesurarà, el volum de dades, l’entorn, la concurrència i el mètode de mesura. Fixar un número sense aquestes condicions produeix una prova amb poc valor. No utilitzis el resultat d’un ordinador de desenvolupament com a promesa automàtica sobre l’experiència de tots els usuaris.

La seguretat també necessita requisits delimitats. L’ASVS d’OWASP proporciona una base per definir i comprovar controls tècnics d’aplicacions web, inclòs el seu ús en processos de contractació.[1] L’equip pot seleccionar els requisits pertinents i registrar-ne la versió. Aquesta selecció no equival a una certificació ni a una garantia d’absència de vulnerabilitats.

Enumera sistemes externs, documents, accessos i decisions del client necessaris per al lliurament. Assigna a cada dependència un responsable i un estat: disponible, pendent de confirmació o subjecta a investigació. En una integració, identifica operació permesa, entrada, sortida esperada i resposta a errors; «connectar el sistema» deixa massa coses sense confirmar.

Una capacitat incerta necessita una investigació definida i una decisió posterior, no una promesa incondicional de lliurament. L'exemple de descomptes exclou aplicar-los al sistema de facturació: preparar una consulta tècnica sobre aquesta integració no l'afegeix automàticament a la primera versió.

Prepara dades de prova permeses que permetin restaurar el mateix estat inicial sense afectar operacions reals. Registra entorn, rol i responsable de revisió, i vincula cada sortida o captura al seu criteri. Distingeix «no provat» de «fallit» quan una dependència impedeixi fer la comprovació. Així s'entén una demostració parcial i una altra persona la pot repetir.

Un document d’encàrrec ha d’incloure codi, instruccions d’arrencada, configuració, proves i informació necessària per al manteniment, segons l’abast contractat. Cal identificar quines llicències, serveis externs o comptes aporta cada part. Una demostració visual, per si sola, no resol la titularitat dels accessos ni la continuïtat del projecte.

Designa una persona amb capacitat de validar les regles de negoci i una altra amb responsabilitat tècnica. Defineix com es registraran incidències, quina evidència cal aportar i com es repetirà la comprovació després d’una correcció. La revisió pot ser per fases, perquè els problemes d’interpretació apareguin abans del lliurament complet.

Quan s’afegeixi una necessitat, relaciona-la amb els requisits afectats. Si canvia un estat del procés, revisa també permisos, notificacions, dades i proves. Un registre curt de decisions ajuda més que diverses versions contradictòries del mateix document.

Versiona l'annex quan canviï l'abast. Registra requisit afectat, motiu, impacte i decisió autoritzada, tot conservant la versió anterior. Distingeix primer un comportament acordat que no s'ha complert d'una capacitat realment nova; després actualitza conjuntament el cas d'acceptació, els exemples i la documentació de lliurament. Canviar només la llista comercial deixa instruccions contradictòries.

Pots utilitzar aquestes pautes per preparar una primera conversa sobre desenvolupament de programari a mida. A Opruvo, l’abast i el pressupost es concreten després d’estudiar requisits, dependències i viabilitat; els criteris d’acceptació permeten donar una base verificable a aquesta conversa.

Lliura als candidats els mateixos escenaris, dades permeses i criteris d’acceptació. Compara lliurables, exclusions, dependències, proves, documentació, propietat del repositori i suport; separa pagaments únics i costos recurrents. Demana que expliquin qui analitza, desenvolupa, revisa i manté cada part. Una demostració acotada amb dades fictícies permet revisar com treballen, però no acredita per si sola experiència anterior ni resultats futurs. Deixa per escrit les diferències abans de comparar imports.

1. OWASP, Application Security Verification Standard: https://asvs.owasp.org/

Font consultada el 3 de novembre de 2026. L’exemple i les taules són propostes editorials, no plantilles contractuals.