A BA where I'm currently working spelled it out best in a meeting a while back (Brian D). In our organization, the business analysts own the "who, what, why, where, and when" and the developers own the "how".
Not sure how this maps into other people's organizations, but it seems to be a good starting point. Very often I read requirements with a lot of "how" in them.
Examples of this sort of thing include:
- Create a web service to enable validation of item information
- Build a screen with 4 fields (create date, last modified date, historical cost, deleted flag
What I would expect, as a developer is something more like:
- We need to be able to run the mainframe part validation routines against part data submitted from third parties
- We need to display item information to our sales users... critical information they need to understand includes when the item was created, when it was last modified, what it cost before the last modification, and an indication if the item is currently able to be sold in our retail outlets
These examples are a little more verbose (thought they don't need to be), but also decouple the implementation (how) from the problem (why) and free the development team to explore alternative solutions. Perhaps instead of SOAP/WSDL web service, posting XML via HTTP is better... or maybe just FTPing a file is best... In the second example, perhaps it's best to just show an iconic indicator of if the item is active or not (versus a boolean flag). In addition, instead of simply naming the fields that should be displayed, the intent (why) and audience (who) of the page is better explained.