Requirements tracking vs awkward clients - tools/tech or process?

@AndyDentPerth

From a local slack, discussing approach on how to capture and evolve requirements. I've not looked at tooling or any new approaches in this spaces for a good 15 years. Any insights?

The OP on there says:

Today's struggle: I find myself constantly coming back to this idea of a "better way of capturing requirements"

new client sent some additional requirements through on Friday, asking me to assess and advise if we can hit them within the timeframe

the answer is "probably, but it will create risk for reaching the deadline", but the challenge is really around quantifying the requirements into something useful, so that the business and technical requirements are understood

I feel like it's a problem an app could explore solving, but has anyone even seen any good methodologies for this? A lot of different project management & sldc methodologies out there, but is there anything that deals with requirements gathering?

I like the idea of documenting how business reqs translate into technical reqs ("Employee fired" -> "HR.TerminationDate < Today()") and then sort of assigning those requirements into use cases.

What I'd love is just a nice UI for capturing that process, both the iteration and the decision-making. I waited like 6 months for someone to tell me the address for their internal SMTP server once. Anohter time I kept explaining that if they used OfficeLocation to determine which domain to provision a user to, it would cause problems, and I wanted them to own the decision
(ultimately it doesn't matter and it went live after they owned it and then they had a bunch of problems that I charged to fix)