krav Flashcards
Vilken kravnivå man väljer beror i huvudsak
på den specifika leverantörsnivån
ja
Intressenter är personer eller roller som direkt
eller indirekt påverkas av systemet
ja
Projekttypen påverkar sällan
ansvarsfördelningen mellan intressenter
nej
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
ja
Användbarhetsproblem är ofta mer oväntade
än programmeringsproblem
ja
I en heuristisk utvärdering låter man en
slutanvändare utan tidigare kunskap om
systemet utvärdera systemet.
nej
Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav
nej
Estimering på ratio-skala innebär parvis
jämförelse på graderad skala
ja
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.
ja
Enligt Moores modell är kunderna i den sena
majoriteten (late majority) pragmatiska,
försöker undvika andras misstag och vill se
goda referenser
nej
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
nej
Parvisa jämförelser innebär högst en
jämförelse per krav
ja
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
ja
Följande krav:
R3: Systemet ska följa stilguide xx.
är mer riskfyllt för leverantören än kunden
nej
Marknadsdriven kravhantering innebär få
konkurrenter, ofta mindre formella
specifikationer och liten närhet till kunderna.
nej
Card Sorting, Laddering och Scenario-analys
är exempel på prioriteringstekniker
nej
Kvalitetskrav slår sällan tvärs över många
funktioner.
nej
Granskning ad hoc innebär att man följer
givna riktlinjer.
nej
Kvalitetsaspekter motverkar ofta varandra så
som ökad säkerhet kan ge minskad
användbarhet
ja
Noggrannhet (accuracy), Autencitet
(authenticity) och integritet (integrity) är
kvalitetsegenskaper som ingår i säkerhet
(security)?
nej
Elicitering, analys och specifikation är de tre
första stegen i kravprocessen
ja
I en heuristisk utvärdering låter man en
slutanvändare utan tidigare kunskap om
systemet utvärdera systemet.
nej
Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav.
nej
Marknadsdriven kravhantering innebär få
konkurrenter, ofta mindre formella
specifikationer och liten närhet till kunderna
nej
Det är lämpligt att skapa ett kontextdiagram
mot slutet av ett projekt när implementationen
är komplett
nej
Det är oftast lämpligt att ta med både
domäninformation och illustrativa exempel i
anslutning till ett krav.
ja
En uppgiftsbeskrivning bör leda till
uppfyllnad av ett mål
ja
Flera oberoende granskningar finner ofta färre
fel jämfört med en enda granskning
nej
Laddering är en valideringsteknik som skapar
förståelse för olika termer och som kan
användas som underlag för terminologi
nej
Hårdvarukrav ska inte specificera vilka
komponenter som ska användas utan det är
funktionskraven som ska specificeras
ja
SLUT+ Ö (CRUD + O) står för skapa, läsa,
uppdatera, ta bort, översikt (create, read,
update, delete, overview
ja
Spårbarhet bakåt inom kravhantering innebär
att kraven kan spåras till kod, design och test
nej
Generella mål och nyckelområden?
Intressentanalys
Hitta nuvarande problem?
Observationer
Ta fram förslag All framAda system
Fokusgrupper
Finna realisAska möjligheter
Prototypframställning
Avgöra prioriteter
Fokusgrupper
Inkonsekvenser mellan olika krav
CRUD
Spårbarhetsproblem
Strukturkontroll
Missade krav
Mål-krav-spårning
Läsbarhetsproblem
Strukturkontroll
OrealisAska krav
Prototyptestning
Förhandling (negotiation)
Prioriteter
Mål-domän-analys (goal-domain analysis)
Fullständighet
Brainstorming
Framtida systemidéer
Intervju (interview)
Nuvarande arbete
Mål-krav-spårning (goal–requirements tracing)
Missade krav?
CRUD (skapa, läsa, uppdatera ta bort)
Läsbarhetsproblem
Prototyptestning
Orealistiska krav?
CRUD (skapa, läsa, uppdatera ta bort)
Inkonsekvenser mellan krav?
Strukturkontroll (structure check)
Spårbarhetsproblem
Prototyper (prototyping)
Realistiska möjligheter
Vilken kravnivå man väljer beror i huvudsak
på typen av användargränssnitt
nej
När man utvärderar ett systems användbarhet
försöker man undvika att ta hänsyn till
användarens subjektiva upplevelse
nej
Heuristiska utvärderingar hittar ofta fler
verkliga problem jämfört med
användbarhetsutredningar
nej
Krav på målnivå gör att leverantörer slipper ta
ansvar även för omstrukturering av
verksamheten kring produkten
nej
Spårbarheten underlättas om målnivån är
produktorienterad.
nej
För att kunna utföra ett användbarhetstest
krävs ett fungerande system.
nej
Öppna mått (open metric) passar bra när man
vill överlåta åt leverantören att definiera hur
kvalitetskrav ska mätas.
ja
En kravingenjör förväntas hjälpa
intressenterna att hitta realistiska och
kostnadseffektiva produkter.
ja
Enligt Moores modell är kunderna i den tidiga
majoriteten (early majority) teknik glada och
är intresserade av att prova de nya teknikerna.
nej
Kostnads/värde - relationer estimeras oftast
bättre genom relativa bedömningar än absoluta
siffror.
ja
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
Ofullständiga datakrav ger större problem i
praktiken än ofullständiga kvalitetskrav.
nej
En fullständig kravspecifikation kan normalt
uppnås med en liten ansträngning
nej
Följande krav:
R2: Leverantören ska tillhandahålla kvalificerad
supportpersonal.
är mer riskfyllt för leverantören än för kunden
nej
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
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
Om E/R-diagram är för svåra för
intressenterna att tolka kan man med fördel
komplettera med ett klassdiagram
nej
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
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
Observationer (observations) passar bättre än
fokusgrupper (focus groups) vid elicitering av
prioriteter.
nej
Prototypframställning (prototyping) passar
bättre än intressentanalys (stakeholder
analysis) vid elicitering av generella mål och
nyckelområden
nej
Pilottest (pilot test) passar bättre än
strukturkontroll (structure check) för att hitta
spårbarhetsproblem.
nej
CRUD (create, read, update, delete) passar
bättre än strukturkontroll (structure check) för
att hitta inkonsekvenser mellan olika krav
ja
Prototyptestning (prototype test) passar bättre
än strukturkontroll (structure check) för att
hitta orealistiska krav
ja
För uppgiftsbeskrivningar (task descriptions)
ska varje uppgift helst vara öppen så att
måluppfyllnaden blir flexibel
nej
Virtuella fönster (virtual windows) ska inte
innehålla menyer och knappar.
ja
