系统架构主题之四：软件系统需求管理技术及其应用

对于软件开发来讲，需求通常都是不稳定的，这也是影响软件开发获得成功的主要因素之一。为了应对这种情况，就需要进行需求管理。需求管理主要有需求变更和需求追踪。需求管理通常是在需求基线的基础上进行的。

1 软件需求管理技术概念

  软件需求管理包括如下内容

  变更控制：识别出问题，问题分析和变更描述，变更分析和成本计算，变更实现，修改后的需求。

  版本控制：确定需求文档版本，确定单个需求文档版本。

  需求跟踪：定义对其他需求的连接链，定义对其他系统元素的连接链。

  需求状态跟踪：定义需求状态，跟踪需求每一个状态。

  

  需求追踪包括正向追踪（客户需求到软件需求到下一级工作产品）和逆向追踪。通常实际操作层面，是以需求跟踪矩阵来维护的。

  

2 实际系统开发中如何进行需求管理

对需求管理最关键的一点是控制需求变更。从理论上和工程实践上来看，总是有不受控的因素导致需求发生变更，但是需求的变更最终是要传导到设计、编码、测试、维护的后续链节的，且越往后，变更的实现成本就越大。所以，困难的一点就在于如何对需求变更进行充分的分析，合理的决策是否需要接纳变更或接纳哪些变更项目。

需求管理在需求挖掘获取阶段就实际上开始了。如果需求挖掘不充分，获取存在明显的遗漏疏忽，那么后续的变更就不可避免，因此，越是做足了需求获取的工作，越是能够减少后期的变更。

在充分的需求获取基础上，梳理各个功能和非功能需求，提出需求基线，以此为基准，进行需求的管理。

在某电力系统项目中，对需求管理采用的方法为需求跟踪矩阵。在需求产生之初，需求跟踪矩阵就介入了。开始时主要是对需求进行分类记录。

最开始的需求跟踪矩阵包括了原始需求和软件需求，通常原始需求和软件需求是1比n的关系。一个原始需求，可能会转换为多个软件需求来实现。也存在软件需求没有明确的原始用户需求来对应，这通常存在于多个用户需求隐含的包含了软件质量属性上的一些要求的情况下。对于这一点，在需求跟踪矩阵中，通过在软件需求的影响因素列表中加以标注。对于复杂的，涉及多个子模块、多种产品形态的系统，需求的内容会比较多，此时对需求进行简单的分层，有利于需求管理。通常，能够独立的子系统或者集成产品，都有自己专门的需求跟踪矩阵文档。为了保持系统的完整性，存在最顶层的总需求文档。在我们的项目中，终端产品、服务器各个独立服务，一般都有自己的需求文档。正常情况下，这些需求的变化，会继续向下传导到更底层的子模块，通常不会逆向传导到上层系统。这样，需求的管理任务就会被实质上拆解，从而提升了管理的精细度和及时性。另外，为便于总体把控，子模块的需求变更记录也会抄送到上层管理着，在每周进度追踪会议上，都会做简单的复盘，确保这些需求的变更不逆向传导。

在初步构建的系统需求跟踪矩阵通过评审后，发布总体的需求基线版本。后续的任何变更都将纳入到变更管理中。

需求确定后，大模块的划分基本也就确定了，各个模块负责的下一阶段设计工作同步展开。此后新的需求变更提出后，需要走变更管理流程，包括三个步骤：提出变更分析报告，包括为什么变更，变更的影响。相关干系人对报告作出评价后，召开评审会，对变更是否采纳进行讨论。通常结果包含三种：立即采纳，延迟采纳和不采纳。即便不采纳，也需要给出缘由并归档记录。这类需求后续还是有可能再次进入变更管理流程的。通常，变更影响分析到位，范围界定清晰的变更才会进入立即采纳状态，而还有疑问或者不确定因素，但是有很重要的变更会进入延迟采纳状态，等补充缺失信息后，再次进入变更管理流程。

立即采纳的变更会进入需求跟踪矩阵，在整个开发链条上进行联动关注。相应的设计文档、开发文档、测试文档等都要同步做出响应。这些工作通常有子模块负责团队内部做出。

但实际情况往往不是这么理性，很多变更是跨模块的，不仅有纵向的传导，还有横向的传导。因为可能涉及跨部门，有横向传导的需求变更，会裂变为各个模块的需求变更，独立传导。这有效的减少了沟通工作。比如，增加智能图像识别功能，那么就涉及终端采集、服务端存储、算法端分析、业务端展示等多个模块，所以为了能够独立传导，这类需求都会有接口管理矩阵，用以约束和维护模块间的接口契约。

通常每个月会有一次接口需求状态拉齐的工作。各个模块间对变更的实现，测试会尽早接入，进行初步的可行性验证。这样，可以保证接口的一致性目标不被破坏。

虽然使用接口，可以管理依赖和需求各要素间的关系链条，但是实际中很多时候遇到的不是接口是否足够稳定的问题，而是需求实现的技术复杂度、工作量等的不同，导致前期的月度接口对齐工作无法实施。为了应对这一实践中出现的变化，同项目管理人员一起，讨论了需求的新管理办法，那就是接口先行。涉及各个模块的关联需求，往往存在外部接口，借鉴测试驱动开发的理念，接口先试下moke方法，大家按照月度要求，实现这一目标。即便有新的变更到来，也是先实现对应的接口桩。这样，整个流程就可以运转起来，测试就可以更早接入。后续的月度进度跟踪面对的就不再是接口对齐了，而是完成接口和遗留接口的跟踪。

对接口的跟踪，就更偏向于需求状态的跟踪。接口桩存在的接口，属于已定义的接口，接口测试通过的需求，属于已完成的需求。这样，就讲需求跟踪和状态跟踪统一起来了。

在整个项目开发过程中，需求变更主要来自新业务，这类业务前期需求虽然做了充分讨论，但是客户和模型提供方以及一些合作方的不可控因素，导致成为变更的主要集中地、重灾区。特别是前期客户支持多画面的同时分析到后来的只能支持单画面分析，对需求的影响较大，很多业务和底层支撑数据都要跟随变化。为了有效应对这种情况，对需求变更进行了更加细化的管理，主要是进行优先级排序，通过内部或跟客户的联合会议，根据在功能、质量、属性等方面的影响范围，对需求进行重要度度量。更进一步的，实际中采用了中心圆模式进行度量分析，中心为核心需求，体现系统的核心价值，外围为关键需求、安全管理需求、会议需求、智能检修需求等业务相关需求，将变更映射到度量模型上，集中有限资源，优先处理影响核心价值的需求。除了传统业务，安全业务，增值业务中有关传感器相关的业务纳入核心圈外，智能识别相关业务被放到了更靠外的层。这些智能识别需求目前更多的是锦上添花的效果，而非雪中送炭，但是开发任务量大，资源占用多，虽然技术人员十分不舍，但是管理团队还是决定要暂放到外围，这样更加能够保证整个项目的成功。

通过团队的不懈努力，项目核心需求在交付期限之前基本都完成部署验证。智能方面的业务虽然没有做完，但是通过项目过程，也是积累了很多的经验。相信在核心业务持续造血，支撑基础不断加固的情况下，智能识别会更快的实现突破，从而融入更多的使用价值，正真实现对整个系统价值的抬升。