Systemutvikling - Modellering av krav

Flashcards som dekker sentrale begreper innen smidig metodikk, kravspesifisering og UML-diagrammer (use case, domenemodell, sekvensdiagram og aktivitetsdiagram).

Kaizen

Et Lean-prinsipp fra den japanske skolen (Toyota) som innebærer kontinuerlig læring og forbedring for å styrke helheten fremfor å suboptimalisere.

Just-in-time-prinsippet

Et prinsipp som innebærer at man ikke lager noe før det etterspørres, basert på et sug («pull») etter nye leveranser i stedet for pådytting («push»).

Funksjonelle krav

Krav som beskriver hva systemet skal gjøre, hvilke tjenester og funksjoner det skal tilby, samt hvordan det skal reagere på ulik input.

Ikke-funksjonelle krav

Krav som beskriver hvordan systemet skal implementere og ivareta de funksjonelle kravene (for eksempel krav til ytelse, brukervennlighet, organisatoriske eller eksterne rammer).

Forretningskrav

En kategori funksjonelle krav som beskriver hva organisasjonen overordnet ønsker å oppnå.

Brukerkrav

Krav som beskriver hva brukerne har behov for eller ønsker å kunne gjøre ved hjelp av systemet.

Systemkrav

En mer detaljert definisjon av hva som faktisk skal implementeres i systemet, sett fra brukernes perspektiv.

Sporbarhet (Traceability)

Egenskapen ved krav som sikrer at man vet nøyaktig hvilken del av arkitekturen, designet og koden som påvirkes eller må endres ved nye eller reviderte krav.

UML (Unified Modeling Language)

Et standardisert modelleringsspråk bestående av struktur- og oppførselsdiagrammer for spesifisering, visualisering og dokumentasjon av systemer.

Interessent (Stakeholder)

Enhver part som berøres av eller har en interesse i systemet, slik som oppdragsgivere, brukere, utviklere, systemeiere, myndigheter og eksterne systemer.

Aktør

En rolle som et menneske eller et annet system har når det kommuniserer direkte med systemet og har et mål med bruken.

Primær aktør

En aktør som har et eget mål med systemet, og som initierer ett eller flere use case for å oppfylle dette målet.

Sekundær aktør

En aktør som ikke har egne mål med systemet, men som er nødvendig for å bistå eller realisere målene til de primære aktørene.

Use case (bruksmønster / brukstilfelle)

En beskrivelse av hvordan systemet oppnår et mål av verdi for en aktør, formulert som en komplett, testbar funksjonell enhet («one person – one place – one time»).

Hovedløp (Hovedflyt)

Den standardiserte og ideelle hendelsesflyten i et use case der aktørens mål oppnås uten feil eller avvik.

Alternativ flyt

Tilleggsløp i et use case som beskriver hvordan systemet håndterer avvik, feilsituasjoner eller alternative stier til målet fra et gitt steg i hovedløpet.

Include-relasjon («include»)

En use case-relasjon der et basis use case trekker inn og gjenbruker felles funksjonalitet eller steg som er skilt ut i et eget use case.

Extend-relasjon («extend»)

En use case-relasjon der et use case beskriver en valgfri tilleggsoppførsel eller et tilleggsresultat som kobles på et basis use case under gitte betingelser.

User story (brukerhistorie)

En kort og uformell kravformulering tilpasset smidig utvikling, vanligvis strukturert etter formen: «Som en [rolle] ønsker jeg [funksjon] slik at [verdi]».

Domenemodell

Et klassediagram uten metoder som definerer forretningsdomenes sentrale begreper, objekter, attributter og assosiasjoner for å etablere en felles terminologi.

Sekvensdiagram

Et interaksjonsdiagram som viser kronologisk rekkefølge og meldingsutveksling (metodekall) mellom objekter for en bestemt flyt i et use case.

Aktivitetsdiagram

Et atferdsdiagram som viser forretningsprosesser eller trinnvis hendelsesflyt i et use case gjennom aktiviteter og beslutningspunkter (diamanter).

Prebetingelse (Precondition)

En forutsetning eller tilstand som må være oppfylt og sann før et gitt use case kan igangsettes (f.eks. at kunden er innlogget).

Postbetingelse (Postcondition)

Tilstanden systemet og dets omgivelser må befinne seg i etter at utførelsen av et use case er avsluttet (f.eks. at en regning er registrert betalt eller avbrutt).