Skriv krav som kan testes med et forventet resultat. «Støtter faktura» er for upresist hvis behovet er delt betaling, eksterne kostnader og korrigering av en ferdig faktura. Et krav skal beskrive hva dere trenger å gjøre, ikke bare nevne en funksjon.
Start med driftsformen
En smådyrklinikk, en ambulerende veterinær og et pensjonat har forskjellige kilder for levering og kapasitet. Beskriv først hvilke systemer som skal eie kunder, bestillinger, faglige opplysninger, økonomiske dokumenter og betalingsstatus. Unngå to systemer som begge kan endre samme opplysning uten avklart retning.
| Svakt krav | Prøvbart krav |
|---|---|
| Har integrasjon | Et godkjent testoppdrag gir ett korrekt dokument med referanse |
| Har rapporter | Alle oppgjør for en valgt dato kan spores til bank |
| Har eksport | Uttrekk viser åpne poster, dokumentreferanser og filformat |
| Er enkelt å bruke | Den aktuelle rollen fullfører tre oppgaver uten administrator |
Prioriter før tilbudet kommer
Merk krav som nødvendige, ønskelige og senere muligheter. Be leverandøren skille mellom levert funksjon, tilleggstjeneste og planlagt utvikling. En planlagt funksjon må ikke bli en forutsetning for oppstart uten en håndtert risiko.
For et mulig ReAI-valg må relevant funksjon og faktisk eksport- eller koblingsmulighet avklares. Ingen støtte til et bestemt klinikksystem følger av at begge systemer kan lage filer.
Beregn kostnaden ved å eie løsningen
Ta med lisens, oppsett, opplæring, datarydding, feilretting og uttreden. Kontroller også hvem som får ansvar når en kobling stopper: leverandør, praksis eller teknisk bistand. Et billig system kan bli dyrt hvis all avstemming må gjøres manuelt uten gode referanser.
Avslutt vurderingen med en valgt prøveflyt og tydelige godkjenningskriterier.
Se akseptansetest og leverandørbytte.