Lunds Tekniska Högskola 2005-01-25
Kravhantering
ETS170
Grupp K Josef
Granqvist (d00jgr)
Majk
Kruszewski (e04mkr)
Erik
Wiktorin (d00ew)
Syfte:
Frågans syfte är att
studenten ska tillämpa Lauesens ”The goal-design scale” på ett praktiskt
exempel. Detta kontrollerar både kunskap och tillämpningsförmåga.
Case:
Biblioteket
Smörblomman i Jordbro kämpar mot nedläggning. På grund av minskad statlig
subvention kommer bibliotekets budget skäras ner om ett år. Bibliotekets
nuvarande arbetsstyrka uppgår till 5 stycken heltidsarbetande bibliotekarier.
Om de lyckas rationalisera bort en heltidstjänst kommer de kunna möta de nya
ekonomiska kraven, men med nuvarande arbetssätt är detta omöjligt.
För närvarande används ett ålderdomligt, kortbaserat utlåningssystem (läs
ingen dator) och mycket tid går åt till uppdatering och sökning vid varje
utlånings- och återlämningstillfälle.
Bibliotekets föreståndare har en son som har god programmeringsvana och
erbjuder sig att datorisera hela utlånings- och återlämningsprocessen, vilket
skulle minska administrationstiden drastiskt. Detta skulle bli ett heltäckande
system och kravet från bibliotekets föreståndare är att systemet skall kunna ersätta
all nuvarande kortbaserad verksamhet, från utlåning till sökning etc.
Sonen sätter sig in i kartotekssystemet och kommer fram till att det är
viktigt med funktioner som uppdaterar och övervakar en boks status. Efter ett
möte med bibliotekarierna verifieras detta och de säger att det är kartotekets
viktigaste uppgift.
Då sonen lägger fram sitt förslag om datorisering av kartoteket till
bibliotekarierna möts han av skepsis. De tror sig inte kunna hantera ett system
som bara har text och siffror, som de säger. De har många böcker med snarlika
titlar och redan nu ödslas tid åt att hitta rätt kort vid varje
utlåning/inlämning. Sonen föreslår då att man kan lägga in en bild på varje
boks framsida då dess information visas i datorn. Bibliotekarierna inser värdet
med detta och säger att det skulle spara mycket tid.
Fråga:
Utifrån Lauesens
Goal-design scale, ge ett kravexempel per nivå (mål, domän, produkt och design)
från ovanstående case (6 poäng). Förklara dessutom kortfattat varje nivå (4
poäng).
Bedömningsmall:
Vi värderar
förmågan att tillämpa teorin högre än att kunna dess definition utantill,
därför ger exempel på nivåkraven mer poäng än beskrivning av nivåerna. En
tillfredsställande beskrivning av en nivå ger alltså 1 poäng och ett relevant
exempel på krav från denna nivå ger maximalt 1,5 poäng. (1p + 1,5p) * 4 nivåer = 10 p.
Målnivåkrav: Svarar på frågan: Varför vill kunden lägga pengar
på systemet? Det är ett affärsmål som kan verifieras.
Kravexempel:
-
Efter
att systemet har varit i drift i ett år skall lönekostnaderna kunna minskas med
20 %.
-
Systemet
skall minska tiden för utlåning med i genomsnitt 30 %. (30 % påhittad siffra,
biblioteket får ge en relevant siffra för detta för att möta sina egna
ekonomiska krav).
Domännivåkrav: Produkten skall möjliggöra användaruppgifterna xx
till yy. Det är viktigt att studenten här har klart för sig att det är
uppgifter som ska lösas och inte specifik systemfunktionalitet (functionality).
Domännivåkraven beskriver de aktiviteter som pågår utanför produkten, kraven är
till för att stödja dessa aktiviteter.
Kravexempel:
-
Systemet
skall möjliggöra utlåning och sökning efter böcker.
Produktnivåkrav: De funktioner som systemet skall utföra. Vilken indata som skall generera specifik
utdata. Det ska framgå att studenten kan skillnaden mellan produktnivå och
domännivå.
Kravexempel:
-
Systemet
skall erhålla funktioner för att uppdatera och
övervaka en boks status.
Designnivåkrav: Specificerar exakt produktens användargränssnitt.
Det är däremot viktigt att inte implementeringen rörs
i kraven.
Kravexempel:
-
Då
man tar fram information om en boks status skall en bild av bokens framsida
visas.