项目需求分析怎么写
项目需求分析的概念需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。
需求分析阶段结束后，要求得到:
1.SRS文档System Requirement Specification;
2.DRM 文档；
3.Acceptance Plan. 从广义上理解:需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。狭义上理解:需求分析指需求的分析、定义过程。
一.为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.相信大家都有体会比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.
二.需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.
三.需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括:功能需求做什么,性能需求要达到什么指标,环境需求如机型,操作系统等,可靠性需求不发生故障的概率,安全保密需求,用户界面需求,资源使用需求软件运行是所需的内存,CPU等,软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型做什么的模型.制订规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书好象软考曾经考过这个问题,向下一阶段提交.评审对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四.需求分析的方法需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法在此不讨论.原型化方法是十分重要的是软考等常考的知识点.原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.原型主要有三种类型软考考过:探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。
软件工程需求分析的模板需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。
除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。
1.采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998IEEE 199
8.描述的需求规格说明书模板。
要相信模板是很有用的，但有时要根据项目特点进行适当的改动。1 2 3 4 5 6 A引言 目的 文档约定 预期的读者和阅读建议 产品的范围 参考文献 B综合描述 产品的前景 产品的功能 用户类和特征 运行环境 设计和实现上的限制 假设和依赖附录 C外部接口需求附录 用户界面附录 硬件接口 软件接口 通信接口 D系统特性 说明和优先级 激励/响应序列 功能需求 E 其它非功能需求 性能需求 安全设施需求 安全性需求 软件质量属性 业务规则 用户文档 F其它需求 G附件 词汇表 分析模型 待确定问题的列表 表2 需求规格说明模板a. 引言引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。a . 1 目的对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。
如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。a.2 文档约定描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。a.3 预期的读者和阅读建议列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。
描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。a.4 产品的范围提供了对指定的软件及其目的的简短描述，包括利益和目标。
把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
产品需求文档模板首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。
不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法:
一.描述-解释-预测-监控描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。
预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。
二.需求准备、编写和检查回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。
1. 描述描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。需求准备的过程:了解需求来源管理部门、市场部门、运营部门等，需求背景行业、同业规则现状等；需求分析的过程:了解需求目标、预期效果时间、结果等、使用者习惯、相关人影响；需求编写的过程:描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；需求检查的过程:需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；
2. 解释解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。
就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中:需求准备的过程:了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；需求分析的过程:选择和制定最有效的，满足时间、资源投入等要求的方案；需求编写的过程:详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；需求检查的过程:需求的流程、用户交互动作、系统信息交互等完整性检查；
3. 预测与监控预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。
”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中:预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。
解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中:需求准备的过程:了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；需求分析的过程:选择和确定需求实现方案，评估行为管理方式和管理机制；需求编写的过程:详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；需求检查的过程:需求“异常”流程和相应引导、控制地完整性检查；在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。
所谓标准文档，就可以按照这四个模块作为框架、内容和格式。写在最后产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。
软件需求分析报告模板(完整版)析报告文档;软件概要设计报告文档;软件详细设计报告文档;软件数据库设计报告文档;软件测试验收大纲hi.gta123如有帮助，别忘了采纳哟！goto365testing,测评网,。怎么编写用户业务需求分析需求分析格式1 引言1.1 编写目的【说明】目标:对用户的需求进行收集、整理与分析，弄清楚系统究竟要 “干什么”及“由谁干”，并用合乎规范的文字及图表予以描述。不需要说明“怎么干”，因为那是设计阶段的事情。
有关文字与图表应尽量让用户便于理解。 预期读者:用户方的相关业务人员、双方的开发人员和系统维护人员。 作用:实现开发方与用户方的双向沟通，是把业务需求计算机化的关键步骤。 为下一阶段的概要设计工作提供依据。当用户的需求发生变更时，应添写补充说 明；如变动过大可形成新版本。
软件需求说明Software Requirements Specification的主要作用为: 为用户方与开发方建立共同协议奠定基础。 提高开发效率、强化进度控制。 为项目的的评测与验收提供依据。
便于移植。 作为系统不断提高的基础。1.2 编写背景1.2.1 系统名称及版本号【说明】形如“网银三期***系统V3.0.0”。
其中，版本号的格式为“XX.XX.XX”，X为阿拉伯数字，左“0”可省略。1.2.2 使用者【说明】适应对象和范围。主要指预期读者，也供有关领导审阅。
1.2.3 与其它系统的关系【说明】在用户现有的及预期的整个应用系统中，给本系统准确定位。用示意图及相应的文字予以说明。2 用户的基本情况2.1 系统建设背景【说明】项目背景与依据、现有基础、项目规模、预期目标等。可繁可简，格式自定。
2.2 组织机构与职能【说明】用层次示意图及相应文字表示如果需要开发的系统与部门没有直接依赖关系此节可省略,本章随后的小节数将顺次减
1.，加注:组织机构的层次数、数目、各个机构的职能简述。2.3 用户特点【说明】所在行业特征、操作人员与系统维护人员的数量、学历与水平、数据量大小、使用频度等。2.4 用户业务分析【说明】在本部分，希望系统分析人员能够对用户业务现状进行分析、对用户对本系统的未来发展方向作出一定的预测等。以便设计人员对业务及其发展有所了解，增强系统设计的前瞻性。
2.5 计算机应用现状【说明】可繁可简，格式自定。3 业务需求3.1 项目概述【说明】第
一. 指明项目的开发意图、应用目标总目标、分期目标、作用范围、预期效益等。第
二. 指明在输入信息转变为输出信息的过程中，为了满足用户的业务需求，应用软件必须完成的基本功能采用自然语言叙述。但此时不要求对基本功能进行分解。
第
三. 如果本系统与其他系统相关联，则应确定本系统的基本功能边界可采用图示+文字说明的形式，用蓝色标示出本系统的功能，用绿色标示出相关系统的功能。3.2 约束条件3.2.1 费用约束【说明】 预计投资金额概算、其中软硬件费用的比例、资金分期到位计划。3.2.2 进度约束【说明】预计完成日期、分步实施期限。
3.2.3 其它约束【说明】场地面积限制、通信设施基础、其它干扰因素。 注意:任何计算机系统都不是包罗万象的；用户自身的能力也是有限的。轻诺必寡信。
故应特别指出:由于哪些条件的约束，本系统不能满足哪些业务需求与系统需求。本章主要介绍项目的总体业务功能,要求站在客户的角度把握系统需求.3.3 性能需求【说明】依据ISO9000标准及我们的理解，下面列出了软件的6组性能，共涵盖21个子特性。这些性能/子特性的相对重要性并不是等同的。编写时，可以基于具体项目的实际需求，对下述标题或内容进行取舍/侧重。
事实上不可能做到面面俱到，往往要作出某些折中。本节说明系统在性能方面的预期目标，不要求提供实现上述目标的具体实施方案。3.3.1 功能性【说明】指与软件实现的各项功能及其指定性质有关的一组属性。
这些功能都是满足规定需求和潜在需求所必需的。它包括5个子特性:适用性:与指定业务所需各项功能的实现及其适合程度有关的一些软件属性。准确性:与保证正确或符合要求的结果或效果有关的一些软件属性。互操作性:与软件同一些指定系统交互作用能力有关的一些软件属性。
复合性:使软件遵守相关的标准、约定/法律或类似规定有关的一些软件属性。保密安全性:与针对蓄意或无意而非法存取程序和数据的预防能力有关的一些软件属性。这里主要指的是保护软件的要素，旨在防止各种非法访问、修改、破坏、泄密及感染计算机病毒等。
3.3.2 可靠性【说明】指在规定的条件和期限内，与软件保持其性能水平有关的一组软件属性。成熟性:与软件故障引起的失误频率有关的一些软件属性。容错性:在软件故障发生或其规。
软件工程：3.需求分析需求分析的任务就是准确地回答“ 系统必须做什么 ”。是通过系统分析员与用户一起商定，清晰、准确、具体地描述软件产品必须具有的 功能 、 性能 、 运行环境 等要求。
用户:知道做什么，不知道怎么做。 开发人员:知道怎么做，不知道做什么。 因此，系统分析员必须和用户密切配合、充分交流信息，得出经过用户认可的系统需求。 需求分析的目的是澄清用户的需求，并把双方共同的理解明确地表达成一份书面文档—— 需求规格说明书 。 需求分析是一项软件工程活动，它包括: 需求获取 、 需求建模 、 需求规格说明 、 需求评审 。
需求分析模型 是准确地描述需求的图形化工具，主要有 实体关系图 、 数据流图 、 状态转换图 。需求分析建立起来的模型为日后软件设计人员提供了可被翻译成 数据结构 、 体系结构 、 接口 和 处理过程 设计的模型。 如上图所示，目标系统模型的建立过程分 4 步完成: 把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。
需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。 作为需求分析阶段的复审手段，在需求分析的最后一步应该对功能的正确性、完整性和清晰性以及其他需求给予评价。 需求分析研究的对象是 用户的要求 。
必须 全面理解 用户的各项要求， 准确表达 用户的要求。只有经过确切描述的软件需求才能成为软件设计的基础。 评审应由专人负责，评审组由软件开发成员、软件专家、领域专家和用户构成。
需求分析是一个不断的迭代过程。只有需求全面，准确无误，才能开发出用户满意的系统。 需求获取是软件开发工作中最重要的环节之一，其工作质量对整个软件系统开发的成败具有决定性影响。需求获取工作量大，所涉及的过程、人员、数据、信息非常多，因此要想获得真实、全面的需求必须要有正确的方法。
常规的需求获取的方法有以下几种: 需求分析模型 是准确地描述系统需求的图形化工具。它可以使人们更好地理解将要建造的系统，它有助于系统分析员理解系统的信息、功能和行为，成为确定需求规格说明完整性、一致性和精确性的重要依据，奠定软件设计基础。 需求分析建模的方法有 结构化分析建模 和 面向对象分析建模 。 结构化分析导出的分析模型包括 数据模型 、 功能模型 和 行为模型 。
需求分析模型以“ 数据字典 ”为核心，描述了软件使用的所有数据对象，围绕这个核心的是“ 实体关系图 ”、“ 数据流图 ”和“ 状态转换图 ”。 具体形式如下图所示: 实体关系图ER，Entity-Relationship Diagram :是一种数据模型，是以实体、关系、属性三个基本概念概括数据的基本结构，从而描述 静态数据结构 的概念模型。 ER 包括三种基本元素: 关联的重数 定义了在关联的一端可以存在的数据实体实例的数量。 关联重数可以具有下列值之一: 两个数据对象之间按关联的重数有以下三种关联: 以下实体关系图描述的是教师、课程、学生三者之间的关系。
以下实体关系图描述的是出勤、职工、奖金、扣款之间的关系。 数据流图DFD，Data flow diagram ，是描述数据流和数据转换的图形工具，它是进行结构化分析的基本工具，也是进行软件体系结构设计的基础。 DFD 有四种元素，其基本符号如图所示: 示例，工资计算系统的顶层0层数据流图: 在数据流图中有时也使用 附加符号 : * 、 + 、 ⊕ ，分别表示与、或、互斥关系。
数据流图可分为不同层次，顶层0层DFD 称为 基本系统模型 ，可以将整个软件系统表示为一个具有输入和输出的黑匣子，其加工处理是 软件项目的名称 ，用一个圆圈表示。 DFD 中的每一个加工可以进一步扩展成一个独立的数据流图，以揭示系统中加工的细节。这种循序渐进的细化过程可以继续进行，直到最底层的 DFD 图仅描述加工的 原子过程 为止。
每一层数据流图必须与它上一层数据流图的输入输出保持平衡和一致。 数据流图是在需求陈述的基础上绘制的。 这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能。 第二层数据流图——销售细化: 第二层数据流图——采购细化: 当软件系统涉及 时序关系 时需要进行 行为建模 ，由于数据流图不描述时序关系，系统的控制和事件流需要通过行为模型来描述。
在描述系统或各个数据对象的行为时，采用 状态转换图 。通过描述系统或对象的 状态 ，以及引起系统或对象状态转换的 事件 来表示系统或对象的行为。 状态转换图STD，Status Transition Diagram ，是描述系统状态如何响应外部事件进行转移的一种图形表示。
状态 是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有: 初始状态 、 中间状态 和 最终状态 。 事件 是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的外界事件的抽象。
在状态转换图中，圆圈“○”表示可得到的 系统状态 ，箭头“→”表示从一种状态向另一种 状态的转移 。箭头旁标上 事件名 。 数据字典DD，Data Dictionary 用来描述数据流图中的数据存储、数据加工和数据流。
数据字典与数据流图配合，能够准确、清晰地表达数据处理的要求。 对于在数据流图中每一个被命名的图形元素均加以定义 ，其内�。
需求分析实例回答:海底行神10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg
1.98
9.提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭close-end问题所不能做到的。 需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明:比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式Kiel and Carmel 199
5.。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统MIS的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入buy-in的一种方式。 尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。 在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。 需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。用例在需求分析中的使用多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求McGraw and Harbison 199
7.。
Ivar Jacobson
1.99
2.把这种看法系统地阐述成用例用例的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色actor和用例用例。角色actor表示系统用户能扮演的角色role。
这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的。
