A little creativity goes a long way for developers and testers, who often think of many feasible ways to build or evaluate software. However, they must stay in line with specifications, which detail how a software ultimately will work.
A software requirements specification (SRS) serves as the foundation for any software development project. Developers, in concert with professional writers, create SRS documentation. Senior developers, in particular, can lean on their experience collecting client input to shape the final product and record this information in an SRS.
SRS authors must clearly understand the process of requirements gathering. SRS documentation must be complete, consistent and unambiguous, and it needs to steer clear of subjective language and superlatives. A good SRS takes time and effort to create, but it's worth it, as it can clarify goals, speed results, lower costs, improve software quality and create customer satisfaction.
SRS documentation describes a number of aspects about an application, including:
- the software's functionality;
- external interfaces, such as the UI or APIs that connect the software to other business systems;
- performance requirements, including speed, availability and response time;
- portability and security attributes; and
- relevant constraints, such as prevailing standards, resource limitations and database needs.
It's just as important what the SRS author leaves out. SRS documentation should focus on the product itself. Avoid project or process discussions about cost estimates, delivery schedules, development methodologies, test and validation criteria, and customer reporting. While these points are all important to the project's success, different documents can outline their criteria. Separate from the SRS, the software team should discuss a competitive bid request, a development plan or other documents.
Continue reading at TechTarget.com
All about Requirements
How to Write and Structure Worthwhile SRS Documentation