Kravspesifikasjon

Kravspesifikasjon 

Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert 

applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen og hva som forventes av de 

forskjellige lagene i denne, men også krav til hvordan systemet skal designes og dokumenteres. 

Skrevet av: Lars Haugan;Tim Sæterøy;Ole Henrik Paulsen;Anders Struksnæs 

Filnavn: Kravspesifikasjon.docx 

Status: Godkjent 

Versjon: 1.0 

Opprettet: 14.01.2013 

Sist endret: 25.01.2013 19:52:00 

Sider: 11

Skrevet av: 

Lars Haugan;Tim 

Sæterøy;Ole Henrik 

Paulsen;Anders Struksnæs 

Revisjonshistorikk 

KRAVSPESIFIKASJON 

Status: 

Godkjent 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Dato Versjon Beskrivelse Forfatter 

16.01.2013 0.1 Disposisjon fullført. * 

18.01.2013 0.9 Informarsjon fylt inn i dokumentet fra eksternt 

sammarbeidsverktøy 

* 

25.01.2013 1.0 Godkjent * 

*Alle punkter er dokumentert og godkjent av Ole Henrik Paulsen, Tim Sæterøy, Lars Haugan og Anders 

Struksnæs. 

Filnavn: Kravspesifikasjon.docx Side: 2 av 11

Skrevet av: 




1. PRESENTASJON 


Status: 

Godkjent 

PROSJEKTTITTEL Nettverksbasert applikasjonsovervåking 

APPLIKASJONSTITTEL PySniff 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

OPPGAVE Utvikle en applikasjon for innhente, prosessere og presentere nettverksdata 

for å illustrere driftssituasjonen til applikasjoner. 

1.1 MEDLEMMER I PROSJEKTET 

Anders Struksnæs 

Lars Haugan 

Ole Henrik Paulsen 

Tim Sæterøy 

1.2 OPPDRAGSGIVER 

SpareBank 1 Gruppen AS 

KMIT & Innkjøp 

Hammersborggata 2 

0191 Oslo 

origo@sparebank1.no 

1.3 KONTAKTPERSON 

SpareBank 1 Gruppen AS 

Martin Jensen 

Martin.Jensen@sparebank1.no 

40218026 

Avdelingsleder KMIT & Innkjøp, Drift Alliansen 

1.4 VEILEDER 

Torunn Gjester 

Seksjon for Informasjonsteknologi 

Høgskolen i Oslo og Akershus 

1.5 BAKGRUNN 

Origo og Drift Alliansen er avdelinger for IT brukerstøtte og drift i SpareBank 1 Gruppen. Avdelingene 

leverer tjenester til SpareBank 1 Gruppen AS med datterselskap og bankene i SpareBank 1 Alliansen. Som 

en del av oppgavene til Origo og Drift Alliansen jobbes det med monitorering og overvåking av ITtjenestene 

innen SpareBank 1 Gruppen AS. 

Hensikten med prosjektet er utviklingen av et nytt overvåkingsverktøy som kan benyttes for overvåking av 

applikasjoner som benyttes i SpareBank 1 Gruppen AS. Applikasjonen vil være et supplement til dagens 

driftsovervåking og innføre begrepet trending i overvåkingen. Data skal trendes i form av å finne en grense 

på hva som er normalt og hva som ikke er normalt i bestemt tidsperiode (baselining). 

2. FORORD 

Denne kravspesifikasjonen er beregnet for utviklere, oppdragsgiver andre som er med i prosessen med 

utvikling av applikasjonen. Kravspesifikasjonen definerer de krav som skal være til prosjektet og 

applikasjonen og er ment som et kontinuerlig verifiseringsdokument for å sikre god utvikling i prosjektet. 


Skrevet av: 





Status: 

Godkjent 

3. LESERVEILEDNING 

Innholdsfortegnelse 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

1. PRESENTASJON 3 

1.1 MEDLEMMER I PROSJEKTET 3 

