Kravspesifikasjon. Forord

Transkript

1 Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den holder seg innenfor de definerte rammene og kravene til brukervennlighet, kvalitets- og datasikring. Kravene deles opp i funksjonelle og ikke-funksjonelle krav. Hovedkravene er gitt av oppdragsgiver og løsningen er utarbeidet av gruppen. I testfasen vil dette dokumentet vise Statsbygg om at applikasjonen er utviklet etter deres ønsker. Kravspesifikasjon har en viktig rolle i prosjektarbeidet som tilrettelegger betingelser for prosjektet. Det er viktig å følge kravspesifikasjonen jevnlig for å oppnå et godt resultat. Kravspesifikasjonen må være entydig og konkret slik at det ikke oppstår komplikasjoner for forståelse av applikasjonsutviklingen. Kravspesifikasjonen skal hjelpe oss med å utføre arbeidet og forholde oss til kravene som er blitt satt. Kravene er opprettet med hensyn til ønsket funksjonalitet av oppdragsgiveren. Alle kravene skal være målbevisste, realistiske og tidsbegrenset. Kravspesifikasjonen er beregnet både for oppdragsgiveren og oss selv. Det skal hjelpe oss som utviklere å utforme en applikasjon som dekker behovene og oppfyller målene til prosjektet. Denne skal også gi oss beskrivelse av hvordan vi skal utvikle prosjektet og hvilket mål vi tar hensyn til. Til slutt skal vi klare å se hva vi har klart å oppnå og de fleste målene bør være realistiske slik at vi ikke unngår noen av dem. Kravspesifikasjon fungerer som en skriftlig avtale mellom oss og oppdragsgiver. Det er både et styringsdokument og et kontraktfestet dokument ovenfor hvilke krav vi skal oppfylle.

2 Innholdsfortegnelse Forord... 1 Innledning... 3 Om bedriften... 3 Bakgrunn for prosjektet... 3 Funksjonelle krav... 4 Brukerkrav... 4 Systemkrav... 4 Ikke-funksjonelle krav... 5 Tekniske krav... 5 Sikkerhetskrav... 5 Rammekrav i systemet... 5 Brukstilfeller... 6 Use case modell... 6 Detaljerte use case beskrivelser... 7 Krav til kode... 9 Krav til systemkonstruksjon... 9 Krav til dokumentasjon... 10

3 Innledning Om bedriften Statsbygg er Norges største statlige eiendomsaktør i sivil sektor med en eiendomsportefølje på rundt 2,7 millioner kvadratmeter til en verdi av ca. 30 milliarder kroner. De driver stedplanlegging, byggfaglig rådgivning, eiendomsforvaltning og styring av byggeprosjekter. Statsbygg er en forvaltningsbedrift med 830 ansatte, med hovedkontoret i Oslo og fem regionskontor. Statsbygg er statens sentrale rådgiver i bygge- og eiendomssaker, byggherre, eiendomsforvalter og eiendomsutvikler. Statsbygg har som mål å være statens førstevalg. Statsbygg er en statlig forvaltningsbedrift. Statsbyggs oppgave er å tilby gode og funksjonelle lokaler til statlige virksomheter, og å realisere vedtatte samfunnspolitiske mål i forhold til arkitektur, statlige planinteresser, kulturminnevern og miljø. IKT avdelingen på hovedkontoret består av ca. 30 ansatte fordelt på 3 gruppe, IT Support (Teknotorget), IT Drift og IT System. Teknotorget har et lager for oppbevaring av varer. Eksempel på varer er tonere til multimaskiner, mus og tastatur, minnenøkler, eksterne harddisker m.m.. Disse varene deles forløpende ut til brukere ved behov, og varer må etterbestilles når det er tomt på lager. Bakgrunn for prosjektet Et av gruppemedlemmene er ansatt i Statsbygg som IT-medarbeider(Teknotorget). Medlemmet hadde muligheten til å utføre hovedprosjektet hos Statsbygg. Etter å ha hørt og sett på oppgaven, virket oppgaven interessant og spennende. For å få en dypere gjennomgang av oppgaven, hadde gruppen møte med kontaktpersonen og ble positive til å utføre oppgaven hos arbeidsgiveren. Dagens situasjon: Avdelingen Teknotorget har i dag ingen elektronisk system som holder rede på varer som kjøpes inn og leveres ut til ansatte i Statsbygg. Det fører til at Statsbygg ikke har oversikt over antall enheter til enhver tid. Statsbygg ønsker derfor å få rede på lagerbeholdning i form av en web-basert applikasjon. Applikasjonen vil være en effektiv løsning for brukerne og tilgjengelig over Statsbyggs nett.

4 Mål for oppgaven Hensikten med produktet er at ansatte skal på en enkel måte kunne registrere varer inn og ut av lager, og samtidig se hvilke produkter som de har inne på lager. Dette skal hjelpe dem å finne ut når de må gjøre nye innkjøp. Lagersystemet skal være i bruk av ansatte på Teknotorget. Funksjonelle krav Brukerkrav Brukeren skal kunne: registrere en ny vare i systemet registrere en vare ut av systemet søke opp vare med navn, varenummer, leverandør eller merkenavn opprette en ny kategori i systemet slette kategori som utgår slette vare som utgår skrive ut rapporter på enkelte varekategorier skrive ut rapporter på enkelte varer logge seg med initialene sine redigere epost-varsel endre eksisterende vare Systemkrav Systemet skal kunne: varsles for bestilling av minimumsantall av vare sende varsel per e-post til en felles postboks sende varsel nr 2 til fellespostboksen, dersom ny vare ikke blir registrert inn i løpet av 14 dager gjenkjenne duplikat registrering og ikke tillate det liste alle varer, men skille mellom de som er tilgjengelig på lager og ikke på lager be om innloggingsinformasjon ved oppstart av applikasjonen vise logghendelser for alle varer være anvendelig under bruk

