A software requirements specification (SRS) is an important document that reports the result from the system requirements determination (SRD) which forms a basis for subsequent activities in the systems development process. In order to increase the knowledge base of SRS and how they could be structured nine SRSs are analyzed. The analysis aims at demonstrate similarities and differences in SRS composition and requirements organization. The reason for doing this is to be able to give some advice on how a SRS could be improved and thereby supporting development of information systems better. The result from the analysis shows that SRSs are structured either by following the IEEE (Institute of Electrical and Electronics Engineers) standard 830 with three main sections (introduction – overview – list of requirements), or another structure (introduction – references – list of requirements). In what specific way specific requirements in SRSs are structured differ from SRS to SRS. The most frequent type of requirements is functional requirements, which is not a big surprise. However, more unpredictably is that non-functional requirements are getting so low attention. One finding is that even though using standards might not be the only way to formulate SRSs, they are being used and serve their purposes, at least to some extent. But, standards high focus on functional requirement could be an influential factor explaining SRSs high focus on functional requirement. The main conclusion is that future SRSs should spend more focus on non-functional requirements since these are both more difficult to describe and will probably play an even more important role for information systems in the future.