Stakeholder-Value and Product-Value Requirements define what we want to achieve using a Scale and a Goa-Llevel, while Solutions are intended to move us along that Scale from where we are towards the Goal-Levels.
To have a Solution, we must first understand the Requirement it is intended fulfill. Solutions only exist in the light of the Requirements it is meant to achieve. Solutions can only be as great as our understanding of the Stakeholder-Value and Product-Value Requirements are.
Discussions about for how good Solutions are, or which Solution is better, without having a clear Idea of what kind of challenge it might solve, are fruitless. I avoid discussing which Solution we should use without having Stakeholder-Value and Product-Value Requirements specified first.
Your Solutions my Project
Your Solutions might become someone elseâ€™s projects, and your project might be someone elseâ€™s Solution.
The chain of someoneâ€™s Solutions becoming someone elseâ€™s projects might have many layers. The number of layers depends on, among other things; the size and complexity of a project, as well on how you choose to organize your organizational structure.
In smaller projects, we might operate with two levels, Product Level & Solutions Level. At the Product Level we express the end states with Product-Functions and Product Values. At the Solutions Level, we might just specify Solutions, like; use titanium, use a Standard GUI layout etc.
In more Complex projects, we might have 3 levels, a Stakeholder-Level, a Product-Level, and a Solutions Level. Each Level is viewed as Solutions for the Level Before it. The Products-Level are Solutions for the Stakeholder-Level, the Solutions Level are Solutions for the Product-Level.
We can expand in both directions as needed. We can have several Stakeholders, some Before others, we can have several products, and the products can be broken down several levels. Each Level down are Solutions for the Level above.
Categories of Solutions with Examples
I find it useful to separate Solutions into categories. Here are four main categories.
Build Solutions describe the actual parts, material, design and components of the Product.
Examples are material used to make a Product; computer code, the physical design of the Product, parts to be used in the Product.
.Titanium: use titanium.
.Thickness: 10mm Â± 0.2 mm.
Sub-Function Solutions are Sub-Functions that support a higher Requirement. They differ from ordinary Sub-Functions in that they are not a necessary part of the Product, no one is requiring the Product to perform a Sub-Function Solution, it is an option, a Means to an end. A Sub-Function Solution does not tell us how, just what it will do.
Examples are any Sub-Functions that are not a Requirement; air-cooling in a room, an address book on a telephone, internet in a hotel room.
.Euro: include all the European languages.
.US: include US English.
Process Solutions describes Processes that can be used to develop the Product. Processes that alone will not make any Product, but when applied to the developing Process can increase the Effectiveness of the development.
Examples are anything that can help the developers do their job better; computer applications, a system to sharpen the knifes regularly in a kitchen, a Checklist to follow, a Document change management tool, Evolutionary Delivery, Waterfall, Inspection.
Speckqc: use specification Quality control
.Req: on all new Requirements
.Qual: No more than 1 Major Defects per page remaining
.Sol: On all new Solutions
.Qual: No more than 3 Major Defects per page remaining
Product-Values and Sub-Product-Values
Sub-Product-Values are Solutions to satisfy Product-Values. Product-Values are Solutions to satisfy Stakeholder Values. As an example a Product-Value of Usability can possibly be there to help us meet a Stakeholder Value about reducing the Cost of ownership of a Product. Usability is not an end in itself; it is a Solution to meet a higher end state. As seen from the perspective of Stakeholders, all Product-Values are Solutions.
Scale: average time to learn how to operate the system
Past 2004 120 min.
Goal 2005 30 min.
1. A Solution-Specification is a written definition of a Specific-Solution-Idea. A template for Solution-Specification is given in Figure 7.6.
2. A Solution-Idea is not usually a Requirement. A Solution-Idea can, in Principle, be changed at any time for a â€˜betterâ€™ Solution-Idea (without having to ask the permission of any Stakeholders because the System designers are responsible for the proposed Solution-Ideas). A â€˜betterâ€™ Solution meets the Requirements by giving more performance and/or less Cost.
3. A satisfactory Solution-Idea can have some negative performance Scalar Impacts, and still be acceptable overall. As long as the negative Impacts (negative Side-Effects) of a Solution-Idea do not prevent us from reaching all the required Goals Levels, the Solution-Idea can be used.
5. â€˜One mans Solution becomes anotherâ€™s Requirement.â€™. The Concept of Requirement and Solution is relative to the Level of Process observation. A top Level Solution becomes a â€˜Requirementâ€™ at the next Level
[Solution-Idea *047]: ||
---[ -ïƒŸ --ïƒ -] --ïƒ ---ïƒ P
M Vb B T1 Vb T2
Illustration for paper â€˜Vision Engineeringâ€™ (July 2008). M = Mission, Vb = Core Value barrier â€“ Constraint. B = Benchmark Level. T1 and T2 are Target Levels of Performance Attribute P (a Core-Purpose). S1 and S2 are Strategies. Based on ideas in Collins and Porras, â€œBuilt To Lastâ€.
A lying-down rectangle. (The standing rectangle is a Document icon.)
This Concept entered by Adore.
Table of contents: