I do not have the access to the IEEE standard and information on the net are contradictory. Can I capture user requirements in SRS using use cases? Or I should keep use cases separate as they are more like scenarios than separate requirements?
The answer is yes, you can use UML Use Cases to describe requirements in your SRS, however, the original SRS needs to be customized for that purpose because the standard is out of date.
It is important to bear in mind that the latest published version of the SRS standard IEEE 830-1998 is from 1998. The standard does not apply well to modern software engineering. Instead of following it as-is, we can use it as a basis for defining our own SRS.
One of the reasons is that in 1998, requirements were typically written as required functions. The major paradigm was procedural programming. Often, requirements were stated in a natural language. Today, we are using object-oriented programming and different techniques/tools to support it.
The best practice is, and always was, to write unambiguous requirements. For that, UML is a perfectly viable notation. The only suggestion would be to consider also textual use cases before deciding on graphical diagrams. Use cases contain much more information in text which helps to clear out possible misunderstandings.
Accessing the Standard
Without the need to buy a copy of the standard, you can read its outline available for free at wikipedia. Some software engineers have been using IEEE 830-1998 as a basis for their own custom SRS. That is how issues with its age can be addressed.
Examples of Customized SRS With Use Cases
Paper on the topic (A good enough solution to follow)
UML Use Cases were written long after the IEEE standards on SRS (UML in 1994 and SRS ten years earlier in 1984). Therefore there aren't really a reliable source on answering the if-and-where use cases should be in an SRS.
The IEEE standard for an SRS document mostly tells you how the document should be formed. So if you really want the use-cases placed somewhere in the SRS it would be under the "Specific Requirements" part of the document. Use-cases are specific scenarios and should be treated as specific requirements.
However the first step you should ask your client or reciever what they want from the requirements document. Do they really want to have UML Use Cases or something else? There are a bunch of ways to elicit requirements and some clients most likely want it their way. For reference check out the book "Software Requirements - Styles and Techniques" by Soren Lauesen.