kravspesifikasjon

20.04.23 Kravspesifikasjon 1

Kravspesifikasjon Kravspesifikasjon:

Pensum definert gjennom forelesningene (Powerpoint filer)

Mye overlapp med IT-strategi delen Vi har tidligere sett på hvordan organisasjoner kan få

maksimalt ut av alle sine IT systemer, her ser vi på kravene til ett system

Denne forelesningen kan også fungere som en oppsummering av mye av det vi tidligere har snakket om

Referansebok: Del I av Kotonya, G. & Sommerville, I., Requirements

Engineering, Wiley, 1997.


Bakgrunn IT prosjekter har vært plaget av:

Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Uklarhet om mål er oppnådd

Ofte legger en skylden på uklare kravspesifikasjoner

Med kravspesifikasjonen ønsker en: Bedre styring Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov


Kravspesifikasjon kan være mangt… Et formelt dokument, en juridisk

bindende kontrakt, mellom kunde og utvikler om hva som skal gjøres

En prototype En liste av mål for systemet, samt en

skisse til løsning Kan starte med en vag ide

”hei, vi har et problem med å lage en ordreplan”


Her skal vi I stor grad se på mer formell

kravspesifikasjon Kunnskap om dette er viktig da

enkelte organisasjoner krever dette Men, vi skal også se på andre måter

å lage en kravspesifikasjon på Kravspesifikasjonen blir viktig for

store systemer


Forskjellige typer av krav kan inngå:

Generelle

Funksjonelle

Krav til implementasj

on

Effektivitet

Brukervennlighet


Problemer Upresise mål Kravspesifikasjonen beskriver ikke brukernes virkelige

behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne),

mange punkter, svak overordnet forståelse Misforståelser mellom bruker, de som utvikler

spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har

vi sjelden Kravspesifikasjonen tar ikke hensyn til at visse mål er

vanskelig å oppnå Hva når de egentlige kravene endres over tid?


Kan føre til… Forsinket leveranse Fordyret leveranse Behov for store endringer etter installasjon Systemet blir benyttet galt, lite eller ikke i det

hele tatt Systemet kan være upålitelig Kritiske brukere Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs Indirekte kostnader (jobben blir ikke gjort)


Ofte Store kostnader til utvikling og tilpassning Systemet blir tatt i bruk Det virker Men uklart om en har oppnådd noe F.eks. (fra en vit. artikkel):

It is therefore very unlikely that any ERP implementation can simply be asserted to be a success or a failure

Men det er selvfølgelig systemer som er en åpenbar suksess eller en åpenbar fiasko


Kravspesifikasjonsprosessen

Hvordan man håper at denne skal gå!


Aktiviteter


Kravspesifikasjonsdokumentet inneholder:


IEEE/ANSI 830-1993 (standard): Introduction

Purpose Scope of the product Definitions References Overview of document

General description Product perspective Product functions User characteristics General constraints Assumptions and dependencies

Specific requirements functional, non-functional, interface, performance, database and

network requirements, etc. Index


Hvem bruker kravspes. dokumentet?


Guidelines:


Prosessen


Data


Aktivitetsmodell

elicitation – å få fram, synliggjøre


Tradisjonell modell

Waterfall model


Mer moderne


Utvikling, først når vi vet hva vi skal lage:

Utvikling av systemet (detaljspesifikasjon, programmering…)

Denne fasen er lite formalisert, åpen, med mange usikkerhetet

Denne fasen bør være formalisert, entydig og sikker


Hvem er involvert?


Roller


Verktøy for å understøtte kravspesifikasjonsprosessen:


CMM – Capability Maturity Model

SEI, Software Engineering Institute i Pittsburgh bruker disse 5 nivåene.


Nivåer av utvikling mht softwareutvikling: Initial:

Udisiplinerte prosesser, individer bestemmer hvordan ting skal gjøres og hvilke teknikker som skal brukes

Repeatable level: Grunnleggende prosesser for budsjettering og

planlegging av utviklingsprosesser er beskrevet og kan repeteres

Defined level: Dokumentasjon, standardisering

Managed level: Kvalitetskontroll

Optimizing level: Kontinuerlig prosess for forbedring, objektive målinger


”in” å karakterisere organisasjoner på denne måten

Mest anvendelig for store softwarehus

Har mange prosjekter Ofte store prosjekter Mange prosjektdeltagere Formalisering er nødvendig for å få

oversikt og kontroll

Problemer med modellen Mange softwareutviklere bruker en

ad hoc modell (nivå 1) med stor suksess

Eksempler: Microsoft, Google, Facebook, Apple

Men dette kan sies å falle innenfor kreativ softwareutvikling, mens “maturity” modellen kanskje er ment for mer rutinepreget virksomhet?


Forenklet modell for kravspesifikasjon


Best practices


Requirement Elicitation


Fire dimensjoner Application domain understanding

Forstå institusjonen, området der systemet skal anvendes. Hvem er brukerne, hva er brukernes bakgrunn. Hvilke holdninger eksisterer…

Problem understanding Hva er målene for systemet, hvilke problemer skal vi