5 Ikke-funksjonelle krav Tekniske krav Webapplikasjon skal kunne utvikles i.net, CSS, XHTML, JavaScript, SQL database. Løsningen skal utvikles i Visual studio 2010 i C# Webapplikasjon skal være satt på oppdragsgiverens egne server Systemet skal være kompatibel med alle nettlesere Systemet skal ikke bruke mer enn 5 sekunder på å finne vare etter søk Systemet skal ha høy endrebarhet og tilrettelagt for eventuelle utvidelser Sikkerhetskrav Systemet skal kun være tilgjengelig innad Statsbyggs nett Samme passord som innlogging på pc-en vil bli brukt på systemet Brukere blir lagt inn i AD systemet av ansatte i Teknotorget Rammekrav i systemet Systemet skal: utvikles slik at applikasjonen skal enkelt kunne vedlikeholdes senere dokumenteres være ferdigstilt til juni være kun på norsk kjøres på Statsbygg sin pc plattform som er Windows 7 med støtte for 64 og 32 bit kjøres i pilot før en eventuell implementasjon

6 Brukstilfeller Use case modell Figur 1. Use case modell som beskriver systemets hovedfunksjonalitet

7 Detaljerte use case beskrivelser Registrere ny vare Hovedaktør: Bruker Trigger: Brukeren ønsker å registrere ny vare Forbetingelser: Bruker har tilgang til systemet og er logget inn Sluttbetingelser: Bruker har lagt en ny vare i registeret Hovedscenario og trinn (suksess): 1. Bruker trykker på Legg til ny vare knappen 2. Bruker fyller alle felt med informasjon om varen 3. Bruker fyller ut antall varer som legges inn 4. Bruker trykker lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 2a Bruker fyller ikke ut alle obligatoriske felt (feiltilfelle) 2b Vare med samme navn ligger allerede i systemet (feiltilfelle) 2c Bruker fyller ut ugyldig datatype i feltene (feiltilfelle) 3a Bruker fyller inn ugyldig tall 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 1: Detaljert use case beskrivelse:

8 Oppdatere vare Hovedaktør: Bruker Trigger: Brukeren ønsker å oppdatere vare Forbetingelser: Bruker har tilgang til systemet og er logget inn Sluttbetingelser: Bruker har oppdatert en vare Hovedscenario og trinn (suksess): 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på Oppdater vare knappen 3. Bruker fyller nødvendig informasjon som f.eks. antall 4. Bruker trykker på lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 2a Bruker bommer på knappen og trykker på X i stedet. 3a Feil datatype blir skrevet inn(feiltilfelle) 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 2: Detaljert use case beskrivelse: Slette vare Hovedaktør: Bruker Trigger: Brukeren ønsker å slette vare Forbetingelser: Bruker har tilgang til systemet og er logget inn Sluttbetingelser: Bruker har slettet en vare Hovedscenario og trinn (suksess): 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på slett vare knappen 3. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 3a Systemet krasjer/overbelastes (feiltilfelle) Tabell 3. Detaljert use case beskrivelse:

9 Logge inn Hovedaktør: Bruker Trigger: Brukeren ønsker å logge inn Forbetingelser: Systemet er oppe Sluttbetingelser: Brukeren har logget seg inn Hovedscenario og trinn (suksess): 1. Brukeren skriver inn brukernavn og passord 2. Brukeren trykker på logg inn 3. Systemet sjekker om brukernavn og passord er riktig 4. Systemet logger inn brukeren Utvidelser (unntak/feiltilfeller): 1b Brukeren fyller ikke ut feltene 3a Brukeren skriver inn feil brukernavn eller passord Tabell 4. Detaljert use case beskrivelse Krav til kode Krav til systemkonstruksjon Gruppen har valgt å utvikle webapplikasjonen med Microsoft.NET siden det er en komplett utviklingsplattform. Programmeringen av.net skjer hovedsakelig med programvaren Visual Studio som tilbyr fullspekket funksjonalitet, samt databasehåndtering som vil egne seg best til å utvikle en web-basert applikasjon. Når det gjelder utforming av design har gruppen valgt å bruke C#, CSS, javascript og HTML for å utvikle et brukervennlig grensesnitt. For redigering av bilder og grafiske enheter bruker gruppen Adobe Photoshop og MS Paint. Microsoft Office Visio brukes i planleggingsperioden for å få et konkret overblikk over webapplikasjonens oppbygning og hendelsesforløp. Databasen er en SQL database hvor blant annet alle tabeller og deres sammenhørighet planlegges.

10 Krav til dokumentasjon Systemet skal dokumenteres og leveres til oppdragsgiver All dokumentasjon skal skje jevnlig under prosjektperioden Prosjektdagbok skal føres daglig Dokumentasjonen skal ha et formelt språk Skal være tilgjengelig på gruppas nettside Dokumentasjonen skal følge en standard Styringsdokumentasjon Prosjektskisse Prosjektdagbok Forprosjektrapport Arbeids- og fremdriftsplan Kravspesifikasjon Sluttdokumentasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon