Kravställning för grc systemstöd

Kravställning för GRC-
systemstöd
Christian Hekmati och Christoffer Paulsson
GRC 2016, 19 maj

Innehåll
• definition av krav
• varför behövs
kravhantering?
• lärdomar från kravställning
för GRC-systemstöd
• summering
©TranscendentGroupSverigeAB2016

Definition av krav

Definition av krav
• Beskriver vad en organisation önskar göra för att realisera
sitt verksamhetsbehov.
Problem
• Ett förslag på lösning avseende en organisations
verksamhetsbehov.
Lösning
• En konstruktion av mjukvara, hårdvara eller annat som
realiserar en organisations verksamhetsbehov.
Produkt

Definition av krav
• Vi behöver reducera våra telefonikostnader.
Problem
• Använd VoIP-teknik
Lösning
• Skype for Business (Lync)
Produkt

Enligt IEEE 6101 definieras krav som:
1) Ett villkor eller en egenskap som en intressent behöver för att
lösa ett problem eller uppnå ett mål.
2) Ett villkor eller en egenskap som ett system eller en
systemkomponent måste inneha för att uppfylla ett kontrakt, en
standard, en specifikation eller ett annat formellt styrande
dokument.
3) En dokumenterad förekomst av ett villkor eller en egenskap
beskrivet i (1) eller (2).
1 Standard Glossary of Software Engineering Terminology

Klassificering av krav
Krav
Produktkrav
Begränsnings-
krav
Funktionellt
Icke-
funktionellt
Verksamhets-
begränsningar
Tekniska
begränsningar

Exempel: Funktionellt vs. icke funktionellt
Systemet skall ge möjlighet till att
exportera all transaktionsdata i excel och
pdf-format.
All transaktionsdata upp till 100 MB skall
kunna exporteras inom 60 sekunder.
(prestanda).
Produktkrav
Funktionellt
Icke-
funktionellt

Exempel: verksamhets- vs. teknisk
begränsning
Interna resurser i projektteamet arbetar
utifrån normal arbetstid (9.00-17.00) och
är inte berättigade till övertid.
Systemet behöver vara kompatibelt med
databasserver MS SQL Server 2012 eller
senare.
Begränsnings-
krav
Verksamhets-
begränsningar
Tekniska
begränsningar

Abstraktionsnivåer för krav
©TranscendentGroupSverigeAB2016©TranscendentGroupSverigeAB2015
1. Verksamhetskrav
2. Lösnings-
/systemkrav
3. Produkt-
/komponentkrav
Kravledare
Organisation
Systemleverantör/-er

Varför behövs kravhantering?

Varför behövs kravhantering?
Utifrån vår erfarenhet är pragmatisk kravhanteringsprocess en viktig
framgångsfaktor vid införande av ett nytt systemstöd.
• otydliga verksamhetsmål för kraven eller
själva projektet
• otillräckligt intressentengagemang
• bristande planering
• bristande kvalitet hos kraven
• vaga kravformuleringar
• saknade intressenter
• otillräckliga krav- eller lösningsspecifikationer.
Utmaningar som
kan uppstå utan en
fungerande process
för kravhantering är:

Kravkvalitet
För att kvalitetssäkra krav
kan organisationer utgå
ifrån följande kriterier:
Krav-
kvalitet
Korrekt
Genom-
förbart
Nödvändigt
Prioriterat
Entydigt
Verifierbart
Unikt
Design-
oberoende

Kvalitetskriterium: korrekt
Kravet måste på ett specifikt sätt
beskriva de funktioner som ska
tillhandahållas. Referenspunkten
för att bedöma korrektheten är
källan till kravet (till exempel en
intressent i projektteamet).

Kvalitetskriterium: genomförbart
Kravet måste vara möjligt att
utföra inom ramen för känd
kapacitet och/eller
begränsningar för systemet och
miljön.

Kvalitetskriterium: nödvändigt
Kravet ska beskriva vad en
organisation (eller andra
intressenter) verkligen behöver
och vad som behövs för att
uppfylla ett externt krav eller en
specifik standard.

Kvalitetskriterium: prioriterat
Kravet ska tilldelas en prioritet
som indikerar hur viktigt det är
för organisationen (need to have
vs. nice to have).

Kvalitetskriterium: entydigt
Kravet ska bara kunna tolkas på
ett sätt, det vill säga att olika
läsare ska kunna tolka och förstå
kravet på samma sätt.

Kvalitetskriterium: verifierbat
Det ska gå att verifiera att kravet
har implementerats korrekt.

Kvalitetskriterium: unikt
Kravet ska inte innehålla flera
krav. Detta kräver tillräcklig
detaljering för att specificera ett
enskilt krav.

Kvalitetskriterium: designoberoende
Kravet ska beskriva vad som ska
göras, inte hur det ska göras.
Innehållet i ett krav ska inte
föreskriva eller antyda
implementeringsdetaljer.

Lärdomar från kravställning för
GRC-systemstöd

Lärdom #1 – förvirring kring begreppet
krav
Indikator Lösning
• Projektets intressenter hänvisar till
krav vilka saknar tydliga begreppet
som beskriver kravet.
• Utbilda alla projektdeltagare i ett
tidigt skede kring krav, terminologi
och metoder för kvalitetssäkring.

Lärdom #2 – otillräckligt
intressentengagemang
Indikator Lösning
• Nyckelintressenter involveras inte
vid utformning av systemet.
• Avsaknad av process för validering
(producerar vi rätt produkt?) och
verifiering (producerar vi produkten
rätt?).
• Utse och tydliggör förväntningar på
kravledaren som identifierar och
säkerställer deltagande samt
återkoppling från nyckelintressenter.
• Etablera en gemensam process för
validering och verifiering.

Lärdom #3 – vaga och ambitiösa
kravformuleringar
Indikator Lösning
• Tvetydighet uppstår när flera
intressenter tolkar ett krav på olika
sätt.
• Utgå ifrån kvalitetskriterierna för
krav (se ovan).

Lärdom #4 – avsaknad av prioritering
Indikator Lösning
• En stor andel av kraven (till exempel
80 %) är definierad med hög
prioritet.
• Definiera vägledande principer för
vad som anses vara hög, medel, låg
prioritet.

Lärdom #5 – Otillräcklig
konsekvensanalys vid kravförändringar
Indikator Lösning
En kravförändring kan:
• vara mer komplicerad än väntat
• ta längre tid än planerad
• vara tekniskt (eller ekonomiskt)
ohållbart
• vara i konflikt med andra krav.
• Etablera en systematisk process för
analys av effekterna vid varje
föreslagen kravförändring.

Summering

Kravställning för grc systemstöd

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Kravställning för grc systemstöd

Similar to Kravställning för grc systemstöd (20)

More from Transcendent Group

More from Transcendent Group (9)

Kravställning för grc systemstöd