Syfte:

Frågans syfte är att kontrollera att studenten har lärt sig innebörden och användandet av 4 utvalda sätt att skriva funktionella krav på (4 sätt som vi tycker är viktiga att kunna).

Tentamensfråga:

Det finns ett antal olika sätt att notera funktionella krav på som passar olika bra beroende på vilken typ av produkt som ska utvecklas och vilka som är delaktiga i kravprocessen. Här nedan presenteras fyra av dem. Din uppgift är att ge en kort beskrivning av hur metoden fungerar samt nämn en fördel och en nackdel med metoden.

a) Händelselista och funktionslista (Eventlist and functionlist)

b) Skärmbilder och prototyper (Screens and prototypes)

c) Uppgift och lösning (Task and support)

d) Användningsfall (Use cases)

Svar:

a) Händelselistan beskriver de händelser som systemet ska stödja. Dessa händelser kan skrivas både på domännivå eller på produktnivå (eller både och). Ett exempel på en domännivåhändelse kan t ex vara ”Boka platsbiljett på tåg” och ett exempel på en produktnivåhändelse kan vara ”Hitta ledig plats”. En fördel med händelselistor är att det är en bra och lättförstålig checklista på vad man ska utveckla, och en nackdel är att det lätt blir designkrav vilket kanske inte efterfrågas. (s 80-82)

b) Skärmbilder och prototyper går ut på att man tar fram exempel på hur den färdiga produkten ska se ut och att man sedan sätter dessa exempel som krav (för att senare skapa innehåll bakom fasaden). En fördel med prototyper är att det är lätt att få feedback från kunder redan i kravstadiet viket oftast leder till en bättre kundacceptans när produkten väl är färdig. En nackdel är att metoden passar dåligt om inte uppgifterna som systemet ska stödja är väl definierade från början. (s 88-91)

c) Uppgift och lösning är en variant av ”task descriptions” och beskriver en domännivåaktivitet (t ex ”Sälja tågbilett”) som bryts ner i ”sub-tasks” (t ex ”skriv ut biljetten”) vilka i sin tur får förslag på lösningar. En fördel är att de är lätta för kunden att utvärdera samt att kunden kan vara delaktig i hur uppgifterna ska lösas istället för att det helt och hållet ligger på utvecklarnas ansvar. En nackdel är att det är mycket jobb med att ta fram alla ”task’s”. (s 104- 113)

d) Ett use case beskriver hur en funktion i produkten används och genom att täcka in produktens all funktioner får man fram hur den ska se ut och vad den ska klara av. En fördel med use cases är att de är relativt lättförståliga och en nackdel med dem är att de ofta hamnar nere på designnivå och att uppgifter som inte har ett bestämt händelseschema blir svåra att få med.

Kommentar:

Poängsättningen bör vara jämnt fördelad mellan de fyra uppgifterna och inom vare deluppgift ska metodbeskrivningen tilldelas lika många poäng som för-och nackdelar tillsammans. Möjligtvis är frågan lite väl omfattande men i så fall går det bra att ta bort en eller två metodbeskrivningar.