Denna fråga grundar sig på fallet ticket-machine ur Lausens Software Requirements, styles and techniques.
a) Nedan är fem krav listade. Varje krav har en speciell svaghet som går emot Davis 24 kvalitetsattribut. Para ihop varje krav med det attribut du anser att det tydligast bryter mot genom att dra streck mellan dem. Endast en relation per krav och attribut är tillåten (5p)
|
Krav |
Kvalitetsattribut |
|
R1: Svarstiden från knapptryckning till skärmuppdatering
ska vara snabb så att användarna inte upplever systemet som långsamt. |
Designoberoende |
|
R2: Resmålen ska representeras som noder och kopplas samman till en graf. |
Entydigt |
|
R3: När som helst på dygnet ska det alltid gå att få sin biljettbokning konfirmerad inom 5 sekunder. |
Verifierbart |
|
R4: 98% av alla terminaler ska klara fem år av klimat motsvarande metereologisk data i appendix A. |
Precist |
|
R5: Vid bokning måste krav på rökfri kupé anges av användaren. |
Genomförbart |
b) Ge ett förslag på hur varje krav skulle kunna göras om så att de inte längre bryter mot kvalitetsattributet. (5p)
Rätt svar:
a)
R1: Ej precist nog. Inget specifikt numeriskt mål anges för ”snabb” vilket bland annat försvårar verifieringen av kravet.
R2: Kravet är inte
designoberoende. Nu har man redan låst designen vid en viss
implementationslösning.
R3: Ej genomförbart. Att kräva att en funktion som utsätts för
slumpfördelade ankomster från potentiellt oändligt antal användare alltid
ska uppfyllas är orimligt.
R4: Svårt och dyrt att verifiera. Detta eftersom kravet berör
tillförlitlighet över tiden och slitaget är svårt att simulera.
R5: Ej entydigt. Är man tvugen att kräva rökfri kupé oavsett man vill ha det eller inte under bokning, eller är det bara då man vill garanteras en rökfri kupé som man måste ange krav på detta?
b)
R1: Den tid som användaren upplever som långsam bör definieras för att kravet ska bli precist.
Ex: Svarstiden från knapptryckning itll skärmuppdatering ska i 90% av fallen vara mindre än 15 sekunder.
R2: Kravet ska inte ge en designlösning, utan utrycka vad det egentliga behövet är. Genom att ställa frågan varför kan kravet ledas tillbaka till det ursprungliga behovet.
Ex: För att underlätta för kunden att hitta sitt resmål ska alla möjliga resmål vara listade, samt hur de hör samman.
R3: Sannolikheten säger att det krav är omöjligt att genomföra i 100 % av fallen. För att lägga en nivå kan kravet utryckas som att huvuddelen av biljettbokningarna ska gå att uppfylla inom tiden.
Ex: När som helst på dygnet ska det i 95 % av fallen gå att få sin biljettbokning konfirmerad inom 5 sekunder.
R4: Kravet kan t.ex. brytas ner till delkrav som alla är lättare att verifiera, alternativt formuleras så att man hänvisar till vedertagna teststandarder.
Ex: Terminalen ska vara vattentät för tryck upp till 50mm/cm2.
Ex2: Terminalen ska genom tester uppfylla slitagekrav enligt ISO...
R5: Entydig formulering:
Ex: Vill användaren garanteras rökfri kupé måste detta anges under bokningen.
Poängsättning:
a) 1p för varje korrekt koppling. Max 5p.
b) 1p för varje krav om studenten givit en bra omformulering.