Kravspecifikation. Sammanfattning. Redaktör: Patrik Sandström Version: 2.0 Datum: I Tal-Lab kan ingen höra dig skrika

Transkript

1 I Tal-Lab kan ingen höra dig skrika Kravspecifikation Redaktör: Version: 2.0 Datum: Sammanfattning Projektgruppen Pum-grupp 1 skall utveckla ett system för talsyntes åt avdelningen för Human-Centered Systems (HCS) vid vid Linköpings Tekniska Högskola. Talsyntesen skall bygga på konkatenering av ord som hämtas från en databas och resultatet skall presenteras i form av ljud och rörelser. Kravspecifikationen beskriver de krav som ställs på systemet, samt en översiktlig bild av systemet och dess användare. Dokumentet ligger till grund för den fortsatta utvecklingen av systemet i form av arkitektur- och designspecifikation. Den innehåller även villkor för leveransen samt acceptanstest för utvärdering av systemet.

2 Projektidentitet Projektgrupp Stum Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare Kjell Enblom Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig Andreas Rasmussen Implementationsansvarig Gustav Veide Systemansvarig Kundansvarig Thomas Janowski Testansvarig E-postlista för hela gruppen Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, Mustapha Skhiri, Handledare Sten Sunnergren, Examinator och kursansvarig Robert Kaminski, IDA

3 Dokumenthistorik Version Datum Utfärdade ändringar Utfärdade av Dokumentet skapades Lade till info ang. databasen i kap Uppdatering enligt inspektionsprotokoll Separerat momenten inmatning av text och uppmärkning genom hela dokumentet. Lagt till krav 4.2 Grafisk Användargränssnitt. Utökat 1.3 Dokumentöversikt. Tagit bort arkitekturdelar ur 2.4. Ny bild och mer konsekvent text i hela 3.1. Ändrat förklarning/motivering i I-1.1, I-3.3, I-4.1. Lagt till villkor för acceptanstestets utförande i kapitel 10. Testfallen i bilaga C är helt omarbetade. De är mer konkreta och testfallen täcker fler än ett krav. Två negativa testfall, AT-2, AT-4, har lagts till i bilaga C. Gustav Veide ii

4 iii

5 Kravspecifikation Inledning Syfte Läsanvisningar Dokumentöversikt Dokumentberoende Distribution Förklaring av begrepp Projektbeskrivning Parter Bakgrund Syfte Systembeskrivning Användarkategorier Användarmiljö Antaganden Användningsfall Användningsfallsdiagram Mata in indata Lägga till data Söka i databasen Ta bort data Kravutformning Notation Kravklassificering Identitetsnummer Kravnivåer Normal Extra Motivering Status Källa Påverkar Krav-källförteckning Grunder för talsyntes Utökad talsyntes Syfte Databasens utformning Databasens grundfunktioner Testdata Användarens bakgrund Leveranskrav Funktionella krav Talsyntesmotor Databas Icke-funktionella krav

6 Kravspecifikation Talsyntesmotor Databas Datainsamling Användargränssnitt Produktkomponenter Mjukvara Demonstration Dokumentation Leveransvillkor Tid för leverans Plats för leverans Leveransprotokoll Installation Utbildning Acceptansvillkor Avtal Acceptanstest Referenser Externa dokument Interna dokument Bilaga A Avtal A.1 Parter A.2 Avtalad specifikation A.3 Acceptans av produkten A.4 Leverans av produkten A.5 Underhåll A.6 Projektavslut A.7 Upphosvrätt och nyttjanderätt A.8 Intrångstalan A.9 Force majeure A.10 Skiljedom A.11 Signatur Bilaga B Leveransprotokoll B.1 Mjukvara B.2 Demonstration B.3 Dokumentation B.4 Signatur Bilaga C Acceptanstestfall C.1 Testfallsutformning C.2 Testprotokoll

7 1 Inledning Detta kapitel beskriver dokumentets upplägg och innehåll samt innehåller generell information om dokumentet. 1.1 Syfte Dokumentets syfte är att ge en beskrivning av det system som skall produceras och att definiera de krav som kunden har på systemet. Kraven som finns på systemen skall fastställas fullständigt och skall vara en grund för överenskomelsen med kunden för vad som skall levereras när projektet är klart. Dokumentet fungerar sedan som en grund till arkitektur- och designspecifikationen. 1.2 Läsanvisningar För att få en snabb översikt över vad dokumentet innehåller rekommenderas avsnittet 1.3 Dokumentöversikt i kapitlet Inledning. För att få en översikt över vad projektetgruppen skall utveckla rekommenderas kapitel 2 Projektbeskrivning. För att få en mer detaljerad bild av vad som krävs av systemet rekommenderas kapitel 6 Funktionella krav och kapitel 7 Icke-funktionella krav. Kravens utformning beskrivs i kapitel 4 Kravutformning. Detta är den viktigaste delen i dokumentet och ligger till grund för avtalet mellan kund och projektgrupp. För att få en översikt över vad som kommer att levereras rekommenderas kapitel 8 Produktkomponenter. För att veta i detalj vad som skall levereras bör Kapitel 9 Leveransvillkor och kapitel 10 Acceptansvillkor läsas. Kapitel 1: Inledning 1

8 1.3 Dokumentöversikt 1. Inledning Detta kapitel beskriver dokumentets upplägg och innehåll samt innehåller generell information om dokumentet. 2. Projektbeskrivning Innehåller en övergripande beskrivning om systemet som skall utvecklas. Innehåller information om kunden, systemet och användaren. 3. Användarfall Beskriver systemets användare och innehåller användningsfall som beskriver hur systemet skall fungera i vanligt förekommande situationer. 4. Kravutformning Beskriver hur kraven är utformade, dess notation samt hur förändringar av kraven skall dokumenteras. 5. Krav-källförteckning Beskriver kravens ursprung, vem eller vad som ställt ett krav. 6. Funktionella krav Beskriver vilka funktioner som skall ingå i systemet. 7. Icke-funktionella krav Beskriver de regler och ramar som de funktionella kraven skall uppfylla och hålla sig inom. 8. Produktkomponenter Beskriver vilka komponenter, mjukvara och dokumentation, som den färdiga produkten kommer bestå av. 9. Leveransvillkor Beskriver var, när och hur systemet skall levereras till kunden. 10. Acceptansvillkor Beskriver vilka villkor som måste vara uppfyllda för att kunden skall anse att systemet är godkänt. 11. Referenser En lista av referenser. Bilaga A: Avtal Beskriver det avtal som skall ingås mellan kund och projektgrupp om vad som skall levereras till kunden. Bilaga B: Leveransprotokoll Beskriver det protokoll som skall användas av kunden för att säkerställa att alla komponenter finns med i systemet vid leverans. Bilaga C: Acceptanstest Beskriver de testfall systemet måste klara av för att verifiera att alla krav är uppfyllda. 2 Kapitel 1: Inledning

