Forelesning IMT2243

7. Februar 2006

Tema : Kravspesifisering : produktet og prosessen Viewpoint – en ”myk” tilnærming, gunstig i den

innledende runde med brukerkrav Tradisjonell analysemetode : Strukturert Analyse

En arbeidsmetode som går dypere inn i spesifiseringen

Pensum : Kap. 7 i Sommerville,

Art.saml. ”SASD-modellen”

Kravspesifisering

Kravspesifisering = arbeidet med å få frem en beskrivelse av oppdragsgiverens

/ kundens samlede krav til den nye programvaren på en strukturert, oversiktlig

og forståelig måte. Beskrivelsen skal være på en form som blir forstått av de

som skal utvikle løsningen.

Målformuleringern i emnebeskrivelsen viser at dette temaet er svært

sentralt i emnet :

”Studentene skal ha forståelse for grunnleggende administrative og

teknologiske aspekter ved spesifisering, utvikling, innføring og

vedlikehold av datasystemer.  De skal være i stand til å reflektere

over IT-systemenes betydning for verdiskapningen i virksomheter

og ulike tilnærmingsmåter i systemutviklingsprosesser. De skal

kunne anvende metoder og teknikker for kravspesifisering og

analyse. ”

KravspeksifikasjonenVed utarbeidelsen av kravspesifikasjonsdokumentet står man overfor en avveining mellom å lage beskrivelser som er lesbare for mange

interessenter og relativt raske å sette opp anvende strengt formalistiske spesifikasjonsteknikker

som gir utvetydige krav

Svært ofte praktiserer man bruk av ”Strukturert naturlig språk” i kombinasjon med anvendelse av enkelte grafiske notasjoner innen deler av spesifikasjonen.

Forts. Kravspesifikasjonen

Kravspesifikasjonsdokumentet bør dekke : Funksjonelle krav Ikke-funksjonelle krav (operasjonelle) Grensesnitt mot brukere, andres systemer og enheter Avgrensninger

Dokumentet er sentralt som : Beslutningsgrunnlag for evt. videreføring av prosjektet. Vedlegg til en kontrakt mellom kunde og leverandør Utgangspunkt for alt designarbeid. I design finner man

ut ”HVORDAN” beskrivelsene i kravspesifikasjonen best løses.

Grunnlag for all testing (Planlegging, Utforming, Gjennomføring og oppfølging)

Kravspesifiseringsprosessen

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Involverte i prosessen

Det er mange involverte parter i selve analysearbeidet

- sluttbrukere, utviklere, ledere, leverandører

- en analyseekspert bør ”dra i trådene”

De involverte har et sterkt varierende forhold til og kunnskap om data

Stor variasjon i motivasjonen hos deltagerne

Arbeid i grupper, kombinert med individuell forberedelse

Kreativitet innen et strukturert rammeverk en utfordring

Viewpoints – en “myk” spesifiseringsmetode

En arbeidsmetode der man forsøker å finne flest mulige aktuelle perspektiver på den nye løsningen

For hvert viewpoint (perspektiv) forsøker man å identifisere dette viewpointet’s krav til programvaren

God måte å få i gang arbeidet på, da fokusen er så intuitiv at alle kan delta konstruktivt uten ”forkunnskaper”

Fremgangsmåte for Viewpoints

1. Identifisere ulike viewpoints

2. Strukturere viewpoints Gruppere i viewpoint Avdekke overlapp og konflikter i viewpoints Lage hierarki

3. Dokumentere med viewpointbeskrivelser

Metoden egner seg som en oppstart før man går dypere inn i en Strukturert Analyse eller Objektorientert Analyse

Steg 1 : Identifisering

Brainstorming for å komme opp med ulike forhold rundt løsningen

Se etter interessenter, brukergrupper, tjenester, komponenter, personer, organisasjonsenheter, hendelser, tilstander osv. rundt systemet

Forsøk deretter å finne ut hvilke av disse som er viewpoints. Grupper / kategoriser også de andre ”idéene” som er dukket opp (ønskede tjenester, operative krav, komponenter, tilstander osv.)

Viewpoints identification

Querybalance

Gettransactions

Cashwithdrawal

Transactionlog

Machinesupplies

Cardreturning

Remotesoftwareupgrade

Ordercheques

Userinterface

Accountinformation

Messagelog

Softwaresize Invalid

userSystem cost Printe

r Security

Cardretention

Stolencard

Orderstatement

Remotediagnostics

ReliabilityUpdateaccount

Fundstransfer

Messagepassing

Cardvalidation

Customerdatabase

Manager

Accountholder

Foreigncustomer

Hardwaremaintenance

Bankteller

Steg 2 : Strukturering

Gruppér de ulike viewpoints, se etter overlappinger

Knytt de aktuelle tjenester til det enkelte viewpoint

Gi en kortfattet beskrivelse av viewpointet

Sett opp et viewpoint-hierarki

Viewpoint service information

FOREIGNCUSTOMER

Withdraw cashQuery balance