1.2 OPPDRAGSGIVER 3 

1.3 KONTAKTPERSON 3 

1.4 VEILEDER 3 

1.5 BAKGRUNN 3 

2. FORORD 3 

3. LESERVEILEDNING 4 

4. LOGISK DATAMODELL 6 

4.1 DATAFLYTMODELL 6 

5. SYSTEMKRAV 7 

5.1 FUNKSJONSKRAV 7 

5.1.1 KRAV TIL SENSOR 7 

5.1.2 KRAV TIL DATABASE 7 

5.1.3 KRAV TIL CORE 8 

5.1.4 KRAV TIL FRONTEND 8 

5.2 TEKNISKE KRAV 9 

5.3 KRAV TIL DATALAGRING 9 

5.3.1 FUNKSJONELLE KRAV 9 

5.3.2 IKKE FUNKSJONELLE KRAV 9 

6. KRAV TIL DESIGN 9 



7. KRAV TIL KODE 9 

7.1 KODESTANDARD 9 

7.2 VARIABLER OG FUNKSJONER 10 

7.2.1 FUNKSJONELT 10 


7.3 KOMMENTERING 10 

7.4 SPRÅK 10 

8. KRAV TIL DOKUMENTASJON 10 

8.1 OBLIGATORISK DOKUMENTASJON 10 

8.1.1 STYRINGSDOKUMENTER 10 

8.1.2 SLUTTDOKUMENTASJON 10 

8.2 GENERELLE KRAV TIL DOKUMENTASJON 10 

8.3 PROSJEKTDAGBOK 10 



Skrevet av: 





Status: 

Godkjent 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 


8.4 MØTEREFERATER 11 

8.5 VERSJONSKONTROLL 11 



9. UTVIDELSER 11 

10.FREMMEDORD OG DEFINISJONER 11 

11.LENKER / KILDER 11 


Skrevet av: 





Status: 

Godkjent 

4. LOGISK DATAMODELL 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Følgende modeller viser hvordan dataflyten går mellom de forskjellige delene i systemet. Bilde 1 viser en 

overordnet modell av hvordan systemet er utformet. Her blir data fra nettverssensorer sendt til «core», som 

er applikasjonens kjerne for mottak av data. Data optimaliseres og settes inn i det første laget i databasen, 

som inneholder sanntidsdata. «Core» er der all logikken skal foregå, og dreier seg blant annet å hente ut data 

som skal sendes til frontend. Frontend har igjen ansvaret for presentering av data. 

Bilde 1 - Dataflyt fra nettverkssensor til presentasjonslag 

4.1 DATAFLYTMODELL 

Bilde 2 - Avansert logisk datamodell for illustrering av informasjonsflyten i applikasjonen. 

Beskrivelse av punkter i modell 

Link1 og Link2 Her går dataen vi er ute etter. Applikasjonsdata i rådata. For eksempel http kall. 

S1 og S2 Her sniffes datatrafikk på linjen opp til dedikerte sensorer som er installert på 

maskinen. 


Skrevet av: 





Status: 

Godkjent 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Link3 og Link4 Her overfører sender sensoren rådata direkte inn i Core. Dette er samme data som blir 

transportert i S1 og S2. 

D1 Data sendes videre til det første laget i databasen. 

D2 Ved aggregering blir data sendt fra det første databaselaget til plugin (D2). 

D4 Her går uaggregert data inn fra D1 til plugin og blir aggregert og sendt på D4 som 

aggregert data. 

F1 Kommunikasjonen mellom core og frontend og benyttes ved henting av både realtime 

data og aggregerte data. 

F2 Database direkte knyttet til frontend som ikke har nettverksdata. 

D5 Aggregert data blir hentet ifra databaselag 2 og sendt via F1. 

5. SYSTEMKRAV 

5.1 FUNKSJONSKRAV 

5.1.1 KRAV TIL SENSOR 

5.1.1.1 FUNKSJONELLE KRAV 

