一、需要需求的地方有：
1、项目的范围；
2、成本估算；
3、预算；
4、项目计划；
5、软件设计和测试；
6、文档和培训手册；
二、记录需求的方式有：
1、Stackholder的需要（涉众的需要）；
2、软件特性；
3、软件需求规格，要求无二义性，完整，一致，可跟踪，并且不含设计信息；
它们的层次如下
三、需求产物
业务用例模型。 所期望系统的目标经常是要解决业务问题或通过提供增值服务开拓商业机会。业务用例将用例的概念扩展为描述业务过程。业务用例模型（与业务用例规格说明一起）提供了一种评价所期望系统范围的方式－－有些部分可以自动化，有些部分不能，有些部分可以通过更改业务过程来进行。这就允许我们从一种业务观点来评价用例模型的完整性，因为每个系统用例必须支持一个或更多的业务用例。
业务实体和领域模型。 大多数系统需要操作和展现业务信息。一个业务实体将一组相关信息字段表示为类。业务实体通过一个业务过程（例如业务用例）被处理和操作，它们接着通过系统用例被自动化。所有业务用例及它们关系的总和组成了领域模型，领域模型描述了问题域。每个系统用例将操作一些实体，并且实体通常被包括在多个系统用例中。
业务规则。 今天，系统的复杂性通常是由系统必须符合的业务规则的复杂性所导致的结果。业务规则将被业务用例和系统用例来表示，并且可以是各种形式，决策表，计算规则，决策树，时间图（描述哪些事件必须发生在其它事件之前或之后，以及从中产生的过程），运算法则，等等。在用例流中描述业务规则通常会把用例规格弄得混乱。因此，它们通常是在单独的工件中被捕获，或者是作为用例规格的附加物。
用户体验模型和情节串连图板 用户体验建模是捕获用户界面需求而不借助于画出屏幕布局的一种便利方式，画出屏幕布局的方式可能要花费巨大的工作量，并且非常可能发生变更。用户体验建模将实际的用户界面屏幕抽象为一个UML类，其原型是«screen»。属性确定了用户在一个屏幕上可以看到什么；操作确定了用户在每个屏幕上可以做什么；并且关联关系确定了航行路线。用户体验情节串连图板是用户体验模型的子集，用于描述与系统用例有关的屏幕。
补充规格说明。 补充规格说明描述了影响多个用例的需求。例如，所有用例都服从权限控制，审计跟踪，个性化，等等。补充需求实际上通常是技术方面的，并且可以是关联于功能、可用性、可靠性、性能以及可支持性。它们通常被表示为“系统应做 ...”形式的陈述语句
