Requirements Conflict Examples
Introduction:
This document contains examples of requirements conflicts and how two methods,
WinWin (Boehm et al., 1995) and Viewpoints (Finkelstein and Sommerville, 1996),
have tried to solve them.
Each example has been structured using an simplified version of the requirements
interaction management lifecycle proposed by W. Robinson (Robinson et al., 2003).
WinWin Example
Adapted from “Applying WinWin to quality requirements - A case study”
(In et al., 2001)
Process:
Requirements Partitioning:
Requirements are partitioned according to their quality attributes using an ‘plug-in’
for WinWin called QARCC (Boehm and In, 1996a). Namely: Dependability,
Interoperability, Usability, Performance, Evolvability & Portability, Cost &
Schedule, and Reusability. The stakeholder does this manually when a requirement is
added to the system.
Conflict Identification:
Interactions identified in three ways:
a) Manually by stakeholders
b) With the aid QARCC, which uses knowledge of interactions between quality
requirements that typically result in conflict.
Resolution Generation:
Resolutions generated in two ways:
a) Manually by stakeholders.
b) With the aid of the S-COST tool, which provides the user with a set of
possible conflict resolutions using the COCOMO model to perform a costbased analysis of requirements. This is limited to cost-based resolutions.
Resolution Selection:
The stakeholders select resolution options manually and an agreement schema is
drafted. WinWin’s iterative voting and adoption procedure is then used to agree on a
schema.
(Note: QARCC is used here to identify which stakeholders need to be notified of each
conflict. It does this by classifying each stakeholder into 1 of 6 groups, each of which
are typically concerned with differing quality attributes).
Example (Adapted): Electronic Library
Context:
“The purpose of this project is to create an attractive user-friendly prototype
for a virtual archive (i.e. a virtual framework for virtual items or collection groups
within a larger collection) of research materials”.
Requirement A: Item Retrieval
“This option allows the user to retrieve items in any format”.
Requirement B: No File Conversion
“File conversion should not be supported”.
Requirements Partitioning:
Requirement A tagged as a usability requirement
Requirement B tagged as a cost / schedule requirement
Conflict Identification:
QARCC’s expert knowledge system flags the possibility of a conflict due to the fact
that usability and cost / schedule requirements typically stand a good chance of
conflicting with each other. The conflict is then verified by the development team
with the following issue: “What is meant by any formats? It may not be possible to
retrieve in any format since file conversion will not be supported”.
Resolution Generation:
Done manually, options as follows:
a) Support file conversions for all major types and increase the budget for the
project.
b) Support file conversions for limited set of formats (e.g. .pdf, .rtf and .doc) and
increase the budget for the project.
c) Make budget and schedule allowances by removing Requirement F: “Provide
a wizard feature for setting up archives”.
d) Add the requirement: “A separate version of each item, one for every format
required, must be submitted to the system when a new item is added”.”.
e) Only support the retrieval of items in formats that are available.
Resolution Selection:
The developers proposed e) to be the best option and this was agreed upon by all
stakeholders.
Viewpoints Example
Adapted from “Managing inconsistencies in an evolving specification”
(Easterbrook and Nuseibeh, 1995)
Process:
Requirements Partitioning:
Partitioning may take place arbitrarily for ease of merging of viewpoints.
Conflict Identification:
A set of logical consistency rules is built to compare different viewpoints (and the
requirements expressed within them by proxy).
Resolution Generation:
Resolutions are generated to fix the logical inconsistencies arising.
Resolution Selection:
No support
Example: Telephone system
Context:
A telephony system is to be developed which will allow for calls to be made
and received from a phone.
Viewpoint A: Calling
Viewpoint B: Incoming Call
Requirements Partitioning:
The diagrams above are the result of a partitioning step that creates a diagram to
represent a subset of the behaviours of a particular device. This was done for ease of
merging of the two viewpoints, and took place manually.
Conflict Identification:
A set of logical rules was constructed to test the consistency of the two diagrams. One
of these rules reveals that nowhere is it specified what should happed if the receiver is
replaced by the callee when in the “connected” state.
Resolution Generation:
A list of resolutions were generated from the following sources:
a) Derived directly from the rule that failed
b) Offered by the developer
c) Method specific heuristics
The resolutions were was follows:
ViewPoint A actions:
1) delete transition(off hook, idle)
2) move state(connected) so it is no longer part of state(off hook)
3) move transition(off hook, idle) so it no longer connects from state(off hook)
4) delete state(connected)
5) delete state(idle)
6) rename state(connected)
7) rename state(idle)
8) devolve transition(off hook, idle) to all sub-states of off hook
ViewPoint B actions:
9) delete state(connected)
10) delete state(idle)
11) rename state(connected)
12) rename state(idle)
Joint Actions:
13) copy transition(off hook, idle) from ViewPoint A to ViewPoint B as
transition(connected, idle)
Resolution Selection:
Resolution 13) was chosen manually. This new state transition diagram is as follows:
Notes on resolutions:
What are our assumptions?
- We have already identified:
a) A set of conflicts.
b) Possibly a list of possible resolutions to the conflicts.
c) Possibly some information on the impact of the resolutions on the quality
goals.
What would we like to do?
- Provide the software engineer with resolutions strategies and assistance with
applying them.
What conflict resolution strategies exist?
- To pick the most desirable resolution to a conflict, given a set of possible
resolutions.
What characteristics of resolutions might be desirable?
- Less cost / schedule of feature development
- Less cost / schedule of the resolution applied
- More functionality
- Effects on quality goals.
How can we help them to pick a resolution?
- Automatically pick a resolution for them
- Provide expert knowledge on ‘good’ ways to pick resolutions.
- Sort the resolutions into a list ordered according to the ‘best’ solution.
What are the characteristics of resolutions that could be considered
to provide the ‘best’ solution?
- Least cost; see (Boehm and In, 1996b)
- Highest level of stakeholder satisfaction (see Note 1).
- Least disruption to the rest of the requirements (see Note 2).
- Leaves the system with the most amount of functionality.
- Provides the highest level of satisfaction to the soft goals.
- As above, but with the use of multi-criteria preference analysis (In et
al., 2002)
- Suggest a set of actions that will make the choice of resolution easier (such
as asking for information from a stakeholder).
- Remove resolutions from the list that we know cannot be chosen.
When might we know when a resolution is not going to be chosen?
- When it involves the editing or removal of an object that should not
be changed (see Note 3).
- Give the software engineer advice on which conflict to resolve first, given that a set
of conflicts has been identified.
When might it be best to resolve one conflict before resolving others?
- When the resolution to a conflict is likely to affect many other conflicts.
How could we deduce whether resolving a conflict is likely to affect
other conflicts?
- It is higher up in the goal-graph, therefore a solution to the conflict
would be affect other conflicts.
- It has the many links to artefacts, thus a resolution would be likely to
affect many other conflicts.
- It can be deduced that that the conflict is the ‘root’ of many other
conflicts, and thus resolving it would also resolve others.
- Provide the software engineer with a set of actions that will make the conflict easier
to resolve
What might these actions be?
- Further questions asked of stakeholders
- The use of analytical methods that might provide better insight.
- To consider certain types of strategy for resolution that might have been
overlooked.
- Give the software engineer advice on when not to resolve a conflict.
When might it be a good idea not to resolve a conflict?
- When it will be easier to resolve the conflict at a later date.
- When the conflict might ‘go-away’ if left alone.
- When the resolution of a conflict is infeasible, or is of a very high cost.
How could information on which resolution strategy to choose be obtained?
- Through research
- From previous resolution choices made during a project
Notes:
Note1: Resolutions based on highest level of stakeholder satisfaction
Each option affects different stakeholders in different ways. Is there a way of
assessing exactly how much they are affected? Maybe give a score out of 10 to each
stakeholder according to their level of authority, and multiply that by a score of how
much they value each resolution? Maybe limit the amount of ‘points’ each
stakeholder can give to resolutions to avoid people scoring 10 to any resolution that is
to their advantage.
Note 2: Resolutions based on the least disruption to the rest of the requirements
Could the ‘ripple-effect’ be considered here? We would need to start with a model: A
goal-graph may be of use here again. All conflicts and requirements relationships
would need to be considered in order to calculate the effect of a particular resolution.
This seems like an intractable problem: Partitioning and other smart methods for
analysis may help here. The result would be to order the list of resolutions according
to the number of new conflicts they produce.
Might it be possible to calculate the probability that a resolution might cause further
disruption based on experience and some data about requirements? This would save
having the check through every possible requirement interaction and might give a
solution that is ‘good enough’.
Note 3: How do we know when an object cannot be changed
The software engineer could tag requirements / artefacts, denoting that they cannot be
edited or deleted. Resolutions that involve these objects to be deleted or edited can
automatically be removed from the list of resolutions.
A set of rules can be set up at the start of the project that forbid the deleting or editing
of certain types of artefacts. For example: we could say that assumptions cannot be
altered.
Could we do this on the fly? i.e. Allow the software engineer to choose to ignore
resolutions which alter certain types on artefacts on a per conflict basis.
We could also change which artefacts are considered ‘unchangeable’ according to the
current stage of the project lifecycle. For example: At the early stages of a project use
case diagrams could be altered without too much worry, but as the project progresses
they might be flagged as ‘unchangeable’ as changing them would be a lot more
costly.
References:
BOEHM, B., BOSE, P., HOROWITZ, E. & LEE, M. J. (1995) Requirements
negotiation and renegotiation aids: A theory-w based spiral approach. IEEE
Proceedings of the 17th ICSE Conference, 243-253.
BOEHM, B. & IN, H. (1996a) Identifying quality requirements conflicts. IEEE
Software, 13, 25-35.
BOEHM, B. & IN, H. (1996b) Software cost option strategy tool (S-COST).
Proceedings of 20th International Computer Software and Applications
Conference, 15-20.
EASTERBROOK, S. M. & NUSEIBEH, B. (1995) Managing inconsistencies in an
evolving specification. Proceedings of 2nd International Symposium on
Requirements Engineering (RE '95), 48-55.
FINKELSTEIN, A. & SOMMERVILLE, I. (1996) The viewpoints FAQ. Software
Engineering Journal, 11, 2-4.
IN, H., BOEHM, B., RODGER, T. & DEUTSCH, M. (2001) Applying WinWin to
quality requirements - A case study. Proceedings of the 23rd International
Conference on Software Engineering, 555- 564.
IN, H. P., OLSON, D. & RODGERS, T. (2002) Multi-criteria preference analysis for
systematic requirements negotiation. Proceedings of the 26th International
Computer Software and Applications Conference on Prolonging Software
Life: Development and Redevelopment, 887 - 892.
ROBINSON, W. N., PAWLOWSKI, S. D. & VOLKOV, V. (2003) Requirements
interaction management. GSU CIS Working Paper 99-7.