How to settle conflicting software requirements between users and stakeholders

Choosing to ignore stakeholder needs during the requirements elicitation phase is a common problem in software development. Knowing how to cater to both stakeholders and users is the first step in delivering dead-on requirements.

Every user has a different perspective of what's important or how something should work. What do you do when you get conflicting requirements from different stakeholders?

This is a good question that raises several important frequently-misunderstood issues affecting requirements discovery. First, thank you for using both the terms "user" and "stakeholder." Many people use "stakeholder" to mean non-users who often are farther removed from the project at hand. I find it preferable and more useful to view stakeholder as a broader, more inclusive term.

In this view, all product/system users are customers, and they can be internal or external. Not all customers are necessarily users. All customers are stakeholders, although not all stakeholders are customers. Stakeholders are the source of requirements. Some usually are very important and greatly influence the requirements, whereas other stakeholders' interests may be smaller, farther removed, and less controlling.

Conflicting requirements are a hidden blessing
What's important
It shouldn't be a surprise that stakeholders differ in how they assess importance of various requirements. What affects me is important to me. What affects you is maybe not so important to me.

Such different perceptions or importance are not really conflicts per se. The conflict arises when trying to prioritize what's important to me (but not to someone else) relative to what's not important to me (but is to someone else). If both get addressed now, the "conflict" is irrelevant. If addressing one means the other doesn't get addressed, or gets addressed much later or lesser, then the requirements conflict can turn into actual conflict between the respective parties.

The simple—but not easy—way to resolve differing perceptions of importance is to compare the ROIs of satisfying each conflicting requirement.

Requirements conflicts
Hardest to deal with are inherent conflicts between business requirements whats where both requirements are recognized as important. Here, how-it-should-work is conceptual, rather than physical as with product requirements. For instance, a classic conflict is between requirements for security and usability. In general, methods of enhancing security come at the price of reducing usability and vice versa.

Similarly, operational requirements of day-to-day users often conflict with the equally important tactical and control requirements of their managers; and both often conflict with executives' strategic requirements.

Although it can be quite challenging, the key to resolving these conflicts is to find ways to align the seemingly conflicting requirements. I've found that the method I call "requirements rethinking" can be very helpful finding ways to get past apparent requirements conflicts.

Dig Deeper on Topics Archive