Arbeidet med kravspesifikasjonen In 140 Sommerville kap 6

Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6

Mål Forstå de viktigste aktivitetene i arbeidet med kravspesifikasjonen og forholdet mellom dem. n Bli kjent med flere teknikker for å arbeide med kravspesifikasjoner n Forstå betydningen av kravvalidering og hvordan kravgjennomganger brukes til dette n Forstå hvorfor det er nødvendig å administrere kravene og hvordan dette støtter arbeidet med kravspesifikasjonen n

• Målet er å skape kravspesifikasjonsdokumentet • Fire grunnleggende aktiviteter • Forstudie • Faktainnsamling og kravanalyse • Kravspesifisering • Kravvalidering • Strukturerte analysemetoder – Muligheter og begrensninger

Forstudie Starter med en grovskisse av systemet og hvordan det skal brukes. n Resultatet er en rapport der konklusjonen er: n – Det er verdt å fortsette videre med kravspesifikasjon – eller ikke. n Dette bør belyses: – Bidrar systemet til organisasjonens mål – Kan systemet lages med eksisterende teknologi innenfor tids og kostnadsrammer – Kan systemet integreres med systemer som allerede eksisterer

n Spørsmål som kan stilles etter at informasjon er hentet inn: – Hvordan kan organisasjonen greie seg uten det planlagte systemet – Hva er problemet med eksisterende løsninger, og hvordan vil et nytt system kunne bidra til å løse problemet – Hvilke direkte bidrag kan systemet gi til forretningsmålene – Kan informasjon overføres til andre systemer i organisasjonen (Datafangst) – Bruker systemet teknologi som er ny for organisasjonen? – Hva skal systemet støtte og hva skal det ikke støtte

n Hvem kan svare på spørsmål – – n Avdelingsledere Utviklere med erfaring fra området Teknologieksperter Sluttbrukere Forstudierapporten skal – Gi en konklusjon – skal vi fortsette? n Forstudierapporten kan endre – – Budsjett Omfang Tidsplan Krav

Faktainnsamling og kravanalyse n Samarbeid mellom utviklere, kunde og sluttbrukere for å: – Forstå anvendelsesområdet – Finne hvilke tjenester systemet skal levere – Krav til ytelse osv Kan involvere mange ulike interessenter n Vanskelig prosess fordi: n – – – Interessentene vet ikke hva de kan kreve Interessentene bruker sin forståelse og terminologi Interessentene har forskjellige mål og utrykksform Politisk innflytelse Dynamisk økonomisk og organisatorisk miljø Interessentblandingen kan endre seg

Faktainnsamling og kravanalyse

Teknikker for faktainnsamling og kravanalyse n Perspektiv n Scenarier n Etnografi orientert VORD

VORD – Viewpoint Oriented Requirement Definition Mange interessenter i et middels system. n Eksempel: Interessenter i en bankautomat ATM n – – – – Kunder i egen bank Andre banker Leder for avdelingskontor Skrankepersonale Databaseadministratorer Sikkerhetssjefer Markedsavdelingen Vedlikeholdspersonale

n Viewpoint kan defineres som – Datakilde eller bruker/sluk – Systemmodell f. eks ER vs tilstandsdiagram – Tjenestemottaker n n n Interaktive systemer Naturlig struktureringsmetode Lett å sjekke gyldighet Også god strukturering av ikke funksjonelle krav Informasjon om VP og tjenester i standard skjemaer

VORD-maler for viewpoint og tjenester Viewpoint-mal Tjeneste-mal Referanse Atributter Hendelser Tjenester Under. VP Referanse Begrunnelse Spesifikasjon Ikke funksjonelle krav Leverandør

VORD n Idemyldring – Boblediagram n Identifisere VP og tilhørende tjenester n Ikke-allokerte tjenester n VP – tjenestemottaker – datakilde – kontrollkilde n CASE nødvendig

