Transcript Krav -uppgift4aTJ

Analys och Design av IS, Uppgift 4a
Theresa Jernriddare
2013-02-27
Uppgift 4 a
Krav
Analys och Design av IS, Uppgift 4a
Theresa Jernriddare
2013-02-27
Innehåll
1.
Inledning ...................................................................................................1
1.1. Introduktion........................................................................................1
1.2. Syfte ..................................................................................................1
1.3. Metod.................................................................................................1
1.4. Avgränsning.......................................................................................1
2. Syfte med systemet ..................................................................................1
3. Systemets intressenter .............................................................................2
4. Kravinsamling ...........................................................................................2
5. Personas...................................................................................................3
6. Funktionella och icke funktionella krav .....................................................3
7. Kravgransning...........................................................................................5
8. Användningsfall ........................................................................................5
9. Diskussion och slutord............................................................................11
Referenser .....................................................................................................12
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
1. Inledning
1.1. Introduktion
Företaget Äventyrsmakarna har nu beslutat sig för att göra slag i saken och
anskaffa ett informationssystem. Ursprungligen hade man enaabrt studenter som
kunder men nu vänder man sig till allmänheten och erbjuder äventyrsaktivieteter.
I takt med att företaget expanderar ökar behovet av ett informationssystem som
kan hantera och snabba upp rutinuppgifter som bokningar, betalningar,
momsredovisningar o dyl.
1.2. Syfte
Den här rapporten syftar till att visa nyttan med ett informationssystem, hur
kravinslamling går till och vad kravinsamligen som sådan skall baseras på. Jag
visar även hur man skapar personas och analyserar användarfall som ska ligga
till underlag för en kravspecifikation.
1.3. Metod
Som underlag för kravinslamlingen inför uppgiften har jag följande dokument:
Förändringsanalys (Mittuniversitetet, 2013) och Äventyrmakarnas Evenemang
Vintern 2012/2013 (Mittuniversitetet, 2013). Jag har även använt mig av Ulf
Erikssons Kravhantering för IT-system.
1.4. Avgränsning
Rapporten innehåller inte tekniska specifikationer och behandlar inte hur
systemet ska byggas utan avgränsas till vad det ska kunna hantera utifrån
kraven.
2. Syfte med systemet
Ett informationssystem kan fylla många syften och ha flera användargrupper, t ex har
en webbshop både frontend och backend där kunder och administratörer, vilka alla
alltså är slutanvändare, använder olika delar av systemet. Man kan jämföra det med
det otroligt populära content managementsystemet WordPress, vilket är det mest
använda verktyget för bloggar idag. Frontend visar själva bloggen och backend är
där bloggaren loggar in, skriver inlägg, godkänner kommentarer, samlar in statistik
osv (Wordpress, 2013, About Wordpress). Nyttan med ett system kan alltså vara
flerdimensionell och vad som förväntas av ett system beror alltså på vilken av
användarna man frågar.
Äventyrsmakarna behöver ett system med frontend och backend. Frontend är till för
att kunderna enkelt ska kunna hitta information om events, registrera kunduppgifter,
göra en bokning och betala för arrangemanget.
I backend ska administratörerna kunna hantera/ändra bokningar, kunddata,
registera/ändra betalningar, se statistik och ta ut momsunderlag till bokföringen.
1
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
3. Systemets intressenter
Systemet har huvudsakligen två typer av användare: kunder och administratörer.
Administratörerna kommer huvudsakligen jobba med att kunna föra in bokningar och
betalningar manuellt samt ta fram underlag till t ex momsredovninsning eller
fakturering.
Kunderna använder systemet för informationssökning, bokning och betalning. Vad
betgrfäffar kunder kan man här dela upp dessa i flera intressentkategorier: studenter,
företag/organisationer, semestrande privatpersoner.
Vidare kan man även tänka sig att en revisor/ekonomiavdelning skulle kunna ha
nytta av systemet om man bygger det så att all moms och övrig relevanta uppgifter
kan sammanställas i rapporter och exporteras till ett bokförings- och
administrationsystem, t ex Visma.
Företagets marknadsförare är även en intressent eftersom han/hon kan behöva
använda sig av nyhetsbrev som skickas ut via systemet, hantera kunddata för utskick
och liknande.
Intressent
Typ av krav
Kund
Hitta information, boka plats på event,
betala, registrera kunduppgifter,
prenumerera på nyhetsbrev.
Registerar bokningar, avbokningar,
registrera betalningar.
Fakturera, exporta momsrapoort och
annat bokföringsrelaterat
Tillgång till kunddata/intresserade av
nyhetesbrev, kunna skicka nyhetsbrev till
kunde, publicera nyheter på
webbplatsen
Administratör
Ekonom
Marknadsförare
4. Kravinsamling
Kravinslamling sker normalt sett med hjälp av relevanta frågeformulär, intervjuer,
personas, användarfall och givetvis utifrån kundens/beställarens önskemål. Inom
användarcentrerad utveckling ska kraven ställas utifrån de reslutat man får fram när
man intervjuar och analyserar alla slutanvändare av systemet. (Eriksson, 2012, s.
61).
I Äventyrsmakarnas fall skulle det vara nödvändiugt att basera kraven på både vad
administratörerna/ägarnas behov och deras kunders behov, eftersom de alla kommer
använda systemet men har olika behov och önskemål på vad systemet ska klara av.
I det här fallet är företaget fiktivt och därför kan inte intervjuer o dyl genomföras.
Kraven baseras därför på det som står att finna i Förändringsanalysuppgiften
(Mittuniversitetet, ,2013, Förändringsanalys ), i evenemangsdokumentet
(Mittuniversitetet, 2013, Äventyrsmakarnas evenemang vintern 2012/2013) och i
förändringsåtgärder jag kom fram till i Uppgift 2 (Jernriddare, T., 2013, s.2-3 ).
2
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
5. Personas
Baserat på systemets intressenter har jag tagit fram tre personas, två av dessa faller
under kundkategorin och en persona är administratör.
Studenten Lina - Lina är 20 år och med en begränsad budget som söker roliga och
meningsfulla aktiviteter att ägna sig åt på fritiden. Lina har inte egen bil så
Ävertysmakarnas upplägg passar henne utmärkt eftersom hon inte kan åka till fjällen
på egen hand, då varken transport eller ekonomiska möjligheter finns. Isklättring är
något hon alltid velat prova men hon har inte råd att skaffa egen utrustning eller gå
med i en klättringsklubb. Genom Äventyrsmakarnas isklättrings-evenemang får hon
möjlighet att låna utrustning gratis och får dessutom hjälp av en duktig instruktör.
Frilufts-Ville - Vilhelm är 60 år och änkeman. Han har inte en stor umgängeskrets
men tycker mycket om natur, foto och att träffa nya människor. Dagsutflykter i stil
med vad Äventysmakarna erbjuder är precis vad han anser vara "lagom".
Skidutflykten är inte så avancerad att man måste vara proffs på skidor och eftersom
man tar det hela i maklig takt så finns det dessutom tillfälle att ta fina naturfoton.
Kaffe och korvgrillning i gott sällskap är dessutom en sådan sak som Ville anser ger
guldkant på tillvaron.
Anja - ägare till Äventyrsmakarna sköter det mesta av bokningar och redovisning.
Inför varje aktivitet är det hon som ser till att alla deltagare har betalat för aktivietetn
och hon mailar även ut en påminnelse med en bifogad lista om att man ska komma
ihåg att ta med sig varma kläder och eventuellt handduk och badkläder (beroende på
aktivitet).
Anja är social och ett riktigt energiknippe men hon vill hellre lägga tid på att
genomföra aktivieterna än att sitta och svara i telefonen dagarn i ända.
6. Funktionella och icke funktionella krav
Informationssystemet ska vara till nytta för alla intressenter. Med nytta kan man avse
funktioner som hjälper användarna att uppnå önksat resultat, men det kan även
handla om ren design och information.
Funktionella krav:
1. Söka efter evenemang. Detta har prioritering nummer ett, för om kunden inte vet
vilka evenemang som finns kan man heller inte boka plats/anmäla sitt intresse.
Information är A och O när man säljer produkter eller tjänster. Efter 14 år som
webbutvecklare har jag lärt mig att hitta informationen på en webbplats är viktigare
än alla andra funktioner.
2. Välja aktivitet genom att klicka på respektive länk. Motivering: Här ska man kunna
hitta mer utförlig information om när evenmanget går av stapeln, priser, vad som
ingår i priset. Ingen köper grisen i säcken utan alla som ska betala för en tjänst vill
veta vad det är de betalar för.
3
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
3. Boka plats till vald aktivitet. En av anledningarna till att bokning inte ligger som
prioritet nummer ett är att bokning även kan ske per telefon. Det finns alltså
alternativa möjligheter att boka plats omgående.
4. Genomföra betalning. Detta är en funktion som underlättar inte enbart för
företaget utan även för kunden som slipper ta med kort eller kontanter till
evenemanget för att betala.
5. Registrera kunduppgifter. Att boka plats på ett evenemang behöver inte
nödvändigtvis betyda att man registrerar sig. Dock ska möjligheten finnas så att man
får möjlighet att ta del av nyheter, erbjudanden, rabatter osv. Detta är mycket viktigt i
marknadsföringsammanhang för företaget.
Icke-funktionella krav:
1. Användbarhet. Kan sidan verkligen användas på det sätt man kan förvänta sig, är
gränssnittet inituitivt eller krävs det en förförståelse för hur informationssystem
fungerar? Kundformulär och bokningsformulär ska anpassas så att de inte an
skickas in tomma eller med felaktiga datatyper.
Användare som inte är vana vid att använda webbbaserade bokningsformulär och
registreringsformulär ska hitta hjälpfunktioner vid varje formulärfält.
Terminologin i systemet ska vara begriplig utan alltför tekniska beskrivningar eller
bransch-förkortningar som ovana användare kanske inte förstår.
2. Design. Webbplatsen måste se seriös ut och genast låta besökarna förstå att de
hamnat hos en arrangör som ägnar sig åt just det de söker efter. Kunden är bara ett
klick från att lämna webbplatsen och söka sig någon annanstans. man har bara
några futtiga sekunder påsig att fånga besökarens intresse och därför hamnar design
högt upp på prioriteringlistan.
3. Prestanda. Det finns inget som är så irriterande som 404 error-sidor och slöa
servrar som inte kan visa bilder eller tar evigheter på sig att ladda en sida. Här
riskerar man snabbt att förlora potentiella kunder. Systemet ska kunna klara samtida
använding och åtkomst till kunddatabasen samt bokningsfunktioner av 100
användare samtidigt.
Sökfunktionen ska kunna presentera resultat inom fem sekunder i 95% av
sökningarna.
4. Underhållbarhet. Det ska finnas systemdokumentation som underlättar för
programmerare att undehålla, bygga ut och modifiera systemet. Ett system blir ofta
snabbt utdaterat och föråldrat och behöver byggas om eller expanderas med nya
funktioner. Man kan inte ta för givet att samma programmerar som byggde systemet
är de som kommer bygga om eller ändra i systemet, varför en noggrann
dokumentation är viktig.
Systemet sall även byggas utifrån en fastställd kodstandard för att framtida
programmerare ska veta hur systemet är uppbyggt och att det inte är en massa
"fulhack" i koden.
5. Tillförlitlighet. Systemet ska kunna återgå till normal hantering efter ett fel, utan att
manuella åtgärder behöver vidtas. Systemet ska vara tillgängligt för användarna 90%
av tiden. Underhåll, uppgraderingar och fel kan ofta ta mer tid än vad man tror så
4
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
man måste räkna med en viss felmarginal, men ändå ha en strävan att ha så lite
nertid som möjligt.
7. Kravgranskning
Inledningsvis sker en informell granskning av kravdokumentet för att hitta enkla eller
uppanbara fel och för att spara in tid. Den infrmellla gransning sker genom att en
kollega läser igenom dokumentet (Eriksson, 2012, s. 166). Därfter sammakallas till
ett första formellt granskningsmöte där samtliga deltagare ska ha läst igenom
kravspecifikationen och sammanställt synpunkter. På mötet går presentatören
igenom dokumentets struktur och de granskare som utsetts kommer med sina
synpunkter. För att granskningen ska ge resultat måste granskarna vara insatta i
dokumentet och vara väl förtrogna med ämnet. Det är lämpligt att ha sakkunniga
inom respektive område som t ex testare, utvecklare och minst en
användarrepresentant för att täcka in kravspecifikationens alla delar (Eriksson, 2012,
s. 169-171).
Efter granskningsmötet sker en omarbetning och uppföljning där dokumentet ska
revideras och sedan kan man hålla ytterligare ett granskningsmöte för att jämföra
kvaliteten på dokumentet från förra mötet och hur det ser ut nu (Eriksson, 2012, s.
166).
På granskningsmöten bör man ha en balanserad grupp av granskare och dessutom
ska dessa ha sammanställt en checklista som tar upp viktiga frågor kring
dokumentet. Detta för att man inte ska missa viktiga frågeställningar som t ex om det
finns tillräcklig information eller om det rentav finns onödig information? Finns det
förslag till lösningar, går det att dela upp något krav i flera krav, går det att testa
kraven eller användarfallen osv? (Eriksson, 2012, s. 180).
8. Användningsfall
Användningsfallen ska beskriva hur systemets användare interagerar med systemet,
eller snarare hur systemet ineteragerar med användarna eller med ett annat system.
Användingsfallen behöver inte vara särdeles tekniska utan mer som en beskrivning
sett utifrån slutanvändarens perspektiv (Wikipedia, 2013, Användningsfall).
Användningsfallen bör dokumenteras på ett strukturerat sätt, t ex i en tabell som
nedan (Eriksson, 2012, s. 140-141).
Aktör
Kund
Kundtjänst
Kund
Användningsfall
Sök information
Registera kunddata
Registrera kunddata
Boka plats på evenemang
Boka kund till evenemang
Prenumerera på
nythetsbrev och
erbjudanden
Användningsfall 1: Det första användingsfallet handlar om att kunden letar efter
information kring ett evenemang, för detta kan man använda sökfunktionen eller
5
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
klicka på en länk under aktuella evenemang. När man hittat den information man
letar efter så ska man kunna trycka på en knapp som heter Boka plats och då hamna
på en sida där man kan fylla i nödvändiga uppgifter och få en bekräftelse direkt på
skärmen (och via epost) om att bokningen är genomförd.
Användningsfall 2: Kundtjänst tar emot ett telefonsamtal av en kund som inte har
tillgång till internet. Kundtjänst ska då kunna registrera kundens data i systemet och
boka in kunden till det aktuella evenemanget/aktiviteten.
Alternativt flöde: Kunden hittar information på webbplatsen men ringer och ber
kundtjänst göra bokningen.
Användningsfall 3: En återkommande kund beslutar sig för att skaffa ett
användarkonto hos Äventyrmakarna och registrerar namn, adress, e-post och
telefonnummeroch bockar samtidigt i en checkbox som medger att man får
nyhetsbrev och erbjudanden till sin inbox.
Användningsfallen ska beskrivas på olika sätt men man brukar ofta använda text,
men även ibland bilder.
När man beskriver användningsfall utifrån text gör man ofta detta i tabellform
(Eriksson, 2012, s. 143). Tabellen nedan visar Användningsfall 1.
ID: 1
Namn: Boka plats på evenemang
Kortfattad beskrivning
Huvudflöde
Alternativt flöde 2
Alternativt flöde 3
Alternativt flöde 4
Författare: Theresa Jernriddare
Kunden söker efter infrmation och bokar
plats till aktivetet/evenemang
1. Kunden använder sökfunktionen och
anger "Skidåkning"
2. Kunden väljer Skidutflykt april 2013 bland
sökresultaten
3. Kunden fyller i bokningsformuläret
4. Bokningsbekräftelse visas på skrämen
och sänds ut som mail
1. Kunden använder sökfunktionen och
anger "Skidåkning"
2. Kunden väljer Skidutflykt april 2013 bland
sökresultaten
3. Kunden fyller i bokningsformuläret
4. Bokningsbekräftelse visas på skrämen
och sänds ut som mail
5. Kunden genomför betalning med kort på
webbplatsen.
6. Betalningsbekräftelse skickas ut via mail
och visas på skärmen
1. Kunden använder sökfunktionen och
anger "Skidåkning"
2. Kunden väljer Skidutflykt april 2013 bland
sökresultaten
3. Kunden ringer Äventyrmakarna ochbokar
plats till aktivteten
4. Kundtjänst mailar en bokningsbekräftelse
till kunden.
1. Kunden fyller i registreringsformuläret så
att kunddata sparas i databasen.
2. Kund bockar i att han/hon vill ha
nyhetsbrev.
3. Kunden söker reda på skidutflykter i april
6
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
Startvillkor
Slutvillkor
3. Kunden bokar plats till skidutflykt
4. Bokningsbekräftelse visas på skärmen
och sänds ut som mail.
Kund med internettillgång
Bokningsbekräftelse skickas till kund
Användningsfall med bilder/diagram:
Användningsfall 2: Kundtjänst tar emot ett telefonsamtal av en kund som inte har
tillgång till internet. Kundtjänst ska då kunna registrera kundens data i systemet och
boka in kunden till det aktuella evenemanget/aktiviteten.
Alternativt flöde: Kunden hittar information på webbplatsen men ringer och ber
kundtjänst göra bokningen.
Användningsfall 3:
Ska man utgår från ett läroboksexempel påhur ett användningsfall ska beskrivas i ett
dokument så ska det innehålla en del formalia (Eriksson, 2012, s. 305-309). Jag har
gjort detta exempel ganska kortfattat för att spara in på utrymme.
7
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
Äventyrsmakarna
Bokningssystem
Användningsfall: Registera kunduppgifter
Version 1.1
Dokumenthistorik:
Datum
2013-02-27
Version
1.1
Beskrivning
Första utkast till
användarfall 3. ID 3.
Författare
Theresa Jernriddare
Innehållsförteckning:
1.1 Kortfattad beskrivning
1.2 Kontaktpersoner
1.3 Termer och förkortningar
1.4 Regler
1.4 Hänvisningar till andra dokument
1.5 Motivering
1.6 Utdrag ur användingsfallsmodell
1.7 Öppna frågor
2. Flöde av händelser
2.1 Huvudflöde
2.2 Alternativflöden
2.2.1 Alternativflöde 1
3 Särskilda krav
4 Startvillkor
5 Slutvillkor
1.1 Kortfattad beskrivning
Dokumentet visar ett användarfall gällande bokningssystem till Äventyrmakarna.
1.2 Kontaktpersoner
Verksamhet
Utvecklare
Kravgranskare
Theresa Jernriddare
Nisse Hult
1.3 Termer och förkortningar
IS: Informationssystem
1.4 Regler
Endast anställda hos Äventyrmakarna skall kunna logga in i systemets
administrationssystem.
Systemet skall följa gängse regler enligt PUL.
8
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
1.5 Hänvisningar till andra dokument
Ej applicerbar
1.6 Motivering
Användningsfallet syftar till att visa flöden och alternativa flöden när en kund registerar
personuppgifter i systemets databas.
1.7 Utdrag ur användningsfallsmodell
1.8 Öppna frågor
Ej applicerbar
2. Flöde av händelser
2.1 Huvudflöde
1. Kund loggar in på sin dator
2. Kund surfar in på webbplats
3. Kund registrerar personuppgifter på webbplats och tackar ja till
nyhetsbrev
4. Server bekräftar registeringen
9
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
5. Server skickar ut
nyhetsbrev
2.2 Alternativflöde
1.
2.
3.
4.
5.
6.
7.
Kund ringer kundtjänst
Kundtjänst svarar
Kundtjänst registrerar kunddata i databas
Kundtjänst registrerar intresse för nyhetsbrev
Kund lägger på luren
Server skickar ut bekräftelse om registrering till kund
Server skickar ut nyhetsbrev till kund
3 Särskilda krav
Ej applicerbar
10
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
4 Startvillkor
Kunden skall ha dator och mailkonto.
5 Slutvillkor
Kunden får bekräftelse på registrering och nyhetsbrev via mail.
9. Diskussion och slutord
Kravhantering är komplext och kan utföras på många olika sätt och vad som bäst
lämpar sig för det aktuella projektet beror på systemets natur och vilka ingående
delar som ska finnas med, vilka användarna är och de tekniska förutsättningarna.
Det finns många svårigheter i kravhanteringen och det börjar redan när man ska
fastställa systemets intressenter. Man måste ställa sig frågan om man baserar
kraven på korrekta personas? Kommer det finnas så många undantagsfall att man
kanske måste skapa fler personas? Hur testar man om användningsfallen är
korrekta och har man täckt in alla typer av användingsfall?
Vidare måste man även tänka på om systemet kan komma att behöva byggas ut
eller ändras i framtiden och vilka krav ska man då ställa för att förebygga eventuella
svårigheter för framtida utveckling?
Dokumentationen är A och O i det här läget och dokumentationen måste granskas
kritisk av en grupp människor vars sammantagna kompetens täcker in alla delar av
kraven. Detta inte minst för att man måste eftersträva att hitta fel i kraven på ett tidigt
stadium, helst innan kravspecifikationen går vidare till utvecklargruppen. Ju senare
man hittar fel i ett utvecklingsprojekt desto kostsammare och mer tidsödande blir det
att åtgärda felen.
11
Analys och Design av IS (Uppgift 4 a)
Theresa Jernriddare
2013-02-27
Referenser
Eriksson, U., (2012). Kravhantering för IT-system. Lund:
Studentlitteratur.
Jernriddare, T., (2013) Vision [Elektronisk]. Mittuniversitet. URL:
https://elearn.miun.se/moodle/pluginfile.php/71138/mod_assignment/s
ubmission/29025/uppgift2.doc?forcedownload=1 [Tillgänglig: 2013-0221]
Mittuniversitetet, (2013). Förändringsanalys [Elektronisk]. URL:
https://elearn.miun.se/moodle/pluginfile.php/71138/mod_assignment/in
tro/2%20F%C3%B6r%C3%A4ndringsanalys.pdf [Tillgänglig: 2012-0221]
Mittuniversitetet, (2013). Äventyrsmakarnas evenemang vintern
2012/2013. Mittuniversitetet. URL:
https://elearn.miun.se/moodle/pluginfile.php/71138/mod_assignment/in
tro/%C3%A4ventyrsmakarnas.pdf [Tillgänglig: 2013-02-21]
Wikipedia, (2013), Användningsfall [Elektronisk]. URL:
http://sv.wikipedia.org/wiki/Anv%C3%A4ndningsfall [Tillgänglig: 2012-02-27]
Wordpress, (2013). About Wordpress [Elektronisk]. URL:
http://wordpress.org/about/features/ [Tillgänglig: 2013-02-21]
12