需求分析怎么写

手机评站网今天精心准备的是《需求分析怎么写》，下面是详解！

项目需求分析怎么写

写一份简单的软件需求分析,大概内容是关于一个记事本的,里面有日历,可修改用户,更改背景,更改音乐,大概构思设置用户:添加用户,显示当前用户.日期;显示当前日历,月历.显示;记事本.背景...

写一份简单的软件需求分析,大概内容是关于一个记事本的,里面有日历,可修改用户,更改背景,更改音乐, 大概构思设置用户:添加用户,显示当前用户. 日期;显示当前日历,月历. 显示;记事本. 背景;更换颜色,图片. 编辑;主要有些对记事本的保存打开什么的 音乐,打开文件 我是个学生,没写过这个东西,麻烦各位高手,点点我怎么写 展开

项目需求分析的概念　　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
　　狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
　　需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务　　简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程　　需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
　　问题识别
　　就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
　　分析与综合
　　逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
　　制订规格说明书
　　即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
　　评审
　　对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法　　需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
　　原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
　　原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
　　原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
　　在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
　　追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

计算机毕业论文中需求分析怎么写？

我的题目是基于ASP.NET的教务信息网站，最好能给出详细的写法。...

我的题目是基于ASP.NET的教务信息网站，最好能给出详细的写法。

如何写需求分析报告

资源简介教会你如何写需求分析报告~~·需求分析说明书 1 、系统功能结构图（ HIPO 图） （在该功能结构图中选一个子系统进行逐层分解） 2 、系统功能说明 （对以上选中的子系统进行功能描述） 3 、现有系统的业务流程图及说明 （对以上选中的子系统绘制手工系统或旧的计算机系统的业务流程图并进行简单的功能说明）

项目需求报告要怎么写？

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

java项目需求分析怎么写

需求文档一般分两类：需求调研报告、需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：项目的背景、项目的目标、项目的范围、用户特点、相关技术、规范标准等。相关约束、用户的组织结构、角色等用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出

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

项目目标与任务需求分析=项目的目标和任务。

目标是具体可量化的,由目的而生,计划是达成目的的筹划,而任务就是计划中的每个完成点 一般先有目的,再有计划,后有目标,用任务完成目标

项目目标（Project Objectives）：简单地说就是实施项目所要达到的期望结果，即项目所能交付的成果或服务。 项目的实施过程实际就是一种追求预定目标的过程，因此，从一定意义上讲，项目目标应该是被清楚定义，并且可以是最终实现的。 项目目标包括：可测量的项目成功标准。项目可能有各种各样的经营，费用，进度，技术和质量目标。 项目目标可能还包括费用，进度和质量指标。每一个项目目标都有属性，例如费用目标就有美元单位或人民币单位。

需求分析：开发人员准确地理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。
基本任务: ⑴问题识别：双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求。
⑵分析与综合，导出软件的逻辑模型
⑶编写文档：包括编写"需求规格说明书","初步用户使用手册","确认测试计划","修改完善软件开发计划"

怎样写一个系统的需求分析？一般都包括哪些内容

方法 　　⑴首先调查组织机构情况 　　包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。 　　⑵然后调查各部门的业务活动情况 　　包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。 　　⑶协助用户明确对新系统的各种要求 　　包括信息要求、处理要求、完全性与完整性要求。 　　⑷确定新系统的边界 　　确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 　　常用的调查方法有： 　　⑴跟班作业 　　通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。 　　⑵开调查会 　　通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。 　　⑶请专人介绍。 　　⑷询问 　　对某些调查中的问题，可以找专人询问。 　　⑸设计调查表请用户填写 　　如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。 　　⑹查阅记录 　　即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 　　通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。 　　分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

软件需求说明怎么写

如何写需求分析报告（软件需求说明书GB856T-88）

近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。

在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。

一、目录： 目录要用word的 “引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。

二、内容部分。 国家标准软件需求说明书G856T-88下载

1引言

1.1编写目的

说明编写这份软件需求说明书的目的，指出预期的读者。

（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）

1.2背景

说明：

a．  待开发的软件系统的名称；

b．  本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

c．  该软件系统同其他系统或其他机构的基本的相互来往关系。

（这部分可以将a,b,c分为2部分，例子如下：

1.2.1项目概况

本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。

1.2.2任务分配

a.       任务提出者：xxx

b.       软件开发者：xx

c.       产品使用者：xx

d.       文档编写者：xx

e.       预期产品使用者：xx

）

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

（这部分很简单，就是描述专业词汇，比如

1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。

2. Word2, 解释。。。

）

1.4参考资料

列出用得着的参考资料，如：

a．  本项目的经核准的计划任务书或合同、上级机关的批文；

b．  属于本项目的其他已发表的文件；

c．  本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2任务概述

2.1目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

（

本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能； 等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。

图

图1. 该系统的组成同其他各部分的联系和接口

）

2.2用户的特点

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束

（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。

xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。

维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。 这部分用户主要是采用了本系统之后的后期工作维护者。

等等

）

2.3假定和约束

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。

（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）

3需求规定

