Utveckling av en kravspecifikation för ett incidentrapporteringssystem

Transkript

1 Utveckling av en kravspecifikation för ett incidentrapporteringssystem Joakim Hedström och Marcus Bengtsson LTH Ingenjörshögskolan vid Campus Helsingborg Lunds Universitet Examensarbete: Handledare vid LTH: Martin Höst Institutionen för Telekommunikationssystem

2 English title: Development of a requirement specification for an incident reporting system Copyright Joakim Hedström, Marcus Bengtsson LTH Ingenjörshögskolan vid Campus Helsingborg Lunds Universitet Box Helsingborg LTH School of Engineering at Campus Helsingborg Lund University Box 882 SE Helsingborg Sweden Tryckt i Sverige Media-Tryck Biblioteksdirektionen Lunds Universitet Lund 2006

3 Sammanfattning Examensarbetet utfördes på Parajett AB, som är ett grafiskt tryckeri i Landskrona. De ville bli ISO-certifierade inom informationssäkerhet som innebär att ett system för rapportering av säkerhetsincidenter ska finnas. En kravspecifikation över detta system utvecklades. Denna är tänkt att användas av Parajett AB för att utveckla eller upphandla ett system. Utvecklingen av kravspecifikationen krävde användning av olika tekniker och metoder. För att analysera och elicitera fram krav användes fokusgrupp, brainstorming och prototyp. Kraven illustrerades med teknikerna kontextdiagram, funktionslista, textkrav, krav med öppna mål, virtuella fönster och uppgiftsbeskrivning. En throw-away prototyp utvecklades för att underlätta då vi tog fram kraven. Utvecklingsprocessen bestod av tre iterationer. I dessa ingick aktiviteterna Teoretiska studier, Throw-away prototyp, Möte med kund, Kravelicietering, Kravspecifikation. Throw-away prototypen medförde att kraven i vissa fall blev för detaljerade och innehöll designkrav. Syftet med examensarbetet var att studera kravhanteringsprocessen och därför testades flera olika tekniker, metoder och standarder vilket ledde till att flertalet krav är utförligt beskrivna. Därför anses arbetet med kravspecifikationen varit mer tidskrävande än nödvändigt. Slutligen konstaterades att evolutionär utvecklingsmodell i form av throw away prototyp är en bra modell att använda då man behöver detaljerade krav innan man påbörjar designen av systemet. I vårt fall krävdes dock inte så detaljerade krav utan tiden kunde istället ha lagts på utvecklingen av systemet. Nyckelord: Kravhantering, IRS, SS , Incidentrapporteringssystem, ISO, prototyp

4

5 Abstract This thesis work was conducted at Parajett AB, which is a graphical printer company in Landskrona, Sweden. They wanted to be ISO certified in information security, which involves that a system for reporting incidents shall be available. A requirement specification of this system was developed. The specification is intended to be used by Parajett AB when developing or buying a system. The development of the requirement specification demands that different techniques and methods have to be used. To analyse and elicit requirements, focus group, brainstorming and prototyping were used. The requirements were illustrated with techniques such as context diagram, function list, feature requirement, open target, virtual window and task description. A throw-away prototype was developed to facilitate the elicitation of the requirements. The development process contained three iterations. In those iterations, activities such as theoretical studies, throw-away prototype, meeting with costumer, requirement elicitation and requirement specification were included. In some cases the Throw-away prototype resulted in requirements that were to detailed and in some cases contained design requirements. The purpose of the examination was to study requirement process and therefore different techniques, methods and standards were tested, which resulted in some requirements to be too detailed described. Therefore, the work with the requirement specification was considered to be more time consuming than necessary. Finally, the evolutionary development model in form of throw-away prototype was seen as a good model to use when you need detailed requirement before designing the system. Such detailed requirement were not demand in our case, the time could have been spent on developing the final system instead. Keywords: Requirement specification, IRS, Incident reporting system, SS , prototype

6

7 Förord Som avslutning på ingenjörsutbildningen Programvaruteknik 120p vid LTH i Helsingborg ska ett examensarbete genomföras. Examensarbetet är på 15p vilket motsvarar fulltidsstudier under ca 15 veckor. Examensarbetet ska resultera i en rapport innehållande frågeställning inom ett ämne och senare leda till en slutsats. Examensarbetet gjordes på det grafiska tryckeriet Parajett AB i Landskrona som bestämt sig för att bli ISO-certifierade inom informationssäkerhet. Standarden ISO SS krävde bland annat att ett system skulle tillhandahållas för att kunna rapportera säkerhetsincidenter. Systemet är förkortat till IRS och står för incidentrapporteringssystem. Uppdraget blev därför att utveckla en kravspecifikation för ett incidentrapporteringssystem. Kravspecifikation som utvecklades blev en del av examensarbetet där den fungerade som ett praktikfall. Syftet med examensarbetet är att öka vår förståelse och kännedom inom kravhantering, vilket gjordes genom att tillämpa olika tekniker och metoder samt att analysera och utforska dess fördelar och nackdelar. Även välkända standarder användes och analyserades. Tack vare detta projekt har kunskaper och praktiska erfarenheter inom kravhanteringen ökat. Känslan för att förstå kundens behov och förmågan att utrycka dessa med hjälp av en kravspecifikation har förbättrats markant. Vi vill rikta ett stort tack till Parajett AB som hjälpt oss under projektets gång. Varje möte på företaget var mycket givande och gav oss mer motivation som gjorde att vi kunde arbeta vidare även när det kändes som jobbigast.

8 Definitioner och förkortningar IRS IEC IEEE ISO IT LTH LIS Incidentrapporteringssystem International Electrotechnical Commission Institute of Electrical and Electronics Engineers International Organization for Standardization Informationsteknologi Lunds Tekniska Högskola Ledningssystem för informationssäkerhet Svensk - Engelsk ordlista Denna ordlista presenteras eftersom att det i rapporten använts många utryck som härstammar från engelskan. Dessa saknar ofta exakt motsvarighet inom svenskan eller motsvaras av utryck som inte är så välkända. Evolutionär utvecklingsmodell Fokus grupp Frekvens Funktionslista Förtillstånd Kontextdiagram Krav med öppna mål Textkrav Uppgift Uppgiftsbeskrivning Vattenfallsmodell Virtuellt fönster Evolutionary development Focus group Frequency Function list Pre-condition Context diagram Open target Feature requirement Task Task description Waterfall modell Virtual window Följande ord har använts på Engelska i rapporten: Brainstorming, Throw-away prototyp och Elicitera.

