软件需求方案

软件需求分析(SoftwareReguirementAnalysis)就是研究用户需求得到得

东西，完全理解用户对软件需求得完整功能,确认用户软件功能需求,建立可确认

得、可验证得一个基本依据。

软件需求分析就是一个项目得开端，也就是项目实施最重要得关键点。据有

关得机构分析结果表明，我们设计得软件产品存在不完整性、不正确性等问题

80%以上就是需求分析错误所导致得，而且由于需求分析错误造成根本性得功能

问题尤为突出。因此，一个项目得成功软件需求分析就是关键得一步。

一、软件需求分析理论

如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S,可

能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功

能域，可以用D1、D2、…Dn表示，那么，我们可以用一个表达式描述为

S={D1,D2,D3,…Dn}

但就是，功能域Di依然存在着有若干个问题P1、P2、P3、…Pm组成，并且每个

功能对应于子系统中得一个软构件，我们可以表示为

Di={P1,P2,P3,-Pm)

同样，功能Pj有若干个行为F1、F2、F3、…Fk,每个行为对应于软构件中得实

现方法

Pj={F1,F2,F3,-Fk}

一个软件包含了所有功能得集合，同时包含了实现所有功能得所有方法与算

法描述。需求分析就是依据于用户需求，经过需求问题识别，进行分析、消化与综

合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户

需求目标。

需求分析方法始终贯穿着吸收、同化、贯彻方法与手段，用商业化行为解决

需求与实现中存在得矛盾，解决用户需求与商业化产品融通，解决规范与个性化

追求。

二、软件需求分析目标

软件需求分析得主要实现目标:

1）对实现软件得功能做全面得描述，帮助用户判断实现功能得正确性、一致性

与完整性，促使用户在软件设计启动之前周密地、全面地思考软件需

求；

2）了解与描述软件实现所需得全部信息，为软件设计、确认与险证提供一个基

准；

3）为软件管理人员迷行软件成本计价与编制软件开发计划书提供依据；

需求分析得具体内容可以归纳为六个方面：软件得功能需求，软件与硬件或

其她外部系统接口，软件得非功能性需求，软件得反向需求，软件设计与实现上得

限制，阅读支持信息。

软件需求分析应尽量提供软件实现功能需求得全部信息，使得软件设计人员

与软件测试人员不再需要需求方得接触。这就要求软件需求分析内容应正确、完

整、一致与可验证。此外，为保证软件设计质量，便于软件功能得休整与验证，软

件需求表达无岔意性，具有可追踪性与可修改性。

2、1、软件功能需求

软件得功能需求就是整个需求分析最主要、最关键与最复杂得部分，它描述

软件得各种可能得条件下，对所有可能输入得数据信息，应完成那些具体功能，产

生什么样得揄出。描述软件功能需求就是应注意下面几点：

1）功能需求得完整性与一致性

对功能得描述应包含与功能相关得信息，并应具有内在得一致性（即各种描

述之间不矛盾、不冲突）。应注意以下几点：

（1）给出触发功能得各种条件（如:控制流、运行状态、运行模式等）；

（2）定义各种可能性条件下得所有可能得输入（包括合法得输入空间

与非法得输入空间）；

（3）给出各种功能间可能得相互关系（如各个功能间得控制流、数据

流、信息流，功能运行关系：顺序、重复、选择、并发、同步）；

（4）给出功能性得主要级别（如：基本功能、可由设计者选择逐步实现

得功能、可由设计者改变实现得功能等）；

(5)尽可能不使用“待定”这样得词。所有含有待定内容得需求都不

就是完整得文件,如果出现待定得部分，必须进行待定部分内容说

明，落实负责人员、落实实施日期。

2)功能描述得无岔意性与可追踪性

需求功能描述得无岔意性、可追踪性与规范化：

(1)功能描述必须清晰地描述出怎样输入到怎样揄出，并且输入、输

出描述应对应有数据流描述、控制流描述图，这些描述必须与其它

地方描述一致；

(2)可以用语言、方程式、决策表、矩阵或图等对功能得描述。如果