9 1.4 Dokumentberoende Förändringar i kravspecifikationen kan innebära att följande dokument måste uppdateras: Projektplan [Aghajani, 2005] Arkitekturspecifikation [Rasmussen, 2005] Designspecifikation [Millving, 2005] Programmeringshandbok [Rasmussen, 2005] Systemförvaltningsdokument [Enblom, 2004] Testplanering [Janowski, 2005] 1.5 Distribution Detta dokument kommer att distruberas till följande: Dokumentexaminatorerna David Broman och Angela Johansson. Projektgruppens handledare Sten Sunnergren. Kunden, kontaktpersoner Bertil Lyberg och Mustapha Skhiri. Projektgruppens dokumentpärm. Kapitel 1: Inledning 3

10 1.6 Förklaring av begrepp I det här avsnittet defineras begrepp som förekommer i dokumentet. Talsyntes Tal Talsyntesmotor Orator Metoder för att generera mänskligt tal på syntetisk väg med hjälp av datorer. Metoden som är aktuell för detta projekt är talsyntes genom konkatenering av ord och stavelser. Här avses ljudet av ord och satser. Den del av systemet som genererar talet. Orator är ett talsyntessystem som bygger på konkatenering av difoner. I Orator finns ett animerat ansikte för uppspelning av rörelser. Konkatenering Uppmärkt ord Stavelser Difoner Tallabbet Sammanslagning av data. Uppmärkningen av ett ord beskriver hur ett ord betonas. Samma ord låter alltså på olika sätt beroende på hur det är uppmärkt. Delbitar av ord. T ex är ordet Flickan uppdelad i två modifierade stavelser, flik och kan. Delbitar av stavelser. Ett rum på Institutionen för Datavetenskap där det finns utrustning för att spela in tal- och rörelsedata. Tabell 1:.Förklaring av begrepp 4 Kapitel 1: Inledning

11 2 Projektbeskrivning Det här kapitlet ger en övergripande beskrivning av projektet. 2.1 Parter Parterna involverade i projektet är kunden och utvecklaren av systemet. Kunden är avdelningen för Human-Centered Systems vid Institutionen för datavetenskap vid Linköpings Tekniska Högskola. Kontaktpersoner är Bertil Lyberg och Mustapha Skhiri. Utvecklare är PUM-grupp 1 med kontaktperson, kundansvarig. 2.2 Bakgrund På avdelningen för Human-Centered Systems bedrivs bland annat forskning om talsyntes. Deras forskning avser talsyntes genom konkatenering av ljudfragment inspelade av en människa och lagrade i en databas. Kunden har ett färdigt system för animering till inkommande talspecifikation, kallat Orator [Projekt Orator, 2005]. Talsyntesen som styr Orator bygger på difoner. I Orator spelas talsyntesen upp som tal samt rörelser på ett animerat ansikte. Kunden är nu intresserad av ett liknande talsyntes-system som bygger på konkatenering av uppmärkta ord och stavelser. Detta till skillnad från Orator som är uppbyggt av ännu mindre delbitar av ord. Kunden vill att systemet som projektgruppen har fått i uppdrag att utveckla, i framtiden skall vidareutvecklas till ett helt eget system. Det systemet skall kunna spela upp både tal och rörelser med en talsyntes som i slutändan svårligen kan skiljas från den individ som genererat taldatabasen. 2.3 Syfte Kunden vill att projektgruppen skall utveckla ett system som skall bli den första byggstenen i ett större system för talsyntes. Målet med det här projektet är att bygga upp en databas med tal och rörelsemönster samt skapa ett färdigt separat system som kan spela upp konkatenerat tal. För att det här projektet inte skall bli för omfattande skall systemet använda det befintliga systemet Orator för uppspelning av rörelser. Kundens huvudsakliga mål är inte att få talsyntes av hög kvalitet. Utan ett system för att testa en annan typ av talsyntes än den som de använt tidigare. Det är under dessa premisser projektet börjar och i följande avsnitt beskrivs detaljerna för systemet. Kapitel 2: Projektbeskrivning 5

12 2.4 Systembeskrivning Systemet kommer att bestå av en databas och till den en motor för sökning och bearbetning av data. Databasen består av ord och stavelser samt en uppmärkning av varje ord och stavelse som beskriver hur det betonas. I databasen lagras samma ord på flera olika platser beroende på hur det betonas. Varje ord märks därför upp enligt speciella regler. För varje ord och stavelse med respektive uppmärkning lagras tal- och rörelsedata. Databasen måste vara expanderbar så att användare själv kan lägga till ord och stavelser. För att användaren skall kunna ändra innehållet i databasen måste det finnas ett gränssnitt mellan databasen och användaren. Systemet skall fungera så att användare ger indata i form av ord. Inmatningen av indata sker i användargränssnittet och är uppdelat i två moment. Först skriver användaren in själva sekvensen av ord, sedan bestämmer användaren hur orden betonas genom att märka upp dessa. Resultatet blir att systemet spelar upp ljud och rörelser motsvarande användarens sekvens av ord. För att göra detta skall systemet gå igenom indatat ord för ord, leta upp rätt ord i databasen, hämta ut motsvarande data och slutligen konkatenera ihop datat. När samtliga ord gått igenom denna process skall ljudet och rörelserna spelas upp. Om en sökning på ett ord misslyckas skall systemet dela upp ordet i stavelser och på samma sätt söka efter stavelser och sedan sätta ihop dessa till det ursprungliga ordet. Ta ut ord Konkatenera tal Spela upp Sök ord Sista ordet? ja nej Figur 1: Förenklat flödesschema över talsyntesmotorn 6 Kapitel 2: Projektbeskrivning

