软件项目如何进行需求分析

软件项目如何进行需求分析

软件项目如何进行需求分析?我们要围绕两个核心问题开展需求分

析：（1）应该了解什么？（2）通过什么方式去了解？

1 应该了解什么

那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲

一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不

象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细

节的问题，如图4.1所示。

一个软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记

为D）分类，每个问题域对应于一个软件子系统。

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

问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中

的一个软构件。

Di = { P1，P2，P3，… Pm }

问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中

的接口。

Pj = { F1，F2，F3，… Fk }

按图4.1结构写成的需求说明书，对于那些只想了解宏观需求的领

导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意

两个问题：

（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本

质，以便选用最合适的技术来实现此需求。

（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或

前后相矛盾，则要重新分析此需求。

2 通过什么方式去了解

了解需求的方式有好几种：

（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，

就非常容易侃出需求。

（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行

家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。

让你感到“听君一席言，胜读十年书。”

（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼

稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，

看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其

成。

软件工程之需求分析过程介绍

软件需求工程过程(SREP)，本文简要地列举并说明了在整个软件需求

工程的过程中的工作职责要点。

一、 开始

1. 项目经理根据项目特点，指定对过程表格的具体要求；

2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类

型)、TRS(需求类型)等，在过程表格中按标准引用.

二、 计划

1. 计划经理估算需求开发时间；

2. 计划经理完成：SPT(进度计划)、TPT(任务计划)，将计划数据录

入PDS(项目计划摘要).

三、 需求获取

1. 软件需求工程师搜集系统概要信息，填写REQ(需求获取概貌)；

2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA(需

求获取/分析)、RES(需求获取情节)、UIR(用户交互需求)；

3. 检查需求获取过程，并填写REC(需求获取检查)；

4. 如果检查不通过，从1.重头开始过程；

5. 软件需求工程师填写TRL(时间记录日志)、PIP(过程改进建议)；

6. 计划经理整理本阶段数据，录入SPT、TPT.

四、 需求分析

1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目

词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析

和面向对象分析的具体作业指导书）；

2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入

NCR；

3. 检查需求分析，完成RAC(需求分析检查)；

4. 如果检查不通过，从1重头开始过程；

5. 软件需求工程师填写TRL、PIP；

6. 计划经理整理数据，录入TPT、SPT.

五、 协商

1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发

现的问题，将决议录入NCR；

2. 软件需求工程师根据决议，修改REA等相关文档；

3. 如果有新的需求引入，需要重新进行需求分析阶段；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT.

六、 需求评审

1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审

日程表；

2. 评审员各自评审分派的内容，将发现的问题录入DRL(缺陷记录日

志)；

3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论；

4. 评审小组以IRF形式提交检查报表；

5. 软件需求工程师根据IRF修订相关文档；

6. 计划经理整理数据，录入TPT、SPT。

七、 需求文档编写

1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需

求说明书》

《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。

2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行；

3. 如果检查不通过，从1重头开始过程；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT。

八、 需求确认

1. 评审小组，对需求进行确认：

l 确认每一个需求及相互关系；

l 需求的总体质量达到标准。

将结果写到RVC。

2. 软件需求工程师根据RVC，修订需求文档，并最终通过；

3. 软件工程师为每一个需求设计测试用例，并录入TRF；

4. 相关人员填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT。

九、 配置管理

1. RD(需求文档)成为基线后，即纳入到配置管理；

2. 如果需要对基线RD(需求文档)进行修改，填写CCP；

3. 配置管理人员征求需求开发小组和其他相关人员(风险承担者)关

于CCP的意见；

4. 如果所有人员通过CCP，则将需求文档的配置管理取出，并填写

CCF；

如果否决需求，则填写RRF；

5. 软件需求工程师修改RD以适应新的需求 (可能包括REA等)；

软件需求调研中的5W+1H定律

/news/newstopic/22/

2005.06.28 来自：mypm 泓峥萧瑟

对于软件的需求调研活动，虽然曾经写过三篇相关的需

求管理文章，出发角度是从整体的需求管理过程考虑；在引入

CMM（二）需求管理KPA活动的基础上，列举了如何进行需

求调研前的需求管理计划活动；在失败的项目中，找出规范和

管理软件需求过程的关健点及需求关联的模型架构（这些可以

参考以前写过的《CMM 需求管理实践经验记录谈》、《从CMM

