项目的需求分析怎么写?

项目需求分析怎么写

项目需求分析的概念需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specificatio郸)2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.

需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.

问题识别

就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型, *** 作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.

分析与综合

逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).

制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.

评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.

原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.

原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个......

软件的需求分析怎么写啊？

1. 引言

1.1　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.

1.2　项目背景

1.2.1项目委托单位:****公司

1.2.2开发单位:***公司

1.3　定义

1.4参考资料

2. 任务概述

2.1　目标:

<1>决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理.

2.2　运行环境:

<1>硬件方面:Pentium级处理芯片

1兆显存的兼容显卡

256色,800*600的兼容显示器

标准兼容打印机

<2>软件方面: WIN95 *** 作系统

2.3　条件与限制:

编程用计算机一台

完成期限2000/7/1

无资金供给

3. 数据概述

数据流程图如下:

3.1　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

3.2 　动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

3.3　数据库描述:

人事管理数据库:公司内人员的个人详细信息,包括档案信息

销售管理数据库:当日销售记录及以前的销售统计,用于销售分析

财务管理数据库:公司内部账目及收支情况详表

技术管理数据库:公司所需各技术档案的详细记录(包括文档)

3.4 数据字典:

<1>数据流词条描述:

1.数据流名:登录信息

来源:用户的输入

去向:系统内部检验部分

组成:用户名,密码

流通量:每次登录输入一次

2.数据流名:登录结果

来源:系统

去向:用户

组成:返回信息

流通量:每次登录返回一次

3.数据流名:输入修改信息

来源:用户

去向:系统判断部分

组成:根据各数据库内容而不同

流通量:依用户输入而定

4.数据流名:反馈信息

来源:系统判断部分

去向:用户

组成:系统经判断后发回的字符数据

流通量: 依系统当前信息而定

5.数据流名:识别信息

来源:系统内部检验部分

去向:系统判断部分

组成:系统各数据库的标识信息

流通量:用户每次输入流通一次

6.数据流名:处理信息

来源:系统判断部分

去向:各数据库处理部分

组成:读取/修改标识,读取/修改的变量名称

流通量:用户每次输入流通一次

7.数据流名:读取修改

来源:系统判断部分

去向:系统各数据库

组成:读取/修改标识,读取/修改内容

流通量: 用户每次输入流通一次

<2>数据文件词条描述:

1.数据文件名:人事数据

简述:存储人员信息

数据文件组成:人员的各项信息(以CString类型为主)

2.数据文件名:销售数据

简述:存储当日及从前的销售记录

数据文件组成:销售的各项信息

3.数据文件名:财务数据

简述:存储财务管理信息

数据文件组成:财务管理的各项记录

4.数据文件名:技术数据

简述:存储公司内部使用的技术档案信息

数据文件组成:技术档案名称,内容

<3>加工逻辑词条描述:

1.加工名:检验

......

项目目标与任务需求分析应该怎么写？

项目目标与任务需求分析=项目的目标和任务，目标和任务是什么就写什么了

项目需求报告要怎么写？

听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。听棠所说到的几点，感受特别深：“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。

如何做需求分析

随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web

服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：

1. 需求分析及变更管理

2. 项目模型及业务流程分析

3. 系统分析及软件建模

4. 界面设计、交互设计及程序开发

5. 系统测试和文档编写

6. 客户培训、技术支持和售后服务

需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？

业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。

一：让客户畅所欲言，罗列出所有的需求

让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求

很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下......

做程序，项目需求分析，一般做多久。

国内很多老一辈的根本不注重这一点。但国外的，很小的开始实战写需求了。因为他们一直认为需求是相当重要。每次都做项目前都是，乱七八 *** 的需求分析，像个草搞。偶尔做一下，改一下。改一下需求，那么，原来的框架，编码都要改。而我同学他们的虽然做需求做了一个月多，但却是按需求很顺利的一气搞定。我问的是：无论是多大，还是多小的项目，都要把需求写清楚再做。

java 项目需求文档要怎么写？

需求文档一般分两类

需求调研报告

需求分析报告

调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。

分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：

项目的背景

项目的目标

项目的范围

用户特点

相关技术、规范标准等

相关约束

用户的组织结构、角色等

用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等

总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出

全球制造业软件信息化技术发展呈现出的特点与趋势必将带动安全防范市场的发展

底层核心技术逐渐成熟

经过数十年的发展，西方发达国家在制造业信息化领域的底层核心技术方面，已经有了长足发展。例如，在三维造型底层核心系统、线性与非线性有限元分析解算器、先进生产排程（APS）技术、五轴联动的CAM加工与仿真技术等制造业信息化领域的关键技术，已经十分成熟，并且在全球的制造企业得到了广泛应用。

支撑企业管理的新兴技术发展迅速，应用领域不断拓展

随着西方企业不断向全球拓展，企业规模越来越大，业务越来越复杂，对制造业信息化厂商提出了更高的要求。因此，制造业软件信息化技术的疆界不断拓展，新兴技术不断涌现。例如，随着企业管理需求的精益化，涌现出企业资产管理（EAM）、大修维护管理（MRO）、需求管理、劳动力管理、企业绩效管理、统计过程控制（SPC）、供应商关系管理的新兴技术。

