TRUE or FALSE

Question 1

En stakeholder har ofta allt ansvar för systemet.

Answer 1

FALSE. No single person or group can, or should, be responsible for the entire system in most cases.

Question 2

Kravhantering process är en sekventiell process av elicitering, dokumentering, validering, och prioritering.

Answer 2

FALSE. IT is iterative and cyclical, with activities often overlapping and repeating throughout the project lifecycle.

Question 3

Kvalitetsaspekter är ofta motverkande.

Answer 3

TRUE. Quality aspects are often conflicting because improving one aspect of quality can negatively impact another.

Question 4

Icke-funktionella krav är ofta svåra att verifiera.

Answer 4

TRUE. NFRs often involve opinions, making them harder to verify well.

Question 5

Spårbarhet underlättar INTE felsökning.

Answer 5

FALSE. It creates clear links between requirements, design, code, and test cases.

Question 6

Man kan bara använda EN eliciteringsmetod i varje projekt.

Answer 6

FALSE. Using only one limits the effectiveness of gathering requirements.

Question 7

I praktiken är det kostnadseffektivt att uppnå en helt fullständig kravspecifikation.

Answer 7

FALSE. Time and effort, changing needs, and diminishing returns can all affect this.

Question 8

Det finns inga exempel där företag hanterar mer än 50.000 krav.

Answer 8

FALSE. Boeing and Tesla are examples of this.

Question 9

Wireframe är inte lämpligt om man vill beskriva gränssnitt.

Answer 9

FALSE. It is commonly used.

Question 10

Ett kontextdiagram är inte lämpligt om man vill beskriva vilka gränssnitt som finns mellan systemet och dess omgivning.

Answer 10

FALSE. A context diagram is suitable for showing interfaces between a system and its environment because it visually represents external interactions and data flows.

Question 11

Genom att fråga “varför” kommer man närmare målnivåkrav, medan med frågan “hur” kommer man närmare designnivåkrav.

Answer 11

TRUE. Asking “why” helps clarify the purpose, while asking “how” focuses on the implementation.

Question 12

Vid brainstorming är det viktigt att INTE kritisera orealistiska idéer direkt.

Answer 12

TRUE

Question 13

En strukturkontroll är inte lämplig för att identifiera motstridigheter.

Answer 13

TRUE. A structure check ensures data follows a predefined format but does not evaluate the logical accuracy or consistency of the content. Since inconsistencies involve contradictions or errors in meaning, a structure check alone cannot identify them.

Question 14

Virtuella fönster är ett för användare mer lätt begripligt sätt att beskriva data jämfört med datamodeller (E/R-diagram).

Answer 14

TRUE

Question 15

I praktiken kan funktionella och icke-funktionella krav vara svåra att särskilja.

Answer 15

TRUE

Question 16

Icke-funktionella krav hör ofta samman med yttre domän.

Answer 16

TRUE. Performance, scalability, and usability typically address broader system qualities and constraints that extend beyond the core functionality.

Question 17

Krav på domännivå innehåller normalt bara klienter från den yttre domänen.

Answer 17

FALSE

Question 18

Den yttre domänen innehåller aktörer som kommunicerar indirekt med systemet via en aktör i den inre domänen.

Answer 18

TRUE

Question 19

För hyllprogramvara (COTS) är det lämpligast att ställa krav på designnivå.

Answer 19

FALSE. Commercial Off-The-shelf Software is commercially available and ready-made. It is not customizable.

Question 20

Kravhantering för hyllprogramvara handlar till stor del om att välja mellan befintliga produkter med redan existerande användargränssnitt.

Answer 20

FALSE

Question 21

Sannolikheten för att en slumpmässigt vald funktion är beräkningsbar är lika med noll

Answer 21

TRUE

Question 22

Automatiserad mjukvaruverifikation (för någon sorts egenskap) is generellt omöjlig.

Answer 22

TRUE

Question 23

Alla Funktioner är beräkningsbara givet rätt input.

Answer 23

FALSE

Question 24

Mängden av alla funktioner är i praktiken lika stor som mängden av alla beräkningsbara
funktioner

Answer 24

FALSE

Question 25

Kravbaserad utveckling görs alltid i början av projketet medan datadriven utveckling bara går att göra i slutet av projektet.

Answer 25

FALSE

Question 26

Datadriven utveckling måste alltid ta hänsyn till GDPR medan kravbaserad utveckling aldrig behöver det.

Answer 26

FALSE

Question 27

Det finns ingen skillnad mellan kravbaserad utveckling och datadriven utveckling.

Answer 27

FALSE