需求—需求分析的任务和步骤
需求分析的任务报告
需求分析的任务报告任务报告：需求分析一、引言需求分析是软件开发过程中的重要环节之一，它的目标是确定系统的使用者或利益相关者的需求，为系统的设计和开发提供明确的方向。
本报告旨在对需求分析的任务进行详细的分析和总结。
二、任务目标需求分析的任务目标是理解和定义系统的需求，包括功能需求、非功能需求和约束条件等。
通过需求分析，可以确保系统能够满足用户的期望和需求，同时提高系统的可理解性、稳定性和可维护性，减少开发过程中的错误和风险。
三、任务步骤1. 收集需求：通过与用户、利益相关者和项目管理人员的沟通，收集系统需求的相关信息。
可以采用面谈、问卷调查、观察等方式获取需求信息。
2. 分析需求：对收集到的需求进行分类、整理和分析，明确需求的内在关系和优先级。
可以采用需求建模等方法来帮助分析和理解需求。
3. 验证需求：与用户和利益相关者一起验证需求的准确性和可行性。
可以通过原型设计、演示和评审等方式来验证需求。
4. 文档编写：将分析和验证完成的需求编写成需求规格说明书，明确需求的内容、边界和限制等。
同时，可以在规格说明书中记录需求的变更和讨论的内容。
四、任务挑战1. 需求变更：需求是动态的，可能在开发过程中发生变化。
对于需求变更的处理需要及时、高效和准确，以避免对整个系统开发过程的影响。
2. 需求与设计的协调：需求是系统设计的基础，但需求的表达和设计的实现存在差异。
需求分析人员需要与设计人员密切合作，确保设计能够满足需求。
3. 需求理解的困难：系统需求往往涉及多个领域的知识，需求分析人员需要具备广泛的知识背景和跨学科的能力，才能准确理解和表达需求。
五、任务收益1. 提高系统的质量：通过需求分析，可以确保系统的功能完备、性能优越和易于使用。
同时，还可以避免开发过程中的错误和风险，提高系统的稳定性和可维护性。
2. 减少项目成本：需求分析可以帮助提前发现和解决问题，避免在后期开发和维护中的重复和费时费力的工作。
这样可以减少项目的成本和开发周期。
需求分析之详细步骤解析
需求分析之详细步骤解析目录第一步：用户访谈 (2)第二步：岗位职责分析 (2)第三步：系统用户分析 (2)第四步：用户场景分析 (3)第五步：用户用例分析 (3)第六步：功能需求分析 (3)第七步：非功能需求分析 (4)第八步：需求规格说明书 (4)需求分析看起来复杂，其实按照流程可以分为八步，辅之以标准分析表格，就可以实现需求分析的标准化流程。
这八步分别为：用户访谈、岗位职责分析、系统用户分析、用户场景分析、用户用例分析、功能需求分析、非功能需求分析和需求规格说明书，如图所示。
下面按照需求操作步骤一步步加以说明和分析。
第一步：用户访谈用户访谈主要是通过和用户交谈，了解到用户对本项目的理解以及他们的一些想法和愿望。
通过这些基础素材，需求人员可以对信息进行整理，从而为后续的分析收集到有价值的素材。
在该步骤，需要用到“用户访谈表”，该表主要包括被访人员信息、用户访谈记录及整理访谈记录。
该表主要是辅助需求人员进行需求信息收集的。
第二步：岗位职责分析岗位职责分析，主要是分析被访谈者的岗位和相关职责信息，为下一步系统用户分析做准备。
第三步：系统用户分析系统用户分析主要是通过岗位和职责的描述，抽象提取出一些共性的东西，将相识岗位合并成系统用户，整理出系统用户的业务需求。
第四步：用户场景分析用户场景分析主要分为总场景分析和分场景分析，其中总场景是根据下表总结出的系统角色，将对应的业务需求分解成几个用户场景；分场景是进一步将每一个场景进行详细描述。
总场景：分场景：第五步：用户用例分析用户用例分析是进一步将每个分场景再细分成用户用例。
第六步：功能需求分析根据分析得到的各个系统用户，先概括性的说明各个系统用户需要做哪些事，然后再进一步详细分析每个功能点的具体功能，即计算机将要帮助用户完成哪些任务。
注意：功能需求分析的读者是程序员，也是系统将来所要实现的功能，所以最好以计算机式的语言加以描述，避免用文学语言进行描述。
需求分析的任务
这类要求集中表现为对系统运行时所处环境的要求。例 如，支持系统运行的系统软件是什么，采用哪种数据库 管理系统，需要什么样的外存储器和数据通信接口等。
软件工程
4．将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开发范畴，但 是据分析将来很可能会提出来的要求。这样做的目的是 在设计过程中对系统将来可能的扩充和修改预做准备， 以便一旦需要时能比较容易地进行这种扩充和修改。
软件工程
三、导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模 型，通常用数据流图、数据字典和主要的处理算法描述 这个逻辑模型。
四、修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，
可以比较准确地估计系统的成本和进度，修正以前制定 的开发计划。
五、开发原型系统
在计算机硬件和许多甚他工程产品的设计过程中经常使 用样机。建造样机通常有两个主要目的：检验关键设计 方案的正确性及系统是否真正满足用户的需要。对于软 件系统的开发，使用“样机”(更正确的名称应该是原型 系统)的主要目的是，使用户通过实践获得关于未来的系 统将怎样为他们工作的更直接更具体的概念，从而可以 更准确地提出和确定他们的要求。
二、分析系统的数据要求
任何一个软件系统本质上都是信息处理系统，系统必须 处理的信息和系统应该产生的信息在很大程度上决定了 系统的面貌，对软件设计有深远影响，因此，必须分析 系统的数据要求，这是软件需求分析的一个重要任务。 分析系统的数据要求通常采用建立概念模型的方法。
软件工程
复杂的数据由许多基本的数据元素组成，数据结构表示 数据元素之间的逻辑关系。利用数据字典可以全面准确 地定义数据，但是数据字典的缺点是不够形象直观。为 了提高可理解性，常常利用图形工具辅助描绘数据结构。 常用的图形工具有层次方框图和Warnier图。
如何做好需求分析
如何做好需求分析一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.(这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.)二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).制订规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.评审对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
软件工程导论第3章
2.访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍 然广泛使用的需求分析技术。 访谈有两种基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题， 以鼓励被访问人员说出自己的想法。 调查表是当需要调查大量人员的意见时的一个十分有效的做法。 分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户， 以便向他们询问在分析调查表时发现的新问题。 在访问用户的过程中可以使用情景分析技术。情景分析技术的 用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用户理解， 而且还可能进一步揭示出一些分析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在 需求分析过程中始终扮演一个积极主动的角色。
（1） 数据对象
数据对象是对软件必须理解的复合信息的抽象。所谓 复合信息是指具有一系列不同性质或属性的事物，仅有单 个值的事物(例如，宽度)不是数据对象。 数据对象可以是外部实体(例如，产生或使用信息的任 何事物)、事物(例如，报表)、行为(例如，打电话)、事件 (例如，响警报)、角色(例如，教师、学生)、单位(例如，会 计科)、地点(例如，仓库)或结构(例如，文件)等。总之，可 以由一组属性来定义的实体都可以被认为是数据对象。 数据对象彼此间是有关联的，例如，教师“教”课程， 学生“学”课程，教或学的关系表示教师和课程或学生和 课程之间的一种特定的连接。
（4）需求验证 由软件开发者和用户一起来进行软件需求规格
说明的复审。确保需求规格说明可作为软件设计和最 终系统验收的依据。
二. 需求获取的常用方法
1. 建立联合分析小组 建立一个由用户、系统分析员和领域专家参加 的联合分析小组，密切合作，共同标识问题，提出 解决方案要素，商讨不同方案并指定基本需求。 这是一种面向团队的需求收集法，又称为简易 的应用规格说明技术。
第3章 需求分析-大纲
第三章需求分析
3.1 需求分析的任务和步骤
——需求分析的任务
……确定对系统的综合要求
……分析系统的数据要求
……建立软件的逻辑模型
——确定对系统的综合要求
……功能性需求
……非功能性需求：可用性，可靠性……
——分析系统的数据要求
……数据字典——定义数据
……层次方框图——定义数据结构
——建立软件的逻辑模型：数据流图、数据字典、实体-联系图、主要算法
——编写软件需求规格说明书
——需求分析评审
3.2 需求获取的常用方法（5个）
——访谈
——问卷调查
——观察用户工作流程
——建立联合分析小组
——快速原型法
3.3 需求分析的方法（4个）
——功能分解法：软件需求当做一棵倒置的功能树
——结构化开发方法：结构化分析、结构化设计和结构化程序设计
——信息建模方法：实体-联系图
——面向对象的分析
3.4 结构化分析技术
——思路：基于数据流图自顶向下逐层分解
3.5 需求分析图形工具
——实体-联系图（Entity-Relationship Diagram）
……实体定义：对软件必须理解的复合信息的抽象
……属性定义：数据对象的性质
……联系定义：数据对象彼此之间相互连接的方式
——数据字典
……定义：数据字典是关于数据的信息的集合，也就是对数据流图中包含的
所有元素的定义的集合。
……四类元素：数据流，数据流分量（即数据元素），数据存储，处理——层次方框图
……定义：用树型结构的一系列多层次的矩形框描绘数据的层次结构。
——IPO图（Input Process Output）。
需求分析(数据库课程设计)全解
《信息系统分析与设计》
1
教学内容
需求分析的任务、步骤；需求分析必须遵循的基 本原则；需求分析的方法；数据流图和数据字典的运 用；结构化语言、判定表和判定树的使用；E-R模型、 层次方框图、IPO图和Warnier图的使用；需求分析文 档和需求分析评审等。
教学要求
1．熟练掌握：数据流图和数据字典的运用；结构 化语言、判定表和判定树的使用。 2．一般掌握：需求分析的任务、步骤；需求分析 必须遵循的基本原则；需求分析的方法；E-R模型、 层次方框图、IPO图和Warnier图的使用。 ３．了解：需求分析文档和需求分析评审。
《信息系统分析与设计》
3
1.2 需求分析的难点
需求分析的难点主要体现在以下几个方面:
（1）问题的复杂性
（2）交流障碍 （3）不完备性和不一致性 （4）需求易变性
《信息系统分析与设计》
4
通过以下做法可以大大克服上述困难： （1）项目的参与者（包括软件设计开发人员和用户等） 必须在需求分析过程中加强沟通和协调。一方面，软件设 计人员应尽量使用通俗的语言与用户进行交流；另一方面， 用户应积极主动地配合软件设计人员的工作。 （2）为了保证需求分析阶段能够提出完整、准确的系 统逻辑模型，开发人员必须花费足够的时间，全面了解用 户的需要，绝不能在需求模糊的情况下仓促进行系统的设 计和编程。根据国外的统计资料表明，在典型环境下开发 系统，需求分析阶段的工作量大约要占到整个系统开发工 作量的20%左右。 （3）使用一些有效的需求分析方法（如结构化分析方 法等）及自动化工具(如CASE工具)来进行需求分析。
《信息系统分析与设计》
2
一、 需求分析概述 1.1 需求分析的任务和目的 需求分析的基本任务是要准确回答“系统必须做什么？”这 个问题。 需求分析的具体任务包括： 1.确定对系统的综合要求 对系统的综合要求主要包括功能要求、性能要求、运行要求 和其他要求等四个方面。 2.分析系统的数据要求 由系统的信息流归纳抽象出系统要求的数据以及数据的逻辑 关系。 3.导出目标系统的详细逻辑模型 通过以上二项分析的结果导出目标系统的详细逻辑模型。 4.修正项目开发计划，编写用户手册概要。 5.编写系统需求规格说明书，并提交审查。
需求分析概念、方法、实践步骤
需求分析(一)概念、方法、实践步骤1. 概念、方法、实践步骤需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。
典型的工作产品：软件需求说明（Software Requirements Specifications，以下简称SRS）其主要包括系统基本概要、业务功能、系统功能（性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。
需求分析阶段的主要活动需求分析阶段的主要活动可以分为需求开发、需求管理2类：需求开发通过对客户、业务、用户、原系统等调查获取原始的需求，经过需求分析逐步识别并使业务具体化，通过形成制作规格说明书（或SRS）使业务系统化，项目团队同客户、用户逐步达成共识对需求得以最终确认，其间可以通过系统建模、POC等方式评估需求的可实现性。
需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库建立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动，通过使用需求管理工具等手段，实现对系统需求按基线进行控制和管理。
其核心内容变更管理、版本管理以及需求跟踪。
需求开发的主要概念以及核心步骤】业务需求反映了企业或组织对（软件）系统的业务要求，通常也包含问题或机会的定义。
问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。
机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。
业务需求通常由管理人员提出，业务需求的解决往往要结合制度、（人员）能力、系统功能等多方面综合解决。
另外,业务需求也反映了企业或组织对（软件）系统的高层次目标要求，就是系统的建设的目的以及目标。
用户需求是指描述用户使用（软件）系统需要完成什么任务，怎么完成的需求，通常是在问题定义（业务需求）的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。
实验一软件工程需求分析
教学辅导——需求分析一、需求分析的任务需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?"这个问题.需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素,并将功能和数据结构分配到这些系统元素中.它是软件实现的基础.需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求.在这个阶段结束时交出的文档中应该包括详细的数据流图（DFD），数据字典（DD)和一组简明的算法描述。
需求分析阶段的任务包括下述几方面。
1．确定对系统的综合需求2．分析系统的数据需求分析系统的数据需求是由系统的信息流归纳抽象出数据元素组成、数据的逻辑关系、数据字典格式和数据模型。
并以输入/处理/输出（IPO）的结构方式表示。
因此,必须分析系统的数据需求，这是软件需求分析的一个重要任务。
3．导出系统的逻辑模型就是在理解当前系统“怎样做”的基础上，抽取其“做什么"的本质.4．修正系统开发计划5．开发原型系统二、需求分析的步骤结构化分析方法（简称SA方法）就是面向数据流自顶向下逐步求精进行需求分析的方法.需求分析的步骤如下。
1．调查研究2．分析与综合应注意下述两条原则：第一,在分层细化时必须保持信息连续性,也就是说细化前后对应功能的输入／输出数据必须相同；第二，当进一步细化将涉及如何具体地实现一个功能时,也就是当把一个功能进一步分解成子功能后，并将考虑为了完成这些子功能而写出其程序代码时，就不应该再分解了。
3．书写文档在这个阶段应该完成下述四种文档资料:（1)系统规格说明。
（2）数据要求。
（3)用户系统描述。
(4）修正的开发计划。
4．需求分析评审三、需求分析的原则1．必须能够表达和理解问题的数据域和功能域2．按自顶向下、逐层分解问题3．要给出系统的逻辑视图和物理视图四、需求分析方法大多数的需求分析方法是由数据驱动的，数据域具有三种属性：数据流、数据内容和数据结构。
《软件工程学》第3章 需求分析-答案
3.1 需求分析的任务和步骤1．需求分析阶段产生的文档是软件需求规格说明书。
2．需求分析的任务是要建立软件的逻辑模型。
3．分析系统的数据要求是软件需求分析阶段的一个重要的任务。
4．需求分析的任务不包括（B）。
A．问题分析B．系统设计C．需求描述D．需求评审5．需求规格说明书是在计划时期可行性研究阶段产生的文档。
（×）6．需求分析阶段的成果主要是需求规格说明，但该成果与软件设计、编码、测试直至维护关系不大。
（×）7．软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
（√ ）8．需求分析中的性能要求是指系统的技术性能指标，包括：存储量、响应时间、精确度和安全保密等方面。
（√ ）3.2 需求分析获取的常用方法3.3 需求分析的方法3.4 结构化分析技术1．要将一个复杂的系统分析清楚，常用方法的结构化分析方法就是（ A ）A．面向数据流自顶向下逐步求精的方法B．由内向外进行分析的方法C．先局部后整体的分析方法D．使用IPO图形工具分析的方法2．结构化程序设计的一种基本方法是（ D ）。
A．筛选法B．递归法C．归纳法D．逐步求精法3．结构化程序设计主要强调的是（ A ）。
A．程序易读性B．程序的效率C．程序的规模D．程序设计语言的先进性4．下列各种叙述中，哪一个不是结构化方法的特征?（ C ）A．严格定义需求B．划分开发阶段C．提供运行模型D．制定规范文档5．通常所说的结构化设计（SD）是属于基于（ B ）的设计方法。
A．数据结构B．数据流C．对象D．以上均可6．通常所说的结构化设计方法就是基于数据流的设计方法。
7．结构化程序设计强调模块采用自上而下逐步求精设计方法，单入口、单出口。
（√ ）3.5 需求分析图形工具。
有关软件需求分析的步骤以及所需文档
有关软件需求分析的步骤以及所需文档、需求分析的几个方面需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面：1、确定软件所期望的用户类；获取每个用户的需求必须全面理解用户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊的要求要进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。
最后将软件的需求准确地表达出来，形成软件需求说明书SRS。
实现步骤：（1）获得当前系统的物理模型首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。
此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估理解他们的需要及未来系统要解决的问题，然后建立一个业务USECASE模型和业务对象模型。
当然如果系统相对简单，也没必要大动干戈区进行业务建模，只要做一些简单的业务分析即可。
方法JSD、面向对象分析方法OOA（主要用UML）、对于有动态时序问题的软件可以用形式化技术，包括有穷状态机FSM的状态迁移（转换）图STD、时序图、Petri网或Z。
每一种分析建模方法都有其优势和局限性，可以兼而有之以不同角度分析，应该避免陷入在软件需求方法和模型中发生教条的思维模式和派系斗争，一般来说结构化方法用于中小规模软件、面向对象方法用于大型软件。
（3）编制需求分析文档（4）需求评审、结构化方法分析步骤1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
同时它也明确了通过接口的信息流和物质流。
2）创建开发原型：创建用户接口原型当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。
用户7）应用质量功能调配：使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2010-09-05
需求—需求分析的任务和步骤（转）
文章分类:软件开发管理
需求分析的任务和步骤
任务：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全面化的建模。