Living in the real world, changes are probably going to happen to requirements unless there's a very short build time.
How you handle them depends on your build methodology.
If you're running a standard waterfall, then you need to freeze requirements at some point to start building, and then manage any changes via change control. In the 'house' example, if the house is half built and needs to moved 10m to the left, then the impact and costs are high, but the impact of changing the roof tiles is small. That's why you'd do an impact assessment as part of your change control. It may be that changes remove requirements (not frequent, in my experience) or change them so significantly that you need to stop building as the resultant product no longer has a value to the business.
If you're adopting some form agile approach, then requirements can be more fluid, and are fed into each iteration the build team works. You might, therefore, decide to leave articulating some (possibly lower priority) requirements until after the build team have started on the high priority requirements.
Some projects lend themselves better to one methodology. Web projects tend to work quite well with agile methodologies, I think. Big infrastructure projects don't.
I think the real question is not so much whether you freeze requirements, as how you work.
I hope this isn't homework....