9 Innehållsförteckning: 1 Inledning Informationssäkerhet SS Standard för LIS Utvecklingsprocessens livscykel Kravhantering Uppdragsbeskrivning Bakgrund IRS Incidentrapporteringssystem Frågeställning Metodbeskrivning Utvecklingsmodell & aktiviteter Metoder och tekniker Genomförande Resultat Struktur över kravspecifikation Systemkrav Diskussion Slutsats Referenser...33 Appendix I: IRS Kravspecifikation

10

11 1 Inledning 1.1 Informationssäkerhet Övergången från ett industrisamhälle till ett IT-samhälle har medfört ett ökat användande av datorsystem och att olika kommunikationskanaler utnyttjas allt mer. Detta ökade användande innebär att osäkerheten kring överföring och lagring av data också ökar. Företag utvecklar idag produkter och tjänster som kan, om de kommer i orätta händer få förödande konsekvenser inte minst ekonomiskt. För att undvika en sådan katastrof ser idag fler och fler företag över sin informationssäkerhet. Ett sätt att göra detta är att certifieras enligt någon av de standarder som intygar god informationssäkerhet. En av dessa är standarden SS [3]. Denna standard innehåller exempelvis krav på att en policy för informationssäkerhet ska vara utformad och att en behörighetskontroll ska finnas. Idag finns det enbart tre företag som innehar detta bevis vilket tyder på att säkerhetsaspekten på företagen är något som bara tagit sin början. 1.2 SS Standard för LIS SS [3] är en standard för LIS (Ledningssystem för informationssäkerhet) som riktar sig till företag där hot mot deras säkerhet kan finnas. Standarden anger krav för att upprätta, införa, driva, övervaka, granska, underhålla och förbättra ett dokumenterat LIS. LIS är utformat för att säkerställa lämpliga och väl avvägda styrmedel för säkerhet som ger tillräckligt skydd för informationstillgångar och inger förtroende hos kunder och andra intressenter. Som komplement till SS har ytterliggare en standard utformats nämligen SS-ISO/IEC [4]. Denna standard innehåller endast riktlinjer för LIS och fungerar som en tolkning av SS Rekommendationerna i denna standard är till för de som ska initiera, införa och underhålla säkerheten i sin organisation. De kraven som standarden SS ställer på företagets ledningssystem för informationssäkerhet för att kunna bli certifierade är omfattande. Krav ställs inom flera område: Fysiskt skydd - Syftar till att skydda företagets informationstillgångar fysiskt, t.ex. tillträdesskydd, brandskydd, kyla och elektricitet. Informationssäkerhet - Syftar till att skydda information mot förekommande hot, förhindra avbrott i verksamheten och minska skador vilket bidrar till att maximera värdet av organisationens verksamhet. Informationssäkerhetspolicy - Ger inriktningen och de övergripande målen för hur informationssäkerhetsarbetet ska bedrivas inom företaget för verksamheten, personalen, kunderna och övriga externa intressenter. 1

12 Kontinuitet Innebär att företagets processer fortlöper utan avbrott. För att skydda verksamheten och dess kritiska rutiner från effekter av oförutsedda allvarligare avbrott eller katastrofer utvecklas en plan kallad kontinuitetsplan. Logiskt skydd - Skyddsåtgärder för företagets informationstillgångar, t.ex. backup system, behörighetssystem och antivirusprogram. Organisatoriskt skydd - Skyddsåtgärder för företagets informationstillgångar, t.ex. regler, dokumentation, ansvarsfördelning och rutiner. Riktighet - Att information inte obehörigt ändras eller modifieras. Sekretess - Att endast behöriga användare kommer åt informationen. Tillgänglighet - Att behöriga användare har tillgång till de resurser de är behöriga till i rätt tid och omfattning. Närmare innebär ett av kraven att det ska då ett misstänkt hot eller en inträffad incident uppmärksammats finnas rutiner för incidenthantering. Hanteringen ska vara snabb och effektiv. Hanteringen ska ske via rapportering innehållande, identifiering av orsak, planering för att förhindra att en liknande incident sker igen, uppföljning av antal incidenter, kostnader och konsekvenser. Ansvariga personer ska bli underättade och en återkopplingsrutin ska tillhandahållas för att ge användarna meddelande om incidentens status. En incident är en händelse som påverkar det enskilda företaget på ett negativt sätt t.ex. olyckor, driftstopp och datavirus. För att uppfylla detta krav rekommenderar man i SS-ISO/IEC att företaget ska ha ett IRS (incidentrapporteringssystem). Denna rekommendation har Parajett AB anammat och vill påbörja utvecklingen av IRS i form av en kravspecifikation. 1.3 Utvecklingsprocessens livscykel När man arbetar med mjukvara är det bra att känna till hur hela processen kan se ut även om man för tillfället bara arbetar med en del av den. Nedan presenteras de två vanligaste modellerna som används under utveckling av programvara Vattenfallsmodellen Vattenfallsmodellen innebär att man arbetar successivt med varje fas var för sig i utvecklingsprocessen [7]. Varje fas ska vara avslutad innan man påbörjar nästa. I praktiken fungerar det inte alltid så utan fel upptäcks ofta och man måste gå tillbaks till föregående aktivitet och ändra dessa [5]. Ett allmänt problem med utvecklingsmodellen är att aktiviteterna i verkligheten inte har någon distinkt gräns mellan varandra. Detta gör att det blir svårt att arbeta exakt enligt modellen, istället får man använda den som ett riktmärke i sin 2

