Here's a simple set of perspectives I use for rationalizing requirements:
- Expert / Technical
Believe it or not, simply identifying these perspective helps a lot. You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement. You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade.
How does this help? Your business goals might be a n orders per hour. Meanwhile, your user wants sub-second response time. Well, that's what your users want, but what will they tolerate? Can your business afford the resources for an idealistic experience? Design is always about trade-offs.
In practice, I generally see industry/standards trump business trump expert/technical, trump user. Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience. On the flip side, some software has catered to users at the expense of the business or industry goals. See the dilema?
You can make a difference. If you build software, know the perspectives, know the goals, and know the scenarios. In some contexts, some tech/expert reccomendations simply do not make sense. Know what you're optimizing. In some scenarios, industry/standards reign, while in others user experience is king. Make sure you have the right representation at the table. Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.