13 Således kommer systemet bestå av: En databas med uppmärkt tal. Gränssnitt till databasen för att kunna lägga till data. Talsynteskomponent för sökning och uppmärkning av ord Användargränssnitt för inmatning av text och dess uppmärkning. Gränssnitt till Orator för uppspelning av röresler. TALSYNTES- MOTOR ANVÄNDAR- ORATOR Visualiserings- komponent GRÄNSSNITT DATABAS Figur 2: Systembeskrivning Kapitel 2: Projektbeskrivning 7

14 2.5 Användarkategorier Till det här systemet identifieras bara en typ av användare som i fortsättningen kallas just användare. Användaren av systemet har inte som mål att få ut en talsyntes som låter bra. Användarens intresse ligger snarare i att testa hur denna metod för talsyntes fungerar i stort, identifiera brister och möjligheter till vidareutveckling. Det är tydligt att användarens mål och kundens mål med systemet är snarlika, och det är troligen så att det är kunden, eller någon som bedriver liknande forskning, är användarna av det här systemet. För att underlätta projektgruppens arbete i utformningen av systemet, har följande antaganden gjorts om användaren: Olika teknisk bakgrund. Vill utvärdera hur denna typ av syntes fungerar i praktiken. Förväntar sig inte ett perfekt resultat. Vet vilka ord som finns i databasen. Har kunskaper i talsyntes. Kan, givet ett visst indata, förutsäga resultatet av talsyntesen. 2.6 Användarmiljö Eftersom användarna har olika teknisk bakgrund är det lämpligt att systemet körs på ett Windows-system då de flesta är bekanta med det. Det måste även finnas möjlighet till att spela upp ljud. För att inte skapa några onödiga begränsningar vill dock kunden att det skall finnas möjlighet att köra systemet även på Unix. För användaren skall det i användargränssnittet vara möjligt att skriva in text och märka upp den. Användargränssnittet är grafiskt för att underlätta inmatningen av indata. Utöver detta finns inga krav på vare sig teknisk eller annan miljö. 2.7 Antaganden Tidigare i kapitel 2 Projektbeskrivning har antaganden gjorts om kund och användare. Här följer några generella antaganden om förutsättningar och begräsningar: Kunden skall bistå projektgruppen med hjälp vad gäller uppmärkning av ord då projektgruppen skall spela in tal och rörelser för att av detta bygga upp en databas. Inspelning av tal sker i tallabbet på Institutionen för Datavetenskap, där kunden tillhandahåller all utrustning. Projektgruppen har tillgång till tallabbet och de datorer som finns där. Kunden tillhandahåller kod från Orator. Kunden ställer inga specifika krav på kvaliteten av talsyntesen. 8 Kapitel 2: Projektbeskrivning

15 3 Användningsfall I det här kapitlet ges en generell bild över hur systemet kommer användas. Användaren och dennes egenskaper är redan identifierade i kapitel 2.5 Användarkategorier. 3.1 Användningsfallsdiagram STUM Mata in indata Användare Lägg till data Ta bort data Söka i databasen <<extends>> Figur 2: Användningsfallsdiagram Mata in indata Användaren vill höra talsyntesen för en viss text, så användaren startar upp sin Windows XP-maskin, sätter på sig sina hörlurar och startar systemet. Användaren vet att orden i texten, som hon tänker mata in, finns lagrade i databasen, antingen som ord eller som stavelser. Eftersom ett ord låter olika beroende på hur det betonas, märker användaren även upp varje ord så att dessa betonas som hon vill. Reglerna för denna uppmärkning är användaren redan insatt i. Användargränssnittet får uppmärkningen att kännas naturlig för att inte förvirra användaren i detta moment. När användaren sedan matat in text med motsvarande uppmärkning letar systemet upp texten, ord för ord, i databasen. När data för alla ord hämtats och satts ihop, spelas talsyntesen upp för användaren i form av ljud och rörelser Lägga till data Användaren vill utöka databasen för att kunna skapa fler meningar att testa talsyntesen på. Hon har tidigare samlat in data till de ord och stavelser hon vill lagra. Användaren lägger in ordet, dess uppmärkning samt ljud och rörsledata i databasen via databasgränssnittet Söka i databasen Användaren behöver ta reda på vilka ord som finns i databasen. Till exempel är det en ny användare med en gammal databas eller så är databasen så pass stor så användaren inte kan komma ihåg allt som finns där. Via databasgränssnittet söker användaren efter ord och stavelser. Kapitel 3: Användningsfall 9

16 3.1.4 Ta bort data Användaren behöver ta bort data ur databasen. Till exempel har hon funnit felaktig data eller har bättre data hon vill lagra. För att ta bort ett ord eller en stavelse använder hon tabort-funktionen i databasgränssnittet. Om användaren är osäker på om ett visst ord finns i databasen använder hon sökfunktionen via databasgränssnittet. 10 Kapitel 3: Användningsfall

17 4 Kravutformning Detta kapitel beskriver hur kraven är utformade, dess notation samt hur förändringar av kraven skall dokumenteras. 4.1 Notation Beskriver notationen. F-1.0 Kravets titel Beskrivning av kravet. Anger kravets nivå, se avsnitt 4.4 Motivering: Anger varför kravet finns, se avsnitt 4.5. Status: Anger kravets status. se avsnitt 4.6. Källa: Anger var kravet kommer ifrån, se avsnitt 4.7. Påverkar: Anger andra krav som påverkas av det här kravet, se avsnitt Kravklassificering Ickefunktionella krav beskriver de egenskaper hos systemet som inte är direkt relaterade till vilka funktioner systemet har. Detta kan vara till exempel prestanda, användarvänlighet eller säkerhet. Funktionella krav beskriver vilka funktioner systemet har, det vill säga vad det skall kunna utföra. Produktkomponenter behandlar vilka komponenter som skall ingå i den färdiga produkten. Dessa innehåller själva mjukvaran och dokumentationen till den. 4.3 Identitetsnummer För att på ett enkelt och entydigt sätt kunna referera till varje krav ges kraven ett unikt identitetsnummer. Identiteten skrivs på formen X y.z där X kan vara antingen F, I eller P. F står för ett funktionellt krav, I står för ett ickefunktionellt krav och P specificerar en produktkomponent. Efter kravklasssificeringen så följer två siffror y och z där den den första anger under vilken kategori kravet ligger och den andra är ett unikt nummer under denna kategori. Från och med version 1.0 av dokumentet får inte kravens nummer ändras. Om det tillkommer nya krav efter version 1.0 av kravspecifikationen så sorteras de in under rätt rubrik med nästkommande unika nummer. Om krav bortförhandlas efter version 1.0 så skall de står kvar i kravspecifikationen men deras status skall då ändras. Mer om detta i avsnitt 4.5. Kapitel 4: Kravutformning 11