13 planering. Ett exempel på hur vattenfallsmodellen kan tillämpas presenteras i figur 1 [7]. Figur 1. Vattenfallsmodellen Evolutionär utvecklingsmodell Idén med denna utvecklingsmodell är att man gör en initial version utifrån en översiktlig beskrivning av systemet. Denna visas sedan för kunden och vidareutvecklas genom flertalet mellan liggande versioner som hela tiden kommenteras av kunden. Detta görs fram till att en slutlig version har uppnåtts. Nedan presenteras två typer av denna utvecklingsmodell. Utforskande utveckling Målet med denna process är att hela tiden arbeta med kunden för att utforska dess krav och utifrån dessa utveckla en färdig version av systemet. De delar av systemet som är kända utvecklas först, därefter vidareutvecklas systemet genom att addera funktioner allt eftersom. Throw away prototyp Målet med denna modell är att förstå kundens krav bättre och därför utvecklas en bättre kravspecifikation över systemet. Prototypen används för att experimentera med de delar av systemet som man vet lite om. I figur 2 presenteras ett exempel på hur en evolutionär utvecklingsmodell kan tillämpas [6]. I detta exempel används först en översiktlig beskrivning för att initiera arbetet i de olika aktiviteterna. Arbetet med de olika aktiviteterna sker under hela projektets gång iterativt. Detta representeras i form av en ny 3

14 version av systemet. I denna figur kan dessa iterationer även tydas i form av pilarna mellan de två gråa boxarna. Figur 2. Evolutionär utvecklingsmodell 1.4 Kravhantering Bakgrund Kravhantering är ett ämne som blivit uppmärksammat mer och mer de senaste åren, inte minst eftersom det kan reducera kostnaden för projektet. Lägger man ner mer tid på kravhantering sparar man tid senare i projektet. Att utifrån kundens önskemål och behov bestämma hur ett system ska vara utformat kan ofta vara svårt. Kommunikationsproblem mellan kund och utvecklare är nästan alltid den bidragande orsaken till att produkten inte blir vad kunden eller användaren önskat sig. En kravspecifikation minskar dessa problem eftersom önskemålen då finns på pränt. Vid utveckling av en kravspecifikation har man flera olika hjälpmedel. Standarder används vid utformning av dokumentet för att inte missa någon viktig del. Metoder och tekniker används för att ta fram och beskriva krav. En kravspecifikation tas framförallt fram när man ska utveckla ett system helt från början. Men det kan vara intressant att även i andra fall ta fram en kravspecifikation t.ex. då en upphandling ska göras. Kunden vet ofta inte vad den vill ha och när den vet det så vill man vara säkra på man får det. I dessa fall kan en kravspecifikation enligt kundens önskemål lämnas över till leverantören som utvecklar systemet efter denna. Kravspecifikationen kan även fungera som en del i ett kontrakt. 4

15 1.4.2 Kravhanteringsprocessen Kravhanteringsprocessen är en kritisk delprocess i utvecklingsprocessen. Fel som görs i denna fas kan hänga kvar hela vägen genom projektet. Missuppfattningar om kundens behov eller helt enkelt bara ren felformulering av krav kan få allvarliga och dyra konsekvenser [7]. Trots att kravhantering visat sig vara väldigt viktigt så har många kravspecifikationer tagits fram helt utan användning av pålitliga metoder och tekniker. Till hjälp finns idag många metoder och tekniker som är specialanpassade för kravhanteringen. Dessa utvecklas kontinuerligt och används mer och mer, men trots allt för lite [7]. I figur 3 presenteras kravhanteringsprocessen i sitt hela utförande [5]. Som kan ses i figuren består kravhanteringsprocessen av ett flertal delmoment. Först görs en möjlighetsstudie där man analyserar vilka behov kunder och användare har, detta resulterar i en rapport. Utifrån rapporten bedöms vad som är möjligt att genomföra praktiskt och ekonomiskt. Efter att ekonomiska och praktiska beslut tagits går man vidare till kravelicitering och analys. Här arbetar man iterativt med att elicitera fram krav vilket inkluderar klassificering, strukturering, prioritering och validering. Detta arbete leder till att en kravspecifikation börjar ta form och att en systemmodell skapats, där kravspecifikationen även inkluderar användarkrav och systemkrav. Kraven i kravspecifikationen valideras sedan mot kund, vilket innebär att man analyserar om de är konsekventa, realistiska, validerbara och verifierbara. Slutligen samlas all dokumentation i ett och samma dokument. Figur 3. Kravhanteringsprocessen 5

16 1.4.3 Kravspecifikation Kravspecifikationen beskriver utifrån kundens behov vad som ska utvecklas. Ofta kan kravspecifikationen ligga till grund för kontrakt och prisberäkningar vilket gör den till en viktig del i utvecklingsprocessen. Kravspecifikationen ska innehålla både system- och användarkrav, där användarkraven fungerar som en inledning till systemkraven. System- och användarkraven kan skrivas var för sig eller under samma avsnitt. Enligt Henninger [5] bör kravspecifikation uppfylla följande sex krav: Den ska endast specificera externa systembeteenden. Den ska specificera krav på implementationen. Den ska vara lätt att ändra. Den ska fungera som ett referensverktyg vid vidareutveckling. Den ska innehålla information där man försöker förutse systemets livscykel. Den ska påvisa acceptabla resultat vid oväntade företeelser. I verkligheten är det svårt att följa alla dessa krav, för att underlätta ytterliggare har ett flertal organisationer tagit fram standarder för kravspecifikationer. Den mest kända är IEEE , [3]. IEEE standarden föreslår följande struktur på kravspecifikationen [5]: 1. Introduktion 1.1. Syftet med kravspecifikationen 1.2. Översikt av produkten 1.3. Definitioner och förkortningar 1.4. Referenser 2. Generell beskrivning 2.1. Produktperspektiv 2.2. Produktfunktioner 2.3. Användare 2.4. Generella krav 2.5. Antaganden och beroende 3. Specifika krav 4. Appendix 5. Index Denna standard ses inte som idealisk men anger goda riktlinjer och råd för hur en kravspecifikation kan se ut. I verkligheten beror det ofta mycket på vilken sorts mjukvara som utvecklas [5]. 6

