UML软件工程组织

需求管理

    需求管理这个词有两个部分：需求和管理。先说需求，需求是什么，需求就是你要买衣服时要对售货员说你要多大的衣服。需求很难说清楚，比你搞不清楚自己的尺码还难，因为售货员会看看你的身材，拿出一件衣服让你试一下，不合适可以不给钱。但是软件不行，你会说我先给你开发个软件给你试一下，不好不用给钱吗，我反正不会。需求会变，如果你胖了或是瘦了，发现原来的衣服不能穿了，你会再买一件，如果再买一件衣服需要花掉你10000块钱，你怎么办？而由于软件不合适更换软件的费用是非常惊人的。

    人类的大部分的工程都会有比较严格的计划和质量保证，例如建筑。但是工程一旦落实到软件开发上的时候，大家就会变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（L effingwell 1997）。如果你对建成的桥不满意，要求设计师把桥转90度，他一定会认为你疯了，但是软件开发中经常都有发生要求开发者更换操作系统的事情，要知道，这二者对项目而言的工程量可没有太大的差别。
所以呢，正是由于需求的难表述性和易变性，所以需求需要有科学的分析方法和管理方法，这里分析方法不是本文的重点。

需求的特点

    需求的特点刚才已经提到了，就是难以表述和易变。可是，为什么需求会有这种的特点呢？

    在计算机产生的早期，计算机只是少数人的“宠物”，这些人个个学富五车，才高八斗。他们可以用010101之类的语言直接操纵计算机，他们也乐此不疲，那时候计算机对人类的影响还不是很大。随着计算机硬件越来越快，越来越小，软件也发生了翻天覆地的变化。计算机变成了社会不可或缺的一种工具。但是，计算机的文化，计算家的理念一直都没有变化，今天的程序员和几十年前的程序员骨子里还是一样的。他们喜欢操纵计算机，思考都和计算机一样，运用逻辑思维，甚至在他的思想中只有0和1。这对于感性的普通人来说无法接受。可是，普通人使用的软件正是这些拥有逻辑思维的人设计制造的。程序员的思维贯穿了软件设计的全过程，同样也贯穿了需求过程，而普通人没有这方面的思维，他们觉得和程序员打交道极为困难，在程序员的眼里，世间的一切都是有清楚的界限的：0和1。需求过程中，双方往往发现要么双方不能达成共识，要么双方达成共识的内容其实有相当大的出入。所以在需求过程中经常出现用户讲不清楚，讲不完全需求的情况。更要命的是，在需求阶段就又问题的需求，如果在软件后期发现，那么改正的费用是非常可怕的。有时候，甚至会超出项目本身的费用。

社会在卖方时代的时候，企业只需要生产出产品，保证产品的质量，就不用担心产品的销售了，所以生产的过程也是比较稳定的。随着社会进入买方时代，企业必须不断的适应市场，适应消费者才能保证不为社会所淘汰，所以企业的经营活动必须不断的变换以保证企业具有活力。这种变化对于计算机系统来说是非常可怕的一件事。计算机系统必须不断适应企业的变化而变化，否则就会阻碍企业的发展，原先是为了加速企业发展而开发的信息系统却成了企业发展的束缚，这不是一个极大的讽刺吗？除了宏观的原因外，需求的不易表达也是需求易变的一个原因，需求分析的不清晰和不完整导致了需求必将发现变化，要么就是对原先的需求进行修改，要么就增加需求。

需求的总流程

需求的总流程如下图：

    需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。在上一篇中，我介绍了一个我自己所经历的需求过程的例子，这个例子就经历了整个的需求过程，

    由于我们讨论的重点是在需求管理，所以上图左半边的部分不再我们的讨论范围之内。

需求管理

    软件能力成熟度模型（The Capability Maturity Model ，CMM）的第二级（可重复级）中将需求管理做为六个关键过程域（Key Process Areas ，KPAs）的一个：

    需求管理的目的就是在客户和遵循客户需求的软件项目之间建立一种共同的理解。

需求的目标包括：

