Software Requirements Elicitation Holde foredrag om SRE. Det er ikkje nødvendig å skrive av ifra de slides som blir presentert, vi komme til å legge de ut på internett: http://www.cognit.no/leendert/sfteng/slides/

Identifisering av krav Etter feasibility study så kommer Identifisering av krav som neste steg i requirements engineering prosessen. Vi kan sette i gang med identifisering av krav når: A statement of work (SOW) er mottatt av kunden. Kunden er identifisert Vi har opprettet forbindelse med interessentene for prosjektet. Vi samler inn krav for å få svar på: Hvilket/hvilke problem som må løses Hvor problemet ligger Hvem som er eier av problemet Hvorfor det trenger en løsning Hvordan et programvaresystem kan hjelpe Når en løsning må foreligge Hva som kan hindre en løsning Involvert i kravidentifisering: Sluttbruker, ledere, utviklere som er involvert i vedlikehold, domeneeksperter, fagforeninger osv. Første steg: analysis, specification , validation SOW: skal inneholde en beskrivelse av hva prosjektet skal levere samt en oversikt som beskriver det arbeidet som kreves for å fullføre prosjektet. Hvilket/Hvilke: for å avgrense problemet. Hvor: forstår (totale) sammenhengen Hvem: identifisere interessenter Hvorfor: Indetifisere interessentenes mål Hvordan: samle inn noen sceanrio Når: Hva kan hindre: Identifisere Risiko og om det er gjennomførbart Involvert. interessenter

Vanskeligheter ved elicitation Kunnskapen kan være distribuert mellom mange kilder Det kan oppstå konflikt mellom kunnskap fra forskjellige kilder Folk kan ha problem med å beskrive kunnskap de sjelden bruker De som kjenner til problemet kan være for opptatt med å løse det ved å bruke det gamle systemet. Folk har ikke tillatelse til å fortelle det du trenger å vite Folk vil ikke fortelle deg det du trenger å vite. Distrib.: Sjelden tilgjengelig i explicit form. (Ikkje nedskreven) Forskj. Kilder: Grunnen til at det kan oppståkonflikt: Folk har forskjellig mål og forståelse for problemet. Sjelden bruk: Beskrivelse kan være unøyaktig rasjonalisering av expert oppførsel Tillatelse: Organisatoriske faktorer kan betye noe i den sammenheng.. Vil ikke: Det som kommer ut kan berøre de.. Så da lar de være

”Ved å bedre requirements elicitation, bedrer man hele prosessen rundt requirements engineering, noe som vil resultere i et bedre system!” Fordi elicitation er den første delen i systemutviklingsprosessen, så er den helt avgjørende for om resten av systemutviklinga blir bra eller ikkje.

Noen innsamlings teknikker Intervju Prototyping Brukstilfeller Observasjon

Intervju Typer: Fordeler: Ulemper: Strukturert: forhåndsdefinerte spørsmål Ustrukturert: åpne spørsmål Viktig å rettlede brukeren/kunden på riktig spor Fordeler: Rikholdig samling av informasjon Ulemper: Stor mengde med kvalitative data kan være vanskelig å analysere Bruker og konsulent misforstår hverandre. Bruker vet ikke hva han trenger, eller greier ikke å forklare det.

Prototyping Initial versjon av systemet. Fokuserer på uklare krav. Fordeler Redusere misforståelser. Vise at løsningen er mulig. Ulemper Gir ikke et komplett bilde av systemet. Fristelse til å levere prototypen som komplett system. Ikke-funksjonelle krav dekkes dårlig.

Brukstilfeller Tekstlig beskrivelse som forteller hvordan Aktør(brukeren) samhandler med systemet Utgangspunkt for å finne brukstilfeller. Typisk skrevet i en brukerens språk. Eksternt syn på systemet. Fordeler Kontrakt mellom kunde og utvikler. Brukerens syn på systemet, sikrer at rett system blir utviklet. Identifisere systemets avgrensing. Ulemper Eksternt syn på kravene vs internt syn på løsningen. Beskrivelsene kan bli komplekse og ”uhåndterlige”.

Observasjon Observerer hvordan brukeren samhandler med eksisterende system Motivasjonsfaktor : Mye er vanskelig å forklare. Fordeler Påvirker brukeren mindre Ulemper Nåværende system, ikke nye løsninger. Vanskelig å strukturere kunnskapen som observatøren får( i hodet, notater, video). Forutsetter kompetanse på området som skal observeres.

Andre innsamlings teknikker Gjenbruk av krav Mye å spare på gjenbruk av krav, ofte opptill 50% Questionnaires Effektiv måte å samle inn informasjon/spørsmål fra et stort antall personer. Group Elicitation Techniques Fokus på grupper, brainstorming. “Hard Data” Collection Fakta og modeller, rapporter. Goal-based Approaches Mål med systemet, visjon. Scenario Beskriver interaksjonen (stimulus -respons) mellom bruker og system.