The Requirements Communication Problem: Process Models Bridge The Requirements Gap by John Forrest of Holocentric. (Original article here)
This white paper proposes that linking requirements back to business processes is the first and best step you can take to ensure the quality of your project's business requirements.
There is another study I read a while ago that says processes lead to problematic requirements management and that (use) cases should be used in preference.
According to the wise folk who wrote that doctoral thesis business process models should only be used for non customer value adding work; typically back office support functions, or where you are automating the whole thing so the customer gets an instant end to end and seamless experience.
This aligns pretty nicely with management theory which suggests that if your front line people are dealing with complex or dynamic customer requirements they shouldn't be locked into processes; rather they should have tools that enable them to achieve desired outcomes.
(And this is where many localised process management teams and frontline management have got things so very wrong.)
Having said that, there is a lot going for mapping requirements back to frontline activities (and processes.) And business process management is still a growing field with plenty to offer in the right context.
Reading the article I felt there are a few incorrect points - e.g. managing requirements is not the MOST important aspect of project requirements. I checked out the business and they sell process mapping solutions. Naturally it's a bit biased.
Bottom line: The article is worth a read but be sceptical that processes are the solution to requirements management. They are just a part of the puzzle.
(You can read another review of this article at ZDnet here.)