2022年需求管理规范 .pdf

《2022年需求管理规范 .pdf》由会员分享，可在线阅读，更多相关《2022年需求管理规范 .pdf（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1需求管理体系改进方法研究计算机软件对于信息技术的发展越来越显出它的重要性。而软件质量又越来越影响它的广泛应用和迅速发展。如何去改进软件过程成为一个急待解决的问题。无疑软件过程又是一个极为复杂的过程。 如果用一棵树来比喻企业的核心竞争力，那么企业的研发能力就是树根，企业的核心产品平台是树干，树叶是各个产品线上的产品。不难看出， 虽然决定企业收益的是其推向市场的各产品线上的产品，但是使一个企业永葆竞争优势的动力源泉是支撑其产品开发的企业研发能力的建设，即持续地将具有竞争力的产品源源不断地推向市场的能力。研发能力笼统地讲就是快速开发满足用户需求及市场需要的新产品的能力，以及用较低成本开发高档次、高

2、质量的新产品能力，以及实现新产品的产品化、商品化的能力。所以，我们能否通过产品开发赢得市场竞争的胜利，关键在于我们研发能力的建设。企业的研发能力是通过高效的研发过程改进体系来保障的，如一支实力雄厚的研发队伍、一个深厚的技术平台和一个卓越的产品开发管理流程。其中，保持产品优势的唯一可持续源泉是卓越的产品开发管理流程，能使企业始终能够发现最佳的产品机遇，高效地开发出具有竞争力的产品，并且以很快的速度将新产品投入市场。产品开发是二十一世纪企业竞争的主战场。如果企业忽视了研发过程改进体系的建设，使得我们在新产品上市速度、产品质量、 研发成本、 技术及模块重用等方面逐渐与业界最佳实践拉开了距离，就会直接

3、影响公司健康、持续的发展。所以，我们得出， 仅仅重视研发仍然是不够的，还需要着力进行高效的研发过程改进体系的建设， 同时将技术成果导向的研发文化转变为市场导向、利润导向的研发文化。企业是趋利的社会单位，卖得出去、带来利润的产品才算成功的产品。在项目管理中，需求的重要性是众所周知的，在IT 业界的研究是：高达60% 缺陷来源于需求不清晰， 超过 80% 的项目维护成本用于需求问题处理，需求管理影响了整个项目成败，而关键项目成败则影响了公司的生存。在需求管理中常遇到三种情况：(1) 需求定义清晰，没有异议性：对于这种情况处理，我们一般要根据项目规模的大小进行同行专家评审，根据成本/ 效益之比，可以

4、采用walkthouth或 Inspection的方式来确定项目需求说明书；对于需求的跟踪，可以根据实际情况，采用需求跟踪矩阵，主要目的是跟踪相对应的Function需求在设计、编码、测试阶段是否有遗漏，其实并不是必须的，如果项目规模很名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 7 页 - - - - - - - - - 2小，或者可裁剪掉或者可以采用其他替代方式。(2) 项目需求有部分不明确：我们一般都会采取分期实施的办法，先进行需求明确的一期的需求合同的开发，如有

5、重大变更， 征得客户同意后列入下期开发，这样相对容易规避风险，否则项目永远没有完结的时候，质量也难以保证。(3) 项目需求基本上都是未知的：这种项目风险最大，如果采用闭门造车，可能采用了很好的技术，结果却找不到市场，造成投资血本无归。一般而言，我们都采用原型Demo的方法，让典型的客户去参与原型的评审，不断确认需求，形成需求基线。相信这种方法能有效缓解风险。对于项目需求控制，一般都是采取与客户协商的方式进行：“客户就是上帝” ，是的，但并不表示客户的所有需求都要马上得到满足，一些公司，规模都很大，所做的项目都是全省推行的，一般人都会想，项目利润是很大的。但是询问起来，都是有苦难言，都说公司没有

6、真正赚到钱。后来一分析情况，发现项目估算时，软硬件原来都是有较大利润的，但最后都倒贴到后期的维护成本。根本原因公司为了争取客户，对于每个大客户的需求都无条件满足，定制化版本， 每个地级市都有一个版本，可想而知，整个省就有二、三十个版本。前期开发是工作量不算太大，在原始版本上修修改改，多加点功能，当时客户满意度都很好，但一旦所有地方版本都上线了，麻烦就来了。 单一个产品就要维护如此之多版本，维护成本可想而知，公司还要不要生存?公司发展就会因此而被拖累，甚至被市场淘汰。针对这种情况，一般而言，都是采取与财政拨款的上级单位一起控制需求，统一版本。业内有些公司的做法是很好的，对于全省的项目， 取得省相

7、关部门的支持，和省公司一起共同分级规范全省需求提出( 如根据重要性、紧急性分为ABCD 类需求，每类需求成本是多少，一清二楚，而且也有计划) ，能有效地避免版本的频繁变更，保证了项目质量，也大大地提升了客户满意度。如何测试需求呢?一是对软件需求正确性的检查，也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时，不要迷信所谓的“都是用户提出的真实的需求”，因为我们必须考虑，提出这些需求的涉众，是否真的可以正确的描述自己的需求?我们的需求人员是否真的可以正确的理解用户的需求?有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来?有没有一些被用户认为他们过去

