How to settle conflicting software requirements between users and stakeholders

How to settle conflicting software requirements between users and stakeholders

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?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

This was first published in July 2010

Back to top