Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Software Requirements Elicitation. Identifisering av krav Etter feasibility study så kommer Identifisering av krav som neste steg i requirements engineering.

Liknende presentasjoner


Presentasjon om: "Software Requirements Elicitation. Identifisering av krav Etter feasibility study så kommer Identifisering av krav som neste steg i requirements engineering."— Utskrift av presentasjonen:

1 Software Requirements Elicitation

2 Identifisering av krav Etter feasibility study så kommer Identifisering av krav som neste steg i requirements engineering prosessen. 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: Vi kan sette i gang med identifisering av krav når: A statement of work (SOW) er mottatt av kunden.A statement of work (SOW) er mottatt av kunden. Kunden er identifisertKunden er identifisert Vi har opprettet forbindelse med interessentene for prosjektet.Vi har opprettet forbindelse med interessentene for prosjektet. Vi samler inn krav for å få svar på: Vi samler inn krav for å få svar på: Hvilket/hvilke problem som må løsesHvilket/hvilke problem som må løses Hvor problemet liggerHvor problemet ligger Hvem som er eier av problemetHvem som er eier av problemet Hvorfor det trenger en løsningHvorfor det trenger en løsning Hvordan et programvaresystem kan hjelpeHvordan et programvaresystem kan hjelpe Når en løsning må foreliggeNår en løsning må foreligge Hva som kan hindre en løsningHva som kan hindre en løsning Involvert i kravidentifisering: Sluttbruker, ledere, utviklere som er involvert i vedlikehold, domeneeksperter, fagforeninger osv. Involvert i kravidentifisering: Sluttbruker, ledere, utviklere som er involvert i vedlikehold, domeneeksperter, fagforeninger osv.

3 Vanskeligheter ved elicitation Kunnskapen kan være distribuert mellom mange kilder Kunnskapen kan være distribuert mellom mange kilder Det kan oppstå konflikt mellom kunnskap fra forskjellige kilder Det kan oppstå konflikt mellom kunnskap fra forskjellige kilder Folk kan ha problem med å beskrive kunnskap de sjelden bruker 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. 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 har ikke tillatelse til å fortelle det du trenger å vite Folk vil ikke fortelle deg det du trenger å vite. Folk vil ikke fortelle deg det du trenger å vite.

4 ”Ved å bedre requirements elicitation, bedrer man hele prosessen rundt requirements engineering, noe som vil resultere i et bedre system!”

5 Noen innsamlings teknikker Intervju Intervju Prototyping Prototyping Brukstilfeller Brukstilfeller Observasjon Observasjon

6 Intervju Typer: Typer: –Strukturert: forhåndsdefinerte spørsmål –Ustrukturert: åpne spørsmål Viktig å rettlede brukeren/kunden på riktig spor Viktig å rettlede brukeren/kunden på riktig spor Fordeler: Fordeler: –Rikholdig samling av informasjon Ulemper: 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.

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

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

9 Observasjon Observerer hvordan brukeren samhandler med eksisterende system Observerer hvordan brukeren samhandler med eksisterende system Motivasjonsfaktor : Motivasjonsfaktor : –Mye er vanskelig å forklare. Fordeler Fordeler –Påvirker brukeren mindre Ulemper 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.

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


Laste ned ppt "Software Requirements Elicitation. Identifisering av krav Etter feasibility study så kommer Identifisering av krav som neste steg i requirements engineering."

Liknende presentasjoner


Annonser fra Google