Tentamensproblem

 

a) En avgörande förutsättning för lyckad kravhantering är god domänkunskap. Vad är då domän? Beskriv kortfattat ett system (eget förslag!) och förklara vad som är produkt, vem/vilka som är aktörer, vad som ingår i domänen (eventuellt både "inre" och "yttre"). (3 poäng)

 

b) Skriv 2 exempel på krav för systemet du valde i a); ett på produktnivå och ett på domännivå. (2 poäng)

 

c) Lauesen beskriver olika modeller (styles) för att beskriva funktionella krav. Beskriv kort två olika modeller utifrån användarens respektive utvecklarens synvinkel. (2 poäng)

 

d) Karlsson beskriver "användningsfall" och hur man skapar dessa. Beskriv användningsfallen till ditt system från a) med hjälp av grafisk notation. Välj så många användningsfall du tycker känns väsentligt, men se till att använda relevanta begrepp. (3 poäng)

 

 

Lösningsförslag:

 

a) Ett exempel på ett system är ett det digitala journalsystemet/tidbokningssystemet på ett sjukhus.

Själva produkten är mjukvaran för journalhantering och tidbokning.

Den inre domänen utgörs av alla som (regelbundet) kommer i direkt kontakt med produkten, dvs. all personal på sjukhuset som skriver i och läser journalerna och deras ”aktiviteter” med produkten.

Den yttre domänen är t.ex. patienterna som ringer och bokar en tid, dvs. personer och andra system som inte kommer i direkt kontakt med produkten utan kommunicerar med användarna av produkten.

 

b) Domän-nivå: Produkten ska kunna användas på hela sjukhuset.
Produkt-nivå: Produkten ska stödja hantering av tidbokning och journaler

c) Modellen ”Kontextdiagram” är diagram/figurer som visar produkten och dess omgivning. Produkten ses i detta fall som en ”svart låda” där pilar visar hur information skickas mellan produkten och omgivningen (användare och/eller externa system). Verifikation: Diagrammen ger en översikt över gränsnittet för utvecklarna. Det är lätt att verifiera gränsnitten under utvecklingen samt när resultatet är klart. Validering: För kunder är diagrammen relativt enkla att förstå, och därför även lätt ätt hitta gränsnitt som saknas, diskutera vad som ska finnas i respektive utanför produkten.

 

”Händelselista och funktionslista” innebär att man ställer upp en lista för händelser som ska hanteras av produkten samt en lista för händelser som ska hanteras av människor och datorer. Man skiljer på domänhändelser (kommer från omgivningen till domän) och produkthändelser (kommer från domän till produkten). Verifikation: Utvecklarna kan lätt se att varje funktion/händelse på listan har implementerats. Validering: Det kan vara svårt för kund att få översikt för att kontrollera att alla händelser finns med. Produkthändelserna är oftast omöjligt för kunden att validera, fast de blir ofta ombedda att göra det.

 

 

d)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Databas

 
 

 

 


Betygskriterier:

a) Studenten ska tydligt visa att hon känner till skillnaden mellan de olika nivåerna och ha kommit med ett bra (eget) förslag på system.

Eget förslag: 0,5 poäng

Beskrivning av produkten: 1 poäng

Beskrivning av (den inre) domänen: 1 poäng

Beskrivning av (den yttre) domänen: 0,5 poäng

 

b)1 poäng per krav. Inga halva poäng utan fel eller rätt!

 

c) För poäng borde lösningen innehålla följande:

Modellens namn samt beskrivning av notation (text, diagram..etc.)

Validering: Är det lätt för kunden att förstå modellen och kontrollera att allt finns med?

Verifikation: Hur lätt är det att kontrollera att kraven verkligen implementeras? 

 

1 poäng för varje modell som beskrivs enligt ovan (max.2 poäng).

 

d) Självklart kan man komma på många fler användningsfall till detta exempel, men huvudsaken är att studenten visar hur att han/hon vet vad användningsfall är och hur man m. h. a. grafisk notation får en överblick över aktörerna och exempel på användningsfall.

 

Korrekta användningsfall till valt system: 1 poäng

Nyttjande av den grafiska notationen: 0,5 poäng

Användande av begreppen aktör och användningsfall korrekt:0,5 poäng