控制指定给软件的系统需求，为软件工程和管理应用建立基线。
保持软件计划、产品和活动与指定给软件的系统需求一致。

    为了实现第一个目标，必须要控制需求基线的变动，实施需求变更控制和版本控制。为了实现第二个目标，必须要对需求进行跟踪，管理需求和其他联系链之间的联系和依赖。

    虽然并没有要求说软件团体必须要实施CMM，但是CMM的思想对任何的软件团体来说都是有益的，CMM为了实行这两个目标，还确定了一系列的执行约定、执行能力、执行活动来达到这两个目标。但是，CMM并没有强制要求软件团体必须遵循的软件需求管理过程。

    对于产生的需求变更，必须要有变更控制的标准、规范的过程来处理，并且由基于业务和技术的原因来赞同或反对这项变更。在接受了软件变更之后，必须要保证软件开发计划要和需求保持一致，并对需求的版本进行控制，避免同时出现多个需求版本的情况。在保证软件开发计划方面会有很多问题产生，例如进度、质量等。这时候，必须就变更和软件项目各小组达成共识，对软件项目计划作出调整，其中包括人员的安排、任务的安排、用户的沟通、成本的调整，进度的调整等。

    为了能够实现上面所阐述的过程，必须要将需求过程文档化，注意，是需求过程，包括了需求开发和需求管理两个方面。使用适当的Case工具也同样有利于管理工作的开展，按照我自己的经验，采用Office和命名准确的目录就已经足够胜任此工作了，但是如果要能够更高层次的使用Case工具，我建议使用关系数据库来管理你的需求。至于在工具方面，是各软件团体自身的情况而定。我相信，没有最好的工具，只有最适合的工具。

变更控制

    记得还在大学的时候，和同学讨论一道知名软件企业的考题：如果客户要求你帮助他修改软件一项功能，你应该怎么做？正确的答案是要向你的项目经理报告。这里面就包含了变更控制的思想。在前面我们已经说过，易变是需求的一个特点，但是任何需求的变动都会对项目产生或多或少的影响，如推迟进度，增加人员等。如果没有对变更的控制，那么项目就会失去控制。我就见识过一个软件项目在经历了无数次的因需求变更导致的延期之后，发现改变的功能已经远远偏离了原先的需求定义。

    研究表明，扩展需求对百分之八十的管理信息系统项目和百分之七十的军事软件项目造成风险（Capers Jones 1994）。扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。具体的原因包括在软件系统中引入新功能往往会带来新的问题，新加入的需求和以前的需求有矛盾之处。

    由于需求的可变性，所以没有需求变更是不可能的，并不是说你的需求分析不够完整，业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更，管理部门也会决定对项目做出一些调整。所以你在你的项目进度安排中一定要给需求变更留下余地，微软的开发方式中在每一个的里程碑（Milestone）间都预留了50%的时间，也是有这方面的理由。

    然而，这并不是说你要接受所有的要求，国内很多软件公司深得“客户就是上帝”的精髓，客户的所有要求都予以满足，这样做的结果往往就是开发人员疲惫不堪，质量得不到保证，项目延期，客户和软件团队双方的利益都受损失。学会对客户说“不”，当然，回绝必须要讲技巧，并不是一句“不行”就可以解决问题的。昨天我去买东西，我问售货员能不能便宜一点，她回答说：“不行，已经很便宜了！”。最后我就没有买，但是她如果换句话说：“对不起，我们的商品的质量都是特别好的，如果您下次再来的话，我们将给你优惠的价格”，我相信我会买下那个商品。所以说不要讲究技巧。客户的要求应该尽量满足，即时现阶段不行，也要向客户解释清楚，并在下一个版本中考虑客户的要求。

    对于需求变更的控制，保证成功的最主要的两点是将变更应用到整个开发链和记录历史变更。你可能需求一份变更控制文档来说明变更需求，大致需要说明的元素包括：

    概述：说明变更的大致内容，应用范围，对开发链的影响，总之让管理变更控制的人明白你的要求是什么。
    上下文：变更的需求在整体需求中的位置，如果需求是用用例表示的，指出他的父用例是什么。
    规模：根据开发进行的程度，指出实施变更需要付出的代价，这个代价是决定接受需求，通知客户项目延期，在下个迭代周期中实现变更的决定参考。
    提交人签字和所属开发组：决定了提交人所处的立场。

    一般来说接受需求变更提交的组织称为变更控制委员会（CCB 有时也称为结构控制委员会），该委员会的组成包括各开发小组的代表，以保证需求变更实施到整个开发链。CCB的工作流程大致是：

    接收到一新的变更要求后评估建议的技术可行性、代价、业务需求和资源限制。执行系统影响分析、风险分析、危害分析及其它评估。这些分析确保能很好理解接受变更所带来的潜在影响。同样也考虑拒绝变更所带来的对业务和技术的影响。

    CCB决定是采纳或还是拒绝请要的变更。给每个采纳的变更需求设定一个优先级或变更实现日期，或将它分配给指定的产品。CCB通过更新请求状态和通知所有涉及到的小组成员来传达变更决定。相关人员可能不得不改变工作产品，如软件需求规格说明文档、需求数据库、设计模型、用户界面部件、代码、测试文档、用户文档。修改者在必要时应更新涉及的工作产品。

    通过检查确保更新后的软件需求规格说明文档、使用实例文档、分析模型均正确反映变更的各个方面。使用跟踪能力信息找出受变更影响的系统的各个部分，然后验证他们实现了变更。属于多个小组的成员可能会通过对下游工作产品测试或检查工作来参与验证变更工作。验证后，修改者安装更新后的部分工作产品并通过调试使之能与其它部分正常工作。（摘自《软件需求》）

    最后，你需要记录变更记录，并建立需求变更跟踪矩阵来确保变更的实施。

