Yet interesting enough, that definition doesn't mention any of the actual reasons why you'd build software and doesn't speak to end-user/customer/client happiness.
It also implies at least, that we can collect requirements in some adequate way, which is really a circular argument. Requirements gathering is even less mature than other parts of software development.
"why you build software" = requirement.
end-user/customer/client happiness = Customer satisfaction surveys and ratings help you acquiring it. Basic KPIs such as retention rates and engagement can also help you understand this.
A/B testing helps the process of testing assumptions in a data driven way.
That is a definition of requirement that is different than what most of the industry uses. Most of the industry sees requirements as "how the software should behave". Even with your new definition, I've seen little evidence that we have mature processes around collecting requirements.
As for surveys, KPIs, A/B testing etc. Those are neither standardized, proven to be valuable in a rigorous way, nor widely used. All signs of an immature industry. Further, they can only be used in software development processes that allow for iterative deployment.
It also implies at least, that we can collect requirements in some adequate way, which is really a circular argument. Requirements gathering is even less mature than other parts of software development.