Brainscape's Knowledge GenomeTM

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


See full index

ASY IREB > 4. Practices for Requirements Elaboration > Flashcards

4. Practices for Requirements Elaboration Flashcards

1
Q

Conflict

A

a certain disagreement between people

An interaction between agents (individuals, groups, organization) where at least one agent perceives incompatibilities between her thinking/ideas/perceptions and or feelings and will and that of the other agent and feels restricted by other actions

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

Steps to conflict resolution

A
  1. Conflict identification
  2. Conflict analysis
  3. Conflict resolutions
  4. Documentation of conflict resolution
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Common strategy to deal with conflicts

A
  1. avoid
  2. ignore
  3. deny

=> most conflicts remain hidden
If you do not find conflict - probably you have missed one!

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

Indicators of conflicts

A

In documentation
1. contradictory statements by stakeholders
2. conflicting results from analysis of documents or systems
3. inconsistencies across different levels of detail
4. inconsistent use of terms

in communication
1. denial
2. indifference
3. pedantry
4. continuously asking for more detail
5. deliberately incorrect interpretations, concealment or delegation

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

Important aspects of the conflict

A
  1. subject matter (scope of problem)
  2. affected requirements
  3. stakeholders involved
  4. opinions of stakeholders
  5. cause of the conflict
  6. history of the conflict
  7. consequences
  8. project constraints
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Documentation of conflict resolution

A
  1. Assumptions concerning the conflict
  2. Potential alternatives considered
  3. Constraints influencing the chosen technique
  4. The way the conflict was resolved and reasons for chosen resolution
  5. Decision -makers and other contributors
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Conflict types

A
  1. subject matter conflict
  2. data conflict
  3. interest conflict
  4. value conflict
  5. relationship conflict
  6. structural conflict
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Subject matter conflict

A

occurs when conflicting parties really have different factual needs, mostly caused by the intended use of the system in different environments.

First things to do: analyse and document these facts in details and to have the conflicting parties agree on the exact nature of the conflict

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

Data conflict

A

some parties refer to inconsistent data from different sources or interpret the same data in a different may. Due to poor communication, missing background data, cultural differences, existing prejudices, estimates

Hard: bias - your interpretation is self evident

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

Interest conflict

A

based on different positions of the conflicting parties, formed by personal goals, goals related to a group or goals related to a role.

NB ppl might not reveal their true interests

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

Value conflicts

A

based on differences in values and principles of stakeholders involved. A value conflict is more individual and related to global and long-term perspectives. Values are more stable than interests and rarely change.

NB look for higher values that unite the parties

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

Relationship conflict

A

based on negative experiences with another party in the past or in comparable situation with similar people.

NB often cooccur with other conflict types // escalation and exchanging people

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

Structural conflict

A

involves inequality of power, competition or limited resources or structural dependencies between parties. Resulting imbalance cause problems in communication and decision making

NB Escalation might be necessary.

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

Conflict resolution techniques

A
  1. Agreement
  2. Compromise
  3. Voting
  4. Overruling
  5. Definition of variants
  6. Auxiliary techniques

Shell be determined prior to conflict solving!

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

Auxiliary techniques for conflict resolution

A
  1. Consider all facts (CAF)
  2. Plus-Minus-Interesting
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Agreement

A
  1. completely understand each other
  2. agree to a certain option preferred by all parties
  3. can be time consuming
  4. if successful - results will be long lasting
  5. common in data conflicts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Compromise

A
  1. agree on the option that is not their preference because it is better than conflict
  2. suitable for subject matter conflicts, can work for interests and structural conflicts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Voting

A

works when a simple choice is to be made between a clear set of conflicting requirements

NB party that looses the vote might need attention

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

Overruling

A

transfer the choice to a decision maker with higher authority

good for interest and structural conflicts

NB important to agree on the decision maker and pay attention to the looser

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

Definition of variants

A

build separate solutions for all conflicting requirements

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

CAF: consider all facts

A

consider alternative solutions for a number of predefined criteria (cost, time, risk, available resources)

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

Plus-Minus-Interesting

A

participants first identify all positive aspects of alternatives, then the negatives and finally the interesting points, things that need further investigation

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

Change in focus of validation activities

A
  1. at the beginning - specification of requirements
  2. at the later stage - implementation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Categories of validation techniques

A
  1. Review techniques (static)
  2. Exploratory techniques (dynamic)
  3. Sample development (static)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Sample development

A

during original development efforts developers might detect flaws, such as unclarities, omissions and inconsistencies that prevent them from producing their intended output

NB quantity and severity of flaws indicate the quality of requirements

26
Q

Informal review

A
  1. normally follow author-reviewer cycle

common for early drafts

27
Q

Types of formal reviews

A
  1. Walkthrough
  2. Inspections
28
Q

Walkthrough

A

Author of a work product explains it step by step to an audience in an interactive session. participants can comment, identify flaws and suggest alternatives

29
Q

Best occasions for walkthrough

A
  1. early project phase to discuss the feasibility of a certain system concept of solution outline
  2. transfer of an intermediate work product to another party
30
Q

Inspection

A
  1. responsibility is on moderator, not on author
  2. meeting with moderator, author and group of inspectors
  3. experts are asked to check the WP based on their specific expertise, to verify its adherence to standards, norms and regulations
  4. often check is performed individually prior to the meeting, guided by checklists
  5. expert follow a strict process managed by the moderator and provides a detailed audit trail.
31
Q

Exploratory techniques

A
  1. offer a group of stakeholders the opportunity to gain hands on experience with MVP.
32
Q

Common exploratory techniques

A
  1. prototyping
  2. elicitation and validation go together (use elicitation techniques)
  3. alpha testing and beta testing
  4. A/B testing
