A DevDoc, or Developer/Development Document, defines what the developer expects their code to do. It may not necessarily cover everything it can do; users tend to be quite imaginative, if not downright looney, in their approaches, but it will help define and manage expectations for the code.
A DevDoc is not documentation; it is not meant for public-facing documentation but as an internal reference by support services or documentarians to help clearly define and recommend uses for the feature or function the code addresses.
Given the developers’ expectations and a working knowledge of the platform on which the code is being deployed, the DevDoc also provides some framework elements for quality assurance (QA) testing purposes. However, a DevDoc is not a QA guideline.
A DevDoc can often be a simple, short, bulleted list of features and functions. No significant details need to be explained in depth about how the code was written and the reason why it may not even need to enter the conversation.
- What does the code do?
- Where can the features be seen?
- How do the changes interact with the rest of the codebase?
- What other features are affected by these changes?
Of course, the above is not an exhaustive list or even a recommended list of questions to answer in the DevDoc, but your support services and documentarians who receive this information will be grateful.
Besides, a DevDoc is a great way to close the loop and review whether the proposed solution addresses the original request.