角度考虑需求管理计划》、《如何用CRC模型来确定需求》）。

一直以来，感觉自己在经过几个项目试验的基础上对于软件的

需求管理应该是有一定的基础和经验了，然而在最近参与的一

个大型项目过程中，在新加坡项目经理的引导与帮助下，对于

软件需求调研又有了更深一层的体会和认识；总结出需求调研

中的5W+1H定律，在此把自己的一些过程和经验描述出来，

希望能与各同仁一起分享与讨论。

项目背景：

一个中型的企业信息化项目，其中乙方的项目经理是一个拥有

PMP证书的资深项目管理人员。甲方的项目经理是一个有着丰

富项目实施和管理经验的新加坡项目管理人员。（在这里需要

补充的时，在调研产生冲突过程中，外籍人员如何用自己的经

验和技巧，让乙方完全可以接收）

项目成员：

甲方：外包项目经理、外包项目管理人员

乙方：项目经理、系统分析员、界面制作人员

工作内容：

项目需求阶段的活动，对于系统的需求，甲乙双方与最终用户

能达成一致，甲方作为外包管理者，主要是对乙方项目组的项

目进度、项目阶段成果进行跟踪与验收，以保证项目在预期的

时间内完成预期的工作任务。

过程描述：

项目启动后，乙方的项目经理列了一份详细的需求调研时间表、

调研阶段成果目录清单、界面成果等的计划内容，可以用一个

“赞” 字来形容；从计划上看，乙方的项目经理计划真的是完美

无缺；在与用户进行业务需求调研的活动中，乙方不仅记录下

目前用户现有的业务流程，包括目前流程的局限性，流程的执

行性等方面，还为用户进行了将来系统流程的规划，的确是一

个不错的开始。可是在乙方提交其阶段的需求分析文档和界面

时，却发现二者存在了种种的冲突和矛盾，我们无法将需求分

析文档与界面结合在一起。此时，乙方的项目经理解释是因为

文档比界面细，所以二者存在一些理解上的差异。而我们甲方

却总觉得有些不太对劲，但因为同样存在着对用户流程细节的

不熟悉，所以我们也提不出具体的问题，直到有一天，跟着乙

方一起做用户的需求活动后，从乙方项目经理的提问方面，我

们终于明白为什么他们会做出这样的文档和界面。

首先，乙方项目经理对用户的提问是没有序列的，我们所谓的

序列就是项目经理的逻辑是否清晰，除了问及目前的流程外，

最重要的引入项目（即新的软件系统）的目的，所需达到的效

果，可以对用户辅助的东东，而这些乙方的项目经理一字未提

与问，只记录用户所说的过程、局限和要求。这样，乙方项目

经理在分析与规划系统的需求时，就没有一个明确的目的性和

方向性，这里就要引入第一个W定律---WHY定律。WHY就

是为什么用户要引入系统，引入新的信息系统对用户有什么帮

助，在总体工作效能上如何实现一个最终的结果？WHY定律是

要求在需求开始时，项目经理就应该明确的，这个项目是为了

改进用户工作效率；提高部门间的协作机制；加快对客户反应

的体系服务；提升企业的竞争力等等。有了这么一个WHY引

入思想，项目经理就可以理清用户最终要的是可以提供给他们

什么样的系统，在系统的定位和建立上，就有一个明确地最终

目标。

其次，有了一个总体的目标性，从各业务流程的要求入手，引

入第二个W定律---WHAT定律，WHAT则是这个系统要做什

么？实现什么？就是乙方项目经理提出的各业务流程问题、流

程局限性问题、系统要解决的问题等，在这个WHAT的基础上，

把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、

结构需求。引入WHAT定律可以让我们了解到系统的初步需

求。

再次，引入第三、四、五个定律---WHO、WHEN、WHERE定

律，这个阶段其实就是需求细化阶段，在WHAT定律的基础上，

细分系统的用户需求：分析什么人，在什么时间，什么阶段可

以或必须操作这个功能，结合前面的WHAT定律，理清系统的

流程阶段划分，记录并分析系统功能实现的细节，在这个阶段

就可以产生系统需求的用例图（U Ca），作为下阶段设计

的依据。

最后，就是所谓的1H定律---HOW定律，就是怎样实现系统了，

在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，

我们已经搭建了一个非常好的系统需求基础框架，如何在这些

