TRUE or FALSE Flashcards

1
Q

En stakeholder har ofta allt ansvar för systemet.

A

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

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

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

A

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

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

Kvalitetsaspekter är ofta motverkande.

A

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

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

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

A

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

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

Spårbarhet underlättar INTE felsökning.

A

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

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

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

A

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

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

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

A

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

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

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

A

FALSE. Boeing and Tesla are examples of this.

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

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

A

FALSE. It is commonly used.

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

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

A

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

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

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

A

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

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

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

A

TRUE

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

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

A

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.

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

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

A

TRUE

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

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

A

TRUE

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

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

A

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

17
Q

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

18
Q

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

19
Q

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

A

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

20
Q

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

21
Q

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

22
Q

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

23
Q

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

24
Q

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

25
Q

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

26
Q

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

27
Q

Det finns ingen skillnad mellan kravbaserad utveckling och datadriven utveckling.