Fråga inom kravstilar:

Det finns olika kravstilar för att dokumentera data & funktionella krav. Kravstilar kan exempelvis ha delats upp i två kategorier: datakravstilar och funktionella kravstilar.

1) Jämför skillnaderna mellan data- och funktionella krav. (1p)

2) Data –modell med E/R-diagram (Data models ) och virtuella fönster (Virtual windows) är två exemplar på data-kravstilar. Jämför skillnaderna mellan de två stilarna med en kortfattad beskrivning, samt för- och nackdelar. (3p)

3) Några exempel på funktionella kravstilar är

Ge en kortfattad beskrivning av respektive stil samt för- och nackdelar. ( 6p )

Rättningsförslag:

1) Varje krav ger maximalt 0.5 p.

Datakrav specificerar format för indata och utdata och anger vad för information systemet ska lagra.

Funktionella krav beskriver mappning mellan indata och utdata samt hur information ska behandlas.

2) Varje stil ger maximalt 1.5 p. Begreppet ger 0.5 p. Mer än två fördelar ger 0.5 p. En fördel ger exempelvis 0.2 p. Samma regel gäller nackdelar.

Block av diagram som beskriver data inom och utanför produkten.

+ Utmärkt för utvecklarna eftersom många utvecklare har mycket erfarenhet av E/R modellen och kan använda den för att implementera produkten.

+ Lätt att verifiera om data som behandlas av produkten uppfyller kraven.

+ Okänsligt för vilken nivå man jobbar i. Det innebär exempelvis att en tidig analys av information i en domän kommer att skapa en modell som klarar att implementeras med minimala modifikationer.

– Det tar tid att lära sig hur modellen ska användas

– Svårt att bestämmer hur mycket detaljer modellen ska ta med.

– Svårt för kunder att begripa.

Förenklad skärmbild med grafiska och realistiska data, utan knappar och menyer.

+ Lätt för kunder att validera om data modellen och databeskrivningar är tillfredställande.

+ Lätt för utvecklarna att verifiera om systemet innehåller specificerade data.

– Tar lång tid att framställa krav om man inte behärskar tekniken

3) Varje stil ger maximalt 1.5 p. Begreppet ger 0.5 p. Mer än två fördelar ger 0.5 p. En fördel ger exempelvis 0.2 p. Samma regel gäller nackdelar.

Beskriver alla funktions/ produktegenskaper som ska implementeras i produkten i textformat.

+ Lätt för utvecklarna att översätta till programfunktioner vid implementering.

+ Lätt för kunder att validera eftersom det använder användares språk.

+ Lätt för utvecklarna att verifiera om alla funktioner implementerades i slutprodukten.

– Svårt för användare att validera om alla funktioner kommer att vara hjälpsamma för att uppnå användarens ändamål.

Strukturerad text som beskriver användningsuppgifter.

+ Lättförstålig både för kunder och utvecklararena

+ Lätt för kunder att validera eftersom det använder användares språk.

+ Kan direkt verifiera slutsystemet mot uppgiftsbeskrivningarna.

– Inga data är specificerade.

– Stor arbetsinsats för att elicitera alla uppgifter

· Skärmbilder och prototyper ( Screens and prototypes )

Beskriver hur den färdiga produkten kommer att se ut med knappar och menyer.

+ Lätt för kunder att validera om skärmen stödjer uppgifter med hög användbarhet.

+ Kan direkt verifiera om det slutliga användargränssnitten uppfyller kraven.

– Icke väldefinierat krav kan ge negativt resultat

Beskriver de händelser som systemet kommer att stödja. Händelserna beskrivs på domännivå, produktnivå eller både och.

+ Lättförstålig lista på vad som ska utvecklas

+ Lätt för utvecklarna att verifiera om varje händelse och funktion är stödjande eller färdig implementerad.

– Kunder kan oftast inte validera en lista av produktfunktioner och händelser.

Grupp D Marie Ekelund, Wei Gu, Anna Åstrand 2005-01-28