5
I am a developer who works alone and for some time questioned here on what documents would really be important to be produced at the start of the development process.
Analyzing the accepted answer, it seemed clear that the first document that really needs to be done is the project vision document that there is described as:
Project vision: what problem will be solved and how it will be solved and what value this solution will be to the customer. This is very important to stay focused and not be distracted by what is not a priority or divert the project from its primary objective. 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 and Requirements Survey and How to get the necessary knowledge about a domain? it seems clear to me that the project vision document is extremely important, including the starting point for backlog assembly and the organization and prioritization of what needs to be done.
Having this in mind, I researched a little about how to write this document, what should be contained in it, how would be the ideal way to structure and write this content, finally, how to do a good and useful vision document. After all, it is not enough to write anything, what is produced needs to be really useful.
I came to find some models, one of them (which may be downloaded here) it seemed reasonable to me, but it deals with issues even user interface, and I do not know if that is exactly what is sought in this document.
In this context, my question is as follows: 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 I thought should be contained are: motivation for the software and problem to be solved and actors who will interact with the software, but surely there is other information needed.
With whom should we seek the information for the construction of this document? In case the software is done at someone’s request, I believe the information should come from the applicant, but if the software is my idea, I will have the information to assemble this document?
Finally, in summary, how to assemble a succinct and useful project vision document?
EDIT: In view of the votes for closure, I think it is worth clarifying that no response based on opinions is sought. From what I understand in the other questions that I asked the writing of this document is an important part of the requirements collection process and, obviously, there are ways of doing that will result in a useful tool for development and ways of doing that will not add value and will only complicate life. What tells you how to do it right, what the document should contain and all that, is experience. In this case, what I am looking for is an answer not based on opinion, but on experience, being the objective answer in the form: "In this way it has already been tried, it has been used and it has worked".
It is not an issue properly classified as software project) (design software). Removing this tag will make it easier to locate issues.
– user158926
Your question talks about product (software), design, development process. The document that cannot fail to exist in any project is the project opening term and the WBS (or EAP in Portuguese). Everyone else will depend on the nature of the project. Additionally, in view of the doubts raised, it would not be possible to create a product vision document, a project would be necessary to create such a vision (registered in the product vision document). What do you say?
– user158926