For any large software project (i.e. one that requires more than a few scripts performing a one-off task) and for every project that was initiated by a customer request, it is useful to precisely define the requirements before starting to write any code. This might be painful at times and slow down the coding fun, but it should avoid a lot of frustration on either side in the end.
Here is a short summary of what Software Requirements Specification (SRS) (IEEE 830) are, how to write them, what they are good for.
SRS is a complete description of the behavior of a system to be developed, including use cases.
The benefits of writing specifications when planning a software project are:
- Establish the basis for agreement between the customers and the suppliers on what the software product is to do.
- Reduce the development effort by avoiding redesign, recoding, and retesting and revealing omissions, misunderstandings, and inconsistencies early in the development cycle.
- Provide a basis for estimating costs and schedules.
- Provide a baseline for validation (comparison against what the customer needs) and verification (comparison with the formal specifications).
- Facilitate transfer to new users or new machines.
- Serve as a basis for enhancement.
Key points to address:
- Required functionality.
- External interfaces.
- Performance.
- Attributes.
- Design constraints imposed on an implementation.
Avoid design details and coding details in the specs. Hardware requirements etc. go into general System Specifications, not SRS. The content and language of the document should fit the description with the following key words:
Complete, Consistent, Accurate, Modifiable, Ranked, Testable, Traceable, Unambiguous, Valid, Verifiable
Descriptions of “use cases”, mock-up GUI components and other visual aids are extremely useful to communicate with the parties involved.