编写解决方案而不是需求具有危险性。但问题是如此广泛(特别是对非功能需求)，而且可能相当严重，所以，如果我们再次提及这个问题，你会原谅的。
不要预先定下一个设计方案，或强制某个解决方案。同理，不要采用当前对问题的解决方案并把它当成需求写下来。例如，如果这样编写一项安全需求:
在访问账户数据时，产品应该要求输入口令。
那么设计者就强制使用了口令。这意味着即使有比口令更好的安全设备(确实存在许多选择)，产品的构建者也不能使用。这样，糟糕的需求就阻止了设计者寻找替代的，也许是更好的解决方案。
如果这样写:
产品应该确保账户数据只能被授权的用户访问。
你就是在要求产品设计者或安全顾问(有资质做这件事的人)寻找最有效的安全解决方案。除了可能解决错误的问题之外，写下解决方案来代替需求的一个主要问题在于，技术在不断地变化。解决方案将你锁定在这种技术或那种技术上，不论选择的是什么，等到产品构建时，这种技术可能已过时。通过写下一份不包含任何技术成分的需求，你不仅允许设计者使用最合适的、最新的技术，而且当新技术出现时，允许产品改为采用新的技术。考虑下面的易用性需求:
产品应该使用鼠标。
我们可以这样写需求，消除技术的成分:
产品应该使用一种指点设备。实际上，需求可以改进为下面这样:
产品应该允许用户直接操作所有的界面元素。
这项非功能需求自然包括了触摸屏和直接用手指操作界面内容，甚至包括眼动检测。
为了遵从不要写解决方案的指导原则，请检查你的需求。如果它包含任何技术因素或任何方法，就重写它，避免提及任何技术或方法。可能需要反复做几次，直到达到要求的技术无关性，但对最终产品设计的影响来说，这是值得的。