用户需求的基础上，分析系统的需求，如何进行需求规格的分

析与下阶段的设计、实现工作，就是HOW TO ACCOMPLISH

THE SYSTEM了。

在需求阶段引入这5W+1H的定律，在一定程度上保证了系统

需求的准确性，也使得项目经理或需求分析人员可以非常有序

的有条理的开展需求挖掘和调研活动，这样的安排用户在配合

上也非常清晰，知道如何与项目人员配合。其后，在我们的建

议下，乙方改进了工作方式，理清了一些工作序列，不过在最

终文档的提交上，乙方的项目经理为了迎合我们的需求，一直

对需求文档的格式与内容进行修改，没有保持需求分析中应该

有的从粗到细的阶层分析，也导致其需求分析中的不确定性因

素较多，后期的设计工作展开不顺，这些算后话，希望能在以

后的外包管理方面，就存在的这些问题进行其它的分析和讨论。

软件需求说明书

1． 引言

1.1 项目名称

1.2 项目背景和内容概要

（项目的委托单位、开发单位、主管部门、与其它项目的关系，与其

他机构的关系等）

1.3 相关资料、缩略语、定义

（相关项目计划、合同及上级机关批文，引用的文件、采用的标准等）

（缩写词和名词定义）

2. 任务概述

2.1 目标

（项目的开发目标和应用目标。如果是其他系统的一部分，则说明其

关系）

2.2 范围

（包含的业务，不包含的业务）

2.3 假定条件与约束限制

（尽量列出开展本项目的假定和约束，例如：经费限制，开发期限，

设备条件，用户现

场环境准备等）

3．业务流程

4．数据描述

4.1 原始数据描述

a. 静态数据

b. 动态数据

4.2 数据流向图

4.3 数据概念模型和描述

5．功能需求

5.1 功能描述

6．界面要求

6．1报表格式

6．2图形要求

6．3输入输出要求

7．接口要求

(描述与本系统相连的系统的接口的数据格式，数据交换协议，接口

功能等)

8．性能需求

8．1数据精确度

（例如，数据内部精度，外部显示精度）

8． 2数据量

8． 3时间特性要求

（根据所开发系统的特点，规定系统对时间的特性的要求。例如：

系统响应时间、界面更新处理时间、数据转换与传输时间）

9． 运行环境需求

9．1网络和硬件设备平台

（网络拓扑图及设备类型描述）

操作系统平台

数据库系统平台

10.1编程工具

10.2其它支撑软件

11． 其它专门需求

11.1安装和操作

11.2安全保密

11.3维护服务

ITSM项目需求分析的四个关键步骤

CA公司技术经理 侯继涛

ITSM（IT服务管理）由于切中如何整合信息科技投入与业务需求整

合这一顽疾，在国内正在拥有着越来越多的用户，其理念在这些用户

心目中越来越深入人心。但与此相对应的是，大部分用户对于如何定

位该

类项目，如何进行恰当的项目分析工作，确保项目收益等，存在着

很多疑问：

如何建立ITIL概念与企业ITSM项目的对应？

需要推行什么样的管理制度，与ITIL化的流程相对应？

如何建立一个自动化的ITSM工具平台？需要外购还是自己开发？

如何选择工具？

如何定义清楚我的业务需求和工具平台需求？

这些疑问的存在是非常正常的，也只有在项目需求分析阶段更好地解

决这些问题，才能正确的设定企业ITSM项目目标，更好地制定项目

规划，从而确保项目的成功。

1、ITSM需求分析第一步，确定流程实施的优先顺序

ITSM项目，需要重点参考ITIL所定义的十个流程和一个功能点，这

些流程整合在一起，可以帮助企业更好地管理IT服务。但是，推广

任何一个流程都需要一定的代价和时间，这些流程也不一定符合每个

企业的文化，因此，第一个要解决的问题是，从哪个或那几个流程开

始呢？

根据CA公司近几年的实践经验，企业可从如下几个方面来确定流程

实施的优先顺序：

流程成熟度－相对企业的需求，哪个或哪几个流程是最迫切需要改进

的？

投资回报率－根据目前的需求和企业的文化，哪个或哪几个流程可以

取得较大的投资回报？

痛苦点－IT部门内部的最大困扰是什么？哪个或哪几个流程可以帮

助改进它们？

组织架构－是否存在传统的井架式组织架构？这种组织架构可以通

