需求—需求分析的任务和步骤（转）
需求分析的任务和步骤
任务：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全⾯化的建模
