Kravene til en IT-understøttet løsning skal specificere hvordan relevante processer skal gennemføres i den nye løsning, og derunder hvordan IT-systemer skal understøtte processernes aktiviteter.
Krav specificeres på baggrund af forretningsanalyse, der har afdækket muligheder for at udvikle og implementere en løsning, der optimerer virksomhedens processer.
Løsningsarkitekturen udtænkes og dokumenteres med udgangspunkt i kravene, men også med hensyntagen til den eksisterende infrastruktur, vedtagne arkitekturprincipper, omkringliggende systemlandskab og tilgængelige og fremtidssikrede teknologier.
Kode skrives i overensstemmelse med kravspecifikationen arkitekturen, testes af udviklere med kravene som reference, og bygges løbende sammen til et samlet IT-system, der testes af testere – igen med kravspecifikationen som facit.
Hvis kravene kan realiseres med et indkøbt standardsystem, er det sjældent nødvendigt at udarbejde og dokumentere en løsningsarkitektur. Så vil der heller ikke skulle skrives kode, men der vil ofte være en opgave med at konfigurere det indkøbte standardsystem.
Kravspecifikationens opbygning
Indledning
En indledning nævner projektet og dets formål, og ofte kan en tabel med revisionshistorik være praktisk.
Use cases
Evt. kan et use case diagram bruges som oversigt, men jeg anbefaler at man altid også laver en liste, da use case navnene sjældent er information nok, og da diagrammet ikke eger sig til at inkludere beskrivelser af use casene.
Suppler diagrammet med en liste over aktørernes roller:
- Rollenavn.
- Fagområde (helst direkte reference til et defineret fagområde i enterprisearkitekturen.
Derefter følger en liste af use case specifikationer:
- Nummer.
- Navn.
- Kort beskrivelse.
- Navn på understøttende system.
Selve use case specifikationerne skrives som separate dokumenter.
Generelle krav
Eksempler på generelle krav, der ikke egner sig til at specificeres i use cases, eller som gælder på tværs af alle use cases:
- Kommercielle krav.
- Teknologikrav.
- Sikkerhedskrav.
- Dokumentationskrav.
opdel efter de kategorier, der er relevante for det konkrete projekt. Ingen opdeling er også helt okay.
Forretningsregler
Forretningsregler gælder på tværs af alle use cases, og egner til at specificere ting som beløbsgrænser, formler for diverse beregninger, tidsfrister mm.
Use case specifikationens opbygning
Indledning
Kort reference til det overordnede kravdokument, samt meget kort introduktion til projektet, efterfulgt af:
- Use case nummer.
- Navn.
Brug bydemåde – fx “Opret medarbejder” eller “Bogfør faktura”. - Aktørens rollebetegnelse.
- Det understøttende system (som skal indfri kravene i use caset).
En revisionshistorik kan også være praktisk at medtage.
Normalt forløb
Det normale forløb er det hyppigst forekommende, uden fejl og forviklinger. Det enkleste er at specificere trinene som en nummeret liste startende med den igangsættende hændelse, fulgt af systemets og aktørens handlinger.
Det kan fx se således ud:
- Brugeren åbner systemet.
- Systemet viser registreringsskema for indeværende uge.
– Projekter, der er åbne for tidsregistrering, og som medarbejderen tidligere har registreret tid på, eller tidligere har fremsøgt og favoritmarkerede, vises i registreringsskemaet.
– For hvert vist projekt, vises et indtastningsfelt for hver af ugens 7 dage. - Brugeren indtaster det arbejdede antal timer brugt i et eller flere af de viste projekter i registreringsskemaet.
- Systemet opdaterer samlet antal timer per dag og for hele ugen efter hver indtastning.
- Brugeren gemmer det opdaterede registreringsskema.
- Systemet viser at registreringsskemaet er gemt.
- Brugeren lukker systemet.
Efterfølgende specificeres alternative forløb.
Alternative forløb
Alternative forløb kan indledes på grund af valg, aktøren foretager i andre forløb – fx det normale forløb, eller hvis systemet ikke kan fuldføre et trin i et andet forløb – fx på grund af at der opstod en fejl, eller fordi en regel nødvendiggør et alternativt forløb.
Et eksempel kan så således ud:
- Brugeren starter en fremsøgning af projekter (efter trin 2).
- Systemet beder om en søgetekst.
- Brugeren indtaster en søgetekst.
- Systemet viser alle projekter, der matcher den indtastede søgetekst.
- Brugeren vælger et af de viste projekter.
- Systemet indsætter det valgte projekt i registreringsskemaet.
- Brugeren fortsætter med trin 3.
Der kan være behov for mange alternative forløb for at sikre klare og tydelige krav til alle tænkelige scenarier.
Tips og tricks til use cases
- Brug altid kun ordene “brugeren” og “systemet” i teksten til trinene. Det gør læsningen nemmere, og det gør kopiering af gentagne trin til andre lignende use cases nemmere.
- Nummerer gerne alle de alternative forløb. Dermed kan der nemt refereres til et specifikt trin i hvilket som helst forløb – fx er trin 4 det trin i det normale forløb hvor systemet opdaterer totalerne i registreringsskemaet, og trin 1.6 er det trin i det første (nr. 1) alternative forløb hvor systemet viser det fremsøgte og tilføjede projekt i registreringsskemaet. Når sidste trin i det alternative forløb henviser til trin 3, er det underforstået at trinnet med nummer 3 er et trin i det normale forløb.
- Vær så detaljeret som muligt – men indenfor rimelighedens grænser. Tag fx trin 3 – altså trin 3 i det normale forløb. Der fremgår det strengt taget ikke at brugeren skal kunne indtaste timer for hver dag i ugen på hvert vist projekt. Det er rimeligvis underforstået, men der kan komme spørgsmål fra udviklerne til den slags, så vær parat til at revidere use caset, så det bliver endnu tydeligere.
- Hvis der i kravspecifikationen fx er specificeret en forretningsregel om at der ikke må registreres mere end 24 timer per dag, behøver use caset ikke nødvendigvis at pensle ud at de indtastede timer ikke kan gemmes, hvis det indtastede data ikke overholder reglerne. Alternativt kan du indsætte ekstra trin, der specificerer at systemet kontrollerer de indtastede timer, og tillader brugeren at gemme, hvis dataet er korrekt udfyldt (altså overholder eventuelle forretningsregler).
- Følg SMART [Wikipedia] princippet.
Det betyder i praksis at use caset skal referere til den proces, kravene i use caset understøtter, at kravene er rettet mod et specifikt system, at kravene kan verificeres, er realiserbare og realistiske, og angive eventuel tidsmæssig sammenhæng.
Typiske fejl og misforståelser
- Brug IKKE user stories i stedet for use cases!
User stories duer IKKE til kravspecificering. De er opfundet som teknik til at opdele udvikling af use cases med mange indbyggede forløb i overkommelige klumper. Fx kan formalforløbet repræsenteres en en user story, og en anden user story kan beskrive hvordan brugeren tilføjer et projekt i registreringsskemaet. - Brug IKKE tabelformat!
Mange prøver at indrette use cases som en tabel med to kolonner – brugeren til venstre og systemet til højre. Problemet med dette layout er at ikke alle handlinger kun leder til en enkelt reaktion. Brugeren udfører en handling, men der kan være hensigtsmæssigt at dele systemets reaktion op i adskillelige trin. Samtidig medfører tabelformatet at der bliver mindre bredde til teksten til hvert trin, og specifikationen ender med at blive spredt over over mange sider. Det forringer overblikket. - Brug IKKE diagrammer!
Det kan være fristende at forsøge at tegne use cases som UML aktivitetsdiagrammer eller lignende. Men symbolerne er fattigere end velvalgte ord, og du ender med at bruge meget tid på at tegne, uden at nogensinde kunne opnå den nødvendige grad at præcision. - Undgå at diktere designdetaljer!
Det kan være fristende at skrive i use casets trin hvordan systemet skal kodes, fx hvilken databasetabel, der lagres i, eller hvilken farve eller tekst en knap skal have på skærmen. Men det er en fælde! Teknisk design og kodning skal overlades til arkitekten og udviklerne, ligesom hensigtsmæssige valg af farver, former og begreber i brugergrænsefladen bedst overlades til specialister indenfor interaktionsdesign. - Skriv IKKE acceptkriterier!
Hvis du føler behov for at supplere din kravformulering med en liste af acceptkriterier, betyder det bare at din kravformulering er noget vrøvl. En god kravformulering står alene, og skal IKKE uddybes eller nuanceres. Blev hellere ved med at arbejde med kravformuleringen, indtil den er fyldestgørende og SMART [Wikipedia]. - Brug IKKE Excel eller PowerPoint!
Brug kun Word eller andre tekstbehandlingsværktøjer, eller webbaserede dokumentationssystemer som fx Concluence.