17 1.4.4 Eliciteringstekniker En eliciteringsteknik används för att ta fram nya krav. Det finns ett flertal olika tekniker för att göra detta. Nedan presenteras de tekniker vi tyckte var till störst hjälp Brainstorming Denna eliciteringsteknik utgår från en grupp av personer som under fria former tillåts presentera alla förslag till lösningar och de problem som kan tänkas vara möjliga på systemet. Metoden har en viktig regel som innebär att inga förslag och lösningar får kritiseras. Detta är till för att stimulera ett obegränsat tänkande. Man lägger ingen vikt vid kvalitén på förslagen utan alla förslag antecknas. Anteckningarna gås sedan igenom och de bästa förslagen identifieras. Personer som ofta deltar vid brainstorming är kunder, utvecklare, och potentiella användare Fokusgrupp Fokusgrupp är en mer strukturerad form av möte eller brainstorming. En fokusgrupp kan innehålla godtyckligt antal deltagare, men antalet brukar hamna på mellan 6-12 personer. Utvecklare, kunder, användare, experter, marknadsförare och chefer är exempel deltagare som normalt deltar i en fokusgrupp. För att bibehålla strukturen under mötet brukar man även använda sig av en moderator. Ofta får användare och kunder inleda med att ge sina synpunkter på hur man vill att uppgiften ska lösas. Gruppen diskuterar vidare hur en eventuell lösning kan komma att se ut, allt utifrån varje deltagares eget perspektiv. Lösningar diskuteras, men även de problem som kan komma att uppstå ventileras. En fokusgrupp har fördelen att vara en kreaktiv metod eftersom man får en bra förståelse över vilka behov alla aktörer har. I figur 4 visas ett exempel på en fokusgrupp [6]. Figur 4. Exempel på fokusgrupp 7

18 Prototyp För att underlätta utvecklingen av en kravspecifikation kan en prototyp användas. Denna ger en klar bild över vad utvecklare menar och möjliggör en demonstration för slutanvändare. På detta sett kan man undvika missuppfattningar i ett tidigt stadium. Prototypen kan också användas i flera andra sammanhang. Utvecklare kan använda den för att experimentera fram en lösning på ett problem. Intressenter kan använda den som en utgångspunkt när de ska enas om funktionalitet och omfattning. I utvecklingsprocessen använder man sig i huvudsak av två olika sorters prototyper, evolutionär prototyp och throw-away prototyp. Skillnaden mellan dem beskrivs i figur 5 [5]. Figur 5. Skillnaden mellan Evolutionär och Throw-away prototyp En evolutionär prototyp innebär att utvecklingen av prototypen sker gradvis och syftet är att utveckla ett leveransklart system utan någon form av dokumentation. Fördelen med detta är att resurserna egentligen bara används till det slutliga systemet och slösas helt enkelt inte på något annat. När man gör en Throw-away prototyp är det primära målet är att fastställa systemets kravspecifikation. Prototypen utvecklas, utvärderas och modifieras samtidigt som allt dokumenteras i den kravspecifikation som utvecklas parallellt med prototypen. Den ofullständiga prototypen kastas och används inte senare, istället sker utvecklingen helt från början med utgångspunkt från kravspecifikationen Kravtyper För att kunna beskriva krav på olika sätt och i olika situationer använder man sig av olika kravtyper. Nedan presenteras de typer vi kommer att använda. 8

19 Kontextdiagram Ett kontextdiagram används för att visa vilka användargrupper och externa system som kommunicerar med systemet. Gränsdragningar kan göras för att illustrera domänen d.v.s. vilka objekt som ligger innanför och utanför systemet som ska utvecklas. Illustrationen visar också pilar mellan aktörerna för att visa informationsflödet. Fördelen med denna kravtyp är att man får en god överblick över systemet. Detta leder till en bra domänkännedom och en klarare bild för kunder, utvecklare och andra intressenter om att fastställa vad som ska levereras. I figur 6 visas ett exempel på ett kontextdiagram där den streckade linjen representerar domänen [6]. Figur 6. Kontextdiagram Funktionslista En funktionslista berättar vilka händelser systemet ska hantera. Varje händelse kan ses som ett meddelande eftersom det även bär med sig data. Dessa händelser kan beskrivas både utifrån produkten och också produktens domän. Fördelen med en funktionslista är att man lätt ser vad som ska utvecklas i systemet. Nackdelen är däremot att just identifiering av olika funktioner ofta ses som en aktivitet som tillhör design och inte kravhantering. Likaså ska man se upp med att gruppera kraven eftersom det också ofta ses som en aktivitet som tillhör design. I Figur 7 visas ett exempel på en funktionslista över händelser mellan en aktör utanför domänen och systemet [6]. 9

20 Krav 1: Systemet ska stödja följande händelser/användaraktiviteter/uppgifter: K1.1 Gästen bokar K1.2 Gästen checkar in K1.3 Gästen checkar in K1.4 Byta rum Figur 7. Funktionslista Textkrav Det vanligaste sättet att beskriva ett krav är genom en formulering i vanlig textform. Textkrav är en enkel kravtyp för att specificera kraven både för kunden och för utvecklaren. En utvecklare kan med enkelhet översätta texten till funktioner i systemet. Nackdelen med textkrav kan dock vara att formuleringen kan tolkas olika och få olika betydelse beroende på vem som läser dem. Ett exempel på hur ett textkrav kan se ut visas i figur 9 [6]. Krav 1: Systemet ska kunna lagra att ett rum är upptaget under en viss period för reparation. Figur 8. Textkrav Krav med öppna mål När man specificerar krav finns det situationer då man anger ett numeriskt värde som man vill lämna öppet för kunden att bestämma vid ett senare tillfälle. För att göra detta kan man använda sig av en kravtyp som heter krav med öppna mål. Exempelvis vill man ha en viss svarstid på en förfrågan från systemet. Hur snabbt det går vet man inte innan systemet är färdigt. För att få en extremt snabb svarstid kommer kostnaden öka för kunden, utan att han kanske behöver det. Innan man vet hur snabbt man vill att svarstiden ska vara, så används kravtypen för att få ett tillfredsställt numeriskt värde till rätt kostnad då kravet lämnas öppet för kommande förhandling. I figur 9 visas ett exempel på ett krav skrivit med denna metod [6]. Krav 1: Om användaren är inaktiv i minuter ska användaren loggas ut automatiskt. Figur 9. Krav med öppet mål 10

21 Virtuella fönster Det finns tillfälle då man grafiskt vill visa vilken nödvändig data som ska finnas med i exempelvis en funktion. Då använder man en kravtyp som kallas för virtuella fönster. Syftet med den är att kunden och utvecklaren på ett enkelt sätt ska kunna komma överens om vilken data som ska finnas med. Fördelen är alltså att ett virtuellt fönster är lättförståeligt både för kunden och utvecklaren. Det är dock viktigt att påpeka att virtuella fönster får varken innehålla knappar eller menyer i sina illustrationer, då detta tillhör aktiviteten design. I figur 10 visas ett exempel på ett virtuellt fönster [6]. Figur 10. Virtuellt fönster 11

