TDP005 Projekt: Objektorienterat system

Kravspec

Information kring kravspecen

Kravspecen ska beskriva det spel ni vill implementera i kursen. Tänk på att det ska vara en beskrivning på vad spelet innebär, inte en beskrivning av hur det ska vara implementerat.

Kravspecen är ett kontrakt mellan er och kursledningen. Ert projekt kommer att bedömas utifrån ifall det uppfyller kraven i kravspecen. Vid behov kan kravspecen behöva uppdateras under projektets gång, ifall ni upptäcker att ni inte kommer att kunna göra allt ni tänker er av någon anledning. Ifall ni gör det ska ändringarna stämmas av och godkännas av Jonas. Om ni fått era ändringar av kravspecen godkända ska en ny version av den lämnas in i samband med den slutgiltiga demonstrationen.

Er kravspec kommer att bedömas utifrån vilken kvalitet dokumentet håller, och hur väl det uppfyller punkterna nedan. Vi kommer även att rimlighetsbedöma ert projekt, så att det passar kursens omfattning.

• Deadline: Se "Schema" i menyn.
• Skall omfatta minst 4 sidor
• Innehåll:
  • Spelidé: Vad går spelet ut på?
  • Målgrupp: Vilka är spelarna?
  • Spelupplevelse: Vad gör spelet underhållande att spela?
  • Spelmekanik: Hur interagerar man med spelet? Vilka kommandon? Vad driver spelet framåt?
  • Regler: Vilka regler styr spelet?
  • Visualisering: Hur skall spelet se ut? (ha med en skiss)
  • Kravformulering: Se beskrivning nedan
  • Kravuppfyllelse: En motivering av hur och vilka av kraven ovan uppfyller vilka av de allmänna kraven på spelet (se projektbeskrivningen)
• Kravformulering:
  • Kraven på ert projekt delas upp i två grupper absoluta krav, och tilläggsfunktionalitet
  • Absoluta krav ska uppfyllas för att ert projekt ska bli godkänt med betyg 3. De ska omfatta minst de minimikrav som beskrivs i den allmänna projektbeskrivningen.
  • Tilläggsfunktionalitet är extrakrav som går utöver minimikraven, och som ni kan implementera i mån av tid. För att få högre betyg krävs att en del av dessa är uppfyllda. Det är därför också viktigt att tillräckligt många krav finns att välja på här.
• Att tänka på för kraven:
  • Var tydlig! Det ska tydligt framgå hur spelet är tänkt att fungera, och vilka kraven är. Varje krav ska vara en separat punkt, inga längre meningar eller stycken som beskriver flera krav samtidigt
  • Använd mätbara krav! Om kraven är vaga är det svårt att bedöma ifall de har uppfyllts. Det ska vara möjligt att bedömma om varje enskilt krav är uppfyllt eller ej!
  • Var realistisk! Tänk verkigen igenom hur mycket som är rimligt att göra under kursen, och vilka ambitioner ni har i gruppen.
  • Var fullständig! Kraven i kravspecifikationen ska beskriva hela spelet, ingenting ska vara underförstått eller implicit. Är det en del av spelet finns det ett motsvarande krav.
• Information om kravspecar i allmänhet finns också i första föreläsningens slides.

Kravspecifikationens roll som designdokument

Nu är det ju inte meningen att jobba på ett traditionellt sätt på kursen där man börjar med en omfattande analys och skriver en kravspecifikation. När man jobbar agilt arbetar man ju istället med stories och acceptanstester, och själva system utgör en levande och aktuell specifikation.

Men eftersom det är vanligt att jobba med kravspecifikationer vill jag skriva några ord om det.

Det låter hur trist som helst med en kravspecifikation. Ofta är detta också sant. En kravspecifikation kan vara en tjock lunta med diverse dokument fulla med text och tabeller, och skärmbilder som specificerar användargränsnittet.

Vi vill föra in en ny syn på kravspecifikationens roll i systemutvecklingsprocessen. En kravspecifikation ska vara bärare av en vision för hur det färdiga systemet eller den färdiga produkten kan se ut. Det gäller att visionen bärs fram genom hela utvecklingsprocessen, från analys och design till implementation. På det sättet kommer hela projektet att vara delaktigt i förverkligandet av visionen, och resultatet kommer att vara "laddat" med energi från de som har arbetat med det. Det är ett synsätt som ni kanske aldrig kommer att få läsa om i systemutvecklingslitteraturen, men vad är ett system om inte resultatet av de mentala energier som har format det. Det är denna energi som förs vidare till användarna.

Exempel på kravspecifikationer

De här exemplena kan ge en fingervisning om hur en snygg kravspecifikation kan se ut, men bör inte ses som en fix mall som måste följas och är inte heller nödvändigtvis kompletta. Låt er inspireras..

Sidansvarig: Jonas Lindgren
Senast uppdaterad: 2014-11-21