In the past couple of years, I've worked on two projects.
The first one, we used a very agile methodology. It was very much developer driven. As such, changes were very quick and rapid. Code quality was high becuase it was a new system. There was an emphasis on group ownership of the project and knowledge sharing. Most knowledge transfer with new staff etc. was conducted just by walking someone through the code or system and most staff members on the project knew enough of the project to do that.
The project I thought was successful but one of the regrets I have is the amount of documentation was probably inadequate long term. We had a bunch of user stories which were short term specs only relevant for the sprint, and a a bunch of master specs outlining the business processes that was long term which we would keep up to date. We had no tech specs other than a oneNote page with user logins and links to test envrionments/servers etc.
The problem was keeping a balance between putting enough in there so that it would be helpful and not so much that no one will want to read it and be a burden to maintain. I don't think we ever found that balance. The master specs were probably too generic to be useful to someone that wants to understand the system.
The second project is completely opposite. It's an old system and it's very big. We use a waterfall methodology. This project is very much tester driven. As such we have probably too much documentation - there are thousands of pages in hundreds of word documents and there is duplication everywhere. (eg. documents with the same or very similar introduction texts)
There is a big emphasis on keeping this mammoth of documentation perfect. Creating a simple change to the system requires identifying which documents is affected and making minor changes to all of them.
We document things to levels that's probably not neccessary (eg. I found a doco the other day where the File Save dialog in IE was documented) and there is an emphasis on being correct over being readable.
In short, we have half a dozen Business Analysts and their job consists more of keeping the documentation up to date than of actual analysis.
I think both of these projects have bad practices and what would be optimal is somewhere in between the two. This balance probably depends on the system as well, so how do you decide how much documentation you need and also how to structure it so that maintaining doesn't become more cost than benefit.
EDIT - Hi, sorry should've mentioned it before all the answers came along (I only was just able to check). I'm primarily focused on non-technical business requirements here - those that can be consumed not just by developers (audiences may include BAs, managers, testers, stakeholders etc.)