Sensor skal være uavhengig av resten av applikasjonen. 

Ved flere sensorer skal disse være uavhengig av hverandre. 

Sensor skal kun sniffe TCP. 

Konfigurasjonen i sensor skal kun inneholde ip og eventuelt port for tilkobling til Core. 

Sensor skal ikke forstyrre eller “stjele” kapasiteten eller resurser til andre applikasjoner på serveren 

den står på. 

Sensor skal bare videresende pakker som er definert i sensor. 

Sensor skal aggregere data som videresendes 

Sensor skal determinere hvilken applikasjon trafikken kommer fra, og velge å sende/ikke sende data 

videre basert på dette. 

5.1.1.2 IKKE FUNKSJONELLE KRAV 

Sensor skal ha en oppetid på minimum 96,0% første året etter prosjektet er avsluttet. 

Sensor skal ved bruk på applikasjonsserver ikke benytte mer enn en prosessorkjerne. 

5.1.2 KRAV TIL DATABASE 


Databaselag 1 skal inneholde all data sensoren sender videre til core. 

Databaselag 2 skal kun inneholde aggregert data som hentes i fra databaselag1. 

Det skal være et logisk skille mellom databaselag 1, databaselag 2 og frontend i form av egen 

database. 

Kun “Core inkl. plugins” skal kunne lese, skrive og slette i fra databasen hvor nettverkstrafikk er 

lagret. 


Databaseserveren skal ha en oppetid på minst 99% over ett år i fra prosjektslutt. 

Data i databaselag 1 skal ikke være lagret lengere enn maksimalt 14 dager. 

Data i databaselag 1 skal minst være lagret i databaselag 1 i 1 døgn. 

Data i databaselag 2 skal ikke være lagret i lengere tid enn 27 måneder. 

Data i databaselag 2 skal minst være lagret i databaselag 2 i 25 måneder. 

Gjennomsnittet på spørre-kall skal være under 2 sekunder ved mindre en 4 klienter tilkoblet 

frontend. 


Skrevet av: 





Status: 

Godkjent 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Spørring på real-time data skal maksimalt ha en forsinkelse på 5 sekunder i fra spørringen 

ankommer databasen til databasen svarer. 

5.1.3 KRAV TIL CORE 


Generelt 

Endring av konfigurasjon i core gjøres av en egen konfigurasjonsfil. Inneholder systemvariabler som 

definerer oppførsel i de ulike funksjonene i core. 

Skal ha en socket nettverkstilkobling og ta imot datastrøm fra sniffer. 

Data fra sniffer må preprosesseres for innsetting i databaselag 1; hent ut relevante data, sortering, 

markering i database (for videre prosessering). 

Systemet skal logge feilsituasjoner og informasjon om status til en loggfil. 

Plugins 

Håndtere et sett med plugins som hver jobber med å aggregere data for de ulike 

systemene/protokollene de er beregnet på. Plugins er også ansvarlige for innsetting av data fra 

sniffer til databaselag 1. 

All aggregert data av forskjellige plugins skal formateres etter en standard for innsetting i database. 

Plugins definerer strukturering av tabeller i databasens datalag 2, og skal håndteres gjennom 

databaselaget SQLAlchemy (ORM). Plugins skal også benytte SQLAlchemy for innsetting av data 

til databaselag 2. 

Database 

Core skal vha. plugins transportere og aggregere data mellom databaselag 1 og databaselag 2 i 

databasen. 

Aggregering og flytting av data skal gjøres på et fastsatt tidsintervall, definert i konfigurasjonsfilen. 

Databasespørringer for frontend skal utføres mot analysedata i databasen(e), gjennom plugins som 

har egne kall for strukturering av data. 

Data skal trendes i form av å finne en grense på hva som er normalt og hva som ikke er normalt i 

bestemt tidsperiode (baselining). 

Eks: Antall kall som gjennomsnittelig feiler for system A kl. 09:00 på hverdager 


