Software Requirements 

Always remember:

Our goal is not to create great specifications, but to create great products through great software.

Early efforts will pay dividends downstream, if there is too little time to specify upfront you probably have too little time to do the project.

There is no single 'correct' approach, use whatever makes sense for your project.

Typical Documents

System Specification
The heart of the SRS contains explicit descriptions of the functional and non-functional requirements of the project, performed by hardware, software or both, and where possible referencing the source of the information. It provides a basis for estimating costs and schedules.

Careful review of the SRS can reveal omissions, misunderstandings and inconsistencies early in the development cycle, where they are significantly cheaper to fix.

Functional Specification
Based on the functional specification, this document describes how the product works from the perspective of the user, describing screens, menus, dialogs etc.

This document is technical in nature, providing enough information to avoid ambiguity, describe all features including what happens when things go wrong, but must still be understandable by the client.

Technical Specification
This is a highly technical document, describing the internal implementation of the software.

Typical Methods

Use Case
Unified Modeling Language includes set of graphical notation techniques to create models of software systems. One such use method is the use case, these are a systems analysis methodology to identify, clarify and organise system requirements. They describe a set of sequences of interactions between systems in a system, and related to a particular goal.

Use Case Diagram
These make no attempt to represent the order, or iterations of a system actions.

Atomic Requirements
Each requirement represents a single market need that must be either satisfied, or not satisfied. A well written atomic requirement is independently deliverable, and adds value to your software.

IEEE Guidelines for Requirements
Correct: Including keeping the specification up to date when you find things that are incorrect.
Unambiguous: There must be only one interpretation.
Complete: Containing all that is required by the developers to create the software.
Consistent: The specification should be consistent with itself and its reference documents.
Ranked: This helps protect from gold plating, and marketing nice-to-haves.
Verifiable: Provide quantitative requirements, if possible.
Modifiable: Try not to have the same requirement defined in multiple places.
Traceable: It is often, though not always, necessary to trace the requirement to higher level documentation.