22 Uppgiftsbeskrivning Vissa krav består ofta av flera deluppgifter vilket kan vara svårt att beskriva med ett vanligt textkrav. Ett strukturerat sätt att beskriva krav som innehåller deluppgifter kan göras med hjälp av en uppgiftsbeskrivning. En uppgiftsbeskrivning innehåller följande information: 1. Syfte: Beskriver målet med uppgiften eller vilken uppgift funktionen ska lösa. 2. Förtillstånd: Ett läge som systemet eller aktören måste befinna sig i innan uppgiften kan genomföras. 3. Frekvens: Uppskattning av antalet gånger uppgiften kommer att genomföras under en viss tidsperiod. 4. Deluppgifter: Uppgiften delas in i mindre deluppgifter som presenteras var för sig. 5. Variant: För varje deluppgift kan det finnas en variant som presenteras separat. Den största fördelen med kravtypen är att en komplex uppgift lätt kan benas upp i mindre deluppgifter som både utvecklaren och en utomstående lätt kan förstå. En nackdel med kravtypen är att man måste veta vad en uppgiftsbeskrivning innebär för att kunna tyda och förstå den på rätt sätt. I figur 11 visas ett exempel för en uppgiftsbeskrivning [6]. Uppgift: Syfte: Förtillstånd: Frekvens: Kritisk: Deluppgifter: Incheckning Ge gästen ett rum. En gäst anländer. 0,5 ggr/rum/dag 1. Hitta rum. En grupp med 50 gäster anländer 2. Registrera att gästen checkat in. 3. Leverera nyckeln. Varianter: 1a. Gästen har bokat i förväg. 1b. Det finns inget rum som passar. 2a. Gästen är registrerad vid bokningen. Figur 11. Uppgiftsbeskrivning 12

23 2 Uppdragsbeskrivning 2.1 Bakgrund Parajett AB är ett grafiskt tryckeri som har sitt huvudkontor i Landskrona. All tryckning sker i Landskrona, men man har även ett flertal kontor på andra orter för att kunna sälja sina produkter och tjänster. Tryckerier har idag blivit allt mer elektroniskt avancerade vilket innebär att man behandlar allt större mängd känslig information från flera olika kunder. Därför måste säkerheten ses över och förbättras hela tiden. Parajett AB har bestämt sig för att bli certifierade enligt SS Denna standard definierar alla de krav som måste vara uppfyllda för ett LIS (ledningssystem för informationssäkerhet). Certifieringen innebär inte bara en förevisning om att företaget innehar en hög nivå av informationssäkerhet utan är också ett sätt att få markandsfördelar jämt emot andra företag vilket gör certifieringen ännu intressantare. 2.2 IRS Incidentrapporteringssystem Parajett AB har bestämt att man vill utforma ett datoriserat system för incidentrapportering. Systemet har döpts till IRS som är en förkortning för incidentrapporteringssystem. För att uppfylla angivna krav i standarden SS har Parajett AB bestämt att systemet ska stödja rapporteringsvägar enligt figur 12. Systemet representeras av den streckade fyrkanten. Figur 12. Rapporteringsvägar 13

24 Alla anställda på företaget kommer att kunna erlägga en incidentrapport då en incident inträffat. Rapporten skickas automatiskt till åtgärdsansvarig som i sin tur ser till att incidenten blir åtgärdad och fyller i en åtgärdsrapport. Säkerhetsansvarig har det övergripande ansvaret för att alla incidenter blir åtgärdade och har dessutom tillgång till statistik över alla incidenter för att kunna kvantifiera och följa upp typ av incident, antal incidenter och kostnad för incidenterna. Ett första steg i utvecklingen av detta system är att fastställa en kravspecifikation i form av ett dokument. Dokumentet är tänkt att senare ligga till grund för en vidare upphandling eller utveckling av ett system. Just utvecklingen av denna kravspecifikation är det uppdrag vi har fått av Parajett AB. 2.3 Frågeställning Parajett AB har bestämt sig för att certifieras enligt standarden SS vilken innehåller ett flertal krav inom LIS. Ett av kraven innebär att ett datorsystem för IRS ska finnas. Parajett AB vill att en kravspecifikation tas fram för IRS som antingen kan användas vid upphandling eller tillverkning av ett system. Det huvudsakliga problemet som ska lösas är alltså att en komplett kravspecifikation ska skrivas för IRS, erforderliga tekniker och standarder ska användas för att beskriva systemet i en kravspecifikation. En mer direkt vetenskaplig frågeställning är: Vilken utvecklingsmodell och vilka standarder, metoder och tekniker är lämpliga att använda för att lösa uppgiften och vad blir det praktiska resultatet av att använda dessa? 14

25 3 Metodbeskrivning 3.1 Utvecklingsmodell & aktiviteter När de olika aktiviteterna identifierats fastställdes en utvecklingsprocess utifrån den evolutionära utvecklingsmodellen och med hjälp av en throwaway prototyp. Modellen modifierades till en viss del och benämndes tekniska processen figur 13. Den tekniska processen följdes under hela projektets gång och gav en god överblick av hur arbetet skulle gå till. Figur 13. Tekniska processen Projektet påbörjas med ett introduktionsmöte med Parajett AB. Övre delen i tekniska processen innehåller projektplanen som uppdateras regelbundet och 15

