Lathund Kravhantering med RUP

Viktiga omrden till tenta

1.
2.
3.
4.
5.
6.

Anvndningsfallsmodellering
URPS+ med alla kategorier och passande exempel
Informationsmodellering
Aktivitetsdiagram
Kravspecifikation
Visionsdokumentet

Kravspecifikation
Bestllaren mste p ett korrekt stt kunna uttrycka sina behov.
Kravspecifikationen blir som ett kontrakt mellan bestllare och utvecklare dr
utvecklare har ett ansvar att gra det som kravspecifikationen specificerar.
I en kravspecifikation s ska man frska att se systemet utifrn och inte tnka
p ngra design- och implementationsaspekter. Det r allts viktigt att inte skriva
ner krav utifrn ett rent programmeringssyfte d det r oftast oviktigt. Krav ska
vara tydliga, nrmast juridiskt korrekt skrivna. Vaga krav kan tolkas p mnga
olika stt och bidrar till en oskerhet i utvecklingen. Krav ska glla efter
utvecklingens slut.
Det finns olika typer av krav och de brukar delas upp i behovs-, egenskaps- och
mjukvarukrav. Behoven r en del av den s.k. problemdomnen medan
egenskaps- och mjukvarukrav r en del av lsningsdomnen. Behovskrav
specificerar anvndares och intressenters behov fr att lsa en uppgift. Exemepel
p behov som t.ex. en intressent kan ha r: Systemet ska underltta fretagets
administration av kunder. Egenskapskrav specificerar tjnsten som systemet
tillhandahller fr att uppfylla behoven. Ett exempel som anvnder frra
behovsexemplet r: Anvndaren ska kunna lgga till, ndra, ta bort och skriva ut
uppgifter om kunder. Mjukvarukraven r vad systemet gr p uppmaning av
anvndaren, kringutrustning, och andra system. Mjukvarukrav utgr ifrn
egenskapskraven. Exempel p mjukvarukrav kan vara: Vid start av systemet ska
en behrighetskontroll av anvndaren gras.
Bra frgesammanfattning:
-

Vad r ett krav?

Till vad anvnds krav?
Vilka omrden behver tckas in fr att fullstndigt beskriva ett systems
krav?
Vilka stller krav p ett system?
Vilka r kravtyperna i kravpyramiden?

Kravhantering
Frdelar med kravhantering:
1. Tydliga abstraktionsniver
2. Sprbarhet mellan niverna

3.
4.
5.
6.
7.
8.

Mjlighet till tydlig prioritering

Ev. luckor i kravmassan upptcks lttare
Tydligt kontrakt med bestllare
Skrare projektplanering
Olika systemversioner kan utvecklas med kontroll
Kravfrndringar tas omhand (ingen risk fr okontrollerat svllande
kravbild)

Att ska och tgrda fel brukar man sga r ca 200 gnger dyrare att gra nr
systemet vl r implementerat och r i underhllsfasen. Det r mycket drfr
som det r viktigt att hitta luckor i kraven och s snabbt som mjlig tgrda
dessa. Kravhanteringen gr dock ofta att utvecklingen tar lngre tid, men kan
betala tillbaka sig vid implementering och test. Kravhanteringen kan ocks ses
som ondigt byrkratisk av mnga d den krver ndrad instllning och
frstelse.
Bra frgesammanfattning:
-

Vad r kravhantering?
Varfr ska vi hantera krav?
Vilka begrepp anvnds inom kravhanteringen?

Kravhanteringsprocessen
1. Projektetablering. Hr kommer idn till projektet. Projektet kalkyleras
och estimeras i utvecklingskostnad. Bestllaren beskriver och diskuterar
idn tillsammans med ansvarig fr utvecklingen. Man specificerar roller
och deltagare. T.e.x. bestllare, anvndare och problemdomnexperter.
Man skriver ocks en kravhanteringsplan med versionshantering,
kravstruktur, kravtyper m.m.
2. Analysera problemet. Man identifierar problemomrdet och vad
systemet ska ha fr uppgift. Vad systemet ska ha fr uppgift utgr ifrn
visionen, som kan ses som en utveckling av den ursprungliga idn. Man
planerar, frbereder och genomfr workshops fr att definiera
systemgrnser och hitta systemets begrnsningar.
3. Frst intressenternas behov. Frst utgr man frn toppen av
kravpyramiden. Man identifierar andra kllor till krav och identifierar &
prioriterar behoven. Man pbrjar ocks arbetet med icke-funktionella
krav. Efter det jobbar man sig ner i kravpyramiden till egenskapskraven
och beskriver de funktioner & egenskaper systemet behver fr att lsa
problemen alternativt lsa intressenternas behov. Dessa br sttas i
prioriteringordning. En annan viktig aspekt r att formulera
systemintentionen. Systemintentionen r ocks en utveckling av visionen.
Vad r det som systemet ska kunna gra som t.ex. konkurrenteter inte
kan? Vad r skillnaden? Vi fngar egenskapskraven, identifierar aktrerna
och identifierar vra anvndningsfall.
4. Definera systemet. Hr gr vi ner i kravpyramiden och ner i egenskapsoch mjukvarukraven. Vi beskriver kraven p systemet nr det gller bde
funktionella och icke-funktionella krav. Vi samlar in alla icke-funktionella
krav. Vanligvis s kommer de icke-funktionella kraven ifrn intressenter av