Skal minimum forminske aggregert data med 50%. 

Skal ha en oppetid på minimum 99% etter prosjektets slutt. 

Prosessen som tar seg av aggregering skal være ferdig før neste aggregering av samme data starter. 

Systemet skal kunne takle skalering og ha flere plugins tilsvarende X% stigning i datamengde 

Behandlingen av et kall mot databasen for frontend skal ta mindre enn 4 sekunder. 

Skal støtte en nettverkstilkobling på minst 1 Gbit. 

5.1.4 KRAV TIL FRONTEND 


Frontend skal vise statistikk i form av kall som feiler og hvor mange kall som pleier å feile. 

Frontend skal oppdateres automatisk med ny data minimum hvert minutt. 

Skal kunne presentere sammendrag av den kontinuerlige status. 

o Eksempler: Navn på kall, responstid, antall kall og antall feil. 

Frontend skal benytte mellomlagring av data (cache) for å minske forespørsler til core, som igjen vil 

minske forespørsler mot database. 


Systemet skal kunne benyttes på en overvåkingsskjerm for å gjøre det mulig å respondere på 

driftshendelser. 


Skrevet av: 





Status: 

Godkjent 

Versjon: 

1.0 

Opprettet: 

14.01.2013 

Mellomlagringen av data (caching) skal lagres i maks ett minutt. 

Skal benyttes javascript for å gjøre visning og bruk av frontend så responsiv som mulig. 

Forsiden skal være lastet på mindre enn 2 sekunder. 

Data kan sendes asynkront for å gjøre siden mer responsiv. 

5.2 TEKNISKE KRAV 

Systemet skal kunne kjøre på 64-bits versjon av Linux-distribusjonene som benyttes i 

produksjonsmiljøet til SpareBank 1 (CentOS, RedHat). 

Systemet skal utvikles og kjøres på Python versjon 2.7. 

5.3 KRAV TIL DATALAGRING 

5.3.1 FUNKSJONELLE KRAV 

Gruppen skal bruke Dropbox, Google Docs og Git 

Alle på prosjektgruppen skal ha tilgang til overnevnte lagringsplasser 

5.3.2 IKKE FUNKSJONELLE KRAV 

Sist endret: 

25.01.2013 

19:52:00 

Det skal gjennomføres backup av Dropbox, Google Docs minst 1 gang per uke. (For Git se punkt 

eget punkt) 

Dokumenter og innhold i overnevnte tjenester skal ikke slettes før minst ett halvt år etter 

prosjektslutt. 

6. KRAV TIL DESIGN 


Nettsiden skal benytte skrifttype (font) som er beregnet for lesing på datamaskin. 

Skrifttype brukt på nettsiden skal være åpen og tilgjengelig for bruk på Windows, Mac OS X og 

Linux. 


Det bør være lett å få oversikt 

Det skal være et felles grensesnitt på alle sidene. 

Det skal være gode kontraster i fargebruken. 

Nettsiden skal være kompatibel med alle moderne nettlesere som Chrome, Firefox, Opera og 

Internet Explorer med siste versjon. 

7. KRAV TIL KODE 

7.1 KODESTANDARD 

Koden skal benytte UTF-8 tekst-encoding. 

Koden skal være objektorientert. 

Feilmeldinger skal alltid håndteres med logging av feilsituasjoner til fil. 

Koden skal følge PEP8-standarden [1] 

PEP20-retningslinjene [2] bør følges for god kode. 

Tekst skal aldri skrives stil stdout eller stderr, men til logg. 


Skrevet av: 





Status: 

Godkjent 

7.2 VARIABLER OG FUNKSJONER 

7.2.1 FUNKSJONELT 

Versjon: 

1.0 

Flere ord i variabelnavn skal settes sammen med bruk av underlinje (_). 

Flere ord i funksjoner skal settes sammen med bruk av underlinje (_). 


Variabelnavn skal være logisk i sammenhengen. 

7.3 KOMMENTERING 