26 definierar arbetsprocessen för projektet. För att projektplaneringen skulle fungera bra gjordes även teoretiska studier inför denna. Arbetsprocessen beskiver huvudaktiviteternas samband vilka representeras av den stora runda ringen. Huvudaktiviteterna består av teoretiska studier, throw-away prototyp, möte med kund, kravelicitering, utveckling av kravspecifikation. Dessa aktiviteter genomarbetas i tre iterationer. När dessa aktiviteter är klara ska examensrapporten framarbetas i två iterationer där diskussioner kommer att ske med handledaren Huvudaktiviteter Teoretiska studier gjordes under hela projektets gång. Olika tekniker för att ta fram krav och beskriva krav studerades. Även standarden för att skriva en kravspecifikation studerades. En throw-away prototyp utvecklades och användes därefter under Möte med kund. Denna kontakt med kund var en av de viktigaste aktiviteterna då denna inbringade i princip all information om önskemålen för hur systemet skulle se ut. Utifrån den insamlade informationen gjordes en kravelicitering där resultatet dokumenterades i en kravspecifikation. 3.2 Metoder och tekniker Att elicitera krav visste vi från början var en svår aktivitet då missuppfattningar ofta kan uppstå. Vi begränsade antalet metoder för att elicitera krav så vi fick mer tid att analysera dess fördelar och nackdelar. Tre vanliga metoder valdes ut, brainstorming, fokusgrupper och prototyp. Brainstorming användes endast av oss själva och gav många idéer och förslag till krav, upplägg på dokumentet med mera. Fokusgrupper var en bra metod att använda sig av där vi satt i möte mellan utvecklare, kunder, användare, och företagsledning. Prototypen utvecklades i form av webbsidor och visades med en projektor. En kreativ miljö skapades på detta vis där alla kunde diskutera och ha synpunkter på systemet. Kontextdiagram tillämpades för att få en grundläggande domänkännedom. En överskådlig bild representerade domänen där systemets användare, externa system, kommunikation och gränsdragningar visades. Textkrav var en kravteknik som var enkel och bra att tillämpa. Däremot insåg vi att man fick vara extremt försiktig med formuleringen av kravet beroende på att texten kan tolkas på många olika sätt. Virtuella fönster användes flitigt. Tekniken passade bra in på vårt arbete då det fanns en hel del datamängder att visa upp på olika sätt. Förväntningarna var att den inte skulle ställa till problem utan enbart visa vilken data som skulle finnas. Parajett hade dock svårt att uppfatta metoden på rätt sätt. Man undrade var knapparna fanns och hade synpunkter på informationens placering på 16

27 sidan. Vi fick då förklara att ingen design görs på virtuella fönster, utan att man enbart inriktar sig på om rätt data finns med. Den kravteknik som ansågs svårast var uppgiftsbeskrivning. Vi var medvetna om att det skulle ta tid att sätta sig in dess syfte för att kunna använda och förstå den. Det kändes trots det som en naturlig teknik då en större uppgift kunde delas upp i en samling mindre deluppgifter. Om tekniken användes på rätt sätt visste vi att det var en mycket bra teknik, men vi hade i åtanken att den kunde bli förvillande för kunden. Resultatet blev att den underlättade vårt arbete med att presentera krav och Parajett förstod den direkt efter att vi gått igenom teknikens syfte och funktion. 17

28 3.3 Genomförande Start av projektet Den första kontakten skapades efter förfrågan om ett examensarbete på Parajett AB. Deras önskemål skickades sedan via e-post och var först bara beskriven i stora drag. Efter att vi diskuterat projektets omfattning tog vi kontakt med vår handledare vid LTH, som gav sitt godkännande till arbetet. Vi ansåg efter ett tag att det tidsmässigt inte var möjligt att både utveckla ett färdigt system tillsammans med en kravspecifikation. För att använda våra 15 veckors arbete på bästa sätt begränsade vi oss genom att utesluta utveckling, implementering och testning för att istället satsa helhjärtat på att ta fram en fullständig kravspecifikation med hjälp av en throw-away prototyp. Det bestämdes att vi skulle ha tre möten med Parajett AB varav det första enbart skulle ses som ett introduktionsmöte. På det andra mötet med Parajett AB skulle grovstrukturen diskuteras och på tredje mötet skulle kravspecifikationen granskas med diskussioner och synpunkter. Till sist presenterades kravspecifikationen för Parajett AB Introduktionsmöte Efter första mötet med Parajett AB fick vi med oss grundläggande information om vad Parajett AB var i behov av och varför. Informationen bestod av kraven i standarden SS [3] och tillhörande riktlinjer [4]. På så vis kunde vi förstå hur incidentrapporteringssystemet kom att utgöra en av pusselbitarna till den slutgiltiga certifieringen. På första mötet presenterades även företagets interna informationsfolder [10] som innehöll information om standarden och informationssäkerhet samt en första skiss på deras tänkta rapporteringsvägar och blanketter för att rapportera incidenter manuellt (rapporteringsvägarna och uppdragsbeskrivningen presenteras närmare under kapitel 2) Iterationer Den slutgiltiga kravspecifikationen utvecklades genom tre iterationer av: Teoretiska studier Throw-away prototyp Möte med kund Kravelicietering Kravspecifikation Teoretiska studier gjordes kontinuerligt under hela arbetet. Throw-away prototypen utvecklades och presenterades sedan för kunden i under mötena. 18

29 Resultatet från mötena dokumenterades och användes sedan för att elicitera nya krav. De nya kraven dokumenterades sedan i kravspecifikationen. Nedan visas hur kravspecifikationen utvecklades och förändrades genom iterationerna. Denna förändring skedde utifrån prototypen, mötena och våra egna analyser Iteration 1 En första version av Prototypen gjordes där den grova strukturen var framarbetad, vilken representerades av menyer. Denna presenterades för kunden som kommenterade och tyckte till. Utifrån detta kunde den generella strukturen över kravspecifikationen dokumenteras. Stora grupper som administration, incidentrapport, åtgärdsrapport och statistik identifierades. Avgränsningar utarbetades för att visa vad som inte skulle ingå i kravspecifikationen. Också de generella målsättningarna sattes upp, dokumentet strukturerades och kraven delades upp i översiktliga krav och funktionella krav. Systemets aktörer identifierades och utvecklingen av virtuella fönster påbörjades. I Figur 14 visas den generella strukturen på prototypen i form av menyer. Figur 14. Prototyp Generell struktur 19

30 Iteration 2 Prototypen förbättrades och innehöll nu exempel på en del av funktionerna i det tänkta systemet. Den presenterades för kunden och resulterade i tillägg och ändringar i kravspecifikationen. Funktionerna dokumenterades i form av virtuella fönster och uppdragsbeskrivningar som användes för att beskriva krav. Det bestämdes att systemet skulle kunna hantera olika användargrupper med olika behörighet. Detta ledde även till att funktionsgrupper infördes. Kravspecifikationen hade fram tills nu skrivits helt på engelska, men efter önskemål från Parajetts sida skrevs kravspecifikationen om till svenska, detta för att reducera missuppfattningar. Vi uppfattade att en del av kraven skulle vara svåra att förstå och tog därför beslutet att införa en speciell hjälptext när svårare krav förekom. I figur 15 och 16 visas exempel på funktionerna Lägg till kontor och Redigera kontor som lagts till i prototypen under denna iteration. Figur 15. Prototyp Funktionen Lägg till kontor 20

