3 ms·
The requirements and the spec are very different things. The requirements are exactly the thing that comes from the stakeholders. The spec is a way longer docum
by chronial 5y ago
The requirements and the spec are very different things. The requirements are exactly the thing that comes from the stakeholders. The spec is a way longer document that must match the requirements, but it is not the requirements.
Also, the requirements for a spaceship are only "must travel to the moon" if your customer is a 5 year old child. The real list of requirements is way longer and includes things like "must be compatible with our existing launch infrastructure".
- PeterisP 5y agoWhile it's true that requirements come from the stakeholders, often the stakeholders don't really have them, they don't know them, and when they think they know them, often those are not the "real requirements" but some proxies which may even need to be violated to get a good product - i.e. I may think that a significant requirement is to ensure that some thingamajig very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig at all. The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.