Sidhuvudet innehåller central information om projektet:

• Projektgrupp 
• Aktuella versioner av projektets viktigaste dokument
• Länkar till dokumentens versionshistorik
• Projektdeltagare

Versionshistoria
Dokumentet inleds med versionshistorik. Versionshistoriken inkluderas från annan plats och är gemensam för samtliga versioner av kravspecifikationen. För kravspecifikationen skall samtliga versioner från version 0.99 redovisas i versionshistoriken.

Rubrik
Dokumentets rubrik utgörs av dokumentets namn "Kravspecifikation" samt versionsnummer.

Avsnitt 1. Referenslista
Under denna rubrik redovisas de dokument man refererar till i dokumentet, t ex projektplan etc. Det är t ex viktigt att en viss version av en testplan eller designdokument refererar till rätt version av kravspecifikationen.

Avsnitt 2. Introduktion

Avsnitt 2.1. Syfte
Här presenteras dokumentets syfte

Avsnitt 2.2. Omfattning
Här presenteras omfattningen på den programvaruprodukt som ska utvecklas och dess tänkta användning.

Avsnitt 2.3. Ordlista
Här presenteras och definieras olika icke självklara eller tvetydiga ord och begrepp som används i dokumentet.

Avsnitt 2.4. Dokumentöversikt
Här ges en översikt över dokumentet som sådant

Avsnitt 3. Produktbeskrivning
Här ges en grundläggande beskrivning av produkten samt bakgrunden till de krav som presenteras i dokumentet. Om programvaran har gränssnitt till andra system är det lämpligt att beskriva de gränssnitten här samt gränssnitt för användare och hårdvara.

Avsnitt 4. Krav
I detta avsnitt beskrivs kraven som ställs på programvaran.

Alla krav och användningsfall ska ha unika nummer. För att underlätta introduktion av nya krav under projektets gång är det ofta lämpligt att använda olika nummerserier för olika typer/kategorier av krav.

Syftet med projektplanen är att dokumentera projektes planering för projektets egen räkning och för kännedom för projektets projekthandledare.

Projektplanen beskriver vem som har ansvar för vad under projektet och när olika möten, arbetsinsatser och andra aktiviteter planers äga rum. 

För att underlätta detta tillhandahålls ett veckoschema i xls-format med kända upgifter som kan utökas eller minskas efter projektets egna idéer.

Följande rubriker förselås:

• Dokumentansvariga
• Projektdeltagare och ansvarsfördelning
• Tidplan(er)
• Externa deadlines
• Projektinterna deadlines
• Risker

Sidhuvudet innehåller central information om projektet:

• Projektgrupp
• Aktuella versioner av projektets viktigaste dokument
• Länkar till dokumentens versionshistorik
• Projektdeltagare 

Dokumentet inleds med versionshistorik. Versionshistoriken inkluderas från annan plats och är gemensam för samtliga versioner av testspecifikationen. För testspecifikationen skall samtliga versioner från version 1.0 redovisas i versionshistoriken. Att man refererar till rätt version av kravspecifikationen är viktigt.

Rubrik
Dokumentets rubrik utgörs av dokumentets namn "Testplan" samt versionsnummer.

Avsnitt 1: Referenslista
Under denna rubrik redovisas de dokument man refererar till i dokumentet, t ex projektplan etc. Det är t ex viktigt att en viss version av en testplan eller designdokument refererar till rätt version av kravspecifikationen.

Avsnitt 2: Introduktion
Här presenteras systemet som ska testas på ett sätt som kan förstås av någon som inte läst projektplan eller kravspecifikation.

Avsnitt 3: Testprocess
Här beskrivs samtliga moment i testprocessen. Vilka momenten är varierar mellan olika organisationer och projekt men vanligt förkommande är:

• enhetstest
• integrationstest
• systemtest
• acceptanstest

För varje moment ska åtminstone följande beskrivas:

• Ansvarig: vem ska genomföra testerna. Enhetstester genomförs ofta av samma personer som utvecklat komponenten medan system- och integrationstester ofta genomförs av testspecialister.
• Typ av test: T ex strukturell (white-box) eller funktionell (black-box)
• Härledningsstrategi: Vilken eller vilka metoder man använder för att ta fram testfallen, t ex complete statement coverage.
• Stoppregler: Beskriver vad som ska ha uppnåtts för att testmomentet ska kunna avslutas, t ex alla testfall kan exekveras utan att nya fel inträffar

Avsnitt 4: Testade artefakter
Här beskrivs vilka system eller systemdelar som ska testas i de olika testmomenten. Vid enhetstest behöver man ofta låta simulatorer eller stubbar i en simulerad miljö representera delar av systemet som ännu inte utvecklats medan man under systemtest använder målmiljö och under acceptanstest målmiljö med ovana användare.

Avsnitt 5: Rutiner för dokumentation av testresultat
Här beskrivs hur utfallen från testerna ska dokumenteras, sparas och kommuniceras.
 

