A SRS should function as a contract between the customer and the service provider, defining precisely the requirements and duties of each part, usually before the project starts. It should help clear up most uncertainties between customer and developer at an early stage, reducing risk and overhead later in the project's life.
A good SRS is essential for the success of any software project. Too often regarded as just an auxiliary phase, with no practical use or applicability, it is frequently overlooked by unexperienced developers.
It should be noted that an SRS contains functional and nonfunctional requirements only and does not offer design suggestions, technological solutions or business issues.
A well-written SRS accomplishes four major goals:
- Provides the customer with feedback, enabling him to assess whether the development organization has understood correctly and completely the problems or issues to be solved and the behavior needed of the system. Therefore, the document should not use any formal language, but a natural language which is more suitable for the customer.
- Allows problem decomposition. By writing down the requirements, definitions and delimitations of subproblems become visible, ideas are clarified and detailed, non-related issues are separated.
- Serves as base for the design specification. Thus, it should be written in enough detail to make creation of the design specification as easy and natural as possible.
- Can be used to define product validation checks. Since it describes the system from the functional point of view, it helps in the process of writing test cases.
|
|