18 4.4 Kravnivåer Samtliga krav är klassificerade under en av tre kravnivåer. Nivån anger kravets prioritet samt betydelse för systemets funktionalitet Denna nivå beskriver baskraven. Dessa skall vara uppfyllda vid leverans. De är grundläggande för systemets funktionalitet Normal Krav på normalnivån skall vara uppfyllda vid leverans om projektet inte drabbas av några oförutsägbara händelser som leder till tidsbrist i projektet. Krav på denna nivå skall uppfyllas för att systemet skall få en tillfredställande funktionalitet. Ett normalkrav kan endas tas bort efter förhandling med kunden Extra Extra krav är de lägst prioriterade kraven och skall endast implementeras om det finns tid över när både bas och normalkrav är uppfyllda på ett tillfredsställande sätt. 4.5 Motivering Motivering beskriver varför kravet är med. Detta för att enkelt kunna se om kravet tillför systemet något. 4.6 Status Status beskriver om kravet är aktivt eller inte. Om kravet skall uppfyllas så är kravet aktivt. Om projektgruppen under projektets gång vill ta bort ett krav i kravspecifikationen så måste kravet först förhandlas bort med kunden. Sedan uppdateras kravets status till inaktivt i kravspecifikationen. 4.7 Källa Anger en referens till en källa i kapitel 5 Krav-källförteckning som beskriver kravets ursprung. 4.8 Påverkar Under denna rubrik anges vilka andra krav detta krav påverkar. Om det kravet ändras skall det vara enkelt att hitta vilka andra krav som eventuellt måste modifieras på grund av denna ändring. 12 Kapitel 4: Kravutformning

19 5 Krav-källförteckning I det här kapitlet beskrivs samtliga källor till de krav som defineras i dokumentet. Alla krav har en referens till detta kapitel som anger vem eller vad som ställt kravet. 5.1 Grunder för talsyntes Kravet kommer från de funktioner som är grundläggande för att skapa talsyntes enligt den metod systemet avser, se kapitel 2.4 Systembeskrivning. För att skapa denna typ av talsyntes måste systemet kunna konkatenera och spela upp tal, dessutom måste det finnas indata, alltså en beskrivning vilket tal systemet skall skapa. Ursprungligen kommer de här kraven ur kundens krav att skapa talsyntes enligt denna metod. 5.2 Utökad talsyntes I kapitel 2.2 Bakgrund, beskrivs att kunden har en vision om ett system som kan mer än bara spela upp ljuddata ur en databas. De här kraven handlar om utökad funktionalitet så som möjlighet att spela upp rörelser och signalbehandla det konkatenerade ljudet. 5.3 Syfte Kraven kommer ur projektets syfte som är direkt ställt av kunden, se kapitel 2.3 Syfte. 5.4 Databasens utformning Kraven kommer ur det faktum att databasen är uppbyggd av ord och stavelser med uppmärkning samt data för talsyntesen, se kapitel 2.4 Systembeskrivning. 5.5 Databasens grundfunktioner Kraven kommer från hur databasen används, både av talsyntesmotorn och användaren, se kapitel 2.4 Systembeskrivning och kapitel 3 Användarfall. 5.6 Testdata Kraven är direkt ställda av kunden för att ha en liten men fungerande mängd data i databasen när systemet är klart. 5.7 Användarens bakgrund Kraven har som uppgift att se till att systemet tar hänsyn till användarens mål, kunskaper, begränsningar och andra egenskaper, se kapitel 2.5 Användarkategorier. 5.8 Leveranskrav Komponenter som kunden kräver skall finnas med vid leverans. Kapitel 5: Krav-källförteckning 13

20 14 Kapitel 5: Krav-källförteckning

21 6 Funktionella krav Detta kapitel beskriver de funktionella kraven som ställs på systemet. Funktionella krav, är krav som ger systemet utökad funktionalitet. 6.1 Talsyntesmotor Det här avsnittet beskriver de krav som är specifika för talsyntesmotorn. F-1.1 Inmatning för uppmärkt text En användare skall kunna mata in ord och märka upp dessa på ett format sådant att systemet klarar av att utföra en korrekt sökning på dessa ord. Motivering: Indata måste skickas manuellt till systemet. Användaren gör detta. Källa: se kapitel 5.1 Grunder för talsyntes. Påverkar: F-1.2, F-1.3, I-4.2 F-1.2 Ta ut uppmärkt ord Systemet får som indata en sekvens med ord, ur denna sekvens skall talsyntesmotorn ta ut ett ord i taget att arbeta med. Motivering: Talsyntesmotorn arbetar med ord. Därför måste den kunna ta ut varje ord för sig ur indatat. Källa: se kapitel 5.4 Databasens utformning. Påverkar: - F-1.3 Ta ut uppmärkt stavelse Om en sökning inte hittar det specifika ordet skall det uppmärkta ordet delas in i uppmärkta stavelser. Normal Motivering: Systemet blir mer generellt om det kan hantera stavelser på samma sätt som det hanterar ord. Eftersom det finns ett ändligt antal stavelser, men i princip oändligt antal ord, blir ett system som inte kan hantera mindre delar än hela ord, specifikt för den mängden ord. Källa: se kapitel 5.4 Databasens utformning. Påverkar: - Kapitel 6: Funktionella krav 15

