《软件项目如何进行需求分析》由会员分享，可在线阅读，更多相关《软件项目如何进行需求分析（28页珍藏版）》请在金锄头文库上搜索。
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 假定条件与约束限制 （尽量列出开展本项目的假定和约束，例如：经费限制，开发期限，设备条件，用户现 场环境准备
