krav Flashcards

1
Q

Vilken kravnivå man väljer beror i huvudsak
på den specifika leverantörsnivån

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Intressenter är personer eller roller som direkt
eller indirekt påverkas av systemet

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Projekttypen påverkar sällan
ansvarsfördelningen mellan intressenter

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Följande krav:
R1: 95% av användarna ska anse att systemet
är lätt att använda
är mer riskfyllt för leverantören än för kunden

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Användbarhetsproblem är ofta mer oväntade
än programmeringsproblem

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

I en heuristisk utvärdering låter man en
slutanvändare utan tidigare kunskap om
systemet utvärdera systemet.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Estimering på ratio-skala innebär parvis
jämförelse på graderad skala

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Fördelar med dynamiska modeller av vad
användaren gör, är att de hjälper till att
strukturera krav och stödjer spårbarhet.

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Enligt Moores modell är kunderna i den sena
majoriteten (late majority) pragmatiska,
försöker undvika andras misstag och vill se
goda referenser

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Följande krav:
R1: Leverantören ska påbörja felrättning
inom 24 timmar efter upptäckt.
är mer riskfyllt för leverantören än kunden

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Parvisa jämförelser innebär högst en
jämförelse per krav

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Följande krav:
R2: Nybörjare ska kunna genomföra uppgift A
och B på mindre än 15 minuter, erfarna
användare på mindre än 2 minuter
är mer riskfyllt för leverantören än kunden

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Följande krav:
R3: Systemet ska följa stilguide xx.
är mer riskfyllt för leverantören än kunden

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Marknadsdriven kravhantering innebär få
konkurrenter, ofta mindre formella
specifikationer och liten närhet till kunderna.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Card Sorting, Laddering och Scenario-analys
är exempel på prioriteringstekniker

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Kvalitetskrav slår sällan tvärs över många
funktioner.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Granskning ad hoc innebär att man följer
givna riktlinjer.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Kvalitetsaspekter motverkar ofta varandra så
som ökad säkerhet kan ge minskad
användbarhet

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Noggrannhet (accuracy), Autencitet
(authenticity) och integritet (integrity) är
kvalitetsegenskaper som ingår i säkerhet
(security)?

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Elicitering, analys och specifikation är de tre
första stegen i kravprocessen

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

I en heuristisk utvärdering låter man en
slutanvändare utan tidigare kunskap om
systemet utvärdera systemet.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav.

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Marknadsdriven kravhantering innebär få
konkurrenter, ofta mindre formella
specifikationer och liten närhet till kunderna

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Det är lämpligt att skapa ett kontextdiagram
mot slutet av ett projekt när implementationen
är komplett

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Det är oftast lämpligt att ta med både
domäninformation och illustrativa exempel i
anslutning till ett krav.

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

En uppgiftsbeskrivning bör leda till
uppfyllnad av ett mål

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Flera oberoende granskningar finner ofta färre
fel jämfört med en enda granskning

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Laddering är en valideringsteknik som skapar
förståelse för olika termer och som kan
användas som underlag för terminologi

A

nej

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Hårdvarukrav ska inte specificera vilka
komponenter som ska användas utan det är
funktionskraven som ska specificeras

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