22 Kravspec1fikation 2.0 F-1.4 Konkatenera tal och rörelsemönster Talet och rörelsemönstret för varje ord eller stavelse skall konkateneras så att det ihopsatta talet och rörelsemönstret till slut motsvarar den inmatade sekvensen utav ord. Motivering: Talet och rörelsemönstret som slutligen spelas upp skall motsvara samtliga inmatade ord. Källa: se kapitel 5.1 Grunder för talsyntes. Påverkar: F-1.6 F-1.5 Koppling till Orator Rörelsen som munnen gör för varje ljud skall kunna simuleras på det animerade ansiktet i Orator. Systemet skall ha ett fungerande gränssnitt till Orator för att skicka rörelsemönster till ansiktet. Normal Motivering: Talsyntesen blir mer trovärdig med ansiktsrörelser, eftersom det animerade ansiktet finns i Orator behöver systemet ett gränssnitt för att skicka data. Källa: se kapitel 5.2 Utökad talsyntes. Påverkar: - F-1.6 Spela upp ljud Systemet skall generera utdata i form av tal utifrån de inmatade orden. Detta tal skall systemet spela upp. Motivering: Talsyntes huvudmål är att generera tal av givet indata. Källa: se kapitel 5.1 Grunder för talsyntes. Påverkar: - 16 Kapitel 6: Funktionella krav

23 6.2 Databas Det här avsnittet beskriver databasens funktioner. I databasen finns uppmärkta ord med motsvarande tal och rörelsemönster lagrade. F-2.1 Lägg till data För att kunna utöka databasen skall ny data kunna läggas in i databasen. Motivering: En användare måste kunna lägga till data som denne vill testa talsyntesen på. Källa: se kapitel 5.5 Databasens grundfunktioner. Påverkar: I-3.1, I-3.2, I-3.3 F-2.2 Ta bort data Om databasen blir för stor eller innehåller felaktig data, skall möjligheten att ta bort data finnas. Motivering: Utan denna funktion finns ingen möjlighet att ha kontroll över innehållet i databasen. Källa: se kapitel 5.5 Databasens grundfunktioner. Påverkar: - F-2.3 Söka efter uppmärkt ord Både användare och talsyntesmotorn skall kunna söka efter ord i databasen. Motivering: Talsyntesmotorn måste hitta tal och rörelsemönster för varje ord i databasen. För användaren är det mer av bekvämlighets skäl, det skall vara enkelt ta reda på förekomsten av ett visst ord i databasen. Källa: se kapitel 5.5 Databasens grundfunktioner. Påverkar: F-1.4 F-2.4 Söka efter uppmärkt stavelse Både användare och talsyntesmotorn skall kunna söka efter stavelser i databasen. Normal Motivering: Av samma anledning som systemet kan skall kunna söka efter ord skall även ett mer generellt system kunna söka efter stavelser. Källa: se kapitel 5.5 Databasens grundfunktioner. Påverkar: F-1.3,F-1.4 Kapitel 6: Funktionella krav 17

24 Kravspec1fikation Kapitel 6: Funktionella krav

25 7 Icke-funktionella krav Det här kapitlet beskriver de icke-funktionella krav som ställs på systemet. De icke-funktionella kraven utökar inte systemets funktionalitet. De fastställer regler och ramar som de funktionella kraven skall uppfylla och hålla sig inom. 7.1 Talsyntesmotor Det här avsnittet beskriver systemets generella regler. I-1.1 Separat system Systemet skall fungera som ett eget system separat från Orator. Det vill säga att talsyntesen skall fungera precis likadant oavsett om Orator finns med eller ej. Motivering: Systemet är inte tänkt att i framtiden användas med just Orators animerade ansikte. Det skall vara möjligt att utveckla ett eget ansikte till systemet eller att köra det utan något ansikte alls. Källa: se kapitel 5.3 Syfte. Påverkar: - I-1.2 Systemmiljö Systemet skall implementeras på Windows XP. Motivering: Användare av detta system har olika teknisk bakgrund, därför behöver systemet kunna köras på ett operativsystem som de flesta kan hantera. Källa: se kapitel 5.7 Användarens bakgrund. Påverkar: - I-1.3 Systemmiljö Systemet skall att implementeras på unix. Extra Motivering: För att göra systemet mer generellt. Källa: se kapitel 5.7 Användarens bakgrund. Påverkar: - Kapitel 7: Icke-funktionella krav 19

26 7.2 Databas Det här avsnittet beskriver regler för databasens generella upplägg. I-2.1 Innehåll-Data I databasen skall det för varje ord och stavelse finnas information om tal och rörelsemönster. Motivering: Allt tal och rörelsemönster som systemet skall använda måste finnas tillgängligt i databasen. Källa: se kapitel 5.4 Databasens utformning. Påverkar: F-2.3, F Datainsamling Projektgruppen skall samla in en liten mängd data och föra in detta i databasen i syfte att testa systemet. I-3.1 Datainsamling Projektgruppen skall samla in och bearbeta data i form av tal och rörelsemönster samt föra in detta i databasen. Motivering: Det kommer krävas data för att testa systemet. Källa: se kapitel 5.6 Testdata. Påverkar: - I-3.2 Innehåll-Kvantitet Databasen skall innehålla minst fem minuter tal. Motivering: Systemet kan, med en tillräckligt stor databas, sätta ihop alla ord. Här simulerar vi endast en sådan generell databas. Källa: se kapitel 5.6 Testdata. Påverkar: - 20 Kapitel 7: Icke-funktionella krav

27 I-3.3 Synkronisering I databasen finns tal lagrat i form av ljud och rörelsemönster till det animerade ansiktet. Ljud och rörelse skall vara lagrat så att de är synkroniserade med varandra. Det vill säga ljud och röreslsedata är klippt vid samma tidpunkt ur respektive dataström. Motivering: Om rörelserna och ljudet inte är lagrat synkroniserat kommer de heller inte spelas upp synkroniserat, då blir talsyntesen inte trovärdig. Källa: se kapitel 5.6 Testdata. Påverkar: Användargränssnitt Det här avsnittet beskriver krav för användargränssnittet. I-4.1 Användarvänligt I användargränssnittet skall kopplingen mellan ord och dess uppmärkning som användaren matat in, framgå tydligt. Motivering: Svårigheten för användaren är initialt att förstå hur systemet kräver att orden är uppmärkta. Användargränssnittet får uppmärkningen av ord att kännas naturlig för att undvika förvirring. Källa: se kapitel 5.7 Användarens bakgrund. Påverkar: - I-4.2 Grafiskt användargränssnitt Användargränssnittet skall vara grafiskt. Motivering: För att underlätta och ge bättre översikt för användaren vid inmatning av indata. Källa: se kapitel 5.7 Användarens bakgrund. Påverkar: - Kapitel 7: Icke-funktionella krav 21

