I am a bit baffled. From the responses, sounds like most people do not maintain a sep business logic documentation. Coming exclusively from a consulting background, I have always been curious as to how private/product companies handle this, especially since there is no "business analyst" job at companies like Microsoft (for example).
So, how then do developers definitively know what to build (especially when many developers are working on an app) - in other words, what the business users communicated about their needs/requirements and ensuring/verifying you got it right (in other words, that your unit tests themselves are correct)? Moreover, if the same developer writing the code also writes the tests (probably often the case), there could be a problem with test accuracy.
Perhaps an ultra-lean or during-construction documentation technique works better for certain types of applications (e.g., internal product development) as opposed to others (e.g., companies contracted to build business solutions) especially where there may be more creative license/leeway to evolve or refactor what to build? Even so, there must be some pre-coding documentation - mockups, notes, models, etc...
EDIT http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html
Just read this on Steve Yegge's blog. Spam comments at end of this post, but the gist is that you can probaby get away with anything if you are working on your own creative product development project. But as more than one commenter pointed out, many projects are not in this realm. Adding risk to the mix are solution longevity, construction duration, developers, must-have specs, risk of wrong specs (e.g, releasing private data or allowing unprivileged functions), and business logic complexity. A combination of these factors will determine how much trouble or risk one may invite by not documenting before construction. The risk may well be low for many projects.
On the why, I do think that not knowing the why can make development soul-less and dreary. Unless one is writing some low-level plumbing or helper pieces, knowing why can help make development work more exciting and connected.