I am a developer who has been working alone for some time I asked here about which documents would really be important to be produced early in the development process.
Looking at the accepted response, it seemed clear to me that the first document that really needs to be done is the project view document that is described here as
>Project Overview: What problem will be solved and how it will be resolved and what is the value of this solution for the client. This is very important to stay focused and not distract yourself from what is not a priority or divert the project from its primary purpose. This document is very short and the simple act of writing it, as I said, helps to deepen the understanding of the problem and the solution.
Combining this with the discussions presented in the questions Domain-Driven Design e requirements survey and How do I get the necessary knowledge about a domain? it seems clear to me that the project vision document is extremely important, including it being the starting point for backlog assembly and organizing and prioritizing what you need be done.
With this in view, I researched a little about how to write this document, what should be contained in it, what would be the ideal way to structure and write this content, how to do a good and useful vision document . After all, it is not enough to go out writing anything, whatever is produced needs to be really useful.
I came across some templates, one of them (which can be downloaded here ) until me it seemed reasonable, but it does address user interface issues, and I do not know if that's exactly what you're looking for in that document.
In this context, my question is: how to write a good and really useful vision document for the project? What should it contain and how should it be structured? Some points that I thought should be contained are: motivation for the software and problem to be solved and actors that will interact with the software, but certainly there is other information needed.
With whom should we seek information for the construction of this document? In case the software is made at the request of someone, I believe that the information should come from the applicant, but if the software is my idea, I will have the information to assemble this document?
Anyway, in short, how do you assemble a concise and useful project vision document?
EDIT : By virtue of the closing votes, I think it's worth clarifying that you're not looking for an answer based on opinions. From what I understand in the other questions I've asked to write this document is an important part of the requirements collection process and obviously there are ways to do that will result in a useful development tool and ways of doing that will not add value and they will only complicate life. What tells you how to do it the best, what the document should contain and everything, is experience. In this case, what I seek is an answer not based on opinion but on experience, being the objective answer of the form: "this way it has already been tried, it has already been used and it worked."