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