需求还是解决方案
很不幸，对需求的描述常常以解决方案的形式给出。我们在谈论需求时，总是无意识地说出我们认为需求应该如何解决，基于我们的个人经验。这导致陈述把重点放在一种可能的解决方案上(这种方案不一定最合适)，通常隐藏了真正的需求。
需求越抽象，就越不可能是解决方案。
检查该需求:它是否包含技术元素?它的编写方式是否描述了某种过程?想想下面这个潜在的解决方案:
产品应该使用 JavaScript来实现界面。
你不知道这是不是最佳解决方案。不论如何，它都不是真正的需求，必须退回给提出者，要求澄清。
有时我们无意识地陈述了解决方案。例如，下面就是一个解决方案:
产品应该在菜单条上有一个时钟。
“时钟”和“菜单条”都是解决方案的一部分。我们建议真正的需求应该这样写:
产品应该让用户意识到当前的时间。
这似乎有点迁腐，但可能有更好的方法来实现这项需求。如果以一种抽象的方式来编写需求，其他解决方案都是可能的。除了时钟外，有很多其他的方式让人们意识到时间(星盘可能是一种，但不一定更好)。同样，除了JavaScript以外，也有其他一些方式能构建易用的界面。
检查需求的技术内容。你必须拒绝所有不是需求的解决方案，除非解决方案实际上是限制条件。
本文地址：https://www.yitenyun.com/6910.html
上一篇：Python AES加密解密
下一篇：Typora绘图