Service list

Withdraw cashQuery balanceOrder chequesSend messageTransaction listOrder statementTransfer funds

Service list

Run diagnosticsAdd cashAdd paperSend message

Service list

ACCOUNTHOLDER

BANKTELLER

Detaljert kravanalyse

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

Metodebruk i analysen

Vi skal gjennomgå to hovedretninger av metoder til bruk i

analysefasen :

Strukturert Analyse (SA)

Objektorientert Analyse (OOA)

Metodebruk ”strammer inn” arbeidet i analysefasen, og

brukt riktig vil resultatet bli en økt forståelse for oppgaven

og et bedre spesifikasjonsdokument for hva som skal

inngå i løsningen.

Strukturert analyseMetoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser under spesifiseringsarbeidet.

SA ble utformet på en tid der fossefall-modellen hadde utstrakt anvendelse, og man ofte hadde rasjonalisering som hovedmål ved utvikling av nye IT-systemer.

Metoden er fortsatt relevant å anvende i spesifiseringsarbeid spesielt når man arbeider etter en sekvensiell utviklingsmodell. Særlig gjelder dette utvikling av ”funksjonsfokuserte” og transaksjons-orienterte løsninger der kravene er stabile over tid.

Strukturert analyse

Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller/beskrivelser : Dataflytdiagrammer DataDictionary Datamodeller Strukturert språk (Structured Definition Language) Beslutningstrær

SA er en funksjonsorientert metode :

- finne funksjonene i systemet

- kartlegge informasjonsflyten rundt funksjonene

Eksempel på en SYSTEMMODELL :

Klient

Kontoransatt

Tannlege

1. Registereklient

2. Mottatimebestilling

Klientregister

4. Genereredagsrapport

Klinikkdata

5. Registrereklinikkinfo 3. Generere

tjenestestatistikk

Timeregister

Timeforespørsel

Personalia

Klientinfo

KlientkodeTimer_idag

Kapasitet

Klinikkinfo

Klinikkinfo

Tjenesterapportgrunndata

Tjenesteliste

Timehistorikk

Tjenesteforespørsel

Dagsforespørsel

Dagsinforamsjon

Dagsrapportgrunndata

Timetilbakemelding

DataFlytDiagram

En teknikk (innen Strukturert Analyse) som benyttes til

å lage en systemmodell

Funksjoner

Informasjonsflyt

Omgivelser

Tegning av DFD er den første og mest sentrale

aktiviteten i en Strukturert Analyse

En systemmodell representert i et DFD gir en god

oversikt og er forståelig for alle

DFD

Prosess (funksjon)

Bearbeider/manipulerer input om til output

En prosessboble for hver funksjon i systemet

Navngis ut fra hva den ”gjør”

DFD

Dataflyt (informasjonsflyt)

Viser hvordan data/informasjon flyter i systemet.

Vi fokuserer på logiske modeller og flyt av modeller. DFD

anvendes også til å vise flyt av ”fysiske elementer”.

Modellen viser ikke rekkefølgen på flytene, bare retning

Navngis

Detaljspesifiseres i DataDictionary

DFD

Datalager / register

Viser en samling av data som må ligge lagret i systemet

Viser ikke hvordan dataene skal lagres

Dataene ligger passive inntil de blir kalt opp

Unngå registre uten ”inn” og ”ut” flyt

Lengst mulig ned i DFD-strukturen

DFD

Terminator / Ekstern enhet

Viser kilder til / mottaker av informasjonsflyt i vårt system Kan være roller, interessenter, andre systemer etc.

Nivåhåndteringen i DFD Kontekstdiagram

Viser omgivelsene til vårt system. Sentral informasjonsflyt

til og fra systemet modelleres, og vil bidra til å klarlegge

kravene til alle eksterne grensesnitt for vår løsning

Nivå 0

Bryter ”systemboblen” fra kontekstdiagrammet ned i

enkeltprosesser som samlet viser den sentrale funksjonalitet i

systemet.

DFD x (tall fra 1 - ..)

Er en detaljering av de mer komplekse dataprosessene på

nivå 0

Tips ved utarbeidelse av DFD

1. Hold modellen på en side

2. Velg gode og meningsfulle navn

- roller fremfor navn

- navn på prosess = et verb + et objekt

3. Ikke lag modeller med mange elementer

- mindre enn 10 prosesser

- få registre (vi driver IKKE databasedesign her)

4. Ikke forsøk å ”si alt” med modellen, vis det viktige

- lesbart og forståelig

Stegene videre innen Strukturert Analyse

Gå ikke videre med de andre teknikkene før dere

har utarbeidet gode DFD’er på flere nivåer

I de påfølgende stegene anvendes teknikker som : Data Dictionary – settes opp på Registre og Informasjonsflyter

Strukturert Språk som detaljspesifiserer hver Prosess

Beslutningstabeller som detaljspesifiserer beregninger etc.

Datamodell (Semantisk) som viser forhold mellom

informasjonselementer