Kravspek: Mål-orientering

Transkript

1 Kravspek: Mål-orientering Guttorm Sindre, IDI Mål-orientert kravmodellering Utgangspunkt: mål (som er mer abstrakt enn krav) F.eks forretningsmål for organisasjonen Fokuserer på HVORFOR et system skal lages (krav: HVA, design: HVORDAN) bedre forståelse av behov bedre struktur på kravene Spesifikke krav knyttes til mål som de understøtter 3 artikler to ulike metoder for mål-orientert analyse Mylopoulos/Chung/Yu: softgoals Antón: GBRAM et praktisk case-studium med GBRAM og use cases Mylopoulos/Chung/Yu From Object-Oriented to Goal-Oriented Requirements Analysis Communications of the ACM, jan 1999 Motivasjon OOA populært, Stort fremskritt stemmer ikke med [Davis95], men sammenlign m DFD Integrerer mange ulike uttrykksformer Generalisering og aggregering Modell av problemområdet, eks. Fig 1 Men svakheter særlig mhp ikke-funksjonelle krav dårlig behandlet av eksisterende teknikker dårlig tilfredsstilt i mange prosjekter Løsning: mål-orientering (softgoals) Få med både funksjonelle og ikke-funksjonelle krav tidlig, og på en strukturert måte Hvordan bruke softgoals? Eks., kontorstøttesystem OOA, kan modellere personer, arbeidsoppgaver, informasjonsobjekter som det jobbes med, etc. Men krav om anvendbarhet, fleksibilitet o.l. passer ikke inn i noe spesielt objekt Softgoals kan representere Ikke-funksjonelle krav / målsetninger Og relasjoner mellom slike Hvorfor soft? Mål i AI: klare logiske kriterier, true når alle sub-mål er tilfredsstilt, ellers false Ikke-funksjonelle krav: trenger løsere kriterier, satisficed vs unsatisficeable Relasjoner mellom softgoals (Tabell 1) AND (G, {G 1,..., G n } ) G tilfredsstilt hvis alle submål G 1,..., G n er tilfredsstilt og det ikke fins negative indisier mot det G kan ikke tilfredsstilles hvis ett submål G 1,..., G n er utilfredsstilt og det ikke fins positive indisier for det OR (G, {G 1,..., G n } ) G tilfredsstilt hvis ett submål G 1,..., G n er tilfredsstilt og det ikke fins negative indisier mot det G kan ikke tilfredsstilles hvis ingen submål G 1,..., G n er tilfredsstilt og det ikke fins positive indisier for det + (G 1, G 2 ) G 1 bidrar positivt til G 2 (G 1, G 2 ) G 1 bidrar negativt til G 2 1

2 Ikke-funksjonell kravanalyse Interessentene blir enige om ikke-funksjonelle krav (eller mål, f.eks Anvendbarhet, Fleksibilitet) Disse modelleres som softgoals Jfr. Flexibility i Fig 2 Hvert overordnet softgoal detaljeres til et måltre Alt under Flexibility i Fig 2 Se på måltrær for ulike softgoals finn overlapp og konflikter (sorte piler i Fig 2) Velg løvnode-mål som skal tilfredsstilles Dette er prosjektets design-avgjørelser Hvilke høyere mål som er tilfredsstilt finnes utifra dette Funksjonell kravanalyse Kan også støttes av softgoals, jfr Fig 3 ScheduledMeeting dekomponeres i lavere mål Relasjoner ikke-funksjonelle funksjonelle Mulige konflikter, mulig støtte Også her valg av løvnoder Oppsummering Mål-orientering bedre enn OO mhp kravspek Mer krav-orientert syn på verden Enklere å få med ikke-funksjonelle krav Fokus på beskrivelse og evaluering av alternativer Bedre sporbarhet Mulighet for gjenbruk av domenekunnskap i form av målstrukturer? OO fremdeles relevant i sene stadier av kravanalysen virker fint sammen med mål-orientering I fremtiden: mål-orientert design/programmering? ~ agent-orientert programmering, økende interesse Annie I. Antón Goal-Based Requirements Analysis Method Proc. ICRE 96 Innledning Oversikt Intro til mål-orientering Analyse og evolusjon av mål Erfaringer med GBRAM Diskusjon / Konklusjon Intro til mål-orientering Forteller HVORFOR Noen likheter med viewpoints Viktige spørsmål Hvordan identifisere mål? Hva skjer med kravene hvis mål endrer seg? Analyse av mål (1) : konsepter Mål: hva virksomheten ønsker å oppnå Krav : hvordan et mål skal oppnås av et system Operasjonalisering: detaljering i presise submål Oppnåelsesmål: noe som skal gjøres Vedlikeholdsmål: betingelse holdes sann Agent: rolle/enhet/system m ansvar for mål Begrensninger: krav mhp måltilfredsstillelse Mål-dekomponering: submål-struktur Scenarier: eks. på handlingssekvenser Mål-hindringer: mål / oppførsel som står i veien for andre mål 2

