Software requirements specification (SRS) is, in the software development process, a result of the requirements and specifications phase. That is, a software requirements specification is for the analysts to find out what the customers indeed expect the software system to do for them. When working on the software requirements specification, we only specify what this software system is, but never ask how this software system shall be manufactured. A software system has been specified, by software requirements specification (SRS) 1.0, hopefully to be an integrated whole, embodied in its assembled components, their interactions with each other and the environment. Since software structure and software behavior are the two most prominent views of a software system, integrating the software structure and software behavior apparently is the best way to achieve a truly integrated whole of a software system. Because software requirements specification 1.0 does not specify the integration of software structure and software behavior, very likely it will never be able to actually form an integrated whole of a software system. Structure-behavior coalescence (SBC) provides an elegant way to integrate the software structure and software behavior, and hence achieves a truly integrated whole, of a software system. A truly integrated whole sets a path to achieve the desired software requirements specification (SRS). SBC facilitates an integrated whole. Therefore, we conclude that software requirements specification (SRS) 2.0 using the SBC approach, which contains three fundamental diagrams: a) architecture hierarchy diagram, b) component operation diagram, and c) interaction flow diagram, is highly adequate in specifying a software system.