There are no rules for how you organize your use cases. It looks like you're ordering them by ID now, which makes sense. But there's no reason why you couldn't split the table into multiple tables based on some alternative grouping. The important thing to do is to make sure that each requirement (in this case, your use cases) have a unique identifier that allows you to link use cases together (such as parent/child relations that it looks like you have).
However, my bigger suggestion would be to stop using a document to capture your requirements. Instead of using a word processor to product a document, use a tool designed for managing requirements. There are quite a few options out there. A spreadsheet would be a huge step up, since most spreadsheet applications have the ability to do things like dynamic coloring of cells based on the cell's value (or another cell's value), sorting, searching, and filtering. Some ticketing systems can also be used for a requirements life cycle and add tagging or labeling, searching, and sorting, and perhaps integrations with other tools, including the ability to export to a document format if you need one. This would allow you to give better views of requirements to your users on demand.