Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I am learning a little bit about project management with the book, "Making things happen".

Now I'm confused what the vision, requirements, design, and specification are. If I read the book everything seems logical but if I try to write such documents everything falls apart. :)

For example (based on a mixed hardware/software product where we will develop a next generation):

  • Vision:

    • Generation 2 of product should be easier to manufacture and support
    • The user should be able to configure the system
  • Requirements:

    • Production cost targeted at Generation 1 less $1,000
    • Product shall be bluetooth capable with an Android App
  • Design/Specification (I haven't understood the difference):

    • Replace the motors with cheaper ones
    • Add an arduino with a bluetooth shield to communicate with the android app

Are the points i have as vision and requirements okay? I have no idea what should be in the design and what in the specification.

Thanks for your help!

share|improve this question

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer

To me, this is a Vision Breakdown Structure, just like a work breakdown structure. You are taking something from the abstract and strategy level and breaking it down to the very specific and tactical.

It is easier to see if you think about a product with which we are all familiar, like a car.

Vision: To be able to transport people and material quickly and efficiently using green power technology

Requirement: Move family of five with up to 500 pounds of cargo; between $30K to $50K price; adverse driving conditions capable; several configuration choices; hybrid technology

Design: SUV with four doors, 6- and 8- cylinder engine between 250HP to 300HP enabled by both fuel and battery, both manual and automatic transmission

Spec: Specific body structure, specific engine model, specific transmission types.

Each of these levels is linked by degree of abstraction. If you meet the tactical, you fulfill the strategy and vision.

share|improve this answer

Take this with a grain of salt because my corporate world may be different from your corporate world.

  • Vision is your richly-imagined future, addressing what it is and why you want to be there, and what your guiding principles are. An example is the mission/vision statement for Target stores "Our mission is to make Target the preferred shopping destination for our guests by delivering outstanding value, continuous innovation and an exceptional guest experience."
  • In order to achieve your Vision you need to define key Business Capabilities that will bring you to the end-state. The "vision" that you list reads more like business capabilities to me.
  • Business Capabilities are fleshed-out by defining Functional and Non-Functional requirements. I think your second bullet under requirements falls in this category.
  • Design describes how the requirements will actially be implemented. I think your bullets under design would fit here.
  • Specifications refer to acceptance criteria that define successful achievement. I think your first bullet under requirements is a specification. Others could include e.g. processing time.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.