Scenarier Beskrivelse av samhandling bruker/system n Nyttig ved overgang fra grovbeskrivelse n Kan inneholde: n – – – n Tilstandsbeskrivelse ved start Hendelsesrekkefølge Mulige feil og hvordan de takles Samtidige aktiviteter Tilstandsbeskrivelse ved slutt Uformelt eller strukturert – Hendelsesscenarier – Use case (Anvendelsestilfelle)

Hendelsesscenarier n Del av VORD – beskriver hendelsesrespons n Hver enkeltinteraksjon kan dokumenteres med eget scenarium – Dataflyt (dataflow) – Systemhandlinger – Unntak

– – – Ellipse er datautveksling med VP Kontrollinfo fra/til boksens topp Data går ut på høyre interne data uten ramme Unntak vises under boksen. Ved flere unntaksmuligheter i skyggeramme Neste hendelse vises i skyggelagt boks

Use Case n Scenariebasert (Jacobson 1993) n UML (Use Case + Interaksjonsdiagram) n Aktører og interaksjoner

Sekvensdiagrammer

Etnografi Programvaresystemer er i en sosial sammenheng n Sosiale og organisatoriske krav kritisk suksessfaktor n Observasjonsteknikk n – – n Analysator i omgivelsene for systemet Følge med i og notere hva som faktisk gjøres Ubevisst organisering Komplekst og rikt – ikke som antatt Spesielt effektiv i to sammenhenger: – Finne forskjeller mellom faktisk og beskrevet prosess – Finne behov for samarbeid Kan brukes sammen med prototyping n Er ikke nok alene n

Kravvalidering Er spesifikasjonen = kundens behov? n Det bør sjekkes at spesifikasjonen er n – – – n Gyldig Konsistent Komplett Realistisk Verifiserbar Teknikker – – Gjennomgang Prototyping Testtilfeller Automatisk konsistenssjekk Vanskelig for utviklere n Enda vanskeligere for sluttbruker n

Kravgjennomgang Manuell prosess med representanter for oppdragsgiver og utviklerorganisasjon n Formell eller uformell n – Uformell diskusjon mellom utviklere og interessenter kan gi gode resultater – Formell gjennomgang. Sjekke alle punkter • • • Konsistens Kompletthet Testbarhet Forståelighet Sporbarhet Tilpasningsdyktig – Konflikter, feil og mangler må skrives ned og løsning finnes

Kravadministrasjon n Store systemer spesielt utsatt forandringer – – Skal forbedre eksisterende situasjon Vanskelig å forutse hva nytt system innebærer Stor og variert brukergruppe. Støttebalanse Oppdragsgiver og sluttbruker har gjerne forskjellig behov – Endret systemmiljø – Økt forståelse gir nye krav Kravstyring er å forstå og styre endrede krav n Parallelt med faktainnsamling og kravanalyse n Ulike krav har ulik stabilitet n

Konstante og flyktige krav n Konstante krav – Stabile krav som er forbundet med kjernevirksomheten n Flyktige krav – Krav som sannsynligvis vil skifte – Fire klasser: • • Krav som kan forandres av eksterne instanser Krav som har kommet til underveis Krav som er avhengige av det nye systemet Krav til kompatibilitet med arbeidsmåten.

Kravstyringsplanlegging n Dette må du ta stilling til: – Kravidentifisering – Kravstyringsprosess – Sporbarhetsopplegg – CASE-støtte

Sporbarhet n Eierinteressent og begrunnelse n Hvilke andre krav henger sammen med dette kravet n Hvordan er dette kravet planlagt innfridd n Kravsammenhenger – Matrise – Database

Matrise for kravsammenheng

Kravforandringsadministrasjon n Formell metode gir konsistent og kontrollert behandling – Problemanalyse og forandringsspesifikasjon – Forandringsanalyse og overslag – Implementering • Kravspesifikasjonsdokumentet bør være skrevet forandring: Få eksterne referanser og modulær oppbygning n Ikke fall for fristelsen å gjøre en rask endring og så dokumentere etterpå