典型的方案级需求是以功能点（附加一些非功能性需求以及约束）为需求表达要素，而功能应该属于解决方案空间，即设计阶段所处的域。完整的语义可以粗浅的理解为，在设计阶段产出的方案，通过某些功能，解决了需求阶段用户提出的某个问题。
“用户的需求是登陆功能”，用户真实的需求真的是希望系统有登录功能吗，应该是需要系统提供安全性保障才对吧。而登录功能也是解决安全性需求的方案。
那么我们该如何正确的对待需求？当是面向问题域；而问题该如何描述？当以场景进行描述。“用户希望在什么情况下，用至多多少成本，完成一件什么事情”，这是问题场景描述。而诸如“你们给我做一个开瓶器”吧，这是购买成熟产品时候，出自用户之口的描述。一款待开发的产品并不是成熟的产品，用户没有义务，且没有能力描述最终的产品概念。大概率，用户的需求是一个打开酒瓶的装置，而不一定是一个开瓶器。
请确信，用户没有能力描述解决方案。
“我的浴室要地中海式风格，我的卧室要哥特式风格……”，如果你按照用户的描述老老实实做出一份装修设计方案，那么你得到的大概率与用户想要的存在巨大出入。你是专家，用户不是，他所谓的哥特式风格基于他对哥特式风格的认知，而不是学术上定义的那样。这种情况下，你需要做的是挖掘客户对哥特式风格的认知，那将包含他真正的需求。
请记住，用户没有提供需求的义务。
“这些客户什么也不懂，总说一些天马行空的要求，一个明确的功能点也提不出来，按照他们说的做了，又让我改”。工作这些年，多次听见同事类似的抱怨。需求不是客户提出来的，而是软件团队挖掘出来的，需求的规格化就更不可能是客户来完成了。毕竟，一款产品是否对的客户预期，到底是谁的责任？
来自公众号：更多点击
