LITET PM ANG DEN 'RUDIMENTÄRA KRAVSPECEN'

Ni ska inte förfärdiga en 'riktig', fullödig kravspec; bl a
skulle det nog ta alldeles för lång tid. Det ni ska skriva och
redovisa kan inskränka sig till ungefär detta:

- 1 -
Först en liten bakgrund till hela projektet: I vilken verksamhet
behövs systemet, vad sysslar man med där, vilka är de tilltänkta
användarna, vad är vinsten med detta system. Det där borde kunna
vara nån halv sida text.

- 2 -
Sen en lista över de funktionella kraven:

Det kan väl tänkas finnas 15-25 olika 'kommandon' (i vid mening)
eller funktioner som användaren kan initiera. Många av dessa kräver
att användaren ger data, och somliga ger en synlig respons. Andra
kan åstadkomma något 'bakom kulisserna' (data sparas, t ex). Både
vad för slags data, vilken respons eller vilken annan effekt som
'kommandot' har ska specas.

Ett exempel kan vara "Programmet/systemet skall fråga användaren
efter personnummer och kurskod, och svara med det utdelade betyget
för kurs och person i fråga, eller att personen inte deltagit."

Det innebär att ett funktionellt krav i detta sammanhang ska
specas väldigt konkret och inte bara allmänt som "Systemet ska
kunna visa en persons betyg på en kurs." Alltså, inte bara vilken
övergripande uppgift som ska lösas, utan också hur man ska bete
sig för att få det till stånd., och vad det resulterar i.

På samma sätt för varje funktionalitet. Och kom ihåg att här
kan nu ingenting anses 'självklart' eller 'underförstått'. Kom
också ihåg att med tiden ska det kunna gå att med denna spec som
måttstock 'mäta' huruvida systemet uppfyller specen eller inte.
Var alltå noggrann, detaljerad, fullständig. Kanske kan här något
'formellt' beskrivningssätt begagnas?

Funktionaliteten kan behöva delas upp i flera nivåer av krav; de
nödvändiga (skall-kraven) och de mindre nödvändiga, men trevliga
(bör-kraven). Eller fler nivåer ('väntrum'). De kan också behöva
struktureras upp i grupper; såna för en viss typ av uppgifter för
sig etc (i stil med spara data, hämta data, analysera data, ...)

- 3 -
Gränsnittets karaktär ska beskrivas i allmänna ordalag, men inte
i sina precisa detaljer. Man kan t ex säga att det ska vara ett
fråga-svar-system via terminal, men inte formulera frågornas exakta
lydelse. Det blir en upppgift under designen.

- 4 -
Om systemet hanterar data lagrade på externa filer (eller använder ett
databassystem) behöver dessutom filernas/datamängdens struktur
beskrivas lite. Vad lagras? Ungefär i vilken form? Också en antydan om
i vilket läge en 'transaktion' sparas kan behöva infogas.

---
Det handlar nu om att förfärdiga ett DOKUMENT, inte en textfil!!
Ett dokument har bl a ett försättsblad som identifierar projektet,
som talar om vilket projektdokument det är, och som anger vilka
(i detta fall grupp och namn) som är ansvariga. ALLA dokument till
ett projekt bör ha samma layout, logga (om sådan begagnas), systematik
och typsnitt så att läsaren känner igen sig. Mer omfattande dokument
har också en innehållsförteckning. I somliga fall (kanske inte här?)
kan ordförklaringar krävas, och ska man vara petnoga (men jag kommer
på den punkten inte att vara det) ska det också finnas en 'revisions-
historia' och ett 'godkännande'.

Hela denna rudimentära kravspec, med försättsblad, kan väl tänkas
vara på fyra sidor eller mer?

2011-09-07