Requirements Conflict Examples - Camilo Fitzgerald



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 cost-based 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:

[pic]

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.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download