Conflicting Requirements

Two requirements are conflicting if you cannot implement them boththe solution to one requirement prohibits implementing the other. For example, if one requirement asks for the product to "be available to all" and another says it shall be "fully secure," then both requirements cannot be implemented as specified.

As a first pass at finding conflicting requirements, sort the requirements into their types. Then examine all entries that you have for each type, looking for pairs of requirements whose fit criteria are in conflict with each other. See Figure 14.7.

Figure 14.7.

This matrix identifies conflicting requirements. For example, requirements 3 and 7 are in conflict with each other. If we implement a solution to requirement 3, it will have a negative effect on our ability to implement a solution to requirement 7, and vice versa.

Of course, a requirement might potentially conflict with any other requirement in the specification. To help you discover these problems, here are some clues to the situations where we most often find requirements in conflict:

• Requirements that use the same data (search by matching terms used)

• Requirements of the same type (search by matching requirement type)

• Requirements that use the same scales of measurement (search by matching requirements whose fit criteria use the same scales of measurement)

A spreadsheet is a useful tool when you are performing this check. For nonfunctional requirements, consider the requirements that are of the same type. For example, a usability requirement should not, say, have a fit criterion specifying that "users shall be able to carry out all the use cases without any training" if the users in question are research scientists dealing with masses of variable data. Although the product should be as easy to use as possible, we would nevertheless anticipate several months of training will be necessary before the scientists can use it correctly. Thus the fit criterion on the usability requirement is in conflict with the specification of the users.

Another helpful technique for identifying and assessing dependencies between requirements is Quality Function Deployment (QFD), which was popularized in Japan in the 1960s. Its intention is to enable customers, marketing, development, production, design, and managerial staff to work together effectively from the time that a project is started. The heart of the technique is communication of the voice of the customer (or the requirements) throughout the development of the product. QFD uses a tool called the House of Quality (so called because it has the shape of a house), which is a matrix for identifying functional and organizational interdependencies throughout a product's development life.

Hauser, John R., and Don Clausing. The House of Quality. Harvard Business Review, May-June 1988.

For functional requirements, look for conflicts in outcomes. As an example, suppose one requirement for the IceBreaker project calls for de-icing trucks to be routed by the shortest distance, and another specifies the trucks must be given the quickest route. These two requirements do not necessarily mean the same thing, and they may result in different outcomes.

"The foundation of the house of quality is the belief that products should be designed to reflect customers' desires and tastesso marketing people, design engineers, and manufacturing staff must work closely together from the time a product is first conceived."

Source: John Hauser and Don Clausing

Conflicts may arise because different users have asked for different requirements, or users have asked for requirements that are in conflict with the client's idea of the requirements. This type of overlap, which is normal for most requirements-gathering efforts, indicates you need to establish some sort of conflict resolution mechanism.

You, as the requirements analyst, have the most to gain by settling conflicts as rapidly as possible, so we suggest that you play a lead role in resolving them. When you have isolated the conflicting requirements, approach each of the users separately (this is one reason why you record the source of each requirement). Go over the requirement with the user and ensure that both of you have the same understanding of it. Reassess the satisfaction and dissatis faction ratings: If one user gives low marks to the requirement, then he may not care if you drop it in favor of the other requirement. Do this with both users and do not, for the moment, bring them together.

When you talk to each user, explore his reasoning. What does the user really want as an outcome, and will it be compromised if the other requirement takes precedence? Most of the time we have been able to resolve conflicts this way. Note that we use the term "conflict" here, not "dispute." There is no dispute. There are no positions taken, no noses put out of joint by the other guy winning. The users may not even know who the conflicting party is.

If you, as a mediator, are unable to reach a satisfactory resolution, then we suggest that you determine the cost of implementing the opposing requirements, assess their relative risks, and, armed with numbers, call the participants together and see if you can reach some compromise. Except in cases of extreme office politics, stakeholders are usually willing to compromise if they are in a position to do so gracefully without loss of face.