Software requirements define the objectives an application must achieve. These objectives can include conditions or capabilities that help a user achieve something or conform to a system requirement. Software Requirements Specifications or SRS are the means through which these necessary capabilities and conditions are articulated. In order for modern SRS to perform its role well, it must encompass the four fundamental doctrines that ensure understanding between client and developer.
Feedback to the Client
One way to think of an SRS is as a guarantee to the client that the developer recognizes and understands the goals that the software must achieve. That means that even though written by technical writers, an SRS must be written in plain language. The language should be unambiguous, and understanding should be increased through visualization, which can be achieved with charts, tables, diagrams and more.
Decomposition of the Problem
Even if software exists to overcome but a single problem, that problem can be refactored into a number of component parts. Software requirements therefore must be articulated in a manner that presents the problem as simple as possible and organizes it. From the perspective of the end-user, an effective SRS puts borders around the core problems. It also solidifies solutions and shows how these various parts will work together in an orderly and practical fashion.
An Input to the Design Specification
The SRS shapes the design specification. It is the parent document and therefore all subsequent documents derive from it. This includes the statement of work and the software design specification. The practical implication therefore is that the SRS must not only articulate the software requirements but must contain enough detail that a functional design solution can be created from it.
Testing and Validation
The SRS also serves as the parent document for all testing and validation. This includes unit testing only ever seen by the developers as well as proof of concepts and suitability validations that the client sees. What will be tested must be defined but also how that testing will be realized and what the goals will be.
Software requirements and the resulting SRS will vary from one project to the next. They cannot be judged on those individual aspects but on the four core pillars outlined above. Achieving this begins with a series of information gathering stages, including interviews and ROI analyses. The specification is then written based on that data and often revised multiple times until polished. For more information, additional resources can be found at Blueprint Software Systems.