The information that I find important when understanding the requirements of a software system or component include:
The context of the software system.
The system boundaries. What is the scope of the software described by these requirements in the context of a larger system? What are systems that this software has to interact with or exchange data with?
The top level functions. A brief executive summary of what the system does or is supposed to achieve. Given a set of more detailed requirements, what is the purpose of this set of functions and attributes?
The interfaces. If users interact with this software, how do they do it? Do they run it from the command line with arguments? Is there a textual UI? A GUI? How does it communicate with other pieces of hardware and software? Are there requirements to use certain physical interfaces (like RS-232 or USB)? Are there fiber connections or Ethernet connections? Beyond the hardware, are any specific communication protocols required when communicating with other systems?
Who are the users? What are their characteristics, experiences, knowledge, training, familiarity with the domain or similar systems? Consider not just the daily users, but also people who have to maintain the software. Will updates be managed by users or by professional IT?
What assumptions are being made in the rest of the requirements document? What dependencies exist on other software? If multiple pieces of the system are being build concurrently, is any functionality blocking other pieces from starting or finishing? Are any of the requirements blocked until functionality is provided by another component?
Specific requirements.
Functional requirements, or the functions that the system must provide.
Non-functional requirements, or quality attributes. Descriptions of how the system must behave. Examples include availability, fault tolerance, performance, portability, usability, security, and so on.
Other types of requirements and design constraints. Examples include documentation and how it is presented to the user (eg users manuals and/or built-in help and support), configuration management and escrow, and licensing or legal concerns.
If you have the money, I would recommend both books. If you don't want them, maybe your company can buy and own them if there is a company library or something like that. Either way, they are must-reads for anyone working on requirements gathering/analysis.
The information that I find important when understanding the requirements of a software system or component include:
Karl Wiegers, author of Software Requirements and More About Software Requirements also has a website called Process Impact. Although the templates are for sale, you should check out the Goodies section, which has documents that are released for the nominal sum of $5.
If you have the money, I would recommend both books. If you don't want them, maybe your company can buy and own them if there is a company library or something like that. Either way, they are must-reads for anyone working on requirements gathering/analysis.
I also have to recommend not only the book that Donut suggested in his last sentence, Software Requirements (2nd Edition), but also a companion to that book - More About Software Requirements. Both books are by Karl Wiegers, and his website has some interesting reading as well, in particular the Goodies section, which has freeware sample documents and templates.