Der er ikke noget endeligt facit for, hvordan man strukturerer rapporten, men den skal overfor en fremmed læser præsentere og dokumentere projektarbejdet og de resultater det har givet, på en tydelig, detaljeret og letforståelig måde.
Nedenfor ser du et overordnet bud på en struktur der kan være hensigtsmæssig at benytte eller læne sig op ad:
Forside. Her skrives rapportens titel, indgående fag, elevens navn, vejlederes navn, dato samt rapportens antal anslag.
Abstract (engelsk), eller resume (dansk). Forkortet fortælling over rapportens spørgsmål, metode at undersøge disse med samt resultater. Man skal gerne have forstået hele rapporten blot ved at læse abstract/resume!
Indholdsfortegnelse (husk sidetal). Brug formaterne og den automatiske funktion i word til at generere indholdsfortegnelse
Front matter tæller ikke med i antallet af sider!
Redegør for projektets rammer for den uindviede læser. Hvad handler projektet overordnet om? Hvor er vi henne fagligt og praktisk dvs. hvad har du fundet ud af ifm. det faglige område og de centrale begreber indenfor det?
Konkret sammenhæng for det produkt, der skal udvikles og de grundlæggende problemstillinger/opgaver, det skal løse. Her formuleres en problemformulering som et spørgsmål der kan besvares i rapportens konklusion. Det er vigtigt at problemformuleringen er tydelig/entydig, os således præcist definere hvad der undersøges, og herved også afgrænser hvad der ikke undersøges.
Kunne også mere sigende kaldes for undersøgelses metoden. Her er tale om en redegørelse over de fremgangsmåder og metodeplatforme, der er benyttet i forbindelse med analyserne og udviklingsarbejdet i øvrigt. Kort sagt: Hvordan er viden blevet til, og hvordan er det blevet brugt for at besvare opgavens spørgsmål (problemformuleringen). Dette afsnit bør ofte omskrives/rettes til, til sidst!
Analystiske undersøgelser, der giver svar på, hvilke features og funktioner produktet skal indeholde. Det er f.eks. målgruppeanalyse, afsenderanalyse (interessentanalyse i øvrigt), 'user stories', referenceprodukter (konkurrerende løsninger), research af tekniske muligheder, lovgivning/etik, sikkerhed og læsning af relevant teori. Kort sagt konkrete metoder fra de ingående fag.
Dette skal føre til ny viden om krav til produktet. Slut evt. af med en samlet oversigt/delkonklusion for dine identificerede krav.
Diskussionsafsnittet bruges til at bringe mulige løsninger på de identificerede krav i spil. Disse løsninger og deres design og udvikling dokumenteres - evt. i skitseform. Hvordan kommer produktet så til at se ud, og hvilke teknologier anvendes hvordan? Kronologi og teknisk dokumentation.
Slut evt. af med en samlet oversigt/delkonklusion for dine beskrevne løsninger (særligt hvis denne sektion er blevet meget lang).
Hvorvidt er målene fra problemformuleringen opfyldt. Hvor langt er løsningen i forhold til de krav (evt. user stories), du har analyseret sig frem til?. Hvad er opfyldt, hvad mangler (og evt. hvorfor)
Kan den viden og de resultater, projektet har kastet af sig være relevant i andre sammenhæng og hvor?
Hvilke potentialer kan ses?
Faglitteratur, tutorials o.s.v. som I har benyttet.
A/V-materiale kan godt indgå.
Kildekoder, logs, dokumentation af undersøgelser, test mv.
End matter tæller ikke med i antallet af sider!