[jerdthenerd]

Thanks for your reply. When I describe "the business" I am referring to Product teams that manage SOP, help prioritize new offerings, etc. Here's an example of a feature request from the business:

"I want to allow customers to run scheduled reports from our portal and receive them via email."

Development then designs and executes, delivering a scheduled reporting suite for testing. Business will come back with feedback such as:

"I don't like how I have to select the time for every report. Can't you just default it?" or "Only some users from the customer's account should be able to create/edit scheduled reports. Please add this by Tuesday so I can demo." or even "This is great, but my customer has special holidays that they don't want emails to be sent on. We should have a yearly calendar that prevents reports from getting sent."

There is a large gap between feature request "requirements" and the expectations of the business. Thus, we request specific feature request requirement documents to be turned in prior to development starting work.

[syndicatedjelly]

It sounds like there's a step missing from that flow - who makes requirements? Saying "I want something" is not a requirement, it's a user need. Not trying to be pedantic, but it might be the lack of definition around what a requirement actually is, that's causing the confusion and rework cycle.

A requirement is typically of the syntax, "{X} system shall {verb} {functionality}". For example, "The brakes subsystem shall convert kinetic energy of the bicycle into heat in the brake pads".

A feature request "requirement" is not a thing. The product team can request features, and someone (an engineer, or a PM typically) needs to create requirement(s) to capture the feature. As part of that process, there should be a back and forth between engineering and the product team to figure out what exactly is desired.