Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

This was last published in July 2010

Dig Deeper on Gathering Software Requirements Use Cases

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What's important to remember is that requirements are developed. We begin with some "desirements" and work out the solution based on budget, time, technical constraints, and other factors. Sometimes gradually delivering the desired functions is even better, because users don't always know exactly what they wanted / how they're going to use it.

Of course, in a heavily formal Waterfall it's a struggle to put together conflicting requirements.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close