Skriv et kravbrief til en lille intern app på én side
Det er lettere at bestille en nyttig intern app, når behovet kan beskrives uden at starte med skærmenes udseende. Et kort kravbrief skal fortælle, hvem der skal gøre hvad, og hvilket resultat virksomheden forventer at kunne stole på.
Vælg én opgave og en tydelig afgrænsning
Skriv opgaven som en sætning: En medarbejder registrerer en anmodning om en produktdemo, og den ansvarlige kan fordele og afslutte den. Det er et tænkt eksempel. Første version behøver ikke samtidig håndtere tilbud, kontrakter og fakturering.
Microsofts annoncering af appbygning i Copilot Studio gør denne afgrænsning aktuel. Guiden handler om kravene før bygning og kan bruges med andre udviklingsmetoder.
Definér roller og data
Angiv, hvem der må oprette, se og ændre en anmodning. Beskriv også, hvem der ikke skal have adgang. Brug konkrete roller frem for alle medarbejdere, hvis opgaven reelt kun vedrører et mindre team.
Lav derefter en kort feltliste med nødvendige oplysninger og deres kilde. Beslut, om status hører hjemme i appen eller i et eksisterende system. To forskellige steder med hver sin officielle status giver et nyt afstemningsproblem.
Beskriv handlinger og resultat
For hver handling skrives, hvad der skal være sandt bagefter. Når en ansvarlig tildeles, skal den relevante post vise den valgte person. Når en opgave afsluttes, skal tidspunkt og slutstatus kunne findes igen. Beskriv også, hvilke beskeder der eventuelt må sendes.
Adskil en kladde fra en gennemført ændring. En knap med teksten gem bør ikke blot vise en kvittering, hvis data i det underliggende system ikke er blevet opdateret.
Medtag de fejl, brugeren vil møde
Vælg få relevante undtagelser: Et obligatorisk felt mangler, datakilden kan ikke kontaktes, eller en anden bruger har ændret posten. Skriv, hvad brugeren skal se, og hvordan vedkommende kan fortsætte uden at miste eller overskrive oplysninger.
Prøven skal også omfatte en bruger uden den nødvendige rolle. Det er ikke tilstrækkeligt, at knappen er skjult, hvis den bagvedliggende handling stadig kan udføres uden korrekt adgang.
Aftal godkendelse og vedligeholdelse
Angiv en ejer, nogle repræsentative testopgaver og et kriterium for, hvornår første version er klar. Brug syntetiske data under den tidlige afprøvning. Tilføj, hvem der håndterer fejl, og hvordan appen kan tages ud af brug, hvis forsøget ikke giver værdi.
Det færdige brief skal kunne læses af både brugeren og den, der bygger løsningen. Hvis de er uenige om resultatet, er briefet endnu ikke klart nok til at fungere som grundlag for levering.