28 22 Kapitel 7: Icke-funktionella krav

29 8 Produktkomponenter Det här kapitlet beskriver de komponenter som den färdiga produkten kommer att bestå av. 8.1 Mjukvara Här beskrivs vilka mjukvarukomponenter som skall levereras till kunden. P-1.1 Exekverbart program Systemet skall levereras som ett exekverbart program. Motivering: Kunden önskar en körbar version av programmet vid slutleverans. Källa: se kapitel 5.7 Leveranskrav. Påverkar: - P-1.2 Databas Systemet skall levereras med en testdatabas med inspelat tal och rörelser. Motivering: Nödvändighet för att kunna testa programmets funktionalitet och generera tal utifrån indata. Källa: se kapitel 5.7 Leveranskrav. Status: Påverkar: - P-1.3 Källkod Systemet skall levereras med komplett källkod i digital form. Motivering: Nödvändigt för vidarutveckling av systemet. Källa: se kapitel 5.7 Leveranskrav. Påverkar: Demonstration Detta avsnitt beskriver vad som skall demonstreras för kunden vid leverans av systemet. P-2.1 Demonstration av systemet. Systemets funktionalitet skall demonstreras vid leverans. Motivering: För att kunden skall få en överblick av systemet. Källa: se kapitel 5.7 Leveranskrav. Påverkar: - Kapitel 8: Produktkomponenter 23

30 8.3 Dokumentation Detta avsnitt beskriver vilka dokument som skall finnas med vid leverans av systemet. P-3.1 Kravspecifikation Systemet skall levereras med den slutgiltiga versionen av kravspecifikationen. Motivering: Ger kunden en möjlighet att verifiera att de överskomna kraven är uppfyllda. Källa: se kapitel 5.7 Leveranskrav. Påverkar: - P-3.2 Arkitekturspecifikation Systemet skall levereras med den slutgiltiga versionen av arkitekturspecifikationen. Motivering: Förenklar vidarutveckling av systemet. Källa: se kapitel 5.7 Leveranskrav. Påverkar: - P-3.3 Designspecifikation Systemet skall levereras med den slutgiltiga versionen av designspecifikationen. Motivering: Förenklar vidarutveckling av systemet. Källa: se kapitel 5.7 Leveranskrav. Påverkar: - P-3.4 Systemförvaltningsdokument Systemet skall levereras med den slutgiltiga versionen av aystemförvaltningsdokumentet. Motivering: Förenklar vidarutveckling och förståelse av systemet. Källa: se kapitel 5.7 Leveranskrav. Status: Aktivit Påverkar: - 24 Kapitel 8: Produktkomponenter

31 9 Leveransvillkor Detta avsnitt beskriver vilka villkor som gäller vid leveransen av systemet. 9.1 Tid för leverans Slutprodukten skall levereras till kunden senast Plats för leverans Produkten skall levereras till tallabbet hos Instutionen för datavetenskap vid Linköping Tekniska Högskola. 9.3 Leveransprotokoll Vid leverans används ett leveransprotokoll för att kontrollera om projektgruppen har uppfyllt alla krav. Protokollet finns i Bilaga B. 9.4 Installation Systemet skall installeras hos kunden inför demonstration och leverans av systemet. Demonstrationen utförs i samband med acceptanstestet, därför måste installationen ske innan leverans. 9.5 Utbildning Ingen formell utbildning kommer att tillhandahållas utöver demonstrationen. Frågor på systemets funktionalitet hänvisas efter genomförd demonstration till dokumentationen. Kapitel 9: Leveransvillkor 25

32 26 Kapitel 9: Leveransvillkor

33 10 Acceptansvillkor Detta avsnitt beskriver de villkor som gäller för att systemet skall accepteras av kunden Avtal Ett avtal skall ingås mellan kund och projektgrupp. Detta avtal beskriver vad som skall gälla för att systemet skall accepteras. Avtalet finns i Bilaga A och måste undertecknas av båda parter för att vinna laga kraft Acceptanstest Ett acceptanstest kommer att genomföras för att säkerställa att utvecklarens alla åtaganden är uppfyllda. Acceptanstestprotokollet hittas i Bilaga C. Vid leverans skall alla fall på - och Normalnivå i protokollet ha testas och förväntad funktionalitet verifieras. Skulle systemet ej uppfylla villkoren har kunden rätt att refusera systemet. Acceptanstest utförs av projektgruppen tillsammans med kunden i tallabbet innan leverans. Kapitel 10: Acceptansvillkor 27

34 28 Kapitel 10: Acceptansvillkor

35 11 Referenser 11.1 Externa dokument [Projekt Orator, 2005] Projekt Orator (2005), LeveransRapport fas 4,5, DataDesign Interna dokument [Aghajani, 2005] Aghajani, Ali (2005), Projektplan, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas(2005), Arkitekturspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Millving, 2005] Millving, Johan (2005), Designspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Programmeringhandbok, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Enblom, 2005] Enblom, Kjell (2005), Systemförvaltningsdokument, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Janowski, 2005] Janowski, Thomas (2005), Testplanering, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. Kapitel 11: Referenser 29

36 30 Kapitel 11: Referenser