8、使用的软件名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 7 页 - - - - - - - - - 3已经提供了相应的功能，所以认为我们也应当提供，而没有提出来的?关于这个问题，也曾经有朋友提过不同的看法，认为这样对测试人员的要求太高了既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但作为测试人员， 还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。二是

9、要保证软件需求的可测试性。对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。 说的具体一点， 就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证， 或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充我们有理由相信，如果作为测试人员对需求无法产生准确的理解， 那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性， 是在不规范的开发过程中导致返

10、工的一个主要原因。如果认为有必要， 那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。现在当前的测试工作范围已经确定，相应版本的软件需求也通过了评审，我们就可以在这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西，通常会有软件需求规约 ( 以下简称SRS)和用例 ( 以下简称 UC)当然，也可能是一份包含UC的 SRS 。通过对 SRS和 UC的阅读，我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么，多个业务之间的先后顺序是怎样的，用户在处理业务是对于哪些地方有特别的要求，等等。这部分规则，将成为我们的测

11、试需求中最基本的一部分。至于测试需求的表现形式，可以根据自己的需要进行设计，而没有必要把思路限制在到底使用表格方式还是使用文本方式，只要把握一个原则就行了：在一条测试需求中， 用容易理解的自然语言，明确的描述一项需要测试的内容。对于多项测试内容，应尽可能的剥离开来，保证一条测试需求只包含一项测试内容。组织级在技术平台和开发模式不统一的情况下，在过程定义上一定要避免一刀切的标准软件开发过程。 需要根据项目本身的特点和人员情况在满足项目目标的情况下进行适当的裁剪。软件是人开发出来的，过程重要但是人更加重要，两者必须要考虑结合起来，任何强调和夸大一方面的都不合适。对于小型敏捷团队我们更加强调人的重要

12、性，对于大型软件项目可能更加强调规范和过程的重要性，这必须要结合项目特点和实际情况。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 7 页 - - - - - - - - - 4CMMI提供了对多次迭代和快速原型的支持，但是实际上很多的PA ，很多的评估师给出的建议仍然是基于瀑布模型的。而在实际的软件开发中，特别是交付周期只有2-3 个月或更短的项目，很难基于瀑布模型进行开发。全部遵循了CMMI的过程规范和要求， 项目是否就一定能够成功?在这里答案仍然是不一定，关键的问题

13、还是CMMI基于了太多的假设，比如组织能够提供技能合格的人员，需求基本上都能够保证是稳定的，而这些假设往往本身就无法满足。CMMI给我们一个基于很多假设的理想模型， 而实际情况就是如果这些假设都能够很好的满足的话，可能你并不需要CMMI也可以很好保证项目成功。CMMI强调证据，数据，过程和文档。CMMI告诉你需要做什么，你需要有证据来说明你确实做了， 因此准备数据和文档过程是一个要耗费很大成本的过程，在前期我们本身还不成熟的时候更关心的是一项工作投入成本做了以后带来的实际效益即投入产出比。比如需求追踪会被我们经常认为是性价比不高的工作。一个成熟的敏捷团队( 例如 ThoughtWorks) 自

14、然就具备CMM5 级的成熟度， 因为我们在面对项目时解决问题的过程是清晰的、可重复的、可度量的、可管理的、自我优化的。如果在软件过程改进中没有达到这些目标，就没有达到真正的改进效果。文档不能完全代替沟通，但是不能够否认文档和代码的重要性。当我们注重开发过程的管理和规范的时候，软件项目和团队会走向成熟，而过程成熟的一个好处就是整个项目和团队不会完全依赖一两个牛人。项目在不断执行过程中的先进经验和教训能够真正的固化到过程中，形成组织和项目重要的资产。CMMI每个 PA需要做的事情， CMMI不会告诉你怎么去做，但是你必须要首先搞清楚的是为什么要做这件事情，其意义何在?我们在进行软件过程改进的过程中

15、必须是目标和问题驱动的，这样才能够有批判的主动去改进。在中小型的软件企业当中，软件过程的改进更容易半途而废。中小企业， 特别是开发人员小于 40 个人的企业。 一般不会有专门的人员可以组建软件过程组 ，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。 这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的， 而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一

16、方面希望， 可以通过过程名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 7 页 - - - - - - - - - 5改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。持续的改进很重要，但频繁的改进会不利于过程的执行CMM 中定义了每个

17、KPA的目标和一系列的KP ，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。 但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的最佳实践。一般的情况是， 首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再在其他项目或整个企业中推广，也许在推广的过程中，又遇到问题， 再对流程进行修改。 整个的过程定义是螺旋上升的进行。这本身没有问题，但有时当遇到问题时，不要太急于就改流程，或加流程的分支。而要仔细分析后，慎重的进行。太频繁的改动，给人一种不严肃的影响，似乎流程可以随意的改动和定义。最后，没人去遵守流程了。同时，根据不同的项目若定义