31 Figur 16. Prototyp Funktionen Redigera kontor Iteration 3 Under denna iteration gjordes inga större förändringar, endast mindre korrigeringar gjordes inför mötet med kunden. Prototypen vidareutvecklades ganska lite, istället lades det mesta av arbetet på kravspecifikationen för att få den helt färdig. Kravspecifikationen presenterades helt färdig på mötet och levererades till kund. Den färdiga kravspecifikationen beskrivs i kapitel 4 och finns i sitt hela utförande under Appendix I. 21

32 22

33 4 Resultat Resultat av arbetet blev en Kravspecifikation enligt kundes önskemål som anges i Kapitel 2. Nedan presenteras ett sammandrag av denna kravspecifikation. Den kompletta kravspecifikationen presenteras under Appendix I. 4.1 Struktur över kravspecifikation Kravspecifikationen för IRS producerades enligt IEEE std [2] med en del modifieringar för bättre anpassning till projektet och följande upplägg användes: Inledning Bakgrund Syfte Mål, begränsningar och utvidgningar Systemkrav Terminologi Referensdokument Inledning, bakgrund, syfte och mål beskrivs närmare i kapitel 2 i form av Uppdragsbeskrivning från kund. Begränsningar gjordes genom att kravspecifikationen inte kom att innehålla krav för följande funktioner: Statistika sökfunktioner Loggning av händelser Speciella datakrav Kvalitetskrav Projektkrav Den största och viktigaste delen var Systemkrav vilken beskrivs närmare på nästa sida. En lista över använd terminologi och referenser presenterades sist i kravspecifikationen. 23

34 4.2 Systemkrav Till alla krav gavs ett unikt nummer. När ett krav ansågs vara mer avancerat infördes en hjälptext för det specifika kravet. Systemkraven beskrevs med 6 olika kravtyper med fördelning enligt nedan: Antal Textkrav 38 Virtuella fönster 27 Uppdragsbeskrivning 13 Krav med öppna mål 4 Kontext Diagram 2 Funktionslista 1 Tabell 1. Kravfördelning Totalt: Översiktliga krav Systemets domän Ett domänkrav ställdes i form av ett kontextdiagram enligt figur 17. I denna visas vilka aktörer som ingår i domänen och på vilket sätt de kommunicerar med systemet. De aktörer som kommunicerar direkt med systemet är normalanvändare, åtgärdsansvarig, säkerhetsansvarig och administratör. Säkerhetsansvarig kommunicerar med ledningen, dock utanför domänen. Figur 17. Kontextdiagram över systemets domän 24

35 Användargrupper Användargrupper upprättades utifrån de aktörer som kommunicerar med systemet för att kunna stödja olika behörigheter. Användargrupper kom att bli: Normalanvändare Åtgärdsansvarig Säkerhetsansvarig Administratör Funktioner och funktionsgrupper Alla funktioner delades in i olika funktionsgrupper vilka presenteras i figur 18. Funktionerna beskrivs närmare under Incidentrapport Erlägg incidentrapport Visa erlagda incidentrapporter Visa åtgärder av incidentrapporter Åtgärdsrapport Visa inkomna incidentrapporter Erlägga åtgärdsrapport Visa erlagda åtgärdsrapporter Visa tidigare inkomna incidentrapporter Inställningar Ändra lösenord Visa mina uppgifter Administration Användare Kontor Avdelning Incidenttyp Incidentgrupp Statistik Ingår ej Figur 18. Funktioner och funktionsgrupper 25

36 Behörigheter Användarna utför olika uppgifter och ska ha tillgång till olika informationsdata. Därför gavs användarna behörighet till de olika användargrupperna enligt figur 19. Figur 19. Behörigheter En normalanvändare använder systemet för att erlägga en incidentrapport då en incident har inträffat. Incidentrapporten skickas automatiskt till ansvarig för aktuell incidentgrupp. Användaren kan senare även följa upp åtgärdsrapporten för aktuell incident. Åtgärdsansvarig tar emot incidentrapporter och är ansvariga för att incidenten blir åtgärdad. Detta dokumenteras i form av en åtgärdsrapport. Varje åtgärdsansvarig är ansvarig för en eller flera incidentgrupper. En åtgärdsansvarig kan även agera som en normalanvändare. Säkerhetsansvarig har ett övergripande ansvar för att alla incidenter följs upp. Säkerhetsansvarig har även ansvar för att sammanställa all statistik och presentera denna för ledningen och andra berörda. En säkerhetsansvarig kan även agera som en normalanvändare. Administratören är ansvarig för att underhålla systemet. Det kan bland annat innebära att lägga till användare, ändra användaruppgifter, inaktivera användare och lägga till användargrupper. En administratör kan även agera som en normalanvändare. 26

37 4.2.2 Funktionella krav De funktionella kraven delades upp i Inloggning, Utloggning, Incidentrapport, åtgärdsrapport, statistik, inställningar och administration vilkas innehåll beskrivs nedan. Kraven i dessa delar beskrevs med, textkrav, virtuella fönster, uppdragsbeskrivning och krav med öppna mål Inloggning För alla användare på systemet krävs det en behörighetskontroll. Inloggning sker innan man får åtkomst till systemet. I dokumentet ställs tre krav på denna funktion i form av ett namn och lösenord och att dessa ska kontrollers av systemet Utloggning Som inloggad ska det också vara möjligt att logga ut från systemet. Man tar även hänsyn till om användaren har varit inaktiv ett visst antal minuter, då loggas man automatiskt ut Incidentrapport Kärnan i hela systemet är den incidentrapport som ska erläggas. Ett Virtuellt fönster visar i detalj vilken sorts information som ska fyllas i. Men krav finns också på systemet att visa ens erlagda rapporter och visa ens åtgärdade rapporter. Även sökning på incidentrapporter och åtgärdsrapporter ska vara genomförbart med stöd för vissa sökkriterier. Att erlägga en anonym incidentrapport finns det också krav på Åtgärdsrapport En åtgärdsrapport ska kunna erläggas av en åtgärdsansvarig. Denna rapport grundas på de inkomna incidentrapporterna som normalanvändarna har erlagt. Rapporten innehåller information om hur incidentrapporten åtgärdades, av vem den åtgärdades och kostnad för åtgärdandet Statistik Denna del av systemet innefattas inte av kravspecifikation eftersom den är för omfattande, istället prioriterades övriga delar. Funktionerna inom statistik ansågs också vara något man lättare kan ställa krav på efter att systemet satts i bruk Inställningar Alla användare av systemet ska kunna ändra viss användarinformation t ex lösenord. 27