33
Q

Alpha testing

A

is done at the developer’s site in a simulated environment. The group of participants is relatively small, guidance might be given - possible to observe the interaction of the users with the system

34
Q

Beta testing

A

is conducted at the end user’s sites in real production, the system is offered to some group of users with the implicit request to validate its looks and behavior.

Important: provide easy way to give feedback.
Helpful for checking development assumptions

35
Q

Tasks in Requirements Engineering

A
  1. Look for sources of requirements
  2. Requirements elicitation
  3. Conflict resolution
  4. Requirements validation

NB not a linear process

36
Q

Goals of requirements validation

A

to ensure that the quality of the set of requirements elicited and the individual requirements within this set is good enough to enable subsequent system development

37
Q

Search for requirement sources

A
  1. recursive
  2. analyse the relationship with future system - if part of the system - relevant for developer, not RE
  3. system and context boundary are delineated

Only entities for which analysis reveals an interaction with an interface to or an influence on the future system but that remain relatively unchanged during the next development deserve attention and sources of requirements

38
Q

Categories of requirement sources

A
  1. Stakeholders
  2. Documents
  3. Other systems
39
Q

Stakeholder (RE source)

A
  1. Failure to include a relevant stakeholder will have a major negative impact on the quality of the final set of requirements, discovering stakeholder later may lead to expensive changes or at the end useless system.
40
Q

Stakeholders can be found

A
  1. direct / indirect users
  2. business managers
  3. IT stuff
  4. opponents
  5. competitors
  6. government / regulatory institutions

Does a relationship exist between the person/organization and the system?

41
Q

Onion model

A
  1. model for identifying stakeholders
  2. a system is surrounded by several layers of higher level socio technical and social system, each with its own stahekolder.
42
Q

Snowball principle

A
  1. the more stakeholders you have found the easier it becomes to find new ones
  2. after identifying first stakeholders, analyse their relationship in inner and outer surrounding systems => find new stakeholders
  3. documents also refer to stakeholders
  4. analyse stakeholders of a legacy / similar system
43
Q

Layers of onion model

A
  1. Software system
  2. Business system (end user, support)
  3. Containing system (logistics, sales, IT manager)
  4. Wider environment (customer, shareholder, ISP, accountant)
  5. Irrelevant environment
44
Q

Stakeholder list

A
  1. who stakeholder is
  2. how to reach them
  3. when and where they are available
  4. what expertise is their
  5. what is their relevance as a source
  6. what is their attitude towards the project
  7. what is their influence on it
  8. role in the company/project
45
Q

Stakeholder relationship management

A

a continuous process of gaining and maintaining the support and commitment of stakeholders by engaging the right stakeholders at the right time and understanding and managing their expectations

46
Q

In order to engage stakeholders in the elicitation process:

A

you must ensure that they know what the project is about and what their role within the project is

47
Q

Main categories of users

A
  1. Internal users
  2. External users
  3. (potentially) Misusers

NB caractérisation is not strict

48
Q

Internal users

A

Directly related to the organization for which the system is being developed, such as staff, management, subcontractors. They are limited in number, more or less known individually and somehow involved in the project. It is easy to contact them and they can be reached, influenced and motivation through existing channels

49
Q

External users

A

outside the company. The number may be large, they are not known individually and they could be completely unaware or indifferent to the project. Can’t be influenced through formal channels. To get in contact may need to do special things (advertizing)

50
Q

Misusers

A

People who intentionally try to interact with the system in a harmful way (hackers, competitors)

Hard to contact or influence them - but can create measures to discorage them

51
Q

User roles

A
  1. different roles will have different information needs, use the system in their own way and may have distinct access rights to functions and the data

NB need to input representatives of all relevant roles in the elicitation

52
Q

User group

A

when system has too many users, useful to find a number of user types that show certain behavioural similarities within the group as distinct from other groups.

NB every group is a distinct source of requirements => personas.

53
Q

Personas

A

Fictitious individuals that describe typical user groups of the system with similar needs, goals, behaviours or attitudes

NB contains information that is relevant in view of the development of the system at hand

54
Q

Major approaches for creating personas

A
  1. Data-driven
  2. Imagination
55
Q

Data driven persona

A
  1. developed with marketing techniques (interviews, focus groups, other ethnographic data collection techniques) - qualitative personas
  2. statistical analysis of large sample of user base - quantitative personas
56
Q

Imagination: personas

A
  1. e.g. brainstorming with project team
  2. ad hoc personas / proto personas
  3. based on imagination and assumptions, that must be checked and confirmed.
57
Q

Relevant documents for requirements elicitation

A
  1. company
  2. domain
  3. project-related / work instrictions
  4. product and process descriptions
  5. legal and regulatory
  6. solutions from competitors
    …
58
Q

Types of documents

A
  1. internal (easier to get, NDA)
  2. external
59
Q

Documents as sources of requirements

A
  1. great to find other sources
  2. can be direct sources of requirements
  3. great source to understand the context
  4. need to check relevance of the document - check with related stakeholder.
  5. all documents are related to certain stakeholders
  6. can document the list of documents
60
Q

Other systems as sources of requirements

A
  1. internal vs external systems
  2. similar vs interfacing systems

NB some technical constraints form the past might not be relevant anymore and no longer restrict the current solution space

61
Q

Similar systems

A
  1. have certain functionality in common
  2. may be predecessor / legacy, competitor comparable systems from other organisations …
  3. may contact their users to learn more about functionalities and solutions
  4. predecessor or legacy - good source for identifying detailed requirements and constraints
62
Q
A

ASY IREB (7 decks)

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