过哪些流程进行改善？

部门划分－目前的IT部门划分是否合理？需要根据哪些流程进行改

进吗？

资源和预算－目前IT部门拥有哪些资源和预算？能支撑哪些流程的

改进？

目前国内企业在实施ITSM项目时，大多从见效快、实施较容易的事

件管理和变更管理，这也符合国际上的普遍规律。但每个企业还是要

从自身出发，更好的审视企业的需求点。

2、ITSM需求分析第二步，确定流程定义的需求

流程定义需求分析，主要从两个方面来考虑。

一方面，是确定流程定义的六要素。

确定了实施哪些流程以后，就需要进一步关注这些流程的设计和实现

了。作为一个管理项目，流程的重组、优化是最重要的成果，所以要

更好地定义流程的描述和要求。ITIL中所定义的流程有六个要素，需

要在初步定义流程的输入、输出的基础上，确定每个流程节点的六要

素。这些，都将是以后产品实施和制度定义的基础。

另一方面，是根据管理报表的需求来进行适当的流程调整。流程的最

终目标是根据服务水平协议在合适的时间，提交符合质量要求的服

务，流程的定义首先要满足该目标。但是，在某些情况下，要根据监

控和管理的需要，增加一些流程节点。这些流程节点的存在，主要是

为了取得某些管理数据。例如，如果我们希望得到一个故障类型统计

的报表，就需要增加一个流程节点，这个节点，就是指定特定的管理

人员，在关闭事件单时，重新定义事件类别。该节点的定义，可能不

是为了一个票单的快速解决，而主要是为了满足管理的需要。

3、ITSM需求分析第三步，确定对工具平台的需求

流程的优化、重组往往需要部署和实施一些ITSM工具平台作为支撑。

这些工具平台，应该完成什么样的技术需求呢？这些技术需求对工具

的要求如何来分析呢？技术需求主要来自于两个方面：一方面是需要

考虑面向流程的需求，需要分析哪些流程节点采用工具进行自动化，

哪些节点需要利用制度来保障实现；另一方面，需要考虑面向管理信

息的需求，即需要系统产生何种管理信息，采用何种展现方式等等。

一般意义来讲，这些技术需求在工具平台的实现，需要这些工具平台

支持如下配置、定制能力：

配置－工具需提供具有友好界面的定义、配置能力

工作流－实现人与人之间的自动化

触发器、通知、报告等－实现系统与人的自动化

数据交换－实现不同系统之间的自动化

输入界面－实现人与系统的自动化

4、ITSM需求分析第四步，确定管理制度的制定和推广计划

作为典型的管理项目，工具的推广和实施，必然伴随着管理制度的制

定和推广，这些管理制度将进一步细化管理流程，明确管理岗位和职

责。这些是项目成功的重要前提。一般来说，管理制度将明确如下内

容：

角色和职责－确定不同岗位的角色和职责

技能要求－对不同岗位有哪些方面的具体技能要求

培训要求－需要提供培训吗？

管理方式－采用何种管理方式。

沟通方式－采用何种沟通方式。

通过如上四个步骤，企业可以初步勾勒出ITSM项目的框架，进一步

归纳出“软”、“硬”两方面的需求，可以说，ITSM项目已经成功了一大

半。

软件外包流程

一个完整的软件外包项目流程包括：需求分析、总体设计、

详细设计、开发编程、测试分析、系统整合及现场支持。

1.需求分析：建立合作意向后，我们首先会对客户要求有详尽的

了解，准确知道客户需求、客户的商业模式和业务流程，并结合

自身的经验，为客户提出改进建议。

2.总体设计：在需求确定并获得客户认可后，由系统设计师进行

系统架构设计，并与客户一起制定项目实施计划。

3.详细设计：由程序设计人员根据系统架构，真对不同模块的功

能和规格进行详细设计。

4.开发编程：由程序员根据详细设计及计划，进行软件程序代码

的编写。

5.测试分析与系统整合：不同模块的编程工作完成后，经过测试，

并进行系统的整合。

6.现场支持：软件系统开发最终完成后，到客户现场进行安装、

调试、培训。

7.系统运行支持：在系统投入运行后，我们可以为客户进行长期

系统的维护，除了保证系统的正常运行外，还要根据客户的业务

变化以及使用过程中发现的问题，对系统进行修改。