Lunds Tekniska Högskola                                                                                      2005-01-25

Kravhantering ETS170

 

Grupp K                                                                                              Josef Granqvist (d00jgr)

                                                                                                      Majk Kruszewski (e04mkr)

                                                                                                              Erik Wiktorin (d00ew)

 

K1 – Bibliotek Smörblommans datorisering

 

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.