37 Bilaga A Avtal Detta avtal definierar de villkor som gäller för det system som PUM-grupp 1 utvecklar åt avdelning för Human-Centered Systems,, Linköpings tekniska högskola. Systemet utvecklas inom ramen för kursen TDDC02 Programutvecklingsmetodik - projekt vid Linköpings tekniska högskola under hösten A.1 Parter De parter som detta avtal förbinder är: Kund: Avdelningen av Human-Centered Systems, IDA, Linköpings tekniska högskola. Representerad av Bertil Lyberg och Mustapha Skhiri. Leverantör: PUM-grupp 1. Representerad av. A.2 Avtalad specifikation Avtalad specifikation omfattar överenskomna leveransvillkor samt de i kravspecifikationen angivna kraven. Avtalet fastslår att samtliga krav på nivåerna bas och normal skall uppfyllas samt att kraven på nivå extra uppfylls i mån av tid. Skulle kundens tolkning av ett krav inte stämma överens med leverantören, i detta fall PUM-grupp 1, kommer kravet omförhandlas. En omförhandling kan även komma att ske om leverantören upptäcker att något krav inte kan uppfyllas. Vid en omförhandling kommer kravspecifikationen att modifieras och ett nytt avtal tecknas. A.3 Acceptans av produkten Acceptansen av systemet avgörs av acceptanstestet som kommer att utföras innan leverans. Testet verifierar att samtliga aktiva krav på nivåerna och Normal är uppfyllda. Kunden ger sitt skriftliga godkännande till systemet i acceptanstestprotokollet, Bilaga C. Vid eventuella anmärkningar kommer leverantören i mån av tid åtgärda dessa och ett nytt acceptanstest genomförs snarast. Leverantören ansvarar inte för eventuella problem som upptäcks efter kundens godkännande. A.4 Leverans av produkten Villkoren för leveransen finns specificerade i kapitel 8. Leveransen anses godkänd då båda parter signerat leveransprotokollet i Bilaga B samt acceptanstestprotokollet i Bilaga C. Vid eventuell försening av leveransen äger kunden ej rätt till ersättning. Bilaga A: Avtal 31

38 A.5 Underhåll Leverantören förbinder sig inte till underhåll av systemet efter godkänd leverans. A.6 Projektavslut Då detta projekt är en del av kursen TDDC02 Programutvecklingsmetodik -projekt styrs projektavslutet av kursens slutdatum. Om produkten inte skulle vara klar för leverans vid denna tidpunkt levereras produkten i sitt befintliga skick, utan påföljd för leverantören. A.7 Upphosvrätt och nyttjanderätt I samband med leverans delas upphovs- och nyttjanderätten av produkten mellan kund och projektgrupp. Kunden såväl som projektgruppen äger rätt till vidareutveckling av produkten. A.8 Intrångstalan PUM-grupp 1 åtar sig inte att försvara kunden om krav riktas eller talan förs mot denne om intrång i patent, upphovsrätt eller annan rätt på grund av användning av den levererade produkten. PUM-grupp 1 förbinder sig däremot att inte medvetet göra intrång i patent, upphovsrätt eller annan rätt. A.9 Force majeure Om någon av parterna förhindras fullfölja detta avtal på grund av omständigheter utanför dennes kontroll är det tillåtet att flytta leveransdatum eller bryta avtalet utan konsekvenser. A.10 Skiljedom Tvister angående tolkning av detta avtal skall avgöras av kursledningen för kursen TDDC02 Programutvecklingsmetodik - projekt vid Linköpings tekniska högskola. 32 Bilaga A: Avtal

39 A.11 Signatur Ovanstående avtal godkännes härmed av båda parter. Avtalet är upprättat i två original och båda parter har fått ett exemplar. Kundrepresentant: Mustapha Skhiri, IDA, Linköpings Tekniska Högskola Namnteckning... Ort...Datum... Leverantörsrepresentant:, PUM-grupp 1 Namnteckning... Ort...Datum... Bilaga A: Avtal 33

40 34 Bilaga A: Avtal

41 Bilaga B Leveransprotokoll Denna bilaga fungerar som stöd för att kontrollera att alla komponenter som skall ingå i systemet, enligt överenskommelse, finns med. Protokollet skall vid leverans användas av kunden för att säkerställa en komplett leverans. Är samtliga komponenter med vid leverans skall protokollet undertecknas av båda parter. B.1 Mjukvara Krav Nivå Komponent Levererad P 1.1 Exekverbart program P 1.2 Databas P 1.3 Källkod Tabell 2:Mjukvara B.2 Demonstration Krav Nivå Komponent Levererad P 2.1 Demonstration av system Tabell 3:Demonstration B.3 Dokumentation Krav Nivå Komponent Levererad P 3.1 Kravspecifikation P 3.2 Arkitekturspecifikation P 3.3 Designspecifikation P 3.4 Systemförvaltningsdokument Tabell 4:Dokumentation Bilaga B: Leveransprotokoll 35

42 B.4 Signatur Leveransen godkännes härmed som komplett av båda parter. Kundrepresentant: Mustapha Skhiri, IDA, Linköpings Tekniska Högskola Namnteckning... Ort...Datum... Leverantörsrepresentant:, PUM-grupp 1 Namnteckning... Ort...Datum Bilaga B: Leveransprotokoll

43 Bilaga C Acceptanstestfall Detta avsnitt beskriver de testfall som skall utföras vid acceptanstestet. Syftet med acceptanstestet är att avgöra om systemet uppfyller de krav som ingår i avtalet. Varje krav kan ha ett eller flera testfall. Varje testfall har ett förväntat resultat. testfallen har en bestämd ordning för att acceptanstestet skall gå så smidigt som möjligt. C.1 Testfallsutformning Alla testfall är beskrivna enligt tabellen nedan. AT-X representerar test-id där X är ett unikt nummer för testfallet. När ett test är uppfyllt skall det bockas av under dess acceptans-id. AT-X uppfyllt Syfte Syftet med testet. Krav Referens till kravet som testet berör. Kravnivå Indata Utförande Förväntat resultat Nivå på kravet., normal eller extra. Indata till systemet för testet. Kortfattad beskrivning av hur testet skall utföras. Beskrivning av förväntad utdata eller resultat av test. Tabell 5:Struktur av ett testfall. Bilaga C: Acceptanstestfall 37