typen drift, frvaltning, och arkitektur. En genomgende analys grs ocks

p de lsningar vi har gjort.
5. Strukturera och organisera kraven. Det r viktigt att skilja p krav p
projektet och krav p systemet. Man br sortera och strukturera kraven p
systemet i olika kravtyper. Det visar kravens hierarkiska ordning. Man br
upprtta sprbarhetslnkar, hur kraven relaterar till varandra.
6. Detaljera systemet. Hr skrivs anvndningsfallsspecifikationer.
Prototyper av anvndargrnssnittet ritas ut.
7. Granska kraven. Hr har man granskningsmten dr man kollar igenom
hela anvndningsfallsmodellen.
8. Stm av med bestllare. Man kollar att man r verrens och att det
stmmer med kravbeskrivningen.
9. verlmna till Analys & Design, och Test.
10.
Hantera ndringar. Krav frndras, d det kravstllarna
(bestllaren) kan ha ndrat uppfattning. Det kan behvas ndring av
nuvarande krav, utkade krav och nya krav. Bttre lsningar p problem
kan ha kommit fram. Efter det gr man tillbaka till steg 1 och kan iterera
kravprocessen.
Bra frgesammanfattning:
-

Vilka br medverka i kravarbetet?

Vad gr vi fr att analysera problemet?
Vad innebr det att definera systemet?
Vad r anvndbart fr att strukturera och organisera krav?
Vad ska granskas i kravhanteringen?
Vilka tar emot kraven?

Strukturera och organisera krav

Nr vi hller p med krav s mste vi skilja p krav fr systemet och krav p
projektet. Krav fr systemet r kanske de mest vanliga kraven, Det ska kunna g
att bestlla..., medan krav p projektet kan vara: Utvecklingsperioden fr inte
verstiga 6 mnader. En annan viktig aspekt r att sortera & strukturera kraven
p systemet i olika kravtyper enligt kravpyramiden. Indelningen av mjukvarukrav
delas in i funktionella- och icke-funktionella krav. De funktionella kraven
specificerar direkta anvndningsfall som systemet ska anvnda medan ickefunktionella krav kan vara krav p prestanda, frvaltningsbarhet,
designbegrnsningar, tillfrlitlighet, och anvndbarhet. Dessa kategorier brukar
frkortas FURPS+.
Funktionalitet
Funktioner Det ska kunna g att spara och ndra en anvndare.
Anvndbarhet
Mnskliga hnsynstaganden Frgblinda personer ska kunna anvnda
systemet.
Estetik Det grafiska grnssnittet ska vara anpassat till mlgruppen.
Konsistens Frgerna ska matcha p alla sidor.
Dokumentation Online-dokumentation ska alltid finnas tillgnglig.

Flersprkstd UI ska kunna finnas p bde svenska och engelska.

