Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

ASY IREB > 2. Fundamental principles of requirements engineering > Flashcards

2. Fundamental principles of requirements engineering Flashcards

1
Q

Task

A

a coherent chunk of work to be done

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

Activity

A

an action or a set of actions that a person or group performs to accomplish a task

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

Practice

A

a proven way of how to carry out certain types of tasks or activities

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

Nine fundamental principles

A
  1. Value orientation
  2. Stakeholders
  3. Shared understanding
  4. Context
  5. Problem, requirement, solution
  6. Validation
  7. Evolution
  8. Innovation
  9. Systematic and disciplined work
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q
  1. Value orientation
A

Requirements are means to an end not an end in itself.

NB benefits of RE are long-term whereas the costs are immediate

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

Benefit of a requirement

A

is a degree to which it contributes to building successful systems (systems that satisfy the desires and needs of stakeholders) and to reducing the risk of failure and costly rework in system development.

Economic value of RE is indirect - saves costs

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

Cost of requirements

A

cost of eliciting, validating, documentating and managing it

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

Influencing factors on the amount of RE

A

Criticality of requirement can be assessed in terms of

  1. importance to stakeholders
  2. impact of missing the requirements
  3. effort needed to specify
  4. distinctiveness of requirement
  5. degree of shared understanding between stakeholders
  6. existence of reference system (examples)
  7. length of feedback cycle
  8. kind of customer supplier relationship
  9. regulatory compliance required

NB effort invested shall be inversely proportional to the risk.

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

Core goals of RE

A

understanding stakeholder’s desires and needs and minimising the risk of delivering a system that does not meet these desires and needs

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

Stakeholder

A
  1. every stakeholder has a role in the context of the system to be built
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Persona

A

fictitious character that represents a group of users with similar characteristics

used for stakeholder roles with to many individuals or when individuals are unknown

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

Stakeholder classification by influence

A
  1. Critical
  2. Major
  3. Minor

Useful for resolving conflicts between requirements and prioritising

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

Critical stakeholder

A

not considering these stakeholders will result in severe problems and make the system fail or render it useless

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

Major stakeholder

A

not considering these stakeholders will have an adverse impact on the success of the system but not make it fail

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

Minor

A

not considering these stakeholders will have no or minor influence on the success of the system

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

Forms of shared understanding

A
  1. explicit shared understanding
  2. implicit shared understanding

NB both can be false, concentrate about relevant things

17
Q

Explicit shared understanding

A

achieved through carefully elicited, documented and agreed requirements.

18
Q

Implicit shared understanding

A

based on shared knowledge about needs, visions, context, e.c.t.

19
Q

Enablers of shared understanding

A
  1. domain knowledge
  2. domain-specific standards
  3. previous successful collaboration
  4. existence of reference systems known by all people involved
  5. shared culture and values
  6. informed mutual trust
20
Q

Obstacles for shared understanding

A
  1. geographical distance
  2. supplier-customer relationship guided by mutual distrust
  3. outsourcing
  4. regulatory constraints
  5. large and diverse teams
  6. high turnover among people involved
21
Q

Context (in RE)

A

part of a system’s environment being relevant for understanding the system and its requirements

Entities in the context will somehow influence the system or even interact with it but will not be contained in the system itself

22
Q

Context boundary

A

boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements

23
Q

System boundary

A

boundary between the system and surrounding context

24
Q

Scope of system development

A

the range of things that can be shaped and designed when developing a system

Not always the same as the system boundaryD

25
Q

Domain assumptions

A

assumptions about real-world phenomena in the context of a system

26
Q
  1. Problems, requirements and solutions
A

inevitably intervened.

no sense to create requirements if there is no problem to solve or no solution to be developed

27
Q
  1. Validation
A

Non-validated requirements are useless.

28
Q

Validation

A

the process of confirming that am item matches stakeholders needs

29
Q

Things to validate

A
  1. Agreement about the requirements has been achieved among stakeholders (conflicts resolved, priorities set)
  2. Stakeholder’s desires and needs are adequately covered by the requirements
  3. The domain assumptions are reasonable
30
Q
  1. Evolution
A

Changing requirements are no accident, it is normal.

enabling change while preserving stability

31
Q

Reasons for changing requirements

A
  1. Change business process
  2. Competitors launching new products or services
  3. Clients change priority and opinions
  4. Changing in technology
  5. Feedback from system users asking for new or changed feature
  6. Detection of errors in requirements or detection of faulty domain assumptions
32
Q
  1. Systematic and disciplined work
A

A systematic and disciplined approach to RE improves the quality of a system

No one-size fits all in RES

33
Q

Systematic and disciplined RE

A
  1. Configure RE that is well suited for the problem at hand and fits development process
  2. Select appropriate RE practices and work products available based on the environment
  3. Do not always use same process, practices and Was
  4. Do not reuse practices from past successful RE works without reflection
34
Q
  1. Innovation
A

Good requirements engineers are innovation aware, strive for exciting new features, look at big picture

Do not assume you know everything better than the stakeholder

35
Q
  1. Stakeholders
A

RE is about satisfying the stakeholders’ desires and needs

36
Q
  1. Shared understanding
A

Successful systems development is impossible without a common basis

37
Q
  1. Context
A

Systems cannot be understood in isolation

ASY IREB (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions