You are kidding me right? The information you have presented indicates only that you have a problem. It provides nothing about the nature of the problem nor what you've done to try to solve the problem, let alone the parameters within which the problem exists.
My early suggestion would be that it is critical that you use the Search button and/or google to work it out for yourself...
But, there are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they exist. Here's one approach to finding those "hidden" requirements.
First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage.
Then, interview the project manager or developers and find out what they intend to do with this release. Document the intentions and use them as requirements.
Solicit input from anyone who is a stakeholder in the project. Share everything you find with everyone and revise it as needed.
Sometimes, writing all of this up as assumptions can go a long way toward gaining a consensus as to the "real requirements" you can use to test against.
Once the system is at all testable, do some exploratory testing. As you find "undocumented features", add them to the list of topics to be discussed.
Find out if the product is internally consistent. (This is an area I find to be very useful) Even if I know nothing at all about a product, I assume it must be consistent within itself, and within the environment in which it must operate.
Look for external standards within which the product must operate. If it is a tax or accounting program - tax law must prevail and generally accepted accounting principles must apply.
Ideally, all of these issues have already been considered and written into the formal Requirements documentation, which is handed to you.
But if not, don't give up. Dig in and discover!
This was said Joe Strazzere in his blogs not by myself i agreed him.