Tillfrlitlighet
Acceptans av frekvens fr systemnedgng Systemet fr tas ur drift fr
underhll maximalt tv timmar per mnad.
terskapbarhet av systemtillstnd vid nedgng Vid systemnedgng ska
databas och andra resurser terskapa sig sjlva till senast knda fungerande
konfiguration.
Exakthet Alla berkningar ska gras med hjlp av tal med minst 5 decimaler.
Genomsnittstid mellan systemnedgngar Systemet fr max g ned 3 gnger
per r.
Prestanda
Svarstider Lagring eller terkoppling vid fel av lagring fr aldrig ta lngre n
fem sekunder frn det att anvndaren initierar operationen.
Uppstartstid Det ska ta max 30 sek att starta systemet.
Resursutnyttjande Systemet fr maximalt ta 4GB internminne i ansprk.
Kapacitet Systemet ska klara av en datagenomstrmmning av 500MB per
sekund.
Frvaltningsbarhet
Testbarhet Systemet ska kunna testas i Visual Studio 2013.
Utbyggbarhet Systemet ska kunna erhlla fler servrar utan att behvas
stngas ned.
Anpassningsbarhet Nya sprk ska kunna lggas till utan att systemet behver
starta om.
Kompabilitet Systemet ska kunna kras p Windows Xp, Windows Vista,
Windows 7 och Windows 8.
Konfigurerbarhet Sprkkonfigurationen ska kunna ndras utan omstart.
Installerbarhet Systemet ska installeras genom en wizard.
Flyttbarhet Kommunikation ska gras mot en centralnod s underliggande
infrastruktur kan flyttas och ndras utan att klienter pverkas.
vriga krav
Designkrav:
-

Design Systemet ska utvecklas i Microsoft Visual Studio

Grnssnitt till externa system XML ska anvndas fr att hmta och
skicka information frn och till andra system.
Fysiska krav Systemet ska f plats i en datarack.

Skerhetskrav:
-

Skerhetskrav Olika personer ska ha tillgng till olika delar av

systemet.

Legala krav:

Legala krav Systemet ska inte ska efter privat information i datorn.

Kravtyperna delas upp i de s.k. artefakterna. Behov och egenskaper kommer frn
visionen. Funktionella mjukvarukrav och ev. unika icke-funktionella mjukvarukrav
kommer frn anvndningsfallen. Funktionella krav, och icke-funktionella
mjukvarukrav kommer frn den kompletterande kravspecifikationen.
Bra frgesammanfattning:
-

Hur indelas mjukvarukrav?

Varfr anvnder vi kravattribut?
Vad innebr sprbarhet?
Vilka kravtyper finns det?
Vad r FURPS+?
Vad knnetecknar icke-funktionella krav?

Anvndningsfall, aktrer och anvndningsfallsmodell.

Ett anvndningsfall beskriver ett beteende och en dynamik i en process. En
diskmasking diskar. En stereo spelar musik. Med en finare beskrivning: Ett
anvdningsfall r en sekvens av handlingar ett system utfr, vilket ger ett
observerbart resultat av vrde fr en specifik aktr. Ett anvndningsfall stdjer
allts aktrens mlsttning med systemet.
Hur hittar vi en aktr? Jo, vem r det som anvnder systemet. En aktr r alltid
utanfr systemet. Det r mnniskor, andra system och externa sensorer.
Hur hittar vi ett anvndningsfall? Jo, vilka r deras mlsttningar med
anvndningen. Det r viktigt att anvndningsfallet specificerar vad systemet ska
gra, inte hur det faktiskt ska gra det.
Ett anvndningsfall r allts mer inriktat p vad en aktr faktiskt vill gra i
slutndan med systemet, och inte hela processen med att faktiskt komma dit. Ett
bra exempel r en mp3-spelare dr mlet ofta r att spela en lt. Dr r just
spela en lt ett anvndningsfall, medan processen med att ska inte r ett lika
direkt anvndningsfall.
Man delar in anvndningsfall i olika ansvar. T.ex. en diskmaskin. Det r
anvndarens ansvar att stoppa in den smutsiga disken, fylla med diskmedel,
stnga luckan, stlla in rtt program, starta, ppna luckan och ta ut den smutsiga
disken. Diskmaskingens ansvar r att lsa luckan, snurra trumman, fylla p med
vatten, vrma vatten, tmma vatten, lta vattnet avdunsta, lsa upp luckan.
Nr man ritar ett anvndningsfallsdiagram s drar man linjer mellan aktrer och
anvndningsfall fr att visa relationen mellan dem. Eventuell riktning p pilen
visar vem som tar initiativet.
Bra frgesammanfattning:
-

Vad beskriv med anvndningsfall?

Vad r en aktr?
Hur hittas anvndningsfall?
Vilka olika modellelement ingr i anvndningsfallsmodellering? Vad str de
fr?
Hur beskrivs kommunikation mellan aktrer och anvndningsfall?

Vad kan vi gra nr vi har vldigt mnga anvndningsfall eller aktrer?

Anvndningsfallsspecifikation
En anvndnignsfallsspecifikation innehller:
-

12345678-

