Regardless of the tool of your choice, there is a subset of information you may want to collect:

ID: A unique identifier will be needed since the requirement will be cross-referenced in many different contexts, such as test cases, documentation, and code comments. It can follow a naming convention or simply be an incremental number.

Description: A verbal explanation of the use case to be implemented.

Precondition: (If relevant) the situation that the use case originates from.

Essential: How essential the requirement is, usually classified as must have, should have, or nice to have. This may be useful in order to filter requirements to be included in a release.

Priority: A way to order/cluster requirements. Also, a useful way to filter requirements to be included in a release.

Source: The author of the requirement. It may be a department, but it is better if there is also a named owner to contact in case of clarifications being needed.

Group: A way to cluster requirements for functional areas. Also, can be a useful way to collect a set of requirements to implement in a release.

Parent: This is optional, in case you want to implement a hierarchy with a complex/high-level requirement made of a set of sub-requirements