Q:

What is the importance of the vision document and how it helps development?

I'm a developer that works alone, and recently, searching for what kinds of documents I still could benefit, even though I don't require anything formal, I've read that one document that still is highly recomended to write is the project vision document.
I found it described as a short document (a page and a half or two) containing what problem has to be solved, how it will be solved and how the end user will benefit from the solution.
Reading more, it seems that this document is one extremely important input to discover the requirements and finaly the user stories.
In that case, considering that this is, as I understood, the first step when starting to build a software, what is the importance of this document, and how is it used so that it helps the development?
I still don't fully get how such a simple and short document can be that important and help that much.
How is this document important and how it is used to help the development process? In particular, what is the role of this document in the requirements gathering process?

A:

Considering you are working alone the vision document would be less useful for you than most as it's mostly a communication tool. More importantly however, the vision document is a reference point, something you can look back to and determine whether or not your efforts are going to the right place.
Even as a solo developer we can be in two minds about design decisions, or change our minds over time. It might be useful to trust your original vision. If your focus for a tool is to be "multi-platform", but you find yourself getting bogged down with using platform specific code because you're rushing solutions, you might look back at the document and remind yourself of your original idea and way of thinking. It can help you prioritise.
The vision document would also help you to communicate with others what it is you are making to fellow enthusiasts, friends and if the project grows in the future to include an audience or other stakeholders.
It forces you to think about all of the right questions: why, how and what.
Personally I've found it much easier to recite an "elevator pitch" after writing a vision document, because I just quote lines from the vision document.

A:

The vision document describes how the stakeholders see what the future for the product should be.
The goal of the vision document is to keep everyone who is involved in the development of the product focused on the direction that the product should be taken into.
Without a vision document, the chances are high that different stakeholders/departments will try to steer the development in their own direction, with the developers getting caught in the middle with a bunch of conflicting requirements.
If there is a vision document, then it is easier to say "this vision document is the direction that all stakeholders agreed upon and your new requirements deviate from that. We can't take them into consideration until a new vision is agreed upon."

