Kravhåndtering

Kravhåndtering

12.4 Kravhåndtering af den nye løsning

12.4.1 Kravspecifikationens indhold

Der er blevet analyseret hvilke ønsker og krav der er og i den forbindelse er alle aktører (brugere, medarbejdere & administratorer) behandlet og deres brugsmønstre analyseret og resulterer i følgende struktur for systemet er blevet beskrevet. I samarbejde med organisationen er der igennem et interview med ledere og medarbejdere fremkommet følgende kravspecifikation. [1]

  • Et cloudbaseret website og et lokalt interface skal have et enkelt design med fokus på funktionalitet og kun lidt relevant tekst med hensigtsmæssig typografi.
  • Interfacet skal kunne vise information om medarbejdere. Herunder information som Titel, Afdeling, Fornavn, Efternavn, Telefon, Mail og Postnr. Dette gemmes i en database hvoraf der kan laves udtræk til websitet.
  • Websitet skal således vise ovenstående information om medarbejdere.
  • Der skal kunne lave en xml-fil til enkel distribution af relevant information om medarbejdere. Men også andre formater.
  • Der skal være en registreringsside hvor man kan oprette en brugerprofil. Man skal også kunne se info om applikationen samt kontaktoplysninger.

Kravene behandles løbende igennem de forskellige faser og implementeres, således at de ønskede mål for systemet opnås. Søren Lauesen påviser den gode praksis i hans publikation og jeg er enig i ham i at aftalegrundlaget, skal være klart og tydeligt præciseret i starten af et hvert udviklingsprojekt. (Lauesen, 2013)

De fremkomne krav til websitet behandles i flere omgange i de forskellige faser og slutmålet er en fuldstændig realisering af et website, der tilgås fra organisationens eget intranet. Der for så vidt ikke de store problemer i at specificere krav i en kravspecifikation.

Problemet opstår, når dette dokument alene bliver grundlaget for det videre projektforløb. Det, der ofte sker, er, at det nu bliver en fortolkningsopgave at få kravene afspejlet og implementeret i form af design, kode og test. Denne fortolkningsmulighed giver en risiko for, at der opstår et forskelligt syn på, hvorvidt kravspecifikationen er blevet implementeret eller ej. Det kan efterfølgende resultere i kunde-utilfredshed, misligholdelse af kontrakt, budgetoverskridelser og i sidste instans i en retssag.

12.4.2 Fortolkning af krav

Prototyper anvendes naturligt i IT branchen og mange steder med gode erfaringer, men ofte indtræder kilden til de potentielle tvister før dette tidspunkt, nemlig i forbindelse med fortolkningen af de krav der er stillet til systemet, og bliver i øvrigt ikke altid synliggjort via prototypen. Dette er forsøgt imødekommet i denne rapport som lige netop beskriver processen hen imod slutmålet.

Da software som bekendt er en fast bestanddel af vores hverdag i en eller anden udstrækning, så er vi klart afhængig af den kvalitet, produktet leveres med. Hvorfor skulle vi således ikke kunne sikre os, at vore udviklingsprojekter leverer den fornødne kvalitet samt holder sine budgetter og tidsrammer ? For at have et godt udgangspunkt for dette, må vi derfor bestræbe os på, at vi har en fælles forståelse for det fælles fundament – kravspecifikationen.

Skriv et svar

Luk menu