先进生产制造技术带动制造业软件信息化技术发展

随着制造业的产品结构日趋复杂，PLM技术开始向支持机、电、软件混合设计发展，支持产品的包装管理、工程计算和复杂文档的管理。而随着复合材料的广泛应用，支撑复合材料的设计、仿真和制造的软件信息化技术也逐渐发展起来；虚拟现实、逆向工程、试验数据管理、仿真数据管理、可靠性分析等新兴技术也随着工业界的应用需求，而得到蓬勃发展。

广泛应用SOA、SAAS等先进的软件构架和交付方式

随着IT技术的发展，SOA（面向服务的架构）改变了软件的应用模式。SOA架构将固化的软件转变为可以灵活配置的组件，可以实现随需而变，从而降低了软件信息化技术维护、升级的成本，使信息化软件可以更好地适应企业业务流程的变化。同时，越来越多的企业为了降低IT应用的成本，而将购买软件转化为租用服务，这促进了制造业信息化厂商发展SAAS（软件即服务）模式的应用软件。SAAS已成为发达国家迅速发展的新兴软件交付模式。

密切结合Web2.0、SNS和网络技术的新发展

互联网的广泛应用对制造业软件信息化技术的发展产生了深远影响。尤其是Web2.0技术强调互动性，而FaceBook等SNS（Social Networking service，社交网络服务）网站的兴起，使得支撑产品研发的制造业软件信息化技术也开始涌现出新兴技术。微软推出了支持Social Computing的SharePoint系统，达索系统提出PLM2.0技术。而支持广域网应用的很多软件信息化技术也得到跨越式发展，例如远程接入、广域网加速、云计算、虚拟化技术等等。而对于B/S模式的支持，已成为信息化软件的基本功能。

制造业信息化集成技术发展迅速

随着制造业软件信息化技术的广泛应用，实现各类软件信息化技术的集成成为一个重要的发展方向。一些主流厂商纷纷通过并购，而为制造企业提供更紧密的集成方案。例如，西门子PLM致力于实现产品生命周期与制造生命周期的集成；而EAI（企业应用集成）和BPM（业务流程管理）等技术也日益得到广泛应用，MES成为实现ERP与底层自动化系统集成的枢纽。SAP、ORACLE等厂商已经拥有了全面解决企业各个环节管理问题的制造业信息化集成解决方案。

帮助企业遵循环保和企业治理等法律、法规

全球能源的紧缺使得制造业越来越关注节能、环保，支撑绿色设计、绿色制造、绿色供应链的相关技术得到蓬勃发展，例如LCA（Life Cycle Assessment，产品全生命周期评估）技术，对碳排放的评估软件等。同时，由于美国和欧盟对于进口产品提出了日益严厉的环保要求，支撑企业检测和通过相关法律法规的应用软件也开始广泛应用。而随着美国对企业治理的要求越来越严格，尤其是萨班斯法案的出台，使得制造业也需要应用相应的软件系统来实现合规管理。

开源技术长足发展

为了降低软件的应用成本，国外发展起来很多开源的国际组织。不仅是在 *** 作系统层面，有Linux等组织，而且在CAD领域，发展起来IntelliCAD平台，在数据库、ERP和PLM领域，也都发展起来很多开源的组织和产品。开源技术使得众多的开发商可以共同完善技术，推进应用，降低信息技术的应用成本。

全球制造业信息化市场的特点与趋势

在西方发达国家，制造业信息化市场逐渐成熟，甚至走向饱和。目前，西方发达国家的制造业信息化市场呈现出以下特点与趋势：

软件产品销售额萎缩，软件的实施服务和老用户的维护服务的营业额占很大比例。

由于西方国家的企业发展比较成熟，信息化软件应用已经十分普及，因而软件产品（许可证）销售额增长缓慢，甚至出现下降趋势。同时，制造企业普遍购买软件的维护服务，包括热线电话、互联网在线服务和现场的技术支持服务、软件升级服务等。因此，在主流的制造业信息化软件厂商的营业额中，老用户的维护服务所占比例已经超过50%，而很多软件厂商的实施服务收入也超过了软件产品的营业额。因此，制造业信息化厂商普遍非常重视维护服务。

形成了完整的制造业信息化生态系统

西方发达国家已经建立了完整的制造业信息化生态系统，包括制造业信息化软硬件产品提供商、咨询服务与实施商、渠道商、以及第三方研究机构等等。咨询服务公司发展迅速。同时，制造业信息化厂商与用户建立了良好的合作与服务机制，很多厂商组建了用户协会，由用户协会通过定期组织交流，以及用户俱乐部网站等形势，定期向厂商反馈产品改进的需求，这样，促进制造业信息化软件的改进和成熟。同时，国外的高校、研究机构、制造业信息化厂商与工业界建立了深入合作。例如，德国的Fraunhofer、亚琛工业大学都与工业界建立了深入的合作。

制造业信息化厂商之间的并购非常普遍

