Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6.

Presentasjon om: "Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6."— Utskrift av presentasjonen:

1 Arbeidet med kravspesifikasjonen In 140 Sommerville kap. 6

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

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

4 Forstudie Starter med en grovskisse av systemet og hvordan det skal brukes. Resultatet er en rapport der konklusjonen er: –Det er verdt å fortsette videre med kravspesifikasjon –eller ikke. 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

5 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

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

7 Faktainnsamling og kravanalyse Samarbeid mellom utviklere, kunde og sluttbrukere for å: –Forstå anvendelsesområdet –Finne hvilke tjenester systemet skal levere –Krav til ytelse osv osv Kan involvere mange ulike interessenter Vanskelig prosess fordi: –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

8 Faktainnsamling og kravanalyse

9 Teknikker for faktainnsamling og kravanalyse Perspektiv orientert VORD Scenarier Etnografi

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

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

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

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

14

15

16

17

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

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

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

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

22 Sekvensdiagrammer

23 Etnografi Programvaresystemer er i en sosial sammenheng Sosiale og organisatoriske krav kritisk suksessfaktor Observasjonsteknikk –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 Er ikke nok alene

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

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

26 Kravadministrasjon Store systemer spesielt utsatt for 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 Parallelt med faktainnsamling og kravanalyse Ulike krav har ulik stabilitet

27 Konstante og flyktige krav Konstante krav –Stabile krav som er forbundet med kjernevirksomheten 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.

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

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

30 Matrise for kravsammenheng

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