软件项目需求分析的流程，原型分析法与发需求文档管理

（一）软件需求分析的工作步骤和流程

第一阶段：
总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。
该阶段的主要工作方法：客户访谈
输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结）

第二阶段：
详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。
该阶段的主要工作方法：访谈、业务分析、原型设计演示
输出成果：调研分析报告、原型反馈报告、业务流程报告 

第三阶段：
需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统。
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

（二）需求分析之原型分析法

　    原型法（Prototyping）的理念是指在获取一组基本需求之后，快速地构造出一个能够反映用户需求的初始系统原型。让用户看到未来系统的概貌，以 便判断哪些功能是符合要求的，哪些方面还需要改进，然后不断地对这些需求进一步补充、细化和修改。依次类推，反复进行，直到用户满意为止并由此开发出完整 的系统。简单的说，原型法就是不断地运行系统的“原型”来进行揭示、判断、修改和完善需求的分析方法。

      原型需求分析法的特点

      原型法是一种循环往复、螺旋式上升的工作方法，它更多地遵循了人们认识事物的规律，因而更容易被人们掌握和接受。原型法强调用户的参与，特别是对模型的描 述和系统需求的检验。它强调了用户的主导作用，通过开发人员与用户之间的相互作用，使用户的要求得到较好的满足。不但能及时沟通 双方的想法，缩短用户和开发人员的距离。而且能更及时、准确的反馈信息，使潜在问题能尽早发现并及时解决， 增加了系统的可靠性和适用性。

      简单的说，原型法是将系统调查、系统分析和系统设计合而为一，使用户一开始就能看到系统开发后是一个什么样子。而且用户参与了系统全过程的开发，知 道哪些是有问题的，哪些是错误的，哪些需要改进等，就能消除用户的担心，并提高了用户参与开发的积极性。同时，用户由于参与了开发的过程将有利于系统的移 交、运行和维护。

　　但需要注意的是，原型法的适用范围是比较有限的。它只对于小型、简单、处理过程比较明确、没有大量运算和逻辑处理过程的系统比较合适。它的局限 性是对于大型的系统不太适合，因为对于需要大量的运算、逻辑性较强的程序模块，原型法是很难通过简单的了解就构造出一个合适的模型，供用户评价和提出修改 建议。

（三）使用原型法进行需求分析的流程

　　（1）快速分析，弄清用户的基本信息需求
　　需求分析原型法的第一步是在需求分析人员和用户的紧密配合下，快速确定软件系统的基本要求。也就是把原型所要体现的特性（界面形式、处理功能、 总体结构、模拟性能等）描述出一个基本的规格说明。快速分析的关键是要选取核心需求来描述，先放弃一些次要的功能和性能。尽量围绕原型目标，集中力量确定 核心需求说明，从而能尽快开始构造原型。
　　这个步骤的目标是要写出一份简明的骨架式说明性报告，能反映出用户需求的基本看法和要求。这个时候，用户的责任是先根据系统的输出来清晰地描述 自己的基本需要，然后分析人员和用户共同定义基本的需求信息，讨论和确定初始需求的可用性。

　　（2）构造原型，开发初始原型系统
　　在快速分析的基础上，根据基本规格说明应要尽快实现一个可运行的系统。我在这个项目得到的经验是原型系统可先考虑原型系统应必备的待评价特性， 暂时忽略一切次要的内容。例如安全 性、健壮性、异常处理等。如果这时为了追求完整而把原型做得太大的话，一是需要的时间太多，二是会增加后期 的修改工作量。因此，提交一个好的初始原型需要根据系统的规模、复杂性和完整程度的不同而不同。本步骤的目标是：建立一个满足用户的基本需求并能运行的交 互式应用系统 。在这一步骤中用户没有责任，主要由开发人员去负责建立一个初始原型。

　　（3）用户和开发人员共同评价原型
　　这个阶段是双方沟通最为频繁的阶段，是发现问题和消除误解的重要阶段。其目的是验证原型的正确程度，进而开发新的原型并修改原有的需求。由于原 型忽略了许多内容和细节，虽然它集中反映了许多必备的特性，但外观看起来还是可能会有些残缺不全。因此，用户可在开发人员的指导下试用原型，在试用的过程 中考核和评价原型的特性，也可分析其运行结果是否满足规格说明的要求，和是否满足用户的愿望。并可纠正过去沟通交流时的误解和需求分析中的错误，增补新的 要求，或提出全面的修改意见。

