I'm not in love with "requirements". There are some who think that "Requirements" are the be-all and end-all for building great software. They're not wrong, but they are off by a third of a bubble.

Great software companies come from creating and bringing to market (with a great "go to market" strategy) quality software that solves one or more significant problems for an appropriately chosen target audience - and does so measurably better than alternative solutions.

How does such successful software happen? Certainly not by accident.

Understanding the Target Customer
It comes from truly understanding the "target customer" - their needs, their plans, and their pain, the severity of their pain, their ability and willingness to spend money to fix that pain, and knowing what other alternative solutions exist for them (and how your proposed solution compares). And this understanding of target customer needs MUST be done at the earliest stages of product conception to be effective. Otherwise, it's like trying to build the foundation for a house after the house is already built. Not an effective strategy (although it may be a rational one, if you inherit a house that someone else built that lacks a foundation).

This understanding along with the proper people, communication skills and training,
time and effort yields requirements (and priorities, which are embedded and inseparable from requirements by my definition).

Go-to-Market Planning
It also is critical to the formation of a strong go-to-market strategy. Depending on how you look at it:

Great Software + Great Go-to-Market = Wild Success; or

Great Go-to-Market includes Great Software = Wild Success

I'd like to refer users to an outstanding article on SandHill.com by Tony Zingale from Jive Software: "Tips for Thriving in the Software Market". It's about knowing the customer & market and creating great go-to-market strategies. Tony knows a thing or two about successful software companies. Jive Software filed its S-1 in August 2011 for an expected IPO that could raise up to $100 million

This deep understanding is the soil from which all good software things grow. I suppose if deep understanding is the soil, then requirements are the manure that makes the soil fertile. Although perhaps I'm taking this analogy too far.

Requirements - Not the Total Solution
Requirements are not a magic solution for every software problem, however. That's where "Requirements Evangelists" are off by part of a bubble. If you have a weak go-to-market plan, then requirements mean nothing.

Not to mention, lot of things can go wrong in the creation of software "post-requirements". A fair amount of bad software has been created despite the best of requirements.

Requirements as a Best Practice for Successful Software
But almost no good software has ever come about in the absence of solid requirements and priorities. So, those who are Requirements Evangelists keep on evangelizing - as, solid requirements and priorities are a de-facto prerequisite to the creation of quality software. By quality I mean both "useful" as well as "minimal defects".

Yes, some great software has been created without benefit of good requirements, but "luck is not a strategy for success".

Quality software is what drives the success of software companies.

Quality software is what helps corporations and other organizations run better and gives them an advantage in the marketplace.

Properly done, requirements are one of the embodiments of true understanding of the customer.

"Know thy customer" is the first commandment of marketing...and sales...and executive management...and....

So, from that perspective, yes, I love "requirements". It's clearly a Best Practice (capital letters intentional).