构建需求管理的系统工程(ZT)

构建需求管理的系统工程
——专访Telelogic首席过程分析师Jeremy Dick

       问：您这次来到中国，印象最深的是什么？
       Jeremy Dick：这是我第一次来到中国。来到中国我参观了故宫，很奇怪，很多地方我没有看到windows，也许微软在中国遇到了问题，但是我看到了很多DOORS，看来我们需求管理的工具DOORS在中国有很好的未来。（笑）

       问：在需求管理过程领域，您已经有10年的指导实施经验了，您对需求管理的现状如何认识？
       Jeremy Dick：虽然需求管理是常识，但是感觉起来很难，而且不容易理解。正是由于这些原因，使之实施得不是非常好。软件企业和机构日益增长的压力，常常变成不引入更严格的需求工程方法的一个主要理由。但是，正是这些压力，才使得需求工程师在帮助企业和机构正确开发起到更重要的作用。



       问：在软件开发的生命周期中，需求管理处于怎样的地位？
       Jeremy Dick：需求是所有系统健康开发的基础，他们会从头到尾、从上倒下的影响整个开发工作。如果没有有效的需求管理，开发项目就会像在风浪里漂浮着的没有舵的船。最重要的是，采用好的需求管理，听取用户和客户的声音，可以为整个开发过程理出一条清晰的沟通线索。
       需求管理并不只是软件开发里才会有的，开发系统工程的时候也一样会有需求管理的要求。人们经常错误的认为，需求管理只是在产品开发开始的时候需要执行和完成的一个阶段，实际上，需求管理在开发的各个阶段都有着至关重要的作用。
       我想用系统工程里的一个V模型来说明系统开发的生命周期。V模型分为若干层，每个层次都研究适于相应开发阶段所关心的问题。各层之间是下层满足上层的关系，左右两侧又有互相测试、验证的关系。需求管理发生在所有的每一层里，而不只是其中的一层。而且，需求管理不只是发生在前期阶段，而是贯穿了整个生命周期。而需求管理的作用是能够让我们提早地行动，从需要陈述阶段就开始行动。



       问：如何形象的理解需求管理的过程？
       Jeremy Dick：我想用一个古代记录时间的沙漏来说明问题。漏洞的上端相当于需求启发的过程，漏洞的下面是需求开发的过程。上面的活动主要表现为需求的收集，这个时候得到的信息是高度抽象的、有很多歧异的。经过漏洞，对系统的范围做出决定，选择其中哪一些是适合您的需求，这个需求就得到了精炼。这时候问题陈述就是对系统要解决问题的陈述，而不是所有问题的陈述。通过这样一个漏斗的过程，漏下来的需求就是我们系统要满足的需求，这个时候的需求是一个形式化的，而且是有结构的信息。在这个基础上，就可以设计解决方案。在这个过程中，系统工程师充当了主要角色。



       问：需求如此难以琢磨，您是如何建议需求工程师来定义和描述需求的？
       Jeremy Dick：我们可以用模型的分析方法，来对需求做更为详尽、精确的描述。比如模型视图、状态图和类图，都是可以用来从比较抽象、比较高层的角度，来对于需求进行一些描述。Telelogic有很多类似的模型和分析的工具和手段，都是用来帮助、协助我们的工作，完成缩短流程的各种各样的事情。而当大家用一些视图或者类视图，来进行图形化的描述的时候，有些人误以为这些模型就是需求的定义，这是一个错误的概念。这时可以引入文字化的描述，文字化的描述和模型化的需求描述，二者是相互补充、互为说明的。
       另外一种方法，就是用场景分析的方法来进行。这种方法是最常用的一种对用户各方的需求进行详细描述、建立与用户各方沟通渠道、改善与他们之间的沟通的方法。举一个机场行李登记、托运的例子。托运的行李，一定是在目的地被旅行者再重新拿到的。像行李被托运的目标，又可以分成一些子目标，比如说它准备被装载，以及飞行之后卸载的子目标。这样一些子目标，又可以分解成更为小的目标。对于被托运行李的生命周期的分析，以及各个环节场景的描述，我们可以发现，在被托运的过程中到底发生了什么。

       问：对于需求的编写，与其他类型的协作有何不同？编写和评审需求时有什么要注意的地方？
       Jeremy Dick：编写需求当然与写小说不同了，甚至与编写操作手册和用户指南这样的“技术类”协作也不相同。在编写需求文档时，需要仔细综合考虑以下两个方面：可读性和可处理性。第一个问题是关注文档的结构，关注文档的组织方式和流程怎样帮助评审人员把单个需求描述放在整体背景下考虑。第二个问题关注单个需求描述的质量，使用清晰性和准确性的语言，以及如何将需求分割为单一的可跟踪项。编写和评审需求是密不可分的，因为编写好的需求的准则，恰恰就是需求评审应该采用的准则。

       问：您曾经提出，需求管理较其他管理活动更困难。主要是什么原因呢？
       Jeremy Dick：需求管理比其他管理活动更困难。第一个问题是，非常少的人具有管理需求的丰富经验。这主要是因为非常少的机构定义了全机构都要遵循的需求管理过程。结果，面对必须说明的需求的项目，人们能够利用的经验很少。第二个问题，是很多人不能恰当的区分用户或stakeholder需求和系统需求，进而常常不能区分系统需求和设计规格说明。换句话说，他们直接进入解决方案，而不是首先定义独立于解决方案的需求集合。第三个主要问题是管理需求的方式要取决于完成需求工作的机构类型，如供应商机构和产品型公司的管理需求的方式死不同的。第四个问题是在生成需求时监视进展相当困难。最后当然还有不断变更的问题。评估所提出变更的影响或冲突的后果常常相当困难，但是如果没有这种知识，就不能估计引入变更对成本和时间的影响。

       问：最后，按照我们的惯例，您对国内做需求管理的工程师们有何宝贵的建议？
我把我的经验总结一下，与大家分享吧：要区分问题和解决方案这两个区域。作为需求管理的核心，应该知道一些数据和信息之间的关联关系或者追踪关系，以及它们在需求管理中占有的位置。应该了解系统工程“三明治”里系统建模、系统分析和需求管理之间相互的关系。应该知道，要避免使用一些比较模糊或者不恰当的单词，要正确地表述需求。无论是对需求个别的陈述，或者对于整体需求文档的描述，都是有一些标准相对应的，应该在评审中注意。