Adding a lot of detail to a technical document can be expensive to create and maintain. Therefore, this is an important issue to get on the table up front.
If you have a document that is only going to be used by users and trainers, extensive details should be reduced to a minimum. But if the document is going to be used by tech support to troubleshoot product problems, it should contain many operational details.
We completed a documentation set for a product that was being totally supported by the manufacturer. In this case, it would have been a waste of time to include a lot of technical detail because nobody at the company who was selling it needed to do much more than call the factory to have it diagnosed and repaired.
The docs were basically for user, installation, training, and sales support. Quick and easy, with a simple index and a lot of white space.
On the other hand, there was an engineering company that used a “contract manufacturer” that would only repair it if a hardware component failed. It was the company’s responsibility with this rapidly evolving product to support users, tech support, detailed diagnostics, installation, training, sales, and distribution.
As you can imagine that document set was extensive and had to include many details to satisfy the many types of “customers” it served. Some of the docs were dense and several doc levels had to be created in several volumes to meet the needs.
Basically, it is important to put all these items in the up-front requirements before starting something that may need to be redone over and over. Good prep pays, as always.