Funksjoner skal alltid kommenteres med beskrivende tittel og returverdi. 

Variabler trenger ikke å kommenteres. 

Klasser skal kommenteres med hva de skal brukes. 

7.4 SPRÅK 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Gjennomgående språk i koden skal være engelsk, dette for å lette arbeidet med å sette seg inn i koden for 

andre utviklere på et senere tidspunkt, samt at norske bokstaver (æ, ø og å) har vist seg å skape trøbbel i 

tidligere prosjekter. 

8. KRAV TIL DOKUMENTASJON 

8.1 OBLIGATORISK DOKUMENTASJON 

Følgende obligatoriske dokumenter skal utformes i løpet av prosjektets periode: 

8.1.1 STYRINGSDOKUMENTER 

Prosjektskisse 

Prosjektdagbok 

Forprosjektrapport 

Arbeids- og fremdriftsplan 

Kravspesifikasjon (Dette dokumentet) 

8.1.2 SLUTTDOKUMENTASJON 

Kravspesifikasjon 

Prosessdokumentasjon 

Produktdokumentasjon 

Testdokumentasjon 

Brukerdokumentasjon 

8.2 GENERELLE KRAV TIL DOKUMENTASJON 

Dokumentasjon skal følge standard dokumentmal fra SpareBank 1. 

Dokumentene skal være skrevet for visning på papir. 

8.3 PROSJEKTDAGBOK 


Prosjektdagboken skal skrive rett til fil. 

Dato, Navn og Tekst er obligatoriske felter. 


Skrevet av: 





Status: 

Godkjent 

Det skal være mulig å endre alle innlegg. 

Det skal være mulig å legge til bildelink. 


Versjon: 

1.0 

Prosjektdagboken skal være passordbeskyttet med htaccses fil. 

Prosjektdagboken skal være tilgjengelig under hele prosjektperioden 

Siden skal ikke trenge opplæring. 

Filen med dagbokinnlegg skal minst bli tatt backup av en gang i uken. 

Det skal være norske og forstålige feilmeldinger. 

8.4 MØTEREFERATER 

Opprettet: 

14.01.2013 

Sist endret: 

25.01.2013 

19:52:00 

Møtereferater skal skrives med grunnlag i mal fra SpareBank 1. Dokumentet skal lagres på formatet 

«Møtereferat – 2013-01-16.docx» og i PDF-format for publisering. 

Før hvert møte skal det defineres møtepunkter (agenda) hvis dette er optimalt for møtet. 

Møtereferatene skal i etterkant renskrives slik at de er lettere leselige for å kunne se tilbake til hva man ble 

enige om på møtet. 

8.5 VERSJONSKONTROLL 


Alle på prosjektgruppen skal kunne skrive, klone og hente til/fra git repostoriet. 

Ingen skal jobbe direkte på Master branch. 

Master branch skal bli brukt til produksjonsetting 

Alle som skriver til git repostoriet skal kommentere dette på norsk. 


Git repostoriet skal være private og kun prosjektmedlemer skal ha tilgang. 

Det skal taes backup av git repostoriet minst 1 gang per dag. 

Git skal være tilgjengelig minst 99% av prosjektperioden. 

9. UTVIDELSER 

Administrasjonsmuligheter fra frontend. 

Illustrering av trender og data som grafer på frontend. 

Tilgangskontroll for visning av frontend. 

Støtte for flere protokoller 

10. FREMMEDORD OG DEFINISJONER 

Aggregering - Kombinere eller slå sammen data. F.eks minke data over lengre tidsperioder. 

Trending - Det normalet i en gitt tidsperiode. 

Sensor - En applikasjon som leser av nettverkstrafikk eller eksempelvis tekstfiler. 

11. LENKER / KILDER 

[1] - Pep8 - http://www.python.org/dev/peps/pep-0008/ 

[2] - Pep20 - http://www.python.org/dev/peps/pep-0020/

Kravspesifikasjon

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?