3 Analyse av mål (2): prosessen Mål kan finnes fra trad. modeller (DFD, ER,...) setninger som forårsaket designavgjørelser Slike modeller ikke tilstrekkelige alene Andre kilder, f.eks intervjuer med interessenter Tendens til å snakke operasjoner, ikke mål Må derfor omforme til målbeskrivelser Identifiser ansvarlige agenter for hvert mål Begrensninger finnes ofte ved temporale konnektiver avhengighetsrelasjoner Evolusjon av mål Betyr her både endringer ifbm detaljering senere endring av behov (mål / prioritering) Interessante teknikker: Identifisere mål-hindringer, pre- og postbetingelser Scenarier for å evaluere nye prioriteter Forening av overlappende mål, fjerne redundans Kategorisering i submål Produserer et sett av mål-skjema Operasjonaliserte mål, agenter, interessenter, begrensninger og scenarier Kan lett overføres til en kravspek, gir en strukturering av kravene ihht mål Erfaringer med GBRAM fra case-studie Analyserte mål (36) for Career Track Training System (CTTS) på en flybase (AFB) Ingen annen kravanalyse var utført før studien Utgangspunkt skriftlig dokumentasjon av nåværende prosesser, still spørsmål a la: Hvilke(t) mål eksemplifiserer dette setningen? Hvilke(t) mål forhindrer denne setningen? Identifiserte mål, besvar spørsmålet: Hvilken tilstand / betingelse er sann etterpå? Skill oppnåelses- og vedlikeholdsmål, jfr Tab 1 og 2 Erfaringer (forts.) Oppnåelsesmål Gjerne funnet fra prosessbeskrivelser Interessante spørsmål: Er oppnåelse av målet selv - inneholdt?, Uttrykker målet en tilstand som er oppnådd, eller som ønskes oppnådd?, Er oppnåelse avhengig av andre mål? Vedlikeholdsmål Finnes i organisasjonsnivå-beskrivelser, policydokumenter Interessante spørsmål: Uttrykker målet en betingelse som må være sann gjennom alle andre måls operasjonaliseringer?, Er kontinuerlig oppnåelse av målet påkrevd? Identifikasjon av agenter og interessenter Erfaringer (forts.) evolusjon av mål Reduser # mål, gjør mål klarere Eliminer dupliserte mål, forén nesten synonyme mål Raffiner mål basert på system-entiteter #oppnåelsesmål: Bruk begrensninger til å finne mål, Tab 3 Detaljering av mål: presedensrelasjoner (Tab 4) Hvilke mål kommer forut for dette? / etter dette? Agentavhengigheter Identifisering av mål-hindringer, Tab 5 Kan mislighold av et annet mål også hindre dette? Hvilke mål kommer forut for dette? Evolusjon (forts.) Identifisere scenarier, Tab 5 Mål-hindringer: hvordan mål kan feile Scenarier: mer detaljert, omstendighetene Interessante spørsmål: Hvorfor oppsto denne målhindringen?, Under hvilke omstendigheter kan den oppstå? Bidrar til å avsløre skjulte mål og hindringer Bestemme post-betingelser: Hva skjer hvis målet ikke blir oppnådd? Operasjonalisering av mål Målskjema, Fig 1 Spesifisering av aksjoner, like under Fig 1 3

