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

软件项目如何进行需求分析软件项目如何进行需求分析?我们要围绕两个核心问题开展需求分析：（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定律来自：mypm泓峥萧瑟对于软件的需求调研活动，虽然曾经写过三篇相关的需求管理文章，出发角度是从整体的需求管理过程考虑；在引入CMM（二）需求管理KPA活动的基础上，列举了如何进行需求调研前的需求管理计划活动；在失败的项目中，找出规范和管理软件需求过程的关健点及需求关联的模型架构（这些可以参考以前写过的《CMM需求管理实践经验记录谈》、《从CMM角度考虑需求管理计划》、《如何用CRC模型来确定需求》）。一直以来，感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了，然而在最近参与的一个大型项目过程中，在新加坡项目经理的引导与帮助下，对于软件需求调研又有了更深一层的体会和认识；总结出需求调研中的5W+1H定律，在此把自己的一些过程和经验描述出来，希望能与各同仁一起分享与讨论。项目背景：一个中型的企业信息化项目，其中乙方的项目经理是一个拥有PMP证书的资深项目管理人员。甲方的项目经理是一个有着丰富项目实施和管理经验的新加坡项目管理人员。（在这里需要补充的时，在调研产生冲突过程中，外籍人员如何用自己的经验和技巧，让乙方完全可以接收）项目成员：甲方：外包项目经理、外包项目管理人员乙方：项目经理、系统分析员、界面制作人员工作内容：项目需求阶段的活动，对于系统的需求，甲乙双方与最终用户能达成一致，甲方作为外包管理者，主要是对乙方项目组的项目进度、项目阶段成果进行跟踪与验收，以保证项目在预期的时间内完成预期的工作任务。过程描述：项目启动后，乙方的项目经理列了一份详细的需求调研时间表、调研阶段成果目录清单、界面成果等的计划内容，可以用一个“赞”字来形容；从计划上看，乙方的项目经理计划真的是完美无缺；在与用户进行业务需求调研的活动中，乙方不仅记录下目前用户现有的业务流程，包括目前流程的局限性，流程的执行性等方面，还为用户进行了将来系统流程的规划，的确是一个不错的开始。可是在乙方提交其阶段的需求分析文档和界面时，却发现二者存在了种种的冲突和矛盾，我们无法将需求分析文档与界面结合在一起。此时，乙方的项目经理解释是因为文档比界面细，所以二者存在一些理解上的差异。而我们甲方却总觉得有些不太对劲，但因为同样存在着对用户流程细节的不熟悉，所以我们也提不出具体的问题，直到有一天，跟着乙方一起做用户的需求活动后，从乙方项目经理的提问方面，我们终于明白为什么他们会做出这样的文档和界面。首先，乙方项目经理对用户的提问是没有序列的，我们所谓的序列就是项目经理的逻辑是否清晰，除了问及目前的流程外，最重要的引入项目（即新的软件系统）的目的，所需达到的效果，可以对用户辅助的东东，而这些乙方的项目经理一字未提与问，只记录用户所说的过程、局限和要求。这样，乙方项目经理在分析与规划系统的需求时，就没有一个明确的目的性和方向性，这里就要引入第一个W定律---WHY定律。WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确地最终目标。其次，有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律---WHAT定律，WHAT则是这个系统要做什么？实现什么？就是乙方项目经理提出的各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。再次，引入第三、四、五个定律---WHO、WHEN、WHERE定律，这个阶段其实就是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（UseCase），作为下阶段设计的依据。最后，就是所谓的1H定律---HOW定律，就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，我们已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是HOWTOACCOMPLISHTHESYSTEM了。在需求阶段引入这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项目需求分析的四个关键步骤