4. Practices for Requirements Elaboration Flashcards
Conflict
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
Steps to conflict resolution
- Conflict identification
- Conflict analysis
- Conflict resolutions
- Documentation of conflict resolution
Common strategy to deal with conflicts
- avoid
- ignore
- deny
=> most conflicts remain hidden
If you do not find conflict - probably you have missed one!
Indicators of conflicts
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
Important aspects of the conflict
- subject matter (scope of problem)
- affected requirements
- stakeholders involved
- opinions of stakeholders
- cause of the conflict
- history of the conflict
- consequences
- project constraints
Documentation of conflict resolution
- Assumptions concerning the conflict
- Potential alternatives considered
- Constraints influencing the chosen technique
- The way the conflict was resolved and reasons for chosen resolution
- Decision -makers and other contributors
Conflict types
- subject matter conflict
- data conflict
- interest conflict
- value conflict
- relationship conflict
- structural conflict
Subject matter conflict
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
Data conflict
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
Interest conflict
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
Value conflicts
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
Relationship conflict
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
Structural conflict
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.
Conflict resolution techniques
- Agreement
- Compromise
- Voting
- Overruling
- Definition of variants
- Auxiliary techniques
Shell be determined prior to conflict solving!
Auxiliary techniques for conflict resolution
- Consider all facts (CAF)
- Plus-Minus-Interesting
Agreement
- completely understand each other
- agree to a certain option preferred by all parties
- can be time consuming
- if successful - results will be long lasting
- common in data conflicts
Compromise
- agree on the option that is not their preference because it is better than conflict
- suitable for subject matter conflicts, can work for interests and structural conflicts
Voting
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
Overruling
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
Definition of variants
build separate solutions for all conflicting requirements
CAF: consider all facts
consider alternative solutions for a number of predefined criteria (cost, time, risk, available resources)
Plus-Minus-Interesting
participants first identify all positive aspects of alternatives, then the negatives and finally the interesting points, things that need further investigation
Change in focus of validation activities
- at the beginning - specification of requirements
- at the later stage - implementation
Categories of validation techniques
- Review techniques (static)
- Exploratory techniques (dynamic)
- Sample development (static)
Sample development
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
Informal review
- normally follow author-reviewer cycle
common for early drafts
Types of formal reviews
- Walkthrough
- Inspections
Walkthrough
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
Best occasions for walkthrough
- early project phase to discuss the feasibility of a certain system concept of solution outline
- transfer of an intermediate work product to another party
Inspection
- responsibility is on moderator, not on author
- meeting with moderator, author and group of inspectors
- experts are asked to check the WP based on their specific expertise, to verify its adherence to standards, norms and regulations
- often check is performed individually prior to the meeting, guided by checklists
- expert follow a strict process managed by the moderator and provides a detailed audit trail.
Exploratory techniques
- offer a group of stakeholders the opportunity to gain hands on experience with MVP.
Common exploratory techniques
- prototyping
- elicitation and validation go together (use elicitation techniques)
- alpha testing and beta testing
- A/B testing
Alpha testing
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
Beta testing
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
Tasks in Requirements Engineering
- Look for sources of requirements
- Requirements elicitation
- Conflict resolution
- Requirements validation
NB not a linear process
Goals of requirements validation
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
Search for requirement sources
- recursive
- analyse the relationship with future system - if part of the system - relevant for developer, not RE
- 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
Categories of requirement sources
- Stakeholders
- Documents
- Other systems
Stakeholder (RE source)
- 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.
Stakeholders can be found
- direct / indirect users
- business managers
- IT stuff
- opponents
- competitors
- government / regulatory institutions
Does a relationship exist between the person/organization and the system?
Onion model
- model for identifying stakeholders
- a system is surrounded by several layers of higher level socio technical and social system, each with its own stahekolder.
Snowball principle
- the more stakeholders you have found the easier it becomes to find new ones
- after identifying first stakeholders, analyse their relationship in inner and outer surrounding systems => find new stakeholders
- documents also refer to stakeholders
- analyse stakeholders of a legacy / similar system
Layers of onion model
- Software system
- Business system (end user, support)
- Containing system (logistics, sales, IT manager)
- Wider environment (customer, shareholder, ISP, accountant)
- Irrelevant environment
Stakeholder list
- who stakeholder is
- how to reach them
- when and where they are available
- what expertise is their
- what is their relevance as a source
- what is their attitude towards the project
- what is their influence on it
- role in the company/project
Stakeholder relationship management
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
In order to engage stakeholders in the elicitation process:
you must ensure that they know what the project is about and what their role within the project is
Main categories of users
- Internal users
- External users
- (potentially) Misusers
NB caractérisation is not strict
Internal users
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
External users
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)
Misusers
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
User roles
- 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
User group
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.
Personas
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
Major approaches for creating personas
- Data-driven
- Imagination
Data driven persona
- developed with marketing techniques (interviews, focus groups, other ethnographic data collection techniques) - qualitative personas
- statistical analysis of large sample of user base - quantitative personas
Imagination: personas
- e.g. brainstorming with project team
- ad hoc personas / proto personas
- based on imagination and assumptions, that must be checked and confirmed.
Relevant documents for requirements elicitation
- company
- domain
- project-related / work instrictions
- product and process descriptions
- legal and regulatory
- solutions from competitors
…
Types of documents
- internal (easier to get, NDA)
- external
Documents as sources of requirements
- great to find other sources
- can be direct sources of requirements
- great source to understand the context
- need to check relevance of the document - check with related stakeholder.
- all documents are related to certain stakeholders
- can document the list of documents
Other systems as sources of requirements
- internal vs external systems
- similar vs interfacing systems
NB some technical constraints form the past might not be relevant anymore and no longer restrict the current solution space
Similar systems
- have certain functionality in common
- may be predecessor / legacy, competitor comparable systems from other organisations …
- may contact their users to learn more about functionalities and solutions
- predecessor or legacy - good source for identifying detailed requirements and constraints