　　总的来说，原型法是通过强化用户参与系统开发的过程，让用户获得系统的亲身体验，找出隐含的需求分析错误。原型需求分析法是鼓励改进和创造，通 过不断交流来提高需求实现的质量和软件产品的质量，目的是为了更好的提高客户满意度。

（四）软件开发需求文档怎么写 七个问题你一定要考虑

软件开发需求文档怎么写？在软件开发过程中，需求分析可以说是核心任务之一，就像一支将要远航的船队，要在指定时间内到达目录地，他们需要一条正确的航线，才能到达目的地，如果航线有误，他们将会误时到达，或是不回到原位将永远到达不了，这么重要的东西，但在国内很多团队中缺少。

　　在项目完成的时候，回头看看，其实我们做了很多不必要的事，浪费了很多时间、人力和物力，为保证在今后的开发中减少这些错误的发生，现将一些问题记录下来。软件开发需求文档怎么写？为了了解系统需求，先可以从概要式的需求着手，再细化需求，需求分析必须拟定文档，在写文档之前我们必须做好寻求分析的范围，总结为以下几点： 

　　1、要做一个什么样的系统
　　2、系统将要在什么样的环境下进行
　　在设计新系统的同时你必须考虑，要花时间去了解以前系统的功能，接口等，如果不了解，等你把新系统开发完了才发现系统脱离了公司原有的业务流程，让公司无法运作，那就代表你开发的系统根本没有价值。
　　3、要解决哪些问题
　　开发出来软件系统就是为了解决客户需求的，一个B2C网站就是卖商品，主要由客户、商品、购物车、定单组成，将这些核心的功能定义好，其它的意外都不会太影响到整个系统的进程。
　　4、将来可能会有哪些变化
　　面对将来的发展，我们也许不能完全考虑到，但与公司的战略发展，可以提前考虑些，能想到多少就想多少，多多益善，我们开发一个系统不是只满足当前的需求，如果眼光只放在眼前，那么你这个系统很快就会被淘汰，功能也许不需要现在实现，但接口总得留下吧，不然想改进都是很困难的事，如果一个稍微的小需求都要动系统构架，这个系统会越来越不稳定，作为系统分析师，这块也是至关重要的。
　　5、系统可以维持任务的周期是多少
　　系统周期与公司战略发展是紧扣的，一个系统的功能不可能随着社会的变化，能一直满足市场需要的，在设计系统的时候，可以了解一下公司的战略发展，比如公司三年之内要做成什么样，客户多少，网站浏量，可以做下评估，这样就考虑系统构架的问题，你开始就准备构架一个大胖子，但现在需求简单，在实际的运行中，速度缓慢，其实你构架越复杂，系统运行就越缓慢，虽说现在很多大系统运行的都很好，但要想想，人家服务器，网络构架是什么样的，你不可能让你的系统一线就有这么好的环境，就算有，那成本也太大了，一般的公司也吃不消。
　　6、系统分几个阶段实施
　　在开发初期，我们不可能将系统所有的功能都能完成的很好，为了加快开进度，为了系统能尽早上线，我们得像建楼一样，分阶段进行，分段实施。分阶段实施，可以有节约成本，也可以加快实施速度，不管是作为公司的管理人员还是开发人员，能尽快看到成果，会提高信心。
　　7、系统开发团队由哪些人组成
　　一个好的团队，必定是发挥了团队中每个人的优势，在开发团队中，不是你技术能力强，你就是最有价值的人，我相信在开发团队里没有一个从头到尾都能支持的能人，不是不没，是我是觉得不可能存在，也许我么说有些人不服，其实我这么说也有我的理由，一个人也许有机会经历团队中的每个环节，并且都能深入，但绝对不是一个机会，如果有，那就是一个人的开发，一个人的开发也不能叫团队，有时候，一个人什么都能做，多了一个人，什么都做不好，但面对大的项目，不得不进行团队合作。
　　小编带来的资讯到这就结束了，希望对你有所帮助。要想了解更多关于软件开发需求文档怎么写的信息，大家可以去服务购行业资讯平台，那里有超多资讯在等你。如果有不满意的地方，欢迎指正。小编表示真的很惭愧，因为不是这方面的专家，可能有所疏漏，希望大家谅解！

（四）怎样做软件的需求分析？

软件需求的定义：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
需求工程的定义：
需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法：
（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。。
（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面：
1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。
2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。
5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。
6）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。
4.需求分析评价标准
（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。