1、软件项目如何进行需求分析软件项目如何进行需求分析?我们要围绕两个核心问题开展需求分析：（1）应该了解什么？（2）通过什么方式去了解？ 1 应该了解什么那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲 A、B、C 、D 、E 。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题，如图 4.1 所示。一个软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为 D）分类，每个问题域对应于一个软件子系统。S = D1，D2，D3 ， Dn 问题域 Di 由若干个问题（记为 P）组成，每个问题对应于子系统中的一个软构件。Di
2、 = P1，P2，P3， Pm 问题 Pj 有若干个行为（或功能，记为 F），每个行为对应于软构件中的接口。Pj = F1， F2，F3， Fk 按图 4.1 结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。2 通过什么方式去了解了解需求的方式有好几种：（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求
3、。（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。软件工程之需求分析过程介绍软件需求工程过程(SREP)，本文简要地列举并说明了在整个软件需求工程的过程中的工作职责要点。一、 开始 1. 项目经理根据项目特点，指定对过程表格的具体要求； 2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类
4、型)、TRS(需求类型)等，在过程表格中按标准引用. 二、 计划1. 计划经理估算需求开发时间； 2. 计划经理完成：SPT(进度计划) 、TPT(任务计划) ，将计划数据录入 PDS(项目计划摘要). 三、 需求获取 1. 软件需求工程师搜集系统概要信息，填写 REQ(需求获取概貌)； 2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA(需求获取/分析) 、RES(需求获取情节)、UIR(用户交互需求)； 3. 检查需求获取过程，并填写 REC(需求获取检查)； 4. 如果检查不通过，从 1.重头开始过程； 5. 软件需求工程师填写 TRL(时间记录日志)、PIP( 过程改进建议
5、)； 6. 计划经理整理本阶段数据，录入 SPT、TPT. 四、 需求分析1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成 REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）； 2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR； 3. 检查需求分析，完成 RAC(需求分析检查 )； 4. 如果检查不通过，从 1 重头开始过程； 5. 软件需求工程师填写 TRL、PIP ； 6. 计划经理整理数据，录入 TPT、SPT. 五、 协商1. 软件需求工程师利用 NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入 N
6、CR； 2. 软件需求工程师根据决议，修改 REA 等相关文档； 3. 如果有新的需求引入，需要重新进行需求分析阶段； 4. 软件需求工程师填写 TRL、PIP ； 5. 计划经理整理数据，录入 TPT、SPT. 六、 需求评审1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表； 2. 评审员各自评审分派的内容，将发现的问题录入 DRL(缺陷记录日志)； 3. 评审小组负责人组织评审会议，各小组成员提交 DRL 并讨论； 4. 评审小组以 IRF 形式提交检查报表； 5. 软件需求工程师根据 IRF 修订相关文档； 6. 计划经理整理数据，录入 TPT、SPT。 七、 需求文
7、档编写1. 软件需求工程师综合考虑功能需求和非功能需求，编写软件需求说明书 软件需求说明书的编写格式与要求，请参见具体的作业指导书。2. 利用 RDC 检查软件需求说明书是否全面、正确并可执行； 3. 如果检查不通过，从 1 重头开始过程； 4. 软件需求工程师填写 TRL、PIP ； 5. 计划经理整理数据，录入 TPT、SPT。 八、 需求确认1. 评审小组，对需求进行确认： l 确认每一个需求及相互关系； l 需求的总体质量达到标准。 将结果写到 RVC。 2. 软件需求工程师根据 RVC，修订需求文档，并最终通过； 3. 软件工程师为每一个需求设计测试用例，并录入 TRF； 4. 相关
8、人员填写 TRL、PIP ； 5. 计划经理整理数据，录入 TPT、SPT。 九、 配置管理1. RD(需求文档 )成为基线后，即纳入到配置管理； 2. 如果需要对基线 RD(需求文档) 进行修改，填写 CCP； 3. 配置管理人员征求需求开发小组和其他相关人员(风险承担者) 关于 CCP 的意见； 4. 如果所有人员通过 CCP，则将需求文档的配置管理取出，并填写CCF； 如果否决需求，则填写 RRF； 5. 软件需求工程师修改 RD 以适应新的需求 (可能包括 REA 等)；软件需求调研中的 5W+1H 定律 http:/ 来自：mypm 泓峥萧瑟 对于软件的需求调研活动，虽然曾经写过三篇
9、相关的需求管理文章，出发角度是从整体的需求管理过程考虑；在引入CMM（二）需求管理 KPA 活动的基础上，列举了如何进行需求调研前的需求管理计划活动；在失败的项目中，找出规范和管理软件需求过程的关健点及需求关联的模型架构（这些可以参考以前写过的CMM 需求管理实践经验记录谈、从CMM 角度考虑需求管理计划、如何用 CRC 模型来确定需求）。一直以来，感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了，然而在最近参与的一个大型项目过程中，在新加坡项目经理的引导与帮助下，对于软件需求调研又有了更深一层的体会和认识；总结出需求调研中的 5W+1H 定律，在此把自己的一些过
10、程和经验描述出来，希望能与各同仁一起分享与讨论。项目背景：一个中型的企业信息化项目，其中乙方的项目经理是一个拥有PMP 证书的资深项目管理人员。甲方的项目经理是一个有着丰富项目实施和管理经验的新加坡项目管理人员。（在这里需要补充的时，在调研产生冲突过程中，外籍人员如何用自己的经验和技巧，让乙方完全可以接收）项目成员：甲方：外包项目经理、外包项目管理人员乙方：项目经理、系统分析员、界面制作人员工作内容：项目需求阶段的活动，对于系统的需求，甲乙双方与最终用户能达成一致，甲方作为外包管理者，主要是对乙方项目组的项目进度、项目阶段成果进行跟踪与验收，以保证项目在预期的时间内完成预期的工作任务。过程描述
11、：项目启动后，乙方的项目经理列了一份详细的需求调研时间表、调研阶段成果目录清单、界面成果等的计划内容，可以用一个 “赞” 字来形容；从计划上看，乙方的项目经理计划真的是完美无缺；在与用户进行业务需求调研的活动中，乙方不仅记录下目前用户现有的业务流程，包括目前流程的局限性，流程的执行性等方面，还为用户进行了将来系统流程的规划，的确是一个不错的开始。可是在乙方提交其阶段的需求分析文档和界面时，却发现二者存在了种种的冲突和矛盾，我们无法将需求分析文档与界面结合在一起。此时，乙方的项目经理解释是因为文档比界面细，所以二者存在一些理解上的差异。而我们甲方却总觉得有些不太对劲，但因为同样存在着对用户流程细
12、节的不熟悉，所以我们也提不出具体的问题，直到有一天，跟着乙方一起做用户的需求活动后，从乙方项目经理的提问方面，我们终于明白为什么他们会做出这样的文档和界面。首先，乙方项目经理对用户的提问是没有序列的，我们所谓的序列就是项目经理的逻辑是否清晰，除了问及目前的流程外，最重要的引入项目（即新的软件系统）的目的，所需达到的效果，可以对用户辅助的东东，而这些乙方的项目经理一字未提与问，只记录用户所说的过程、局限和要求。这样，乙方项目经理在分析与规划系统的需求时，就没有一个明确的目的性和方向性，这里就要引入第一个 W 定律-WHY 定律。WHY 就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，
13、在总体工作效能上如何实现一个最终的结果？WHY 定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个 WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确地最终目标。其次，有了一个总体的目标性，从各业务流程的要求入手，引入第二个 W 定律-WHAT 定律，WHAT 则是这个系统要做什么？实现什么？就是乙方项目经理提出的各业务流程问题、流程局限性问题、系统要解决的问题等，在这个 WHAT 的基础上，把系统划分成各功能模块，逐步弄清模
14、块流程需求、功能需求、结构需求。引入 WHAT 定律可以让我们了解到系统的初步需求。再次，引入第三、四、五个定律-WHO、WHEN 、WHERE定律，这个阶段其实就是需求细化阶段，在 WHAT 定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的 WHAT 定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。最后，就是所谓的 1H 定律-HOW 定律，就是怎样实现系统了，在前面的 WHY、WHAT、WHO 、WHEN、WHERE 基础上，我们已经搭建了一个非常
15、好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是 HOW TO ACCOMPLISH THE SYSTEM 了。在需求阶段引入这 5W+1H 的定律，在一定程度上保证了系统需求的准确性，也使得项目经理或需求分析人员可以非常有序的有条理的开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。其后，在我们的建议下，乙方改进了工作方式，理清了一些工作序列，不过在最终文档的提交上，乙方的项目经理为了迎合我们的需求，一直对需求文档的格式与内容进行修改，没有保持需求分析中应该有的从粗到细的阶层分析，也导致其需
16、求分析中的不确定性因素较多，后期的设计工作展开不顺，这些算后话，希望能在以后的外包管理方面，就存在的这些问题进行其它的分析和讨论。软件需求说明书 1 引言 1.1 项目名称 1.2 项目背景和内容概要 （项目的委托单位、开发单位、主管部门、与其它项目的关系，与其他机构的关系等） 1.3 相关资料、缩略语、定义 （相关项目计划、合同及上级机关批文，引用的文件、采用的标准等） （缩写词和名词定义） 2. 任务概述 2.1 目标 （项目的开发目标和应用目标。如果是其他系统的一部分，则说明其关系） 2.2 范围 （包含的业务，不包含的业务） 2.3 假定条件与约束限制 （尽量列出开展本项目的假定和约束
17、，例如：经费限制，开发期限，设备条件，用户现 场环境准备等） 3业务流程 4数据描述 4.1 原始数据描述 a. 静态数据 b. 动态数据 4.2 数据流向图 4.3 数据概念模型和描述 5功能需求 5.1 功能描述 6界面要求 61 报表格式 62 图形要求 63 输入输出要求 7接口要求 (描述与本系统相连的系统的接口的数据格式，数据交换协议，接口功能等) 8性能需求 81 数据精确度 （例如，数据内部精度，外部显示精度） 8 2 数据量 8 3 时间特性要求 （根据所开发系统的特点，规定系统对时间的特性的要求。例如： 系统响应时间、界面更新处理时间、数据转换与传输时间） 9 运行环境需求
18、 91 网络和硬件设备平台 （网络拓扑图及设备类型描述） 操作系统平台 数据库系统平台 10.1 编程工具 10.2 其它支撑软件 11 其它专门需求 11.1 安装和操作 11.2 安全保密 11.3 维护服务 ITSM 项目需求分析的四个关键步骤CA 公司技术经理 侯继涛 ITSM（IT 服务管理）由于切中如何整合信息科技投入与业务需求整合这一顽疾，在国内正在拥有着越来越多的用户，其理念在这些用户心目中越来越深入人心。但与此相对应的是，大部分用户对于如何定位该 类项目，如何进行恰当的项目分析工作，确保项目收益等，存在着很多疑问：如何建立 ITIL 概念与企业 ITSM 项目的对应？需要推行
19、什么样的管理制度，与 ITIL 化的流程相对应？如何建立一个自动化的 ITSM 工具平台？需要外购还是自己开发？如何选择工具？如何定义清楚我的业务需求和工具平台需求？这些疑问的存在是非常正常的，也只有在项目需求分析阶段更好地解决这些问题，才能正确的设定企业 ITSM 项目目标，更好地制定项目规划，从而确保项目的成功。1、ITSM 需求分析第一步，确定流程实施的优先顺序ITSM 项目，需要重点参考 ITIL 所定义的十个流程和一个功能点，这些流程整合在一起，可以帮助企业更好地管理 IT 服务。但是，推广任何一个流程都需要一定的代价和时间，这些流程也不一定符合每个企业的文化，因此，第一个要解决的问
20、题是，从哪个或那几个流程开始呢？根据 CA 公司近几年的实践经验，企业可从如下几个方面来确定流程实施的优先顺序：流程成熟度相对企业的需求，哪个或哪几个流程是最迫切需要改进的？投资回报率根据目前的需求和企业的文化，哪个或哪几个流程可以取得较大的投资回报？痛苦点IT 部门内部的最大困扰是什么？哪个或哪几个流程可以帮助改进它们？组织架构是否存在传统的井架式组织架构？这种组织架构可以通过哪些流程进行改善？部门划分目前的 IT 部门划分是否合理？需要根据哪些流程进行改进吗？资源和预算目前 IT 部门拥有哪些资源和预算？能支撑哪些流程的改进？目前国内企业在实施 ITSM 项目时，大多从见效快、实施较容易的
21、事件管理和变更管理，这也符合国际上的普遍规律。但每个企业还是要从自身出发，更好的审视企业的需求点。2、ITSM 需求分析第二步，确定流程定义的需求流程定义需求分析，主要从两个方面来考虑。一方面，是确定流程定义的六要素。确定了实施哪些流程以后，就需要进一步关注这些流程的设计和实现了。作为一个管理项目，流程的重组、优化是最重要的成果，所以要更好地定义流程的描述和要求。ITIL 中所定义的流程有六个要素，需要在初步定义流程的输入、输出的基础上，确定每个流程节点的六要素。这些，都将是以后产品实施和制度定义的基础。另一方面，是根据管理报表的需求来进行适当的流程调整。流程的最终目标是根据服务水平协议在合适
22、的时间，提交符合质量要求的服务，流程的定义首先要满足该目标。但是，在某些情况下，要根据监控和管理的需要，增加一些流程节点。这些流程节点的存在，主要是为了取得某些管理数据。例如，如果我们希望得到一个故障类型统计的报表，就需要增加一个流程节点，这个节点，就是指定特定的管理人员，在关闭事件单时，重新定义事件类别。该节点的定义，可能不是为了一个票单的快速解决，而主要是为了满足管理的需要。3、ITSM 需求分析第三步，确定对工具平台的需求流程的优化、重组往往需要部署和实施一些 ITSM 工具平台作为支撑。这些工具平台，应该完成什么样的技术需求呢？这些技术需求对工具的要求如何来分析呢？技术需求主要来自于两
23、个方面：一方面是需要考虑面向流程的需求，需要分析哪些流程节点采用工具进行自动化，哪些节点需要利用制度来保障实现；另一方面，需要考虑面向管理信息的需求，即需要系统产生何种管理信息，采用何种展现方式等等。一般意义来讲，这些技术需求在工具平台的实现，需要这些工具平台支持如下配置、定制能力：配置工具需提供具有友好界面的定义、配置能力工作流实现人与人之间的自动化触发器、通知、报告等实现系统与人的自动化数据交换实现不同系统之间的自动化输入界面实现人与系统的自动化4、ITSM 需求分析第四步，确定管理制度的制定和推广计划作为典型的管理项目，工具的推广和实施，必然伴随着管理制度的制定和推广，这些管理制度将进一
24、步细化管理流程，明确管理岗位和职责。这些是项目成功的重要前提。一般来说，管理制度将明确如下内容：角色和职责确定不同岗位的角色和职责技能要求对不同岗位有哪些方面的具体技能要求培训要求需要提供培训吗？管理方式采用何种管理方式。沟通方式采用何种沟通方式。通过如上四个步骤，企业可以初步勾勒出 ITSM 项目的框架，进一步归纳出“软” 、“硬”两方面的需求，可以说，ITSM 项目已经成功了一大半。软件外包流程一个完整的软件外包项目流程包括：需求分析、总体设计、详细设计、开发编程、测试分析、系统整合及现场支持。1.需求分析：建立合作意向后，我们首先会对客户要求有详尽的了解，准确知道客户需求、客户的商业模式
25、和业务流程，并结合自身的经验，为客户提出改进建议。2.总体设计：在需求确定并获得客户认可后，由系统设计师进行系统架构设计，并与客户一起制定项目实施计划。3.详细设计：由程序设计人员根据系统架构，真对不同模块的功能和规格进行详细设计。4.开发编程：由程序员根据详细设计及计划，进行软件程序代码的编写。5.测试分析与系统整合：不同模块的编程工作完成后，经过测试，并进行系统的整合。6.现场支持：软件系统开发最终完成后，到客户现场进行安装、调试、培训。7.系统运行支持：在系统投入运行后，我们可以为客户进行长期系统的维护，除了保证系统的正常运行外，还要根据客户的业务变化以及使用过程中发现的问题，对系统进行修改。