SLUT+ Ö (CRUD + O) står för skapa, läsa,
uppdatera, ta bort, översikt (create, read,
update, delete, overview

A

ja

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Spårbarhet bakåt inom kravhantering innebär
att kraven kan spåras till kod, design och test

A

nej

33
Q

Generella mål och nyckelområden?

A

Intressentanalys

34
Q

Hitta nuvarande problem?

A

Observationer

35
Q

Ta fram förslag All framAda system

A

Fokusgrupper

36
Q

Finna realisAska möjligheter

A

Prototypframställning

37
Q

Avgöra prioriteter

A

Fokusgrupper

38
Q

Inkonsekvenser mellan olika krav

A

CRUD

39
Q

Spårbarhetsproblem

A

Strukturkontroll

40
Q

Missade krav

A

Mål-krav-spårning

41
Q

Läsbarhetsproblem

A

Strukturkontroll

42
Q

OrealisAska krav

A

Prototyptestning

43
Q

Förhandling (negotiation)

A

Prioriteter

44
Q

Mål-domän-analys (goal-domain analysis)

A

Fullständighet

45
Q

Brainstorming

A

Framtida systemidéer

46
Q

Intervju (interview)

A

Nuvarande arbete

47
Q

Mål-krav-spårning (goal–requirements tracing)

A

Missade krav?

48
Q

CRUD (skapa, läsa, uppdatera ta bort)

A

Läsbarhetsproblem

49
Q

Prototyptestning

A

Orealistiska krav?

50
Q

CRUD (skapa, läsa, uppdatera ta bort)

A

Inkonsekvenser mellan krav?

51
Q

Strukturkontroll (structure check)

A

Spårbarhetsproblem

52
Q

Prototyper (prototyping)

A

Realistiska möjligheter

53
Q

Vilken kravnivå man väljer beror i huvudsak
på typen av användargränssnitt

A

nej

54
Q

När man utvärderar ett systems användbarhet
försöker man undvika att ta hänsyn till
användarens subjektiva upplevelse

A

nej

55
Q

Heuristiska utvärderingar hittar ofta fler
verkliga problem jämfört med
användbarhetsutredningar

A

nej

56
Q

Krav på målnivå gör att leverantörer slipper ta
ansvar även för omstrukturering av
verksamheten kring produkten

A

nej

57
Q

Spårbarheten underlättas om målnivån är
produktorienterad.

A

nej

58
Q

För att kunna utföra ett användbarhetstest
krävs ett fungerande system.

A

nej

59
Q

Öppna mått (open metric) passar bra när man
vill överlåta åt leverantören att definiera hur
kvalitetskrav ska mätas.

A

ja

60
Q

En kravingenjör förväntas hjälpa
intressenterna att hitta realistiska och
kostnadseffektiva produkter.

A

ja

61
Q

Enligt Moores modell är kunderna i den tidiga
majoriteten (early majority) teknik glada och
är intresserade av att prova de nya teknikerna.

A

nej

62
Q

Kostnads/värde - relationer estimeras oftast
bättre genom relativa bedömningar än absoluta
siffror.

A

ja

63
Q

Följande krav:
R1: Tre prototypversioner ska göras och
användbarhetstestas under designen av systemet
är mer riskfyllt för leverantören än för kunden

A

nej

64
Q

Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav.

A

nej

65
Q

En fullständig kravspecifikation kan normalt
uppnås med en liten ansträngning

A

nej

66
Q

Följande krav:
R2: Leverantören ska tillhandahålla kvalificerad
supportpersonal.
är mer riskfyllt för leverantören än för kunden

A

nej

67
Q

Följande krav:
R3: 95 % av användarna ska anse att systemet
är lätt att använda.
är mer riskfyllt för leverantören än för kunden

A

ja

68
Q

Följande krav:
R4: Nybörjare ska kunna genomföra uppgift A och
B på mindre än 15 minuter, erfarna användare på
mindre än 2 minuter.
är mer riskfyllt för leverantören än för kunden

A

ja

69
Q

Om E/R-diagram är för svåra för
intressenterna att tolka kan man med fördel
komplettera med ett klassdiagram

A

nej

70
Q

Det är oftast lättare för en slutanvändare att
validera händelselistor (event lists) på
produktnivå jämfört med domännivå

A

nej

71
Q

Om E/R-diagram är för svåra för
intressenterna att tolka kan man med fördel
komplettera med virtuella fönster (virtual
windows)

A

ja

72
Q

Observationer (observations) passar bättre än
fokusgrupper (focus groups) vid elicitering av
prioriteter.

A

nej

73
Q

Prototypframställning (prototyping) passar
bättre än intressentanalys (stakeholder
analysis) vid elicitering av generella mål och
nyckelområden

A

nej

74
Q

Pilottest (pilot test) passar bättre än
strukturkontroll (structure check) för att hitta
spårbarhetsproblem.

A

nej

75
Q

CRUD (create, read, update, delete) passar
bättre än strukturkontroll (structure check) för
att hitta inkonsekvenser mellan olika krav

A

ja

76
Q

Prototyptestning (prototype test) passar bättre
än strukturkontroll (structure check) för att
hitta orealistiska krav

A

ja

77
Q

För uppgiftsbeskrivningar (task descriptions)
ska varje uppgift helst vara öppen så att
måluppfyllnaden blir flexibel

A

nej

78
Q

Virtuella fönster (virtual windows) ska inte
innehålla menyer och knappar.

A

ja

79
Q
A