Namn - Diska
Kort beskrivning Frn att en aktr startar diskmaskingen till att disken
r ren.
Lokalt diagram Aktr till anvndningsfallet diska.
Frvillkor Det ska finnas smutsig disk i diskmaskingen. Diskmaskingen
r laddad med diskmedel. Diskmaskingen ska vara stngd.
Fldesbeskrivningar normalflde och alternativflden

Anvndningsfallet brjar nr aktren trycker p starta-knappen.

Diskmaskingen hmtar vatten.
Diskmaskingen blandar vattnet med diskmedlet.
Diskmaskingen diskar disken.
Diskmaskingen tmmer vattnet.
Diskmaskinen avdunstar vattnet.
Diskmaskingen r klar.
Aktren stnger av diskmaskingen.
Eftervillkor
Speciella krav och vrig info Cykeln ska max ta 30 minuter att
genomfra.
Utkningspunkter
Relationer Aktren startar och avslutar processen.
Referenser

Bra frgesammanfattning:
-

Vad beskrivs med anvndningsfall?

Hur hittas anvndningsfall?
Vilka olika modellelement ingr i anvndningsfallsmodellering? Vad str de
fr?
Vad r fr- och eftervillkor?
Var placeras icke-funktionella krav?

Abstrakta anvndningsfall
Abstrakta anvndningsfall r ett delflde som utkar ett anvndnignsfall eller
anvnds av flera andra anvndningsfall till skillnad frn de konkreta, vanliga, dr
de initieras av en aktr och utfr ett komplett flde. Abstrakta anvndningsfall
anvnds fr att frenkla och frtydliga anvndningsfallsmodellen.
En inkluderingsrelation r en association som specifierar att beteendet hos den
ena explicit skjuts in i beteendet i i den andra. Om a drar pil till b s r a
beroende av b. B r d en del av a.
En utkningsrelation r en association som specificerar att ett beteende hos A
som kan skjutas in i B om pilen r dragen frn A till B.

Generalisering fungerar som arv, att de rver. En administratr r t.ex. ofta en

specialisering(generalisering) av en anvndare.
Bra frgesammanfattning:
-

Vad r inkludering?
Vad innebr utkning?
Varfr gr vi generalisering?
Hur uttrycks inkludering och utkning?

Kravdokumentation
Frsta delen av kravdokumentationen r ordlistan. I ordlistan defineras en
vokabulr som resten av projektet ska anvnda. Dessa defineringar hjlper fr en
tydlig kommunikation. Ordlistan fylls med bra termer frn intressenter,
anvndningsfallsmodellen, och visionen.
Andra delen av kravdokumentationen r visionsdokumentet. I visionsdokumentet
beskrivs systemet som frdigbyggt, allts sjlva resultatet av projektet.
Beskrivningen av visionen hlls hgt och br ge en bra frstelse fr vad
systemet ska gra. Visionsdokumentet r dock ingen kravspecifikation utan mer
utav en verblick. Visionsdokumentets frmsta funktioner r att komma verrens
om vilka problem som ska lsas, identifiera intressenter, definera systemets
grnser, och beskriva systemets primra funktioner p ett verblickande stt.
Tredje delen r vr anvndningsfallsmodell och specifikation.
Fjrde delen r vr kompletterande kravspecifikation. Dr beskrivs de ickefunktionella kraven. Icke-funktionella krav struktureras genom FURPS+.
Nr vi har vr anvndningsfallsmodell, vrt anvndningsfall, och vr
kompletterande specifikation s bildar de tillsammans vr kravspecifikation fr
mjukvara, vrt femte steg.
Det sjtte steget r att dokumentera anvndargrnssnitt. Det kopplas till
anvndningsfall och styrs av anvndningsfall dr vi stter anvndaren som
frmsta intressent.
Det ttonde steget r vr ndringsbegran. Det r hr vi fr lov att gra
ndringar p vra krav tillsammans med beskrivng, konsekvenser, och kostnader.
Bra frgesammanfattning:
Vad str i visionsdokumentet?
Vem lser visionsdokumentet?
Vilka kravtyper innehller en kompletterande specifikation?
Varfr har vi en ordlista?
Nmn en typ av anvndargrnssnittsdokumentation.
Vad r kravspecifikation fr programvara?

Anvndningsfallsdiagram
Anvnder aktrer och anvndningsfall och kopplar ihop dessa med korrekta
relationer. Pilen fr association gr t hllet frn den som tar initiativet. T.ex.
bankomatkund -> ta ut pengar -> bankserver. Ett annat exempel r en webbutik.
Medlem -> bestlla varor -> ordermottagare -> leverans av varor ->
lagerarbetare.