Avsnitt 6: Testfall för systemtest
Här beskrivs var man hittar testfallen för systemtest, t ex i appendix. En viktig del av avsnittet beskriver kopplingen mellan krav och test och visar att:

• samtliga krav testas i minst ett testfall
• samtliga test testar minst ett krav 

Lämpligen visas detta genom en kravtäckningsmatris.

Appendix: testspecifikation
Här beskrivs testfallen för de olika testmomenten (ETSA01: Testfallen för minst ett av testmomenten skall beskrivas här)

Alla dokument utöver källkoden ska göras i projektets projektwebb på googled docs/drive enligt standardiserad namngivning och förbestämd struktur. Det är viktigt att endast projektmedlemmarna har läs- och skrivrätt på sidorna. 

Inlämningar av dokumenten sker med automatik såtillvida att projekthandledarna från och med inlämningstidpunkten kan på in på projektgruppens sidor och hämta rätt version. Projektet fortsätta förslagsvis arbetet i en ny version av dokumentet.

6.4.3 Läs- och skrivrätt
Det är inte tillåtet att dela ut läs- eller skrivrättigheter till andra än StIL-identiteter i den egna projektgruppen.

Blankett för ansökan om att få ändra i kravspecifikationen efter att milstolpe 1 uppnåtts:

change_request_form.txt

Instruktioner:

1. Ladda ner en kopia av blanketten på din dator.
2. Fyll i del A.
3. Skicka till projekthandledare som bilaga i ett mail.
4. Projekthandledare fyller i del B och skickar tillbaka.

Alternativt kan motsvarande rutin lösas i projektwebben i dialog med projekthandledaren.

Nedanstående blanketter kan användas både vid individuell granskning och för att sammanställa granskningsprotokoll:

Blankett för granskningskommentarer

Blankett för granskningskommentarer

Processmodellen tillhandahåller en avancerad och en enklare chceklista att användas vid granskning av kravspecifikation och testplan med testspecifikation. Båda typerna av checklistor är lämpliga att använda i anslutning till den individuella granskning som föregår ett formellt eller informellt granskningsmöte. De avancerade checklistorna innehåller rekommendationer om hur man bör gå tillväga vid individuell granskning.

Avancerad checklista krav

Avancerad checklista test

Enkel checklista krav

Enkel checklista test

Vid granskning med hjälp av checklista är det lämpligt att granskningsprotokollet ange dels vilken checklista som använts och dels vilken feltyp eller problemtyp man syftar på när man identifierat ett fel/problem.

För projektplan, designdokument, manualer, programkod och övriga dokument tillhandahålls ingen checklista.

Syftet med designdokumentet är att visa vilka klasser projekten avser implementera och hur dessa klasser hänger ihop. Några avancerade designlösningar förväntas inte. Fokus ligger istället på att upptäcka om projektets designval är så komplexa eller svåra att förstå att man kan befara att vidare arbete avsevärt försvåras. Samtliga klasser (undantag GUI, se nedan) som projektet planerar att implementera beskrivs både i ett klassdiagram och i form av  klassbeskrivningar.

Följande förväntas av klassdiagrammet:

• Klassdiagrammet ger en tydlig bild av hur klasserna hänger ihop. Attribut och metoder behöver inte visas. Se  E/R-diagram från uppgift R.5 för inspiration på hur samband mellan klasser kan uttryckas.
• Multipliciteter på samband visas.
• Färdigskrivna klasser från Javas Swingbibliotek behöver inte beskrivas, inte heller lyssnarklasser etc. som projektet troligtvis implementerar själv. 
• Betrakta gärna GUIt som en entitet i klassdiagramet och uttryck samband till övriga klasser.
• Projektet får gärna inkludera gränssnitten mot hårdvaran. Tänk dock på att syftet med klassdiagramet är att beskriva implementationen av systemet, inte hur systemet förhåller sig till omvärlden (kontextdiagram).

Följande förväntas av klassbeskrivningar:

• Ansvarig utvecklare och kort förklaring av klassens syfte och eventuellt hur den är tänkt att fungera.
• Alla publika metoder. Namn, parametrar och returvärde.

Under utvecklingen av systemet kommer projektet sannolikt vilja göra förändringar av designen. Notera då principerna för ändringshantering i avsnitt 5.7 med den skillnaden att projekthandledaren inte behöver engageras. Hur ofta man behöver ändra designdokumentet anges inte men projektgruppen ansvarar själv för att designdokumentet vid slutleverans stämmer överens med det system som implementerats.

Det finns en uppsjö av verktyg att använda sig av för programvarutestning, både gratisvarianter och kommersiella produkter. I kursen presenterar vi två verktyg som implementerar rön från forskningsfronten inom test, Hexawise och CodeCover. Båda går att använda utan kostnad. Nedan följer korta instruktioner för att komma igång med verktygen.

Kom igång med verktygen