Week_2 Flashcards

(25 cards)

1
Q

Story of concrete user–system interaction used to capture behaviour.

A

Scenario

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

Set of scenarios tied to a user goal; often lists main and alternative flows.

A

Use Case

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

Requirement stating what user and computer accomplish together; postpones who does what.

A

Task Description

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

Extension of a task that lists current problems and proposed computer support for each subtask/variant.

A

Tasks & Support

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

Four abstraction levels: Goal → Domain → Product → Design.

A

Goal–Design Scale

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

Conceptual map of real-world entities and relationships (not a database schema).

A

Domain Model

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

Create, Read, Update, Delete operations over data.

A

CRUD

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

Checking we built the product right (meets its specification).

A

Verification

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

Checking we built the right product (meets user needs).

A

Validation

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

Task element indicating how often and how intense the task demand is; surfaces quality hotspots.

A

Frequency/Criticality

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

Alternative condition/path within a task (e.g., booked vs walk-in).

A

Variant

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

End-to-end process showing actors, dependencies, sequencing.

A

Workflow

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

Requirement type describing behaviour transformations from inputs/state to outputs/state.

A

Functional Requirement

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

Requirement type specifying what must be stored/exchanged; formats and persistent state.

A

Data Requirement

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

Requirement type specifying how well the system performs (e.g., performance, usability).

A

Quality Requirement

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

Choosing levels appropriate to the supplier: vendor vs software house vs consultancy.

A

Selecting Requirement Level

17
Q

Common trap: specifying UI fields and database columns while modelling the domain.

A

Solution Bias in Domain Modelling

18
Q

Good task property: clear closure—user feels ‘done’.

19
Q

Method to validate requirements by simulating tasks and all variants with users.

A

Task-based Validation

20
Q

Linking business goals to specific tasks ensures traceability and correct focus.

A

Tracing Goals to Tasks

21
Q

Why postpone the human/computer split in requirements? To keep design space open and avoid premature constraints.

A

Rationale for Postponing Split

22
Q

Example of Task & Support improvement for hotel keys.

A

Electronic Keys Support

23
Q

Guest’s ‘Hotel Stay’ adds tasks like Select Hotel and Reimburse—revealing missing requirements.

A

Client-Perspective High-Level Task

24
Q

How tasks surface quality needs: frequency/critical scenarios indicate performance/usability targets.

A

Tasks as Quality Pointers

25
Difference between Trigger and Precondition? Trigger starts the task; preconditions must hold before a specific step.
Trigger vs Precondition