大型厂商不断通过兼并、收购，而实现自身的发展壮大，完善自身的产品线和解决方案。例如ORACLE公司，近年来先后并购了Siebel、Peoplesoft、Agile、BEA等大型软件公司，并购的金额累计达数百亿美元；SAP公司去年投资82亿美元并购了BO公司；INFOR公司先后并购了SSA、Softbrands等数十家ERP软件公司，并购金额达30亿美元以上；IBM公司在放弃了盈利低的PC等业务的同时，也斥巨资并购了很多软件公司。而2007年西门子公司斥资34亿美元并购了UGS。而Autodesk、达索系统、PTC等公司也并购了很多专业公司。信息化厂商的并购一方面是为了拓展用户群、获得稳定的维护服务收入，同时，可以完善自身的技术和解决方案。

国际制造业信息化厂商高度重视中国、印度、东欧等新兴市场

目前，平均而言中国制造业信息化的各个细分市场占全球的份额在1-2％之间。但是，由于中国制造业的蓬勃发展，国外主流的制造业信息化厂商已经悉数进入中国市场。不仅在中国设计了营销和服务机构，也逐渐开始在中国设立研发和技术支持中心，以便实现产品、营销和服务的本地化。国际制造业信息化厂商非常注重与中国高校的合作，建立了众多的培训中心，力图培养产品研发、实施、服务和应用人才，为其培养未来的用户。国际制造业信息化厂商也非常重视拓展印度、东欧等新兴市场。在这些新兴市场上，厂商可以获得更高的软件产品销售收入，实现迅速增长。

全球制造业信息化应用趋势

西方发达国家制造业软件信息化技术的应用呈现出以下趋势：

全球大型制造企业引领制造业软件信息化技术的发展。

随着制造业领域的跨国企业在全球的拓展，为制造业信息化厂商不断提出新问题和新需求，从而引领了制造业软件信息化技术的发展。例如，全球企业实现跨国的产品开发、营销和服务，对信息系统提出了支持多语种、多工厂、多个企业实体的开发与管理需求，以及全球协作开发的需求。工业发达国家许多企业将软件信息化技术综合集成并应用服务于研发、管理、财务运作、营销、服务等核心业务，实现了产品研制、采购、销售等在全球范围内的协作，在全球范围进行资源的优化配置。例如，空客A380四国五地的研制生产基地信息共享集成与研制流程协同，30个国家的1500家零部件生产商和供应商之间的网络协同。洛克希德?马丁公司在联合攻击战斗机（JSF）研制过程中，以项目为龙头，以数字样机为核心，以Internet和协同产品商务系统为综合集成平台，实现了CAD/CAE/CAM/MRP/SCM/MRO的集成，建立了全球30个国家、50家公司、50,000用户参与研发的数字化集成协同环境，充分发挥各合作伙伴的优势能力，使设计时间减少50%，制造时间减少了66%，备件减少50%。

制造业信息化应用取得实效

发达国家的制造企业已经广泛树立了对信息技术的正确认识，明确自身对信息技术的需求，将制造业软件信息化技术作为软装备，实现了广泛应用，实施和应用的成功率很高。而制造企业在进行兼并、收购时，也同时会进行IT系统的整合。制造业软件信息化技术，已成为支撑企业的业务拓展和变革，实现企业发展战略的必要支撑。值得关注的是，在西方国家崛起了IDC、Gartner、CimData、AMRresearch等研究机构，对制造业软件信息化技术、市场和应用趋势进行分析，成为制造业软件信息化技术发展的指南。

越来越多的企业进行IT外包和业务外包，强化企业间的协同

在西方发达国家，越来越多的制造企业将非核心业务外包，同时，将IT应用进行外包。这种外包的趋势不仅是中小企业开始通过SAAS模式应用软件，而且很多大型企业也应用了软件租用模式。同时，制造企业非常注重加强与上下游企业、同行企业的协同。一些行业电子商务平台得到了广泛应用。

总之，制造企业对软件信息化技术的发展提出了需求，推进了制造业软件信息化技术的发展；而制造业软件信息化技术在制造企业中的应用，又支撑了制造企业的全球化、服务化、精益化、专业化发展。

转载以下资料供参考

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解需求分析指需求的分析、定义过程。

原因

需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。

需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。

任务

简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。

过程

需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。

问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、 *** 作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。

方法

需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。

原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。

原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。

实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

在使用原型化方法时有两种不同的策略：废弃策略、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。

追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

需求分析20条法则

客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。

3、 分析人员必须编写软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案

通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、 描述产品使用特性

客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、 允许重用已有的软件组件

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、 要求对变更的代价提供真实可靠的评估

有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、 获得满足客户功能和质量要求的系统

每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、 给分析人员讲解您的业务

分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、 抽出时间清楚地说明并完善需求

客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、 准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、 及时作出决定

分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、 尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在 *** 作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、 划分需求的优先级

绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、 评审需求文档和原型

客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、 需求变更要立即联系

不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、 遵照开发小组处理需求变更的过程

为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、 尊重开发人员采用的需求分析过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际 *** 作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT>

---