3.1对功能的规定

用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。

（例如：

INPUT输入

PROCESS处理

OUTPUT输出

LOAD负载量

A

预处理,做怎样的动作，

AA

CC

B

BBBB

Bb

v

C

CCCC

cc

v

表一、xx模块IPO表

对IPO表的简单文字描述。

）

3.2对性能的规定

3.2.1精度

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

（例如：

Xx目标处理：1Byt–10M，包括左右边界值。

yy精度范围：….

ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。

）

3.2.2时间特性要求

说明对于该软件的时间特性要求，如对：

a．  响应时间；

b．  更新处理时间；

c．  数据的转换和传送时间；

d．  解题时间；等的要求。

(这部分只要一一列举就可以：

由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下：

a．  xx响应时间：xxms左右；

b．  yy更新处理时间：yy；

c．  zz数据的转换和传送时间：zz；

d．  vv解题时间：vv。

等等

)

3.2.3灵活性

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：

a．  操作方式上的变化；

b．  运行环境的变化；

c．  同其他软件的接口的变化；

d．  精度和有效时限的变化；

e．  计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

（这部分按列举来即可， 由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下：

f．   操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。

g．  运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；

h．  同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；

i．   精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。

j．   计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。

等等

）

3.3输人输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

（这部分可以把输入输出分为 3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。

XXX输出

数据名称：XXX输出数据

实际含义：用于XX,表示XXXX

数据类型：Character(字符串)

数据格式：XX

数据约束：由于xxx,，大小在xx以内

）

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。

（

根据实际系统要求列举即可

Name名称

Number数量

Size大小

Increase增长

词典xx

xx

xxxx

并行执行，其大小依据实际xx大文本而增长

）

3.5故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。）

3.6其他专门要求

如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

（例如安全保密性：密钥更换等； 预期扩展：扩展兼容等；OS更换：Slackware转SUSE等

）

4运行环境规定

4.1设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a．  处理器型号及内存容量；

b．  外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c．  输入及输出设备的型号和数量，联机或脱机；

d．  数据通信设备的型号和数量；

e．  功能键及其他专用硬件

（列举说明即可）

4.2支持软件

列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。

（操作系统和版本：xxxx

支撑环境和版本：xxxx

备用IDE环境和版本：xxxx

与该软件有关的软件组件：xxxx

后续可能扩展环境：xxxx

）

4.3接口

说明该软件同其他软件之间的接口、数据通信协议等。

(例如：

a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。

图2.软件接口调用图

b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx

)

4.4控制

说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

(例如：

下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下：

图3 .控制流程图

图3的具体说明情况如下表所示：

Name模块名称

Method运行方式

Signal控制信号

Forward控制去向

主程序模块

运行框架

用户调用或运行

1.       调用xx模块

2.       调用xx方法

3.       调用标准输出模块

xxx模块

xxx

xxx调用

Xxx模块

)

附录： 软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88
操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc
测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc
测试计划（GB8567——88）.doc 图1.doc
概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc
开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc
可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc
模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc
软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc

如何做需求分析

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

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

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

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：
1. 需求分析及变更管理
2. 项目模型及业务流程分析
3. 系统分析及软件建模
4. 界面设计、交互设计及程序开发
5. 系统测试和文档编写
6. 客户培训、技术支持和售后服务

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

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

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

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

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

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

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

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

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

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

笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

三：利用自然的语言描述项目模型

在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。

请比较以下两份关于需求的描述，
“用户在访问首页的时候可以在点击‘客户通道’按钮，弹出填写‘用户名’和‘密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。”

“站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。”

前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。

四：利用示意图和图表将用户的需求表现出来

需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。

制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。

在RUP中有这样的描述：

利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。

以用户友好的方式帮助收集并改进用户需求。

鼓励更有创造性、更加创新的设计解决方案。

鼓励团队复审，并避免所有人都不希望出现的特征。

确保以可理解、直观的方式实施特征。

使访谈过程变得轻松，避免出现访谈没有结果的现象。

简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行“实时”演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。

五：什么人要看需求分析报告

项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。

我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。

例如：

项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。
开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；
操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；
界面设计人员根据项目的性质和定位确定表现方式。
测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；

通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：

六：建立需求变更日志，制作新版本的需求分析报告

尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。

在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。

在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。

关于需求分析和变更管理可以参照下图示意：

七：本阶段重点工作角色

在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。

客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。

在实际工作中，很多项目失败的起因都和需求分析有关。 客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。

为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。

以下提供一份需求管理计划的模板可作为参考：

八：总结

根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：

仔细聆听，罗列客户的所有要求；
将需求进行分析，确认可操作的系统模型；
利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意；
迅速确定网站的用户角色；
比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；
分析确定每个角色的权限及可操作的功能；
比如会员可以查看特别信息、修改个人信息、退出登陆等；
前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等；
网站管理员可以更改栏目、修改网站界面等；
制作流程图和示意图将需求表现出来；
让客户参与到示意图的设计中，及时正确的反应出需求变更。
制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
通过需求《管理计划书》使每个参与人员看到共同的努力目标。