Göm menyn

TDDI02 Programmeringsprojekt

Kravspecifikation (obligatorisk)


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. Där varje punkt beskriver en uppgift 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 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ående den 'rudimentära kravspecifikationen'

Ni ska inte förfärdiga en 'riktig', fulländad 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 det ska hända, och vad det resulterar i.

Kom ihåg ingenting kan 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, och fullständig.

Funktionaliteten kan behöva delas upp i flera nivåer av krav; de nödvändiga (ska-kraven) och de mindre nödvändiga, men trevliga (bör-kraven). Man kan även ha fler nivåer om man vill det. Kraven 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änssnittets 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 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 revisionshistorik 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.

Möjliga rubriker i en kravspec

  • Identifikation
  • Sammanfattning
  • Innehållsförteckning
  • Inledning
  • Användarna
  • Funktionella krav
  • Ska-krav
  • Bör-krav
  • I mån av tid-krav
  • Produktkomponenter
  • Programvara
  • Maskinvara
  • Dokumentation
  • Effektivitet
  • Kompabilitet
  • Konfiguration
  • Installation och service
  • Tillförlitlighet
  • Ordförklaringar
  • Index

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å hur programsystemet skall byggas upp på bästa sätt.
  • Används av programmerarna för att veta hur koden de skriver skall få programsystemet att bete sig.
  • Används av testaren för att verifiera vilka (att alla) krav som är uppfyllda.
  • Används av programmerarna för att veta hur koden 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 hantera 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 fler 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ås 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 krav 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: Filip Strömbäck
Senast uppdaterad: 2017-06-26