The type, scope and detail of your documentation should be appropriate. Appropriate in terms of the product, the people involved, the domain, risks, criticality, costs or even other factors. req42 only supports you by suggesting a structure, but does not make any suggestions about the level of detail, notation or target groups.

You have to find out yourself what adequacy exactly means in your case, for your product (with the help of involved people):

First, describe just one small part or aspect of your product - and get concrete, specific feedback on this documentation from involved stakeholders. Check the documentation for its usability. Ask whether the documentation is useful and which aspects of this documentation you can still improve.

• Which parts of the documentation should we expand? Where can we shorten?
• Is the presentation, detailing and notation appropriate?
• Is the output or presentation format (such as: pdf, html, docx, wiki) acceptable?
• Do we need to create separate acceptance criteria for each requirement, or is the requirement text precise enough as a starting point for testers?

For example, create diagrams in multiple iterations or refinements: Your first sketch may be handwritten and very rough. Through feedback, you should find out very quickly whether your representation is going in the right direction at all (good) - or whether you are documenting beyond the concrete information needs of your stakeholders (bad).

In this way, you can clarify expectations through feedback. The more specific you ask your stakeholders for their feedback and/or opinion, the more specific their answers will be.

Avoid closed-ended questions like “Is the documentation okay like this?” - because neither after a “yes” nor a “no” do you know what to do concretely now! Rather ask open-ended questions, such as, “What else would we need to change or add to make this documentation more helpful to you?”