løse… Business context

Systemet skal (som oftest) bidra til utvikling av organisasjonen, hvordan passer systemet inn med andre, med overordnede strategier

Stakeholder needs and constraints Hva er deres motivasjon, hva ønsker de å oppnå


Problemer Application domain understanding

Informasjon om dette er ikke samlet på ett sted, mange kilder, også muntlige, eksplisitt og implisitt

Problem understanding De har et problem, men akkurat hva dette går ut på

og hvordan det skal løses må vi ofte finne ut selv. De vi skal arbeide med er ofte opptatt…

Business context Hvordan fungerer organisasjonen, er overordnede

mål og strategier uttalte? Stakeholder needs and constraints

Stakeholders kan ha sine (ofte gode) personlige motivasjoner i et prosjekt, hva er disse?


”Elicitation” og analyse


4 kritiske aktiviteter: Mål

Beskriv målene for systemet, oversikt over problemet, hvorfor et nytt system kan være nødvendig, begrensninger som budsjett…

Bakgrunnskunnskap Organisasjon, anvendelsesområde, andre systemer…

Organisering Organiser data og informasjon samlet inn til nå,

prioriter mål Brukerkrav

Hva er brukernes krav til det nye systemet


Mål

Skal fortelle oss hva vi skal oppnå, hensikten (”rationale”)

Disse kan brukes når vi må ta avgjørelser underveis (f.eks. for å velge mellom brukervennlighet og effektivitet)

Målene blir viktige når systemet skal evalueres


Oversikt


Analyse /forhandlinger


Teknikker

Samle bakgrunnsstoff (strategiplaner, årsrapporter….)

Intervjuer Scenarioer ”Soft system methodology” (SSM)

Syv faser (se neste slide)


SSM – 7 faser:


Etnografisk undersøkelse

Observasjon av brukerne i arbeid, intervjuer, video, ”de-briefing” hvor vi trekker ut verdifull informasjon


Prototyping Alternativer:

Bruk og kast Evolusjonær prototyping (mer aktuell nå med bedre

verktøy) Mange fordeler:

Kan vise hvordan systemet vil bli, inklusiv ”look and feel” Håndfast Lettere for brukerne å forholde seg til en prototype enn

en spesifikasjon, mer og bedre tilbakemeldinger Hurtigere utvikling Understøtter utvikling i faser Gir utviklerne tidlige kunnskaper om metoder, tidsbruk

m.m.


Prototype Av hele systemet, prototypen kan da bli

systemet (ref. Oshaug) Av deler av systemet:

Brukergrensesnitt Komplekse tekniske løsinger Tidsaspekt

Det er smart å konsentrere seg om ukjente deler først.

Prototyper kan hjelpe oss her.


Analyse av kravspesifikasjon, sjekkliste


Validering

Sjekker for: Kompletthet Konsistens Nøyaktighet

Avsluttende fase i arbeidet


Input & Output


Reviews

Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen


Sjekkliste


Prototyping Validering gjennom prototyping:

Velg testpersoner Utvikle testscenario Utfør scenario

Mange krav kan best testes gjennom prototype:

Opplæring Brukervennlighet Effektivitet (delvis)


Prosess


Modellvalidering

Vi kan ha detaljerte modeller av systemet, for eksempel for dataflyt Er disse i orden? Inkluderer de all relevant

informasjon? Konfliktfritt? Er de konsistent med andre modeller? Beskriver de brukernes behov?


Testing Kan kravene testes?

Kan vi gjøre en eller flere tester i det ferdige systemet for å vise at kravet er oppfylt

Eksempel: Systemet skal være lett å lære? 95% av brukerne skal kunne benytte

systemet etter 10 minutter? Hvilket krav er testbart?


Requirements management

Her er vi opptatt av: Stabile og dynamiske krav Identifisering av krav, lagring Versjonskontroll Sporing (traceability)


Behovet for endringer


Identifisering av krav


Lagringsstruktur for krav


Versjonskontroll (faser)


Versjonskontroll (prosess)


Sporing

Vi ønsker å kunne spore endringer begge veier.

Hvilke underordnede krav kan bli berørt av endringen i dette kravet?

I hvilke overordnede krav inngår kravet som er endret?


Typer av sporing


Oppsummering Følgende må være på plass:

Det er viktig å vite målsettingene for systemet Vi må ha en god og utarbeide idé av

systemfunksjonaliteten Brukergruppene må være kjent Vi må ha valgt metodikk Vi må vite hvordan systemet skal

implementeres Koplinger til andre systemer må være kjent Installasjonsfasen må være beskrevet

Før vi starter utviklingen av systemet


Små systemer – store systemer Mange av de konkrete eksemplene vi har brukt

tidligere har vært for små systemer Små systemer har mange fordeler:

Oversiktlige Begrenset arbeidsmengde Få brukere, få installasjoner

Da kan vi få en betydelig reduksjon av arbeidet med:

Kravspesifikasjon Testing Opplæring

Med store systemer blir alt annerledes, spesielt om de utvikles under en detaljert kravspesifikasjon

kravspesifikasjon

Documents