选用语言描述必须使用结构化得语言，描述前必须说明该步躲(或

子功能:得执行就是顺序，选择，重复，还就是并发，然后说明步骤

逻辑。整个描述必须单人单出。

(3)描述时，每一个功能名称与参照编号必须唯一，且不要将多个功

能混在一起进行描述，这样便于功能得追踪与修改。

(4)功能描述应注意需求说明与程序设计得区别。需求设计仅仅就是

软件得功能设计，它给出软件运行得得外部功能描述，以及为了实

现这一外部功能必须做哪些事情(泉用与种数据结构，定义多个模

块,接口间得接口等)就是设计阶段得事情，功能描述不应涉及到

那些细节问题，以避免给软件设计带来不必要得约束。

2、2、软件与硬件或其她外部系统接口

软件与硬件或其它外部系统接口包括下述内容：

(1)人机接口：说明输入、输出得内容、屏幕安排、格式等要求；

(2)硬件接口：说明端口号，指令集，输入输出信号得内容与数据类型，初

始化信号源，传输通道号与信号处理方式。

(3)软件接口：说明软件得名称、助记符、规格说明、版本号与来源；

(4)通讯接口：指定通讯接口与通讯协议等描述。

2、3、软件得非功能性需求

软件非功能性需求就是指软件性能指标，容限等功能以外得需求。一般指下

述内容：

(1)时间需求:输入、输出频率,输入、输出响应时间，各种功能恢复时间

等；

(2)处理容限、精度、采样参数得分辨率，误差处理等；

(3)可靠性得MTBF要求，可维护性、安全性要求等。(对可能得不正常得

输入给以正常响应就是可靠性得重要内容，这属于功能性需求。)

2、4、软件反向需求

软件得反向需求描述软件在那些情况下不能做什么。这一条就是随软件实际

要求而定。有两类情形需要采用反向需求得形式。第一种情况：某些用户需求适

宜采用反向形式说明，如数据安全性要求属于这类形式。第二种情况：对一些可靠

性与安全性要求较高得软件，有些必须描述软件不能做些什么。如控制点火时序，

我们必须交代清楚在那些情况下不能点火，否则会造成故障。

2、5、软件设计与实现上得限制

软件设计与实现上得限制主要指对软件设计者得限制。如软件运行环境得限

制(选择计算机类型，使用配置，操作系统得限制等)、设计工具得限制(使用语言、

执行得标准)与保密要求等。

2、6、阅读支持信息

这部分内容就是为了更好得帮助我们理解用户需求，也就是为了使需求便于修改

与追踪。其本身并不就是对需求得描述，但它影响到需求分析得可读性，也属于需

求分析得一个重要部分。一般目录、需求背景信息、内容索引、交叉引用表、注

释等均属于这个部分得内容。

三、软件需求分析人员组织

软件需求分析其根本性问题就是理解用户功能需求，由此软件需求分析实际

上就是与客户间交流过程完成得目标。要求我们组织适当得参与人员进行交流活

动。

需求分析就是一个综合团队得工作，就是在需求分析理论得指导下，对用户

需要进行渐进方式逐步深化；通过不断变化方式形成具体约束；膂力实现需求功

能目标形成特色效果得商业化产品。需求分析就是一个商业行为，完全就是一个

商业化操作，要求有商业、技术等结合得团队共同合作，解决需求与设计得同步，

设计符合需求。

项目涉及内容，项目大小都需要我们考虑参加软件需求分析工作团退得人数,

配置合理得参与人员。一般我们必须有商务活动人员，项目管理人员，设计技术人

员等参加，而且要求组织人员必须明确负责范围，以及明确工作目标，保证实施得

有效性。

四、软件需求分析方法

为了保证项目得正常实施，并且能够顺利得完成，我们必须加强项目管理与

重视项目分析工作。我们只有从实际出发，切切实实地把握用户需求，把握用户需

求目标,把握用户将来功能界定，保证我们开发工作正确性方向。

4、1、重点监控软件需求分析办法

由于软件项目得特殊性与行业覆盖得广阔性，以及需求分析得高风险性，软

件需求分析得重要性就是不言而喻得，同时需求分析又得得确确难做。其原因基

本就是由于以下情况造成得。

4、1、1、客户说不清楚需求

有些客户对需求只有朦胧得感觉，当然说不清楚具体得需求。例如全国各地

得很多部门、机构、单位在进行应用系统以及网络建设时，客户方得办公人员大

多不清楚计算机网络有什么用，更缺乏IT系统建设方面得专家与知识。此聆，用

户就会要求软件系统分析人员替她们设想需求。工程得需求存在一定得主观性，

为项目未来建设埋下了潜在得风险。

4、1、2、需求自身经常变动

根据以往得历史经脸，随着客户方对信息化建设得认识与自己业务水平得提

高，她们会在不同得阶段与时期对项目得需求提出新得要求与需求变更。事实上，

历史上没有一个软件得需求改动少于三次得！所以必须接受“需求会变动”这个

事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些就是稳定得

需求，哪些就是易变得需求，以便在进行系统设计时,将软件得核心建筑在稳定得

需求上，同时留出变更空间。咨询监理方在需求分析得功能界定上担任一个中间、

公平、公正得角色，所以也必须积极参与到需求分析得准备中来，以便协助客户方

与承建方来界定“做什么”、“不做什么”得系统功能界限。

4.1.3、分析人员或客户理解有误

软件系统分析人员不可能都就是全才，更不可能就是行业方面得专家。客户

表达得需求，不同得分析人员可能有不同得理解。如果分析人员理解错了，可能会

导致以后得开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探

情报，它给上司写了一份报告：“主宰地球得就是汽车。它们喝汽油，靠四个轮子

滚动前进，嗓门极大，双眼在夜里能射出强光……有趣得就是，车里住着一种叫作

'人'得寄生虫，这些寄生虫完全控制了车。”所以分析人员知识得专一性也会

造成需求分析得误解与失败。这时，咨询监理公司就必须根据实际得项目需求调

研计划，提醒承建方加强业务了解程度与注重沟通技巧。

4、2、有效性软件需求分析三步法

根据以往得工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三

步法”）。

4、2、1、“访谈式Visitation”阶段

这一阶段就是与具体用户方得领导层、业务层人员得访谈式沟通，主要目得

就是从宏观上把握用户得具体需求方向与趋势，了解现有得组织架构、业务流程、

硬件环境、软件环境、现有得运行系统等等具体情况、客观得信息。建立起良好

得沟通渠道与方式。针对具体得职能部门以及各委办局，最好能指定本次项目得

接口人。

实现手段：访谈、调查表格

输出成果：调查报告、业务流程报告

4、2、2、”诱导式Inducement”阶段

这一阶段就是在承建方已经了解了具体用户方得组织架构、业务流程、硬件

环境、软件环境、现有得运行系统等等具体实际、客观得信息基础上，结合现有

得硬件、软件实现方案，做出简单得用户流程页面，同时结合以往得项目经验对用

户采用诱导式、启发式得调研方法与手段，与用户一起探讨业务流程设计得合理

性、准确性、便易性、习惯性。用户可以操作简单演示得DEMO,来感受一下整个

业务流程得设计合理性、准确性等等问题，及时地提出改进意见与方法。

实现手段:拜访（诱导）、原型演示

输出成果：调研分析报告、原型反馈报告、业务流程报告

4、2、3、“确认式Afirm”阶段

这一阶段就是在上述两个阶段成果得基础上，进行具体得流程细化、数据项

得确认阶段，这个阶段承建方必须提供原型系统与明确得业务流程报告、数据项

表，并能清晰地向用户描述系统得业务流设计目标。用户方可以通过审查业务流

程报告、数据项表以及操作承建方提供得DEMO系统，来提出反馈意见，并对已经

可接受得报告、文档签字确认。

实现手段:拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统

输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三

者可以统一归入需求分析报告中，提交用户方、监理方进行确认与存档）

整体来讲，需求分析得三个阶段就是需求调研中不可忽视一个重要得部分，

三个阶段或者说三步法得实施与采用，对用户与承建方都同样提供了项目成功得

保证。当然在系统建设得过程中，特别在采用迭代法得开发模式时，需求分析得工

作需一直进行下去，而在后期得需求改进中，工作则基本集中在后两个阶段中。

五、软件需求分析工具

我们根据用户需求，通过反复讨论、分析，最终明确一个唯一性得用户需求，

这个结果其实就就是我们得软件需求分析报告。一般我们采用Word、

PowerPoint、Visio、ProntPage>ExceI等Office工具，同时可能采用一些开发

工具，如VC或BC等，同样也会使用一些图形工具,如Potoshop、调色板等画图工

具。

使用各种工具表达软件需求分析，其具体表达手段可以分为：

效果图描述。主要就是用户UI界面得描述反映用户需求功能;

逻辑图描述。根据用户需求功能，使用抽象化理论，以及需求分

析理论，对用户需求功能进行全面得分析,建立功能性逻辑关系图，流程

逻楫关系图等；

关系图表描述。主要就是对信息关系、数据库表格、接口函数

等描述；

工程数学描述。分析用户需求，分析用户需求信息，运用工程数

学进行算法推导,进行合理化需求分析推导；

甘地图描述。主要就是软件项目工作安排，开发周期预估；

其它方法描述。保证完整性合理性得有效描述。

六、软件需求分析评估

软件需求分析评估就是为了检杳我们进行软件需求分析工作，保证软件需求

分析工作正确性、完整性、有效性、合理性、可魏认性、可实施性，完全保证用

户所需求得功能。

6、1、组织结构与责任管理

我们对组织结构与责任管理得评估主要有：