Question

In the context of design, what is a Product Vision Document and what two documents from Traditional Requirements Engineering does it replace?

Answer 1

Product Vision Document:
A product vision represents the core essence of its product or product line. A strong product vision is supported by details of who the customers are, what they need, and your go-to-market plan. It captures the essence of what you aim to achieve, the opportunities you have, and the threats that you face.

Traditional requirements are usually thought of as capabilities and constraints of the system; the key
term being system. All good requirements describe what the system can do or shouldn’t do, but those requirements that focus intensely on the system tend to deemphasize user interaction or business context related to the user or business. To be fair, many traditional requirements do
provide context for business and users, but that is usually not the main focus of the requirement, rather it’s the system that is the focus.

The difficulty with having the system be the focus is that it’s easy to make assumptions about what the user wants. I’ve seen requirements be the source of record for the system’s operation. In such a case, interacting with the business or the user while the system is being developed reverted to a series of painful, negotiated change request. The work became a matter of giving the user exactly what she asked for, which may not at all be what she needed.

This is what really makes traditional requirements tough: They’re written from the system perspective. Additionally, they’re often written in the context of a process that enforces change control and a contract based on the requirements themselves. Throw in an ideology that encourages written communication between the business analyst and the development team, and you’ve got a tough job ahead when it comes to delivering value.Changes become a series of tightly controlled negotiations.

As you can imagine, good traditional requirements are tough to write and are a rare commodity. If creating a good requirement is tough, writing an entire body of requirements into a complete and locked-down specification of the system is even tougher. The level of detail can lead to many interdependencies between requirements that have to be analyzed as the requirements are developed. While all requirements specifications have this difficulty, traditional requirements are particularly touchy since the focus is on the system rather than any user interaction.

The user understandably concentrates on the interface and his interaction with the system. A simple change in the user interface can create a ripple effect through the requirements. Unless a good requirements trace is available, even small interface or business process changes can be difficult to manage.