需求是一个项目必须具有的功能和所需要满足的条件。它是软件项目的主要挑战之一，据调查37%的软件问题是由需求导致的，一个软件开发的功能中30%的功能几乎没怎么用过，19%的功能很少用，只用%7的功能一直在用，其他的功能则是有时在用或经常用。这种发现，给我们软件开发带来了启发，以前传统的瀑布模型是将整个需求分析完之后再开发，而现在则是先解决主要矛盾，进行迭代开发，将用户一直会使用的需求中的7%先开发完。
需求类型（FURPS+）：
在软件开发过程中有哪些方式来分析需求了？
首先，我们讨论的需求是系统需求，它主要分为功能性需求和非功能需求，对于功能性需求，一般使用用例模型，而非功能性需求使用补充说明的方式。
用例的几种定义 ：
总之，就是从用户的角度（系统的外部）观察到得系统的行为（使用系统的过程或和系统交互的过程）
用例特征：
业务用例与系统用例的区别：
业务用例就是要完成的业务，系统用例是系统要做的事情，在业务用例模型中，业务角色代表企业外的角色，业务员工代表企业内的角色。例如对于商店来说顾客就是它的业务角色，而售货员就是它的业务员工。
业务用例是用例思想的延续，只是改变了使用场合。用例是从使用者的角度定义“软件系统”需求。而业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。如住房公积金中心是一个业务组织，你或许就是一个业务参与者（如果你准备向住房公积金贷款）。那么办理住房公积金贷款就是一个业务用例。这个业务用例会描述什么呢？它会描述类似如下内容(由于内容复杂仅作示意)：
可见，此处的业务用例描述的是业务参与者（职工）如何使用业务组织（中心）提供的服务的过程。因此业务用例实际上是一种业务流程。它以业务组织外部业务参与者的角度定义业务组织提供的服务。当然业务用例还包括一些内部流程，它可能不是由业务参与者启动的，如采购流程等。因此，业务用例只是使用了用例的思想和形式而已，研究的主题是完全不同的。用例研究软件系统，借助用例定义软件系统需求。而业务用例研究一个目标组织，借助业务用例定义目标组织应该具有哪些业务流程，以及这些流程应该是什么样子的。
用例与功能的区别：
功能的特点：
两种常见的误区：