Notes:
There are various documents produced during any development lifecycle.
Each document should have a clear purpose – and be reviewed against that purpose. I have seen "requirements" documents that fail to state what the system to be delivered is responsible for doing. (For example they describe the manual system that is to be replaced – without indicating which aspects are to be automated.)
Most systems need to be subdivided – into functional areas, into clients and servers, into "components", and so forth. This high level structure of the system needs to be understood because it defines the dependencies between parts of the system.
We assigned each subsystem to a java "package" and documented the role of the package, the principle classes and the interactions with the rest of the system. This normally took the form of class diagrams, use case diagrams and sequence diagrams. (Although other documentation was produced as appropriate.)
The classes to be implemented in a package were designed together (by creating a java file with all the methods bodies dummied out by throwing a "not implemented" runtime exception). This allowed us to produce and review javadocs of the package and all the classes in it. (There were normally a number of "implementation" classes introduced that were not needed in the package design.)