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
Det är lämpligt att skapa ett kontextdiagram mot slutet av ett projekt när implementationen är komplett
nej
26
Det är oftast lämpligt att ta med både domäninformation och illustrativa exempel i anslutning till ett krav.
ja
27
En uppgiftsbeskrivning bör leda till uppfyllnad av ett mål
ja
28
Flera oberoende granskningar finner ofta färre fel jämfört med en enda granskning
nej
29
Laddering är en valideringsteknik som skapar förståelse för olika termer och som kan användas som underlag för terminologi
nej
30
Hårdvarukrav ska inte specificera vilka komponenter som ska användas utan det är funktionskraven som ska specificeras
ja
31
SLUT+ Ö (CRUD + O) står för skapa, läsa, uppdatera, ta bort, översikt (create, read, update, delete, overview
ja
32
Spårbarhet bakåt inom kravhantering innebär att kraven kan spåras till kod, design och test
nej
33
Generella mål och nyckelområden?
Intressentanalys
34
Hitta nuvarande problem?
Observationer
35
Ta fram förslag All framAda system
Fokusgrupper
36
Finna realisAska möjligheter
Prototypframställning
37
Avgöra prioriteter
Fokusgrupper
38
Inkonsekvenser mellan olika krav
CRUD
39
Spårbarhetsproblem
Strukturkontroll
40
Missade krav
Mål-krav-spårning
41
Läsbarhetsproblem
Strukturkontroll
42
OrealisAska krav
Prototyptestning
43
Förhandling (negotiation)
Prioriteter
44
Mål-domän-analys (goal-domain analysis)
Fullständighet
45
Brainstorming
Framtida systemidéer
46
Intervju (interview)
Nuvarande arbete
47
Mål-krav-spårning (goal–requirements tracing)
Missade krav?
48
CRUD (skapa, läsa, uppdatera ta bort)
Läsbarhetsproblem
49
Prototyptestning
Orealistiska krav?
50
CRUD (skapa, läsa, uppdatera ta bort)
Inkonsekvenser mellan krav?
51
Strukturkontroll (structure check)
Spårbarhetsproblem
52
Prototyper (prototyping)
Realistiska möjligheter
53
Vilken kravnivå man väljer beror i huvudsak på typen av användargränssnitt
nej
54
När man utvärderar ett systems användbarhet försöker man undvika att ta hänsyn till användarens subjektiva upplevelse
nej
55
Heuristiska utvärderingar hittar ofta fler verkliga problem jämfört med användbarhetsutredningar
nej
56
Krav på målnivå gör att leverantörer slipper ta ansvar även för omstrukturering av verksamheten kring produkten
nej
57
Spårbarheten underlättas om målnivån är produktorienterad.
nej
58
För att kunna utföra ett användbarhetstest krävs ett fungerande system.
nej
59
Öppna mått (open metric) passar bra när man vill överlåta åt leverantören att definiera hur kvalitetskrav ska mätas.
ja
60
En kravingenjör förväntas hjälpa intressenterna att hitta realistiska och kostnadseffektiva produkter.
ja
61
Enligt Moores modell är kunderna i den tidiga majoriteten (early majority) teknik glada och är intresserade av att prova de nya teknikerna.
nej
62
Kostnads/värde - relationer estimeras oftast bättre genom relativa bedömningar än absoluta siffror.
ja
63
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
nej
64
Ofullständiga datakrav ger större problem i praktiken än ofullständiga kvalitetskrav.
nej
65
En fullständig kravspecifikation kan normalt uppnås med en liten ansträngning
nej
66
Följande krav: R2: Leverantören ska tillhandahålla kvalificerad supportpersonal. är mer riskfyllt för leverantören än för kunden
nej
67
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
ja
68
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
ja
69
Om E/R-diagram är för svåra för intressenterna att tolka kan man med fördel komplettera med ett klassdiagram
nej
70
Det är oftast lättare för en slutanvändare att validera händelselistor (event lists) på produktnivå jämfört med domännivå
nej
71
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)
ja
72
Observationer (observations) passar bättre än fokusgrupper (focus groups) vid elicitering av prioriteter.
nej
73
Prototypframställning (prototyping) passar bättre än intressentanalys (stakeholder analysis) vid elicitering av generella mål och nyckelområden
nej
74
Pilottest (pilot test) passar bättre än strukturkontroll (structure check) för att hitta spårbarhetsproblem.
nej
75
CRUD (create, read, update, delete) passar bättre än strukturkontroll (structure check) för att hitta inkonsekvenser mellan olika krav
ja
76
Prototyptestning (prototype test) passar bättre än strukturkontroll (structure check) för att hitta orealistiska krav
ja
77
För uppgiftsbeskrivningar (task descriptions) ska varje uppgift helst vara öppen så att måluppfyllnaden blir flexibel
nej
78
Virtuella fönster (virtual windows) ska inte innehålla menyer och knappar.
ja
79