以前常在想，为什么需求被称为“需求工程”，而交互却一直被称为“设计”？今天参加了需求工程中的需求分析培训之 后，我确实觉得交互的理论体系上，确实缺少了一些“工程化”的“建模方法”。那么这些工程化的建模方法到底好不好，可不可以为我所用呢？本文叙述的就是如 何借鉴这些工程方法来进行需求分析工作的。
UED是一个日新月异的行业，它采用的技术和方法很多都是非常有效的。但我一直觉得，UED的方法中，对于需求的捕获能力是很强的，但分析能力就稍显薄弱。我觉得应该向传统的需求工程中去借鉴需求分析的方法，把他们工程化的方法吸收进来。
交互设计侧重于对界面交互方式的研究，需求工程则侧重于对于需求的捕捉和分析，两者的理论中都宣称可以贯穿整个开发工作的始终。那么从下两张图上可以看到他们各自都需要完成哪些工作。
阿里巴巴软件的UED流程
需求工程包含的内容
ok，我们很容易从这两张图上得到这么一个结论，UED和需求工程在需求分析这个步骤上是有个交叉点的。今天我们要分析的主角正是这样一个交叉点。
Alan cooper在《交互设计精髓》中是这样定义的：
１、创建问题和前景综述
2、头脑风暴
3、确定人物角色的期望
4、构造场景剧本
5、确定需求
需求工程中需求的层次
业务需求／商业需求：从原始需求，制定产品的功能范围和优先级，定义功能列表，产品经理也可以参照制定预算，
用户需求：描述用户使用软件需要完成什么任务，怎么完成任务，多采用用例的方法
系统需求：这部分主要是对接口的描述和一些非功能需求。
需求工程的问题：
1、用例是一个很耗时的方法，它的价值到底有多高呢？一两次需求变更，就会被它拖得精疲力尽了。尤其是在互联网行业，操作和功能都不复杂的时候，简直就是鸡肋。
2、缺乏对于产品易用性的关注。
3、在用户需求捕捉方法过于单一，主要就是访谈。
把需求工程中对于业务需求的分析方法吸收进交互设计的方法当中，我觉得可以使交互设计的理论体系更加严谨。有人曾经做过这样的尝试，大家可以参考从概念设计到信息架构一文。但是他介绍的方法和我们今天要介绍的需求分析方法还是有很大区别的。
以超市购物流程为例
１、根据业务用例撰写业务规格。这一步分析的是业务而不是操作。
可以参考的正确写法
２、画活动图，确定产品范围。活动图要严格对应我们的业务需求规格中的事件、对象和规则。每次跨甬道也都会产生一个实体。
３、列出功能列表。这一步确定了本版本我们做哪些功能，尽早对这个问题达成一致，对很多产品的开发都很有好处。
4、抽取之前定义的实体和规则。这一步还定义出了一些元数据，虽然不是最后的数据描述，但可以作为参考。
