Plans for any system under development will tend to change over time. This happens as understanding changes and increases on both sides (developer and "customer", or analyst in your case) over time. The fact is that due to the inherent complexities of software development, neither of you is likely to know exactly what the end product will look like. In my personal experience, the end product is often significantly "slimmed down" compared to the initial idea. If it can still delivers the most important things the end users want, and is considered a success.
I'm sure the analyst will have a handful of ideas and perhaps a grand long-term vision for what you are building, but he won't have all the details, and he'll likely lack at least some technical understanding, not only of the potential difficulties, but also of the possibilities ahead.
In addition to coding then, your job is two-fold:
- To try to understand the business as well as you can - not just the abstract spec from the analyst, but also what the end user actually wants and needs. For this, I'd actually try to talk to one or more end users if possible; even a 5-10 minute conversation can clarify a lot, and perhaps simplify some of the requirements.
- To convey back to the analyst (and perhaps the end users) which options they have, and how they compare. If you can help them understand the cost (or the alternative cost) of each option, then you can help them make better, more informed decisions. If you're lucky, perhaps you can find things that can be dropped or modified slightly to made development faster and easier. If you can identify simple improvement opportunities as well, then even better.
If you think the analyst is misunderstanding something, or making decisions that are resulting in an suboptimal use of time and resources, then try to find a way to share your thoughts. Try to be constructively though - avoid stepping on too many toes. How? Provide positive alternatives: Instead of just saying "I don`t think this is going to work", try to go more along the lines of: "I'm not entirely certain that this is the best approach. Have you considered any other options? How about either X or Y?"
Nudging someone along like this can be a delicate balancing act, especially if pride is involved, and it may feel as if it has little to do with programming. If you want your work as a developer to continue to feel positive and meaningful however, it's important to be able to tackle such things.
In the end, it's all about developing a sense of responsibility and ownership both to the process and to the product you're building. Any good business analyst should appreciate this, and welcome your feedback and input - so long as it is provided in a professional and respectful manner.