44 C.2 Testprotokoll Här följer alla testfall inklusive förväntat resultat. AT-1 uppfyllt Syfte Krav F 1.1, I 4.2 Kravnivå Indata Utförande Förväntat resultat Kontrollera att det går att mata in en text i systemet och att denna text kan märkas upp., Tre ord som vi vet finns i databasen. Mata in texten och märk upp orden på ett korrekt sätt i det grafiska användargränssnittet. Systemet ska acceptera orden utan felmeddelande eller att något annat oförutsätt inträffar. AT-2 uppfyllt Syfte Krav F 1.1 Kravnivå Indata Utförande Förväntat resultat Kontrollera att systemet inte accepterar en felaktigt uppmärkt text. Tre ord där uppmärkningen av ett av orden är felaktigt, dvs inte följer gällande regler för uppmärkning av ord. Mata in indatat och låt systmet generera tal utifrån indatat. Systemet ska inte acceptera inmatningen och göra användaren uppmärksam på detta. AT-3 uppfyllt Syfte Kontrollera att systemet kan spela upp tal för en korrekt inmatad sekvens av uppmärkta ord. Vi kontrollerar dessutom att systemet kan söka reda på uppmärkta ord i databasen. Krav F 1.2, F 1.4, F 1.6, F 2.3 Kravnivå Indata Utförande Förväntat resultat,,, Tre uppmärkta ord där vi vet att systemet inte kommer att behöva dela upp några av orden i stavelser för att kunna generera talet. Mata in indatat och låt systmet generera tal utifrån indatat. Systemet ska spela upp tal som motsvarar den inmatade sekvensen. 38 Bilaga C: Acceptanstest

45 AT-4 uppfyllt Syfte Kontrollera att systemet inte spelar upp tal för uppmärkta ord som inte finns i databasen. Krav F 1.2, F 1.4, F 1.6, F 2.3 Kravnivå Indata Utförande Förväntat resultat,,, Tre korrekt uppmärkta ord där ett av orden inte finns i databasen. Mata in indatat och låt systemet bearbeta detta. Systemet rapporterar att de uppmärkta orden inte finns i databasen och därför inte kan generera tal. AT-5 uppfyllt Syfte Krav F 1.3, F 2.4 Kravnivå Indata Utförande Förväntat resultat Kontrollera att systemet delar upp okända ord i stavelser och att systemet kan söka efter stavelser i databasen. Normal, Normal Tre korrekt uppmärkta ord där vi vet att systemet kommer att behöva dela upp ett av orden i stavelser för att tal ska kunna genereras. Ordet måste vara uppbyggt av stavelser som vi vet finns i databasen. Mata in indatat och låt systemet bearbeta detta. Systemet ska spela upp tal som motsvarar den inmatade sekvensen. AT-6 uppfyllt Syfte Krav F 1.4, F 1.5 Kravnivå Indata Utförande Förväntat resultat Kontrollera att Orators ansikte rör sig till de uppspelade orden., Normal Tre uppmärkta ord som finns i databasen och som vi vet har ljud- och rörelsedata lagrade. Se till att det animerade ansiktet är aktiverat. Mata in indatat och låt systemet bearbeta detta. Systemet ska spela upp tal och det animerade ansiktet ska animeras till orden. Bilaga C: Acceptanstestfall 39

46 AT-7 uppfyllt Syfte Krav F 2.1, F 2.3 Kravnivå Indata Utförande Förväntat resultat Kontrollera att det går att lägga in nya ord i databasen och att användaren kan söka efter ord i databasen., Ett ord med dess uppmärkning, tal och röreslemönster. Lägg in datat via ett databasgränssnitt och använd sedan sökfunktionen för att hitta det inlagda datat. Det inlagda datat återfinns i databasen. AT-8 uppfyllt Syfte Krav F 2.2, F 2.3 Kravnivå Indata - Utförande Förväntat resultat Kontrollera att det går att ta bort data ur databasen och att användaren utan problem kan söka efter data som inte finns i databasen., Ta bort ett ord via databasgränsnittet. Sök efter det borttagna ordet. Systemet meddelar via databasgränssnittet att datat inte längre återfinns i databasen. AT-9 uppfyllt Syfte Krav F 2.4 Kravnivå Indata Utförande Förväntat resultat Kontrollera att användaren kan söka efter stavelser i databasen. Normal En stavelse som vi vet finns i databasen. Sök efter stavelsen i databasgränssnittet. Systemet konfirmerar via databasgränssnittet att stavelsen finns i databasen. 40 Bilaga C: Acceptanstest

47 AT-10 uppfyllt Syfte Krav Kravnivå Indata Utförande Förväntat resultat Kontrollera att systemet fungerar utan Orator. I-1.1 Tre uppmärkta ord som finns i databasen. Inaktivera animering av ansiktet och generera tal för indatat. Systemet skall spela upp talet motsvarande den inmatade sekvensen av uppmärkta ord.. AT-11 uppfyllt Syfte Krav Kravnivå Indata - Utförande Förväntat resultat Kontrollera att det systemet går att köra på Windows XP I-1.2 Installera och kör systemet på en pc med Windows XP. Systemet skall kunna köras utan några felmeddelanden. AT-12 uppfyllt Syfte Krav Kravnivå Indata Utförande Förväntat resultat Kontrollera att databasen hanterar ord, uppmärkning, ljud- och rörelsedata korrekt. I-2.1 Ett uppmärkt ord med ljud- och rörelsedata Lägg in det uppmärkta ordet med dess tal i databasen och kontrollera att ordet och dess ljud- och rörelsedata återfinns där. Ordet som sparas i databasen skall återfinnas där tillsammans med dess ljud- och rörelsedata. Bilaga C: Acceptanstestfall 41

48 AT-13 uppfyllt Syfte Krav Kravnivå Indata - Utförande Förväntat resultat Kontrollera att det finns data i databasen och att taldatat motsvarar minst 5 mintuer tal. I-3.1, I-3.2, Gör en uppskattning av den totala tiden tal som finns i databasen. Det skall finnas minst 5 minuter tal lagrat i databasen. AT-14 uppfyllt Syfte Krav Kravnivå Indata Utförande Förväntat resultat Kontrollera att talet och rörelserna är lagrade synkroniserat. I-3.3 Tre uppmärkta ord som finns i databasen. Mata in orden i systemet. Talet och rörelserna skall se ut att ligga i takt. AT-15 uppfyllt Syfte Krav Kravnivå Indata - Utförande Förväntat resultat Kontrollera att representant från kunden klarar av att använda systemet I-4.1 Kundens representant skall själv mata in och märka upp en sekvens av ord. Det genererade talet skall motsvara den uppmärkning kunden gjorde. 42 Bilaga C: Acceptanstest