Every company has it’s own procedures, and sometimes it’s own standard for the following documents, but this is the most common, the order is loosely relevant to prerequisites and chronological order
I have put them down in a table to simplify
In this document, a client refers to a party that receives the code, (any of the steakholders), Implementation lead and developer refer to the programmers, system analyst refers to a system analyst.
| Doc Abbrv. | Document description | Who writes it | Who is it written for |
| SOW | Statement of work | Project management, Chief Information Officer, third-party contractor, So from the developers perspective, any client such as the above | Implementation Lead |
| MRD | Marketing requirements document | Marketing department | All steakholders including Implementation lead |
| URD URS | The user requirements document User requirements specification This document is basically the client outlining the features the developers are to implement | Project management with help from system analysts (Clients) | Implementation lead and any relevant stakeholders |
| SRS | A software requirements specification sheet A description of a software system to be developed, laying out functional and non-functional requirements- or features This document bridges the gap between user/client and developer Also serves as an agreement | Business Analyst, System Analyst, and developers | |
| TRD | Technical requirements document Written by the developers based on the requirement documents submitted by the client, this is an extensive document that connects functionality, features, and purpose together, creating this document is a very lengthy process and it requires “Technical writing skills” as it is meant to convey the whole system to non technical steakholders. | ||
| FSD | Functional specification document | ||
| FRD | Functional Requirements Document | ||
| PRD | Product requirements document. This document communicates the capabilities the product will need. | ||
| SRD | Software Requirements Document written statement of what the software will do or should do. | ||
| FRS | Far more detailed than an SRS | Implementation lead or System Analyst. | |
| Product Roadmap | Timetable | ||
| Product backlog | It is the prioritized list of task-level details needed to execute the strategic plan outlined in the product roadmap. | ||
| Sprint Backlog | Drawn from the product backlog, this is the list of cross-functional team plans to work on in the next sprint. | ||
| SD | Software documentation A user’s manual (Not for the developers) | ||