版本控制

    需求版本混乱造成的灾害主要体现在资源的浪费上面，很多软件团体中经常发生开发组花费时日改进了一项功能，却发现整项功能已经取消，发生错误原因是因为开发组没有拿到最新的需求。

    版本控制包括两个方面：保正人人得到的是最新的版本，记录需求的历史版本。

    如果有专门的需求管理商业工具可以助您一臂之力，由于我并没有条件试用所有的需求管理工具，能够向大家推荐的只有瑞理公司的RequisitePro，推荐的一个重要原因是它能够把需求和瑞理的其他工具如Rose、TeamTest等联系起来，从而实现需求链。

    能够借助工具将需求自动化固然很好，不过，工具使用不当也不会提高生产效率。需求管理的工具其实用简单的Office和任一个关系型数据库就可以解决，而且根据企业自身的特点，摸索出最适合企业用的工具。

    版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已做变更的内容、变更日期、变更人的姓名以及变更的原因并根据标准约定手工标记软件需求规格说明的每一次修改。

需求链和需求跟踪

    如果你是一个开发人员，一天，市场部的小莉跑过来让你修改你正在开发产品的一个小小的功能，这是应客户的要求添加的，你觉得这个要求很简单，再加上你对小莉有好感，可能你就答应了她的要求。可是实际的情况是怎么样的呢？你会发现小小的修改并没有想象的那么简单，对这项产品的修改导致了进程的延误，最糟糕的是，由于这项修改没有传达到整个需求链，其他的开发人员那里由于你的修改出现了一些要命的错误。

    软件工程重视的是过程能力，如果不能严格的确保过程的每一个环节都被不择不扣的执行，软件过程就会不成功，我们都学过法律常识，都知道有法可依还不够，还必须有法必依，执法必严。遗憾的是，中国的软件组织对过程的严格执行并不是特别重视，上面的例子在各团体中都是很普遍的，这可能和中国人的思维方式有些关系，关于这一点，鲁迅先生在很早的时候已经讨论过了，我们就不用在此罗嗦了。

    需求链的概念指的是需求能够上传下达，从客户传达到需求过程，并从需求过程传达到需求过程的下游开发链。而这个传达是可以逆向的。

    需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用（ Ramesh 1998）。

    在CMM三级中要求软件团体必须具备需求跟踪的能力：“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。”

    实际上，创建需求跟踪能力是困难的，尤其是在短期之内会造成开发成本的上升，虽然从长远来看可以减少软件生存期的费用，软件团体在实施这项能力的时候应循序渐进，逐步实施。

    需求跟踪的一种通用的方法是采用需求能力跟踪矩阵。它的前提条件是将在需求链中各个过程的元素加以编号，例如：需求的实例号，设计的实例号，编码的实例号，测试的实例号。他们的关系都是一对一和一对多的关系。通过编号，你可以使用数据库进行管理，需求的变化能够立刻体现在整条需求链的变化上。

    需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。