A project proposal is a marketing document, describing the costs and economic benefits of funding the purchase or development of a piece of software. It is more concerned with the market opportunity or cost/benefit ratio than with the details of the software. A project proposal is a short document. Ten pages is about the maximum.

A software requirement specification (SRS) is a list of all the needs of every stakeholder in the project, including users of course, but also including sales, business management, and the dev team. The SRS is not about features of the software that might meet those needs, as there may be several constellations of features capable of meeting the same set of needs. The software features are detailed in the Software Design Document (SDD).

SRSs and SDDs belong to the world of waterfall development. Agile boosters pretend they have gotten rid of the need for these documents, but the wall full of user story sticky-notes is way too much like an SRS if it is done correctly (which it usually is not).

The hard part of writing an SRS is that most stakeholders will not reveal their actual needs, even under torture. The team must listen to what stakeholders say, and then extrapolate to what they actually want. It’s an art form no longer practiced much. Finding all the stakeholders is also rather difficult for beginners.

An advantage of SRSs and SDDs is that if done right, they allow needs to be traced to features and vice versa. This helps the team design and implement the most important parts first, and makes sure user needs are not left out of the design.

Quality Function Deployment is a graphical tool for tracing needs to features, that is not frequently used in software development. It’s an improvement over the old-fashioned SRS and SDD that doesn’t throw away the planning stages of software development that some agile boosters find so tiresome. If you get nothing else out of this response, go google and type "quality function deployment".