系统架构主题之三：软件系统需求获取技术及应用

软件开发活动的第一项工作就是需求获取。需求获取简而言之就是用于解决软件需要做什么以及为什么做的问题。需求获取阶段关注要做什么，这是很重要的一点。因为技术人员通常在需求获取过程中，会不自觉的就加入实现方面的内容，这是职业习惯本身驱动造成的。就好比一个呼吸科医生看到一个咳嗽的人会不自觉的想这个人可能因为什么咳嗽；一个警察在人群中看到一个神态异常的人可能会不自觉的观察这个人是否是在逃犯等等。

1 软件需求获取手段及概念

软件需求通常包括业务需求、用户需求和功能需求（包括非功能需求）三个层次。

注意，不同规模不同类型的项目，需求获取的技术不同。常见的需求获取方法有：

1. 用户面谈，最直接的，通过直接面对面的交互获取需求；
2. 需求专题讨论会，快速获取，各个方面；
3. 问卷调查，通过使用调查表，收集信息，调查表可以是自由格式或者固定格式；
4. 现场观察，通过观察用户的活动现场及工作习惯，从而了解项目需求；
5. 原型化方法；
6. 头脑风暴法。

JRP，联合需求计划，应该跟需求专题讨论会是一个意思，是一个通过高度组织的群体会议来分析企业内的问题，并获取需求的过程，是联合应用开发的一部分

  

2 实际项目或系统中使用的需求获取技术或上述需求获取技术在实际系统开发中的应用

总的而言，这部分概念范围比较明确，书中也没有太多介绍，因为需求获取本就是一个实践性特别强的活动，需要根据具体项目的应用行业、现有产品现状、企业技术能力、用户规模等多个方面来展开，才能较为合理的完成需求收集工作。

  

在前述某电力系统项目开发中，用户需求的获取主要采取以下几种方式：

1. 针对业务流程情况，采用用户面谈方式，实际了解用户的业务开展情况，具体过程，其中各个环节有什么问题，主要需求在那些方面，哪些方面做得比较好，哪些方面还欠缺。当然，除了现有的技术和业务布局外，根据政策方向、国家产业发展重点支持的领域（比如针对现有的光伏、风电等新能源和储能产业）做一些需求的深入挖掘工作。技术在进步，技术在业务支撑方面，应该也与时俱进，不断推陈出新，适应新的发展要求。
2. 其次，采取了需求专题讨论会的形式进行需求挖掘。以市场人员为主导，将架构师、项目管理专家、领域专家、客户经理等人员、电力系统部门实际接触业务的一线人员召集起来，以线上专题评审会的形式，对前期沟通整理的需求进行评审指导。因为行业特殊，人员特殊，现场开讨论会，并在会上挖掘需求，并不现实。我们采用的方法是做足会前的工作，通过对客户的情况进行充分调研了解，整理需求，然后在会上以专家指导的形式进行点评，以此获取需求方面的有价值信息。
3. 前面也讲了，会前的工作其实更加的多，要做足做充分。这就有了实地调研和头脑风暴方法。产品负责人和技术支持专家拜访客户，进入一线实地观察，了解工作流程、业务现状，做好笔记整理，回来后召开内部各方参与的头脑风暴会议，尽可能对需求进行挖掘梳理。以便在专家参与的评审会议上，对需求项进行过滤，标记出重点需求和可有可无需求。实际中发现，内部的数据采集、施工操作等仍然是重点，而新技术包括安全帽识别、电子围栏、工单管理等，还是锦上添花的部分。但是也有部分是痛点需求，比如无人机异物排除、基于卫星的可靠通信等。可见这些是用新技术解决了以前无法解决的问题或者需要支付更大成本才能解决的问题，对这类需求更加关注。其实也可以看出，这些才是贴合客户实际业务场景的“卡脖子”问题，而从技术人员角度出发的图像识别安全帽、现场作业合规检查、线路发热预警、线路情况统计等，因为有传统惯用方法的存在，在现场一线人员来看，并不是那么迫切需要解决的。当然，也有缺乏典型应用案例的支撑，导致作业人员对一些预警可靠性的疑虑。这其中一些，需要制度、技术、人员共同作用来推广。制度有要求，技术有保障，人员有动力，效果才能有显现。
4. 原型化方法也有用到。像检修工单管理、线路状态实时监测，最初就是做了原型跟用户进行沟通的。但是这块也出现了问题，就是线路状态实时监测，技术人员在没有进行充分了解和不熟悉电网业务情况下，根据对传统信息传递可视化的理解，提供了线路状态监测可视化原型，结果跟客户需求有较大差距。客户因为是行业用户，有自己的专业要求和规范，比如电力线路图并不能随意根据节点上设备名称确定示意图和连接方式，这些都是有领域概念和模型在其中的。还好这些是在初始需求阶段就发现了，技术方面理解作出调整，根据行业的要求，做了图示库和基本元件模型，方便建图，同时邀请专业人员临时加入开发团队，提供相关保障，来指导业务开发过程。后续对检修工单的管理，就吸取了教训，先充分学习了解电路检修作业规程，再结合契合当前移动端使用习惯的App操作方式提供给客户，取得了相对不错的效果。
5. 行业产品分析。每个领域的产品经过演化发展，都有其内在的一些特征。就像产品设计时，通常都会嵌入该公司特有的元素、设计理念，使得产品展示出独特的区分特征，这就是产品的基因。满足这类标准要求的产品，用户一眼就能看出这是哪家公司的产品，并能将其与其他公司产品进行区分，做到这一点，就是成功的设计。实际生活中，这多体现在产品的外观上。比如，我们发现商场促销牌都采用相似的设计方式，户外用品很多也采用了相似的一些元素。软件上也类似，一个行业用户的各类产品，也有一些类似的特质，融入到产品中，不限于软件界面。通过了解这些产品及其提供的功能，进行关联分析，对我们进行需求获取也是有帮助的。比如获取领域概念术语，习惯操作，相似功能、有启发价值的功能等。在这类分析过程中，我们发现用户存在不少演练活动，而这些演练过程中产生的数据和现场画面，需要在后续的复盘检查、宣传展示中都会用到，此时恢复现场多画面，并支持灵活编辑的功能，得到了客户的积极反馈。进一步的通过了解其他产品如何做，客户希望的方式，结合技术本身的约束，综合产品的成本、功能使用频度等，我们提炼该需求，将其作为一个通用功能，在多个业务场景、多个产品线中统一融合，取得了不错的效果。

3 不同手段获取的数据有差异，但都是重要的参考，对设计、测试验证有指导作用。

需求获取是一个反复的过程，不是一次成型的。所以，开发对此要有心理预期，而且需求适应的技术也可能有很大不同。在需求获取过程中，就发现有些数据是内部网络的，有些数据是外部网络的，比如电力设备的相关信息，必须在内网隔离情况下，才能传输，而向视频会议业务，则可以使用外网构建。但是，内外网之间又有一些数据传递需求，这些需求重要的不是技术方面问题，而且规范安全防护方面的问题，是合规的问题。此类需求，通常在整个需求获取过程中被影藏了起来，不同部门涉及范围不同，了解情况不同，大家对这类数据的传输关注程度不同，很多时候并不能体现出来。这就需要在需求挖掘时，工作尽可能做细，从而能够将这些需求突出表现出来，以期得到专业和政策方面的支持。

结合上述两点，如何在不整体升级的情况下，在内部外部网络信息传输不中断的情况下，做到持续集成、持续部署，成为后期需要改进的主要方面。