4 Diskusjon / Konklusjon Erfaringer Flere kilder gir bedre mål Interessenter gir innsikt i synspunkter Diversitet i målinformasjon gir et rikt bilde Kategorisering av mål til hjelp for operasjonalisering Begrensninger hinter om krav og nye mål Unntak ses via mål-hindringer Scenarier avdekker skjulte spørsmål Fremtidig arbeid Videreutvikle metoden, lage verktøystøtte Prøve ut i flere prosjekter, primært e-handel Antón / Dempster / Siege Deriving Goals from a Use-Case Based Requirements Specification for and Electronic Commerce System RE Journal, mai 2001 Motivasjon Scenarier / use cases økende popularitet + effektivt for å få fram mål under analyse + stimulere tenkning, kontrollere endringer sporbarhet over flere endringer komplisert svak prosess-støtte Kobling GBRAM use cases bidra til å strukturere og spore scenarier? Utprøving i praktisk setting Evaluering av GBRAM med utvidelser Evaluering av måten kravspek var gjort på i prosjektet Analyse og evolusjon av mål Utgangspunkt: e-handelsapplikasjon Kravspek (~ seksjon 1 og 2 ihht IEEE std 830) 26 skjermbildedesign 52 use cases innh.: Id, tittel, oversikt, revisjonshistorie pre- og postbetingelser, hovedscenario, alternativer ref GUI, ref andre use cases (includes, extends) Innledningsvis: definerte 292 mål Mål gruppert i predefinerte kategorier, Fig 1 Eliminerte 100 av 292 mål redundante, implementasjonsspesifikke, etc. Utfordringer, risk Kontekst ikke åpenbar for use case Årsak: Indiv. forskjeller i skrivestil, implisitt kunnskap Risk: krav misforstås Løsning (gjort): uttrykke tittel som et mål use case forfattere brukere Årsak: tidspress?? Risk: forenklede antagelser, ingen validering, inkomplette krav Løsning (tenkt): involvere brukere mer tung sporbarhet Årsak: metode, verktøystøtte, inkonsistent spesifikasjon Risk: sporbarhet droppes eller blir rent statisk Løsning (tenkt): bedre verktøystøtte Utfordringer, risk (forts.) use cases inspirert av eksisterende GUI Årsak: tidspress? Forfattere også GUI-designere Risk: fokus på design/implementasjon i analysen Løsning (tenkt): unngå dette feil / inkonsistent navngiving av use cases Årsak: manglende use cases / feil navn Risk: inkomplette krav, uoppdagede konflikter Løsning (tenkt): unngå dette 4

5 Erfaringer Kategorier av oppnåelsesmål (jfr Fig 1) ACHIEVE: noe brukeren skal oppnå MAKE: noe systemet skal oppnå Ga mer komplett sett av mål og synspunkter Mer presis def av automatiseringsgrense Domenespesifikke målklasser Prosess-støtte, e-handel, info visning, sikkerhet Ga bedre kompletthet Avslørte at antall sikkerhetskrav var mistenkelig lite Navngiving av mål ihht begrensninger Bidrar til å se kontekst Erfaringer (forts.) Skille mellom ulike kategorier av mål NOTIFY og INFORM: levere info til en aktør PROVIDE og ALLOW: tjeneste, funksjon Gjør klar problemoppdeling lettere Samling av use cases ikke fullgod kravspek Men forekommer ofte, pga tidspress Kravspek bør uttrykke krav, presist og testbart use cases gjør ikke alltid dette GBRAM nyttig avdekke inkonsistens og mangler i kravspek Forbedre sporbarhet 5