18、了太多了流程分支，最后，实际人员也不知道要去实行哪一套了。总之，频繁改动的规矩， 让人无所适从。 过程制定后，一定要有选择的进行试点。一个进度和成本宽余的项目和一群对过程改进有热情的人是保证试点成功的组合。定义好一套流程，最好的验证方式就是找个真实的项目去跑一遍。并注意收集应用流程前后的各种情况的对比。由于在项目的进行中，还要试验流程， 所以需要更多的培训时间，让项目组的成员了解熟悉新的流程。需要更多的评审， 不但是评审项目本身，还要评审过程和进行必要的度量。一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程，要有热情去沟通在执行新流程当中遇到的问题，他们要有热情去克服进

19、行中的困难，而不是抱怨，他们要有热情去总结和改进新的流程，使它更完善，最总要的是， 他们要有热情作为新流程的传播者， 把流程象星星之火一样在组织中开展。一个坚决支持过程改进的领导是必不可少的。象任何其他的变革一样，一个坚决支持变革的领导是不可缺少的。在一切顺利，大家赞成的时候， 也许感觉不到什么。但当变革遇到阻力，遭受暂时的困难时，这种坚决的支持就是变革是否可以继续进行的保证。因此，在过程改进的初期，于企业的高层进行沟通，让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段，一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程，取

20、得的成果。当然在遇到困难，或需要高层支持时，更要及时开口。( 这对于技术人员主持的过程改进尤为重要。)要有选择的对于KPA进行改进，不一定是最薄弱的名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 7 页 - - - - - - - - - 6KPA ，最重要是选择你可以控制的KPA 。关于这点其实并不涉及CMM 的技术问题，而是一个管理问题。 这里有个现实的例子，一家企业的管理有点乱，高层希望可以通过CMM 的过程改进，来提高企业的产品质量，理顺工作的流程。于是任命了一个

21、开发组的主管( 代称 A)，来主持这个过程改进。结果 A在选择 KPA的时候，认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨，需求经常改变，造成的返工很多，在最终期限的压力下他们不得不经常加班。这个本事没有问题，可是需求管理和变革管理的发起基本是在系统分析组，而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别 ( 即使是暂时的 ) 。现在问题来了， 虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候，他发现，当他去评审需求分析组的工作时，别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。 同时， 流

22、程中只要有一点不太合理的地方，就抱怨的很厉害。最后试点结束，他自己很累，试点的结果也不好，改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后，试点的流程并没有推广。其他的KPA过程改进也不再进行了，随着时间的推移， 过程改进在企业中也不在有人提起。知道这位开发组的主管错在哪里吗? 他选错了 KPA ，他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚，他是个不受欢迎的人。注定了， 在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理，这个至于他管理范围的KPA ，他可以利用手中的权利、资源和威信，组织试点。可能情况

23、就好的多。又或者企业的高层给这个开发主管一个虚职，比如过程改进项目组组长，并任命其他组的组长为过程改进项目组成员。情况也会完全不同。对于过程的改进要有度量。不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。一个有力的对比可以堵住反对者的嘴。不要因为度量管理是CMM4 级的内容就在实施低级别的CMM时放弃度量。一套流程需要一系列度量的数据来说明它改进了多少。而度量的数据将会为它赢得预算和支持。当然度量作为CMM4 级的内容，也是有一定的道理的。收集一套完备、准确的度量是需要大量人力的。但是在一开始，也许我们可以借助一些好的工具达到同样的效果，而不必花费大量的时间和精力。在我就自

24、己做过一个简易的BUG管理工具，并和数据库相连。在项目结束时我可以轻易的了解项目中有多少BUG 、BUG分布如何， BUG的原因统计等度量数据。我只是用了几个SQL语句就掌握了我需要的度量。CMMI不再只有一种级别的模式，还增加了持续改进的模式。即，可以按过程域进行改名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 7 页 - - - - - - - - - 7进，而不是过去按级别进行改进。比如，CMM5级的技术革新管理。其实，在现在新技术层出不穷的当今，一个企业不会因为还

25、没到CMM5 级就不需要技术革新管理。换一种数据库，换一个开发工具，甚至是换一种开发过程等都是一直发生的。若需要完全可以把这个KPA先实施改进。 不是每个人都喜欢改进的过程，特别对于要增加其工作量的过程。有时必须牺牲一些过程的严谨性，去简化过程。 毕竟有过程比没过程好。也许在看到了这条时很多人会不以为然，说：这样做肯定过不了CMM 评审。对，这样确实肯定过不了CMM 级别的评审，可是只要可以对于过程有改进，对于软件质量有提高，就可以了。 一个强有力的执行和守纪律的企业文化，是推广过程改进的保证。一个过程，在试点后，是要推广的，在推广过程中一个强有力的执行力是必然的保证。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 7 页 - - - - - - - - -