任务：

　　1. 通过对问题及其环境的理解，分析和综合，建立分析模型。
　　2.在完全弄清用户对软件系统的确切需要的基础上，用“软件需求规格说明书（SRS）”把用户的需求表达出来。

　　分析模型包含问题及其环境所涉及的信息流，处理功能，用户界面，行为模型及设计约束等。

　　需求说明应该具备准确性，一致性，清楚性，没有二义性，直观，易读和易于修改。为此应尽量采用标准的图像，表格和简单的符号来表示，使不熟悉电脑的用户也能一目了然。

　　步骤：

　　1.需求获取：从分析当前系统包含的数据开始，系统需求包括用户对软件功能的需求和界面的需求。

　　2.需求提炼：分析建模：图像化的分析模型包括数据流图，实体关系图，控制流图，状态转换图，用例图，类对象关系及其行为图等。除系统模型外，更有系统关联图，创建用户接口原型，确定需求优先级别等。

　　3.需求描述：编写SRS：统一格式的文档--模板

　　4.需求验证：改善需求中的二义性，不一致的问题。

　　常规的需求获取方法：

　　1.建立联合分析小组：由用户业务人员，系统分析员和领域专家组成。

　　2.客户访谈：进一步确定需求。这个过程需要系统分析员有充分的准备和良好的交流能力。

　　3.问题分析和确认：去掉错误的，无关的部分，整理有用的内容，以便给用户确认，并在次访谈，如此循环2-5次。

　　快速原型法：步骤：

　　1.利用各种分析技术和方法，生成一个简化的需求规格说明。

　　2.对需求规格说明进行必要的检查和修改后，确定原型的软件结构，用户界面和数据结构等。

　　3.在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试，改进。

　　4.将原型提交给用户评估并征求用户的修改意见。

　　5.重复上述过程，直到原型得到用户的认可。

　　3.3 分析建模

　　软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，终形成需求规格说明。

　　需求工程的活动划分为以下5个独立的阶段：

　　（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；
　　（2）需求建模：为终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；
　　（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；
　　（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；
　　（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。

　　先让我说说领域吧。领域是你的客户和项目所处的大环境，重要的是行业习惯和行业的背景。领域专家是这个行业的专家，领域系统是你对于这个行业作的总体把握。
 
　　业务需求一般是我由我们软件开发人员来搜集的，是企业自身在顾问等引到下自己所作的工作。我们只是去从他们那里直接的拿来可以了。比如为了配合企业生产改造，为了加强库存管理，为了建立企业电子化运行平台，这些都是业务需求。这些东西的建模还是留给咨询顾问吧，我们没有拿那份企业流程重组的钱，也不用费这个力气。
 
　　用户需求是用户为实现器业务需求而提出的基于实际情况的具体目标。比如我的系统要可以查看库存中的零件数量，我需要可以由计算机给出投料方案，计算工资总额。
 
　　功能需求是要去解决这些具体的用户需求所产生的解决方案。这个是我们平常说的需求说明说。要得到这个需要对用户需求作具体的分析，提出具体的实施方法。而评估则是对于这个方法和其所代表的用户需求的评估，比如实现这个需求所耗费的成本是不是小于其带来的收益。我们作的风险评估也是针对这个作的风险评估。
 
　　RUP中只有一个需求模型，那是系统用例模型。所谓业务用例模型是在项目的初始阶段，对于其项目可行性风险分析，企业流程重组，所作的企业运行流程模型。我们可以通过这个模型了解其运作过程，但是这个模型一般不是由我们来作，是由业务和领域顾问来作。
 
　　而AM只是一种建模的风格，不是具体建模的方法。所以在其下的建模，和我们平时的建模没有什么不同，只不过不是要那么重型的去建模。而是强调非正式的建模，非文档的建模，非uml全面化的建模