首先谈下需求的两个层面的问题，一个层面是从需求收集调研到用户需求的开发；第二个层面是软件需求和原型的开发。第一阶段重点是真正搞清楚用户的问题域和场景，从用户的How和What转移到用户的Why的根源分析，只有这样才能够真正挖掘潜在的需求；第二阶段重点则是系统分析，是从现实到抽象的转化，重点是软件需求，原型和用户业务场景的交互实现考虑。两个阶段应该有一定程度的分离，否则很容易造成需求挖掘不充分，出现针对问题而问题，针对功能而功能的非系统解决方案。
其次对于需求收集，分析和开发工作。我们仍然很强调业务场景这个词，在UML 2.0专门有了业务建模的概念，包括业务用例，活动图，状态图和业务组件和对象模型等帮助我们完成对业务场景的系统建模。然后我们往往很容易跳过这一块而直接过渡到系统用例，而系统用例的重点已经会转移到功能的实现上面。一个功能的实现没有站在用户角度去考虑不同的业务场景下，系统如何去更好的支持，导致出现大量的需求遗漏和易用性的问题。这也是易用性的一个较高层次，即业务易用性，是否进行了分角色和分场景的设计。
在谈UCD和交互设计的时候，这个时候谈到了易用性的动态模型，我们原来谈界面规范和配色等更多的是考虑系统的静态易用性问题。在谈交互设计的时候，则是要结合业务场景和业务角色，考虑系统的动态易用性问题，界面规范容易总结，但是交互规范和模式却往往很难进行总结。简单而言，交互模式需要去回答一个问题，即在不同的业务场景下，最佳的交互方案是如何的，这里面究竟有没有规律可遵循？
软件做出来的功能不是用户想要的，则是我们在出功能性需求的时候出现明显的偏差。但是如何功能是不好用，则是我们没有重视需求开发中的非功能性需求方面的描述，而关于软件的性能，UI和交互，安全性，可靠性和健壮性等都是软件的非功能性需求。很多时候软件产品的失败往往就是在非功能性需求上面。
需求的描述上面需要尽量的结构化和条目化，好的需求不仅仅是完整和正确，更加重要的是一定是可以验证的，因此不能出现任何类似易用，较快等模棱两可的词语。另外对于业务场景和到了系统用例的软件需求之间，可能一个场景会对应多个用例，也可能一个用例要实现多个业务场景，如何将业务场景体现到用例中去是必须要分析和解决的一个问题。同时体现了场景后，需求可以更好的指导测试用例的编写，因为我们对测试用例更加强调基于业务场景的测试。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
