Arbeidet med kravspesifikasjonen

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. Viewpoint-mal Referanse Atributter Hendelser Tjenester UnderVP Tjeneste-mal Referanse Begrunnelse Spesifikasjon Ikke funksjonelle krav Leverandør VORD-maler for viewpoint og tjenester

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

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 unntaksmuligheter 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 gjennomgang. 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å