TDDI02 Programmeringsprojekt

Kavspecifikation (obligatorisk)

Filer

Relevanta delar från föreläsning #1 finns här.

Kravspecifikation i ert projekt

Det krävs inte att ni gör en fullständig kravspecifikation, men några väsentliga delar av en sådan ska ni framställa. Det krävs att ni dels beskriver systemets funktionella krav, dels de övergripande kraven på användargränssnittet och dels om systemet kräver något annat stödsystem. Observera att en kravspec på många punkter uttrycker sig i tvingande ordalag.

De funktionella kraven är en lista på alla de händelser som användaren kan trigga. Var var och en beskriver man uppgiften i stora drag, vilken påverkan på systemet/dess data den medför, vilken form av respons som ska ges och särskilt vilka eventuella felkontroller som genomförs och vad som då ska meddelas. Denna lista skulle kunna struktureras upp i händelser av olika kategorier, för att göra det hela mer överskådligt. De funktionella kraven ska dock på den yttersta nivån delas upp i skall-krav (som man inte kan strunta i) och bör-krav (som man kan ignorera om tiden inte räcker), och kanske ytterligare en nivå. Observera att funktionella krav bara ger uttryck för vad användaren upplever.

När det gäller gränssnittet ska ni här specificera dess allmänna karaktär och layout (fråga- svar, textbaserat, ...). Det är också möjligt att i detalj specificera utseendet av varje konversation, men ni kan skjuta upp det till designspecifikationen om ni vill.

Ni måste också specificera vilket externt bibliotek ni använder, samt vilken version av det här systemet ni tänker använda, åtminstone i grova drag.

Kravspecifikationen ska dessutom ha en aldrig så liten inledning, som presenterar den miljö och den användarkategori systemet är avsett för.

Litet pm ang den 'rudimentära kravspecifikationen'

Ni ska inte förfärdiga en 'riktig', fullödig kravspecifikation; bl.a. skulle det 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 blir mellan en halv och en sida text.

- 2 -

Sedan en lista över de funktionella kraven:

Det kan 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 specificeras.

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 specificeras 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 specifikation som måttstock 'mäta' huruvida systemet uppfyller specifikationen 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 uppgift 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 vi kommer på den punkten inte att vara det) ska det också finnas en 'revisions- historia' och ett 'godkännande'.

Hela denna rudimentära kravspecifikation, med försättsblad, kan tänkas vara på runt fyra sidor. Resultatet levereras till er handledare som en PDF-fil.

Nedan om kravspecen i ett större perspektiv av Klas Arvidsson.

Kravspecifikation i ett större perspektiv

Kravspecifikationen är kanske det viktigaste dokumentet. En kravspecifikation används av många personer och det är därför viktigt att den är väl genomtänkt för att täcka alla kommande behov. Kravspecifikationen

• Beskriver entydigt vad programsystemet skall kunna utföra.
• Är kontraktet mellan projektgruppen och kunden. Det är viktigt att kunden förstår vad det står.
• Är dokumentet som skall se till att all involverade i projektet har samma uppfattning om vad som är slutmålet.
• Används av projektledaren när han skall prioritera och planera arbetet.
• Används av den tekniske designern för att förstå hut programsystemet skall byggas upp på bästa sätt.
• Används av programmerarna för att veta hur kuden de skriver skall få programsystemet att bete sig.
• Används av testaren för att verifiera vilka (att alla) krav är uppfyllda.
• Används av programmerarna för att veta hur kuden de skriver skall få programsystemet att bete sig.
• Används av domstol om tvist mellan kund och projektgrupp om vilka krav som är uppfyllda uppstår.
• Används av den som skriver manual för att säkert få med alla viktiga funktioner.
• Används och uppdateras av den som senare utför underhåll och buggfixar.
• Kan behöva uppdateras när kunden förstått vad denne vill ha.
• Kan behöva uppdateras när nästa version skall utvecklas.
• Bör vara lätt att hitta i och lätt att se vad som uppdaterats.
• Bör på ett enkelt sätt kunna refereras till från senare dokument istället för att upprepa information.

Hur tar man fram en kravspecifikation?

Ett bra sätt är att sätta sig in i hur slutanvändaren av programmet (ibland kunden, men inte alltid) arbetar. Vad kommer denna oftast att använda programmet till? Hur går denne tillväga nu? Hur vill denne gå tillväga när programmet är klart? Skriv ned ett scenario, punkt för punkt, hur användarens vanligaste uppgift skall gå till när programmet används. Se till att den vanliga vardagligaste användningen är enklast att hatera för användare. Fundera igenom vad programmet måste kunna för att användaren skall kunna utföra scenariot med programmet. Nu har ni identifierat de allra viktigaste kraven. Börja nu om med nästa arbetsuppgift användaren använder programmet för att lösa och identifiera flera krav. Ett sådant här scenario brukar kallas användningsfall (eng, use case) och är ett viktigt verktyg för att skapa sig en uppfattning om systemet som skall skapas. Användningsfall går med fördel igenom direkt med slutanvändaren när ni tror det är bra nog. Då kan slutanvändaren ge sina synpunkter och ni undviker missförstånd.

Hur skall dokumentet vara utformat?

Det bör finnas en försättssida, som berättar lite administrativ information. Vad är det för dokument? Vilket projekt tillhör det? Vilka arbetar på projektet? Vilken version är det? När var senaste ändring? Vem är ansvarig? Hur många sidor finns det totalt? Vem är kund? Och kanske något mer som är viktigt.

Det bör även finnas en inledning som berättar lite mer om vilka dokumentet vänder sig till i första hand och om hur dokumentet är strukturerat. Om det inte finns i ett separat dokument bör man även berätta lite mer informellt förklarande om projektet och dess mål, vad är det för problem programsystemet skall lösa och för vem?. Ett stort dokument bör ha en innehållsförteckning medan ett dokument på 2-3 sidor kanske inte behöver en.

Vidare bör dokumentet vara väl genomtänkt. Detta är viktigast av allt. Hur gör man för att ändra ett krav senare i projektet? Skall den gamla formuleringen finnas kvar? Hur gör man för att referera till ett krev från senare dokument? Hur gör man för att lägga till ett krav? Ställer det till det med någon numrering?

Viktigt är att allt är rakt och tydligt uttryckt. Använd ord som "ska", "skall", "måste". Ord som "kanske", "bör", "hoppas" bannlyses.

Kraven bör vara uppdelade i grupper där kraven i varje grupp hör samman på ett logiskt sätt. Minst brukar det finnas funktionella krav (t.ex. "en lista på böcker skall kunna visas", "klickar man på en bok i listan skall detaljinformation visas") och icke-funktionella krav (t.ex. "listan skall lagras i en SQLite-databas", "detaljinformationen skall visas inom 1 sekund").

Sidansvarig: Jonas Lindgren
Senast uppdaterad: 2014-09-02