什么是有效的需求

需求通常是客户指定的关于系统实现的行为约束。（“必须支持每分钟 10,000 次交易。”）再次声明，最好在一个独立文档中指定并引用需求。

请注意，某些称作“需求”的东西其实并不真是“需求”。UI 设计通常是作为“需求”指定的，但真正的需求通常不是程序的外观如何，而是它做什么。如果实际用户不在意程序是否使用肾形嵌套紫红色按钮，那么肯定没有对使用肾形嵌套紫红色按钮的“需求”，不论您多喜欢这种按钮。（换句话说，如果用户在意，那么这就是需求，不论有多小。就是这样。）

我曾经有一个客户，他常说“用户需要[某些功能]。”我的回答是“哪些用户？告诉我他们的名字，这样我可以给他们打电话，和他们进行讨论。”由于实际上不存在这种用户，因此很容易忽视这些需求。这并不是说设计人员有时会不考虑有用的功能，但除非有一个真正的用户关心您的创新，否则它们就不切实际。要迫使您的用户们接受某些糟糕的创新很容易，但这些创新什么也干不了，只会在用户使用程序时给他们添麻烦。应拒绝这种诱惑。

了解需求是否有效的一个好的测试是拒绝所有在设计过程的自然产品之前指定的所谓需求（UI 观感、程序结构等）。这种“需求”只是错误的下意识设计。从需求文档中除去此垃圾。如果您有训练有素的商业开发队伍，那么从一开始在此文档中就不会有这些“需求”。

最后请注意，OO 设计人员不可能从“功能”列表着手进行工作。功能列表可能会是很长但又紊乱的未经细心考虑的构思集合，这些构思是某些客户未经大脑考虑而向销售人员建议的。然后销售人员会把此建议转换成“哦，天啊，我们现在必须设计这个功能！！！”，然后我们就这样做了。他们最多不过是建议了研究方向，但他们自己也不知道是否正确。您感兴趣的是为什么会提出这些功能。这种特定功能如何使用户的工作变得更简单？用户想要实现什么？您的其他客户是否想要实现相同的事？是否有更好的方法可以实现目标？最重要的是用户要执行的任务是否是我们以前没有遇到过的用例？