Vision Document, A Practical Approach!
We all know a Vision document is the constitution of the project; it is the most critical document in both agile and UP based software development methods. This document represents a bird’s eyes view of the project and its boundary, including problem statement, constraints in addition to the required services for addressing the problem. This document is a pillar of transparency in the project.
If you confront a vision document as an audience for the first time, you would be surprised how wisely the information is organized in this document and how good it guides you to find out the problem and the general idea of the solution including some other detail about the project and the product environment. On the other hand, if you are a software engineer with no experience in writing a vision you will get confused. It’s not your fault or weakness, because this format is optimized to facilitate communication with the readers not for its writers.
For those, who may forget the general format of a vision document I should recall, this document consists many parts including Problem statement, product positioning, Stack holders, Users, stack holders’ needs, product perspective and environment, features besides project constraints. For more information visit this URL: http://sce.uhcl.edu/helm/rationalunifiedprocess/process/artifact/ar_vsion.htm.
First of all, a vision starts with a problem statement, that is a short business description of the problem at hand, which describe why do we think this problem is a problem? And who would be suffered by the problem? Moreover, what are the adverse effects of the problem and how the business situation would look like if we could solve the problem? Following table represents the problem statement section.
Now, which field should be filled first? Usually, it’s tough to find the problem at first try because as human kinds we need some evidence to get a sense about a phenomenon and its roots, for instance, do you remember about the story of the apple, Sir Isaac Newton and gravity? Newton saw an apple’s fall down then discovered the reason, the gravity. So we may need an apple for finding the main problem, it is the “the impact of which is” filed in the table. So, I suggest you fill the Problem Statement table in the following order:
- The impact of which is
- The Problem of
- A successful solution
The second table in the document is the product positioning which represents an elevator speech to describe the problem, solution and its abilities including competitive attributes of the solution against other options as alternative solutions. Next table shows the appropriate format for this information.
This table provides an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.
But Wait, how could you find the appropriate phrases for [product category] statement or these [statement of key benefit; that is, the compelling reason to buy] and [statement of primary differentiation] in the table, do you have adequate information to fill this blue prints? Of course you DON’T! So just skip this table and go to the Stockholders table.
Stockholders are the people or organizations who may have some effect on the project or vice versa, it means these guys are the root of the needs or constraints. The following table provides sufficient information about them.
We can find these stakeholders using some requirement gathering techniques and write their data in this table. As the problem statement provide initial data to find the stakeholders, doing this step can be the second step in the Vision development process. Based on the vision official format, the users’ information must be represented in a table as following precisely after the stakeholders’ section.
But, how do you find the users? Do you know what should you do as the solution? Do you know what are the features of the final product? Who may use those features? The most common answer is NO. So just leave this step and continue.
In the next step, we have to find the main Stakeholders’ needs, based on the suggested format for documenting the needs, there are some places for the proposed solution for each of them, to express general ideas about the solution. This step is a great candidate to be done as the third step. Now go ahead and fill the following table:
As the forth step, we have to say what should our product do to meet the needs, these services are the product’s features which will be represented in some descriptive text and paragraphs.
Then as the fifth step, we have to describe the product’s perspective and its relation to the surrounding world, as a result, we will have some primitive idea about the category and users of the final software. moreover, the sixth step is to going back to the Users’ table, because now you have enough data to identify and write them down.
The seventh and last step in building the principal stub for a vision, fill the product positioning table as a brief of the problem and solution. Although there are more elements and detailed information in the vision they are just supplementary data to the stub, so you can fill them as any order you wish.
To sum up, in fact creating a vision is a technique to represent critical information about the problem and solution space, also the standard format for this document is optimized to make these areas more understandable for its readers not for people who should develop it. A linear approach to producing this document based on its steps in the document’s template results in a collection of useless information with no rational relation among them.