A System requirement document is a detailed report that elaborates why a product is required, places the product in the situation, and explains what the product will be in terms of its performance. The major chunk of the system requirement document is a detailed plan and a list of the proposed project development plans.
A system requirement document can be divided into several sections. The Business Drivers section explains the motive for the customer to think about the proposed system. The Business Model part explains the deeply rooted business plan of the client for which he plans to develop the new system. After these two sections come the Functional and System Requirements aspects of the report. This section normally houses the hierarchical mentioning of requirements, based on the business as well as functional needs. Technical Requirements section is predominantly important as it is used to mention about the non-functional needs that include the technical framework in which the product should work. A section is maintained for Constraints and Assumptions with which any problems met in the outline or design aspects of the project are analyzed during the developmental phase. The last section is the Acceptance Criteria, which explains the standards with which the customer will finally accept the developed system.
In my opinion, understanding the business plan of the client is the most important step in developing a system requirement document. If any faults are made in this step, the entire later development activities will go futile. Most of the project failures happen due to faulty business plan analysis.
There are mainly two audiences for a system requirement document. One is the client and the second is the development team. It is always better to develop a rephrased document for the client as many of the technical aspects and terms might be unknown to him. At the same time, the development team needs to have clarity about the technical aspects. Hence developing two types of the document for the different audience might enhance clarity in communication.
References
Requirements Definition and Specification. (n.d.). Retrieved April 10, 2016, from https://www.inflectra.com/Ideas/Topic/Requirements-Definition.aspx
