There are a number of different books, often conflicting to some degree or another, depending on which methodology is in use, worse still some use different names for basically the same thing and some replace specific documents with other concepts. A lot also depends on the complexity of the system/project and the field that it is to be used in - with small simple utilities in non-critical areas expect less but for major projects &/or medical, military, space, aviation, etc. expect a lot more.
To wildly generalize for a reasonably complicated project in a reasonably formal environment expect:
- Concept document - used to sell the idea to the management. Without this you will not be able to get the funding to start
- Management Plan - Defines how you will work, Version Control, etc. may be skipped in some organizations/projects either includes the Quality Plan or references one.
- Budget(s) &/or Cost Analysis Documents, Staff availability, etc.
- Risk Analysis - Especially on Safety Critical Systems
- Requirements Capture Documents - not always done
- System Specification - What will the end product do in broad strokes.
- From this you should be able to write the system acceptance specification
- Interface Control Document - Essential if there is more than one subsystem or any external interfacing.
- Coding standards - if not already in place
- If there is a user interface then UX guidelines or design documents
- Detailed design documents, (stories in Agile).
- Unit Test Specifications/Story Acceptance Criteria
- Code & Test Reviews
- Developer Notes, mostly as comments in the code & readme files but possibly also in a Wiki.
- Unit Test Results
- Test Coverage Results
- Bugs & Enhancement suggestions, ideally a ticketing system is specified by the Management Plan.
- System/Integration Test Results
- Release Notes
- Marketing Materials
- Review documents on all of the above
- Lessons Learned
- Maintenance Proposals/Procedures
- Sun-setting or Decommissioning Documents
Expect all of the above to go through several iterations, (hopefully with releases).
You may well have additional documents such as Cyber Security Plans & Test Reports, various documents to meet company, compliance &/or regulatory requirements, etc.
A couple of things that I would urge you to do as you go on:
- Release documents even though you know that they are probably going to change - this gives you a stake in the ground to work to and allows you to manage the changes that inevitably happen, (if you can compare Rev 4 with Rev 3 you can see what changed but if you don't have old copies...)
- Get and use ticketing and version control systems in place ASAP.