A vision is typically a high level view of what you ultimately want to achieve as a result of the project. You would use it to describe the project, identify stakeholders, define success criteria, and goals and priorities. You may also use such a thing to begin to define the most important assumptions, dependencies, constraints, and risks.
In Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Geoffrey Moore presented this template for a vision statement, that would be the most minimal format for a project vision:
For {target customer or user} who {statement of need}, the {product} is a {product category} that {key benefit(s)}, unlike {current state, alternatives}. Unlike {competitors or current state}, our product {primary differentiation and advantages}.
From a vision, scope, or charter, you develop requirements. A requirement is a statement of need of the product or process that is being developed. There are several qualities of a good requirement: cohesive, complete, consistent, atomic, traceable, current, unambiguous, specify importance, and verifiable. A requirement could appear in multiple formats, from a more traditional shall statement ("the system shall compute the distance between two points to an accuracy of no less than 6 inches") to a user story ("as a buyer, I want to be able to add one or more items to my shopping cart for later purchase").
A requirements specification is the set of requirements that a system is to fulfill. Customers and users may have many requirements, but some may not be fulfilled by the system. In a complete system, you can look at its requirements specification as a list of its characteristics. In a system under development, it is the intention for the next milestone.
A design indicates how the requirements specification will be realized. It's a model, simulation, prototype, or other conceptualization of a system. It provides details as to how each requirement will be met and how pieces of the system interact with each other. Sometimes, however the final design is captured is referred to as the system's design specification - this is exactly how the system is to be instantiated by the creators.
The formality, ceremony, and types of artifacts produced for each of these depends on your product development lifecycle, engineering methodology, and project complexity.
Going back to your specific examples for each phase:
Generation 2 of X should be easier to manufacture and support
To me, this isn't quantifiable enough. What is "easier to manufacture and support" mean, exactly? You should quantify this in terms of reducing the need to support (by increasing quality), amount of time to build or repair, or some other measurable goal so you know what current state is, what optimal state is, and what would be considered success or not.
The user should be able to configurate the system by himself.
This may be something you would want to include in your vision, moving configuration out of the hands of technical experts into the user.
Production cost should be 1000$ lower than Generation 1
I don't like the use of the would "should". In order to be successful, is there a minimum amount that should be reduced from the production cost? If so, I would state that as a requirement explicitly with a "must" or "shall" statement. If there are stretch goals, you can use "should" to set a stretch goal.
X should be configurated over bluetooth with an Android App
Again, requirements that are mandatory should be "must" or "shall" statements. I would also consider breaking this up into two requirements: one to allow configuration over Bluetooth and a second to require an Android application to support configuration. This would make the requirement atomic.
replace the motors with cheaper ones
Add an arduino with a bluetooth shield to communicate with the android app
Both of these are things that I'd expect to be realized in a design. I wouldn't necessarily include these anywhere, unless you were on the engineering team doing the design.
There is a business requirement to reduce cost. However, mandating a particular part be replaced with a cheaper (often meaning lower quality) part may compromise product quality. Let the engineers determine if there are ways to achieve the requirements without compromising quality. Somehow, a different motor would be captured, perhaps on a parts list or a drawing or model, if that was one of the things that was changed to continue to meet the requirements.
Choosing Arduino and a Bluetooth shield is indeed a design decision. But again, that's something that flows out of requirements. Often, you may develop multiple designs that are valid. It becomes a matter of choosing which design (or perhaps elements from multiple designs) are best suited to achieving the requirements.
If you're interested in books about the early phases of a project, I can recommend Practical Project Initiation and Software Requirements. Between the two of them, they cover from early project initiation, vision, and scope, right up to the start of engineering design. They are focused on software projects, but would be applicable to multidisciplinary projects that involve some level of software as well. Software Project Survival Guide is also an interesting read across software-intensive project management.