38 Administration Administratörens huvuduppgift är att lägga till och ta bort användare, kontor, avdelningar, incidentgrupper och incidenttyper. All information om dessa ska även kunna ändras. 28

39 5 Diskussion Så här i efterhand kan flera lärdomar göras och man ser flera saker som vi antagligen hade valt att göra annorlunda om vi gjort ett liknande projekt igen. Nedan nämns några av dessa idéer, tankar och svårigheter. När arbetet startade hade vi höga ambitioner vilket i sig var bra, men när arbetet pågått ett tag insåg vi att ambitionerna var för höga. Därför fick vi begränsa arbetet kraftigt genom att inte utveckla systemet, utan bara göra kravspecifikationen. Parajett AB hade innan examensarbetet påbörjat skurit ner kraftigt på personalen och var tyvärr tvungna att skära ner ytterliggare. Detta gjordes ungefär halvvägs in i vårt arbete och försvårade projektet. En av nyckelpersonerna inom projektet försvann och projektet lades även på is för Parajetts del. Vi fortsatte ändå arbetet och överlämnade kravspecifikationen. Projektplanen kan ses som överarbete ur vissa aspekter. Dels för att vi bara var två personer och dels för att det inte var ett så omfattande arbete som skulle genomföras. Mer på detaljnivå så kan man även konstatera att det var svårt att följa den exakt. Ett exempel på detta är aktiviteterna som visade sig flyta samman, mest eftersom vi bara var två personer. Projektplanen fungerade dock mycket bra ur flera andra aspekter. Handledare och personal kunde lättare få inblick i hur arbetet var tänkt att genomföras och inte minst så lärde vi oss även hur man gör en projektplan enligt konstens alla regler. Den mera avancerade prototypen som utvecklades medförde att vi kom för mycket in på designen av systemet istället för eliciteringen av kraven. Det som var bra med prototypen var dock att det var lätt att visa kunden vad vi menade och att den även gav möjligheten att låta kunden prova på systemet. Den var även mycket tidskrävande i förhållande till nytta och eftersom prototypen var så pass avancerad kom vi på mer krav än vad som egentligen behövdes. En del av de krav som eliciterades hörde hemma på designnivå och en del krav var för avancerade. Kravspecifikationen är mycket omfattande (förutom de delar som utelämnats) och har varit tidskrävande. Om detta varit ett verkligt projekt så hade man antagligen inte gjort den så omfattande. Att den är så omfattande beror mycket på att syftet med examensarbetet är att studera hur delar av kravhanteringsprocessen kan användas rent praktiskt. Därför testades flera olika tekniker, metoder och standarder. Sammanfattande kan man säga att den tiden det tog att göra en så avancerad kravspecifikation kunde istället ha använts till att utveckla systemet och en enklare kravspecifikation. Detta var dock svårt att veta från början och hade framför allt inte gett oss samma erfarenheter inom kravhanteringsprocessen som detta arbetssätt gjort. 29

40 30

41 6 Slutsats Parajett AB har valt att certifieras enligt standarden SS som beskriver kraven för ett LIS. Ett av kraven innebär att ett datorsystem för IRS måste finnas. Utifrån detta ville Parajett AB att en kravspecifikation över systemet skulle tas fram. Denna var tänkt att användas vid upphandling av ett system eller utveckling av ett system. En kravspecifikation över systemet togs fram. På grund av tidsbrist är den inte komplett utan följande delar utelämnades: statistiska sökfunktioner, loggning av händelser, speciella datakrav och kvalitetskrav. Kravspecifikationen utvecklades utifrån standarden IEEE Std , referens [2]. För att anpassa standarden till gällande mjukvara gjordes en del förändringar, dock inom ramarna för vad som standarden tillät. Två stycken intressanta utvecklingsmodeller identifierades, vattenfallsmodellen och evolutionär utvecklingsmodell. Vi valde att arbeta efter den evolutionära utvecklingsmodellen som har fördelen att stödja en iterativ arbetsgång. Vidare valde vi att arbete med en throw away prototyp. Detta arbetssätt passade bra på denna typ av projekt där det är omöjligt att göra varje aktivitet färdig innan nästa påbörjas, utan man istället ofta måste gå tillbaks och arbeta med de första aktiviteterna ytterliggare. Den evolutionära utvecklingsmodellen kan alltså konstateras vara en bra modell att använda inom kravhanteringsprocessen, särskilt som i vårt fall när man gör en prototyp. Ett flertal tekniker studerades och valdes ut för att användas under projektets gång. För att analysera och elicitera krav användes teknikerna fokusgrupp, brainstorming och prototyp. Alla dessa tekniker visade sig vara bra på sina sätt. För att illustrera krav användes teknikerna, kontextdiagram, funktionslista, textkrav, krav med öppna mål, virtuella fönster och uppgiftsbeskrivning. Flertalet krav beskrevs med virtuella fönster och uppgiftsbeskrivning som i flera fall ansågs vara tidskrävande i förhållande till resultat. Dessa tekniker kunde alltså ha använts i mindre omfattning, det vill säga bara till de krav som verkligen krävde det. Tillsammans gav dock dessa tekniker och metoder en kravspecifikation som täckte alla aspekter på systemet. Kravspecifikationen är alltså inte komplett. De delar som inkluderas ses däremot som helt kompletta. Kravspecifikationen beskrivs enligt gällande standard och med hjälp av kända tekniker och metoder. Kravspecifikationen blev omfattande och anses ha hög kvalité, detta tack vara prototypen. Parajett ansåg att de delar som kravspecifikationen innefattade var bra. Om kravspecifikationen kommer att användas av Parajett är osäkert eftersom man lagt certifieringen på is. Utifrån arbetet med Parajett togs mycket lärdom av hur svårt det är för utvecklare och kunder att förstå varandra, dock fick vi god 31