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

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Definition av krav

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Definition av krav

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

• 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).

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

1 Standard Glossary of Software Engineering Terminology

Klassificering av krav

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Krav

ProduktkravBegränsnings-

krav

FunktionelltIcke-

funktionellt

Verksamhets-

begränsningar

Tekniska

begränsningar

Exempel: Funktionellt vs. icke funktionellt

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

©

Tra

nsc

en

den

t G

rou

p S

veri

ge A

B 2

015

1. Verksamhetskrav

2. Lösnings-/systemkrav

3. Produkt-/komponentkrav

Kravledare

Organisation

Systemleverantör/-er

Varför behövs kravhantering?

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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:

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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).

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Kvalitetskriterium: prioriterat

Kravet ska tilldelas en prioritet

som indikerar hur viktigt det är

för organisationen (need to have

vs. nice to have).

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Kvalitetskriterium: verifierbat

Det ska gå att verifiera att kravet

har implementerats korrekt.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Kvalitetskriterium: unikt

Kravet ska inte innehålla flera

krav. Detta kräver tillräcklig

detaljering för att specificera ett

enskilt krav.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Lärdomar från kravställning för

GRC-systemstöd

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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).

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

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.

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

Summering

© T

ran

scen

den

t G

rou

p S

veri

ge A

B 2

016

www.transcendentgroup.com