I think that your team might need a little more organization, use tools like Jira to organize yourself and the requirements, try to use SCRUM methodology and you'll be more on track I believe

My suggestion is to use best practices for user story creation, like to follow the INVEST principle, also you need to have Grooming sessions for your stories which would go into sprint. You should practice static testing of your available design documents and available requirement - while doing that you could find missed requirements. Try to create FAS (feature analysis specifications). Also you can try to assign a role of requirements analyst to one tester or dev.
In short, it all depends of what sdlc/stlc you are following.

It would be helpful if you explain the context a bit.

What kind of requirements have been forgotten most in your past?
Functional requirements, quality requirements, constraints?
What was the reason they were forgotten?
Were all the right stakeholders involved early enough?

In my experience, quality requirements tend to be forgotten more often (e.g. the so called -ilities, useability, realibility, also things like performance.)

There are lists of quality attributes that you can pick your checklist items from. The most well known is probably FURPS.

Concerning functional requirements, learning about Story Mapping may be interesting to you.

Many sprints (Scrum or Scrum-like) each:

1. beginning with a product manager entering as many use-cases (stories) as he can think of no matter how do-able, etc, they are and prioritizing them in terms of user/business importance.

2. This is followed by a brainstorming session with the whole team pointing the stories, possibly adding more (oh wait, X requires Y & Z), potential splitting or otherwise organizing stories and adding associated tasks.

3. Now do the sprint (dev & QA)

4. Present the work done to the product manager and end users (if possible) and get feedback. Don't let anyone out of the room until you get good feedback.

Repeat (go back to step 1) several/many times before scheduled deadline.

=> Do not skimp on steps 1,2 & 4 because you want to concentrate on step 3. This is the most frequent problem and it's self-inflicted!

The actual use of the points, etc (e.g. Velocity, Burndown, etc) is optional.

If the problem is identifying requirements in the first place, one practice I would recommend is dogfooding. Sometimes teams will narrow their focus on just the exact features they're developing and the precise success criteria that a customer or dev manager has defined ahead of time. Possibly they may even state a feature has been completed when it only passes unit tests but they haven't actually tested the feature directly by interacting with the application as a whole. When people include directly using the product as part of their development activity, gaps and corner cases become obvious much sooner. Everyone, including developers, should be using the application as a whole and playing around with it. Try resizing the screen, or using unusual gestures, or entering odd data into it - whatever is applicable - to see if something jumps out as missing or broken.

The question is a little vague.

Do you guys do design reviews?

Or are you in just in such a hurry to ship code that nobody is even really sitting back and making sure you're building the right thing in the right order?