Fjernundervisning fra NITOL - HiST
Resyme: Som vanlig tar vi med en liten oppsummering i hvor vi holder på i systemutviklingsprosessen. Vi holder nå på med å beskrive det datasystemet som skal anskaffes. I forrige leksjon holdt vi på med brukergrensesnittet; hvordan det bør utformes, hvordan formulere krav til dette og hvordan spesifisere brukergrensesnittet. I denne leksjonen skal vi se på spesifikasjon av funksjonaliteten og utformingen av kravspesifikasjonen i sin helhet. Å utforme en kravspesifikasjon er mer enn bare å lage en liste med krav. Det er rett og slett å bestemme hva slags system man vil ha. Hva det skal kunne gjøre, hvordan det skal virke og hvordan det skal se ut.
Pensum: Andersen kapittel 2.2 og 21.2.2
Notat av Tore Berg Hansen: "Modul 1 – Krav til programvare"
Forfatter: Arne B. Mikalsen
Dato: 16.03.99
Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å bruke leksjonene f.eks til undervisning eller kursformål må ta direkte kontakt med forfatter for nærmere avtale.
Som vanlig en liten oppsummering i hvor vi holder på i systemutviklingsprosessen. Vi holder nå på med å beskrive det datasystemet som skal anskaffes. I forrige leksjon holdt vi på med brukergrensesnittet; hvordan det bør utformes, hvordan formulere krav til dette og hvordan spesifisere brukergrensesnittet. I denne leksjonen skal vi se på spesifikasjon av funksjonaliteten og utformingen av kravspesifikasjonen i sin helhet. Å utforme en kravspesifikasjon er mer enn bare å lage en liste med krav. Det er rett og slett å bestemme hva slags system man vil ha. Hva det skal kunne gjøre, hvordan det skal virke og hvordan det skal se ut. Vi skal altså gjøre to ting:
1. Utforme et system som dekker behovene og som oppfyller målene og forutsetningene for prosjektet
2. Lage et dokument som beskriver dette systemet: Kravspesifikasjonen.
Det meste av denne leksjonen handler om punkt 2 – hvordan utforme dokumentet. Men først skal vi se litt på punkt 1 – hvordan utforme systemet. Legg merke til at jeg bruker ordet "utforming" annerledes enn Andersen. Han bruker begrepet om teknisk utforming (konstruksjon), mens jeg bruker begrepet om å bestemme hva systemet skal kunne gjøre og hvordan det skal brukes.
Vi må anta at det har foregått en slags problem-/behovsanalyse i virksomheten, og at et forslag til løsning er valgt (f.eks. i et forstudium). Vi må nå avgjøre mer spesifikt hva systemet skal kunne gjøre og hva det ikke skal gjøre. Dette valget må være bevisst.
Viktige oppgaver i denne fasen av systemutviklingen er å holde kontakt med brukerne (de som skal bruke systemet) og oppdragsgiverne (de som betaler for systemet). Disse to gruppene har ofte ulike behov og ønsker.
Brukerne vil ha brukervennlige systemer som er tilfredsstillende å jobbe med. Brukerne vil også ofte beholde systemer og rutiner mest mulig slik de er i dag. De vil beholde det de behersker, det som gir dem status og posisjon i organisasjonen.
Oppdragsgiverne vil ha effektive systemer som er så billige som mulig. De ønsker også ofte å beskytte de investeringene de har gjort tidligere.
På toppen av dette kommer vi, systemutviklerne som ivrer etter å ta i bruk ny teknologi. Her kan det bli konflikter og kanskje trengs det andre fagfolk fra andre felter for å løse opp i flokene.
Her er noen spørsmål vi bør stille oss før vi går løs på utformingen av systemet:
En del av denne prosessen går ut på å bestemme hvilke oppgaver som skal utføres av mennesker i organisasjonen og hvilke som skal overlates til systemet. Til hjelp i denne vurderingen kommer her en liten liste over hvor menneskene har sine sterke sider og hvor datamaskinene har sine sterke sider:
Mennesker er bedre enn datamaskiner til å:
Datamaskiner er bedre enn mennesker til å:
Hvis det er et program som skal utvikles: Finn ut hvilke hoveddeler bør systemet bestå av? Hvilke oppgaver skal systemet ta seg av? Hvilke skjermbilder er nyttige? Hvilke utskrifter/rapporter er nyttige?
Hvis det er et nettverk som skal planlegges: Hvem skal være på nettet i dag og i framtida? Hvilke tjenester skal være mulig å utføre på nettet (post, konferanse, felles databaser, felles filer, delt fax/modem o.s.v.)?
Det er viktig å lage et system som i størst mulig grad støtter opp under rutiner og arbeidsmåter i virksomheten, men likevel tillater frihet og fleksibilitet Systemet bør altså ikke tvinge brukerne inn i rigide arbeidsformer.
Eksempel:
Et korrekturleserfirma skal utvikle et system som skal kunne registrere oppdrag som kommer inn. Systemet skal generere et brev med en bekreftelse til oppdragsgiver, og finne en ledig korrekturleser på det ønskede tidspunktet.
Løsning 1: Skjermbildet for registrering av oppdrag inneholder ingen felter der en kan skrive inn kommentarer. Derimot inneholder det en liste der en kan krysse av for norsk/engelsk, antall sider etc.
Systemet genererer en bekreftelse automatisk ut fra registreringsbildet og skriver ut bekreftelsen på skriveren.
Systemet finner en ledig korrekturleser til det aktuelle tidspunktet og setter denne personen til å ta jobben.
Løsning 2: Skjermbildet for registrering inneholder avkrysningsliste, men også et felt der en kan skrive inn kommentarer.
Når bekreftelse skal genereres starter systemet automatisk en tekstbehandler (f.eks. Word) og et dokument som inneholder forslag til bekreftelse til kunden kommer på skjermen. Brukeren kan så endre dette brevet eller gjøre tilføyelser.
Systemet foreslår en korrekturleser, og genererer et elektronisk brev til den aktuelle korrekturleseren med forespørsel om han/hun kan ta dette oppdraget.
Begge disse løsningene støtter opp under rutinene, men mens løsning 1 er rigid så er løsning 2 fleksibel.
Nå kan vi begynne å skissere skjermbilder. Hva slags dialogtype/typer vil vi ha? (Se leksjon 6). Hvilke rekkefølge skal skjermbildene komme i? (Her kan en eventuelt bruke tilstandsdiagrammer). Vurder skjermbildene. Forkast dem og lag nye om nødvendig. Slike runder med vurderinger og nye forslag øker kvaliteten!
Påminnelser fra leksjon 6: Brukeren bør utføre oppgavene i en naturlig rekkefølge, skjermbildene bør være ryddige og ikke overlesset med informasjon. La de viktigste opplysningene ha den mest iøynefallende plasseringen på skjermen.
Ellers henviser jeg til leksjon 6 om brukergrensesnitt.
Nå har du et system på notatblokka. Da kan det være hensiktsmessig å formulere det i form av en kravspesifikasjon.
Organisasjonene IEEE (Institute of Electrical and Electronics Engineers) og ANSI (American National Standards Institute) har utviklet en standard for hvordan kravspesifikasjoner skal utformes. I følge dem skal kravspesifikasjonen være:
Denne standarden begynner etter hvert å bli ganske gammel, og utvikling av programvare gjøres i dag etter mange ulike metoder. Jeg mener at det ikke er mulig å sette opp en fast standard for hvordan kravspesifikasjoner skal se ut. Hvordan kravspesifikasjonen bør se ut er avhengig av hva slags kravspesifikasjon man trenger! Her er noen faktorer som vil variere:
Dersom det skal utvikles skreddersydd programvare at et eksternt firma, kan kravspesifikasjonen fungere som en kontrakt mellom oppdragsgiverne og utviklerne. "Lag systemet slik det står her, eller vi vil ha pengene tilbake". I slike tilfeller kan det være hensiktsmessig å utforme en detaljert kravspesifikasjon før arbeidet starter opp.
I andre tilfeller skal en kjøpe et ferdiglaget standardsystem - det være seg standard programvare eller et nettverk. I så fall vil kravspesifikasjonen fungere som en "ønskeliste" over hvilke egenskaper en vil at systemet skal ha. Visse av disse ønskene kan selvfølgelig være absolutte krav. Så må en velge det systemet som tilfredsstiller alle kravene og flest mulig av ønskene. Det står noe om valg av standardsystemer i kapittel 15 i Andersen sin bok.
Noen organisasjoner utvikler sin egen programvare. Da er det kanskje ikke nødvendig med noen detaljert kravspesifikasjon. Det viktige da er et tett samarbeid mellom brukere og utviklere.
Dersom det er av stor viktighet at systemet fungerer på en bestemt måte, er det fornuftig å formulere dette i form av en kravspesifikasjon.
Dersom det er et omfattende eller dyrt prosjekt er det viktig å ha en kravspesifikasjon. Men hvor detaljert denne bør være, vil kunne variere. Skal en lage et trygdesystem for hele Norge, vil det f.eks. kunne være greit å ha en kravspesifikasjon.
Det finnes eksempler på det motsatte også:
Da Den norske Bank for noen år siden skulle utvikle et nytt girosystem var kravspesifikasjonen på tre ord:
"Lag et girosystem"
Arbeider en etter livssyklusmodellen (vannfallsmodellen), vil en detaljert kravspesifikasjon være viktig. Etter denne modellen utvikles kravspesifikasjonen en gang, den godkjennes og deretter brukes den (eventuelt glemmes den). Men ofte vil en stadig hoppe mellom analyse, utforming og realisering (f.eks. ved prototyping eller spiralmodellen). I så fall vil det stadig være behov for å oppdatere og endre kravspesifikasjonen.
Ved å jobbe strengt etter livssyklusmodellen vil særlig to problemer melde seg:
Løsningen kan være å drive realisering og testing parallelt med arbeidet med kravspesifikasjonen.
Det kan uansett være lurt å oppdatere kravspesifikasjonen etter hvert som endringer blir bestemt. På den måten vil dokumentet fungere som dokumentasjon, og som basis dersom systemet senere skal endres eller flyttes til en annen maskinvareplattform.
Dette vil kunne variere. Her er tre varianter:
Jeg har mest tro på den siste varianten. Oppdragsgiverne kjenner behovene og oppgavene, utviklerne kjenner mulighetene.
Oj! Krav til kravene! Her er noen punkter jeg mener er viktig:
Det skal være mulig å oppfylle absolutt alle krav i kravspesifikasjonen. Det må ikke være noen faktiske feil i spesifikasjonen som da fort blir oversett. Måten å være sikker på dette kan være å gå gjennom alle krav i spesifikasjonen og undersøke med brukerne/kunden om den dekker behovene de har.
Det er viktig at alle kravene er med i spesifikasjonen. En kravspesifikasjon består gjerne av en hel mengde funksjoner. For hver funksjon må alle inn- og utdata tas med, både lovlige og ulovlige format.
Figurer og tabeller nummereres, og det visestil hver enkelt figur/tabell fra teksten. På denne måten sikrer en at ingen figurer står "i løse luften", men knyttes til teksten og kravene i spesifikasjonen.
Det må ikke være noen "bestemmes senere" i kravspesifikasjonen.
En må passe på at det ikke er noen motsetninger i kravspesifikasjonen. For eksempel:
Hvert punkt i kravspesifikasjonen skal kunne etterprøves, og det skal ikke være noen tvil om kravene er oppfylt eller ikke. Alle skal kunne si utvetydig om et krav er oppfylt eller ikke.
Lag en oversiktlig kravspesifikasjon med mange og gode overskrifter slik at det blir lett å slå opp i den. Det skal være enkelt og likefrem å gjøre endringer i kravspesifikasjonen. Bruk av innholdsfortegnelse og indeksregister hjelper betraktelig på dette. Bruk tekstbehandlernes innebygde mulighet for disse funksjonene. Da kan en automatisk generere nye oversikter ved endringer. Figurnummer og kryssreferanser bør også oppdateres automatisk for å gjøre dokumentet mest mulig modifiserbart.
Bruk et språk som både oppdragsgiver og utviklere forstår. Bruk også beskrivelsesteknikker som er forståelige for begge parter. Noen diagrammetoder kan f.eks. være vanskelige å forstå for "vanlige mennesker" (les: De som ikke har peiling på data).
Et vanlig problem er at kravspesifikasjonen forstås på ulike måter av de ulike aktørene. Det er viktig å formulere kravspesifikasjonen slik at misforståelser unngås. Hvert punkt (alle krav) i spesifikasjonen må ha en tolkning. En må gå gjennom kravspesifikasjonen og undersøke at alle målgrupper har samme oppfatning av kravene. Først da kan en si at spesifikasjonen er entydig og klar.
Ellers finnes det en sjekkliste for kravspesifikasjoner i figur 20.2 i Andersen sin bok.
Kravspesifikasjonen skal si noe om hva systemet skal gjøre, men ikke hvordan det skal gjøres. Ideelt sett skal vi i kravspesifikasjonen ikke si noe om teknologien og oppbyggingen i systemet, bare om funksjonaliteten, brukergrensesnittet, data og om generelle krav. Det er en fordel å vente så lenge som mulig med å ta beslutninger om hvordan systemet skal bygges. På den måten kan en beholde friheten til å velge løsning lengst mulig.
I praksis har vi likevel en viss anelse om hva slags teknologi som skal benyttes. Ofte vil også valg av teknologi påvirke hvilke muligheter som finnes. På denne måten trekkes ofte teknologien inn i kravspesifikasjonen.
Hvordan systemet skal lages avgjøres i konstruksjonen (som Andersen kaller utformingen. Problemområde 3 og 4.)
Under vil jeg si litt om de enkelte kapitlene i kravspesifikasjonen. Dere har tre forslag til utforming av kravspesifikasjon. SINTEFs standard (vi har sett på en annen av SINTEFs standarder i forbindelse med forstudiet) er en variant som vi skal beskrive til slutt i leksjonen. En annen variant står beskrevet i artikkelen "Modul 1 – Krav til programvare", mens den tredje finnes i figur 2.8 i Andersen sin bok. Der er innholdet i de ulike kapitlene godt beskrevet. Her er noen tilleggskommentarer om noen av kapitlene fra boka:
Det viktigste i dette kapittelet er at det inneholder en kortfattet beskrivelse av systemet. Det bør finnes fem setninger som klart og enkelt forteller hva systemet gjør slik at en utenforstående kan danne seg et bilde av systemet.
Kapittelet skal være et sammendrag av resten av kravspesifikasjonen, og det skal ikke inneholde spesifikke krav som ikke er nevnt noe annet sted. Vær kort her.
Eksempel: Hotellreserveringssystem
"Systemet skal holde oversikt over alle bestilte rom og alle gjester på hotellet. Det skal være mulig å registrere bestillinger, få oversikt over alle gjester på systemet og få oversikt over hvilke rom som er ledige."
Her kan en bruke punktene fra forstudiet dersom et slikt er gjennomført. Rammekrav og forutsetninger ble omtalt i leksjon 4. Det vil vel være naturlig å konkretisere punktene her siden vi nå har kommet lengre i prosessen.
Dersom det er et krav at en bestemt teknisk løsning (maskintype, nettverk, verktøy) skal benyttes, så må dette komme fram her.
Eksempel:
"Det er en forutsetning at dagens PCer benyttes, og at disse koples sammen i et lokalnett".
Kapittelet bør også inneholde generelle krav til brukergrensesnittet. Det kan være krav til at visse standarder skal følges, krav til responstid eller læringstid.
Dette er det mest omfattende kapittelet. Her skal alle funksjonene i systemet beskrives. I en del tilfeller er det viktig at dette kapittelet er komplett, d.v.s. at absolutt alt det skal være mulig å gjøre med programmet, skal beskrives her. F.eks. må det beskrives hva som skjer i hvert punkt i alle menyer i systemet. I andre tilfeller er ikke slik kompletthet så viktig.
Det kan være hensiktsmessig å starte med å beskrive egenskaper som er standard for hele systemet. På den måten slipper en å gjenta disse tingene for hver funksjon. F.eks. kan det være at på alle skjermbilder kan en få opp hjelpetekst ved å trykke tasten F1.
Eksempel: Funksjoner i hotellreserveringssystem
- Innlogging i systemet
Reservasjon
- Registrering av gjest i gjestearkiv
- Endring av opplysninger om gjest
- Sletting av gjest fra gjestearkiv
- Registrering av bestilling
- Sletting av bestilling
- Endring av tidspunkter
- Endring av rom for en gjest
- Utskrift av bestilling
- Søk etter en bestemt gjest
Rom
- Registrere nye rom
- Slette rom
- Endre opplysninger om et rom (antall senger, TV o.l.)
Oversikter:
- Oversikt over ledige rom en bestemt dato og tidsperiode
- Oversikt over alle hotellets gjester for en oppgitt dato
Systemfunksjoner
- Sikkerhetskopiering av databasen
En mulig organisering er å dele opp beskrivelsen i naturlige deler. For hver funksjon bør en sette opp følgende:
Eksempel:
Et biblioteksystem kan f.eks. brukes av bibliotekarer, låntakere og systemansvarlige. Det kan være lurt å tilpasse funksjonene og skjermbildene til den enkelte brukergruppe. Bibliotekaren trenger andre opplysninger enn låntaker. Bibliotekarterminologi kan benyttes på skjermbildene til bibliotekaren, men bør unngås til låntakere.
Det er også mulig å beskrive funksjonaliteten i systemet v.h.a. dataflytdiagrammer. Dette er beskrevet i Andersen kapittel 9. Jeg har ikke funnet det hensiktsmessig å ta dette inn i kurset. Det viser seg også at disse diagrammene er vanskelige å forstå for de som ikke har databakgrunn (f.eks. oppdragsgivere og brukere).
En alternativ måte å beskrive funksjonaliteten er v.h.a. objektorientert analyse og design. Det kommer vi inn på i neste leksjon.
Det bør stå i kravspesifikasjonen hvilke dokumenter som skal produseres. Kandidater er:
På samme måte som vi presenterte en mal for forstudierapporten i en tidligere leksjon, skal vi gå gjennom en tilsvarende mal for kravspesifikasjonen. For ordens skyld, oversikten er hentet fra boka"Håndbok i systemarbeid" (Bræk m.fl., TAPIR forlag).
Sett opp en ordliste over datatekniske begreper i gravspesifikasjonen, beregnet for personer med liten eller ingen EDB-utdannelse.
Her spesifiseres rammekrav som gjelder systemet som helhet:
Dette kapittelet gjentas for hvert delsystem og inneholder detaljert beskrivelse av on-line funksjoner og satsvise funksjoner som inngår i delsystemet. For hver funksjon spesifiseres:
Beskriv den logiske sammenhengen mellom datasettene ved hjelp av datastrukturdiagrammer. Hvert datasett beskrives med referanse til inndatabeskrivelsen i kapittel 4.
Beskriv krav til brukerdokumentasjonen, operatørdokumentasjonen, systemdokumentajsonen m.m.
Detaljert beskrivelse av de manuelle funksjonene i det nye systemet, medregnet reserverutiner. For hver funksjon spesifiseres:
Angi forutsatt kunnskapsnivå, kurstyper, kursinnhold, antall kursdeltakere osv.