Is this a common practice if requirements cannot be collected for a certain period?
It could happen, however, if you don't know something, you will guess or ignore it. If this thing is important to the user, chances are they are not going to be happy unless your guess was correct! People who know a particular business well can sometimes guess minor details based on previous experience. Even this may not always work. For example, each bank has its own policy when it evaluates a new customer for a loan. If you skip on the rules or use another bank's criteria, this does not help.
If you can't get all the requirements, it's either because the users don't know how to answer your questions or because your team is not able to ask the correct questions. In either case, the project would be at risk. Certain requirements may be phased into a future version as you suggested. However, this may be risky in some cases. For example, in a project using a Relational Database, missing a many-to-many relation between two tables, requires work on the database and may require a change in the GUI. A practical approach is to:
- Identify what is missing.
- Identify why it has not been finalized.
- If the problem is in your team, fix it.
- If the problem is the user team, clearly identify the risk and possible associated cost. Maybe ask for a change in the user team. Use escalation procedures to make the big fish aware.
- If you make assumptions, document these assumptions carefully.
- Get a sign-off on the entire analysis effort - The good parts and the bad parts of the analysis.
- Always remember that incomplete or bad analysis could easily kill any project.
This may be relevant: Dealing with incomplete requirements