软件项目需求开发方法的实践总结

陶世敏

广西德意数码股份有限公司 广西南宁530022

摘要：需求开发是软件项目设计和开发的输入，做好项目的需求开发，是项目成功的第一步。需求开发没有捷径，必须从需求获取、需求分析、需求定义、需求确认一步一步完成需求开发工作，这是提高软件需求开发效率和质量的可行方法。

关键词：需求开发；需求获取；需求分析；需求定义；需求确认

1 前言

从软件工程的角度阐述，本文所讲的“需求开发”是指收集、获取用户需求或产品需求，并加以分析，形成系统需求规格、功能设计及开发任务的过程。

需求开发作为软件项目生命周期的中最为重要的环节之一，也是软件项目开展的输入源头。据统计，在众多的项目实践中，约有25%的失败项目，是由于需求开发和需求管理不当造成的。如果需求分析方法使用得当，设计开发实施将会事半功倍，对提高软件开发和实施的进度，和项目交付质量有很大的帮助。

需求开发和需求管理，是规范化软件项目需求活动的两大过程，而需求开发是做好需求管理的前提和保障。笔者将近年来参与的多个软件项目所使用的需求开发方法总结如下。

2 需求开发过程

软件是为用户服务的，用户的需求就是用户对软件预期实现功能的期望。换而言之，用户需求就是软件项目的目标及范围的定义，是软件设计、开发和实施的依据。

软件的需求开发过程，可以分为：需求获取、需求分析、需求定义、需求确认四个步骤。

（1）需求获取：通过各种途径获取用户的需求信息，归纳整理产出《用户需求说明书》。

（2）需求分析：将需求获取阶段，获得的用户需求、记录与资料进行全面系统的分析与整理。

（3）需求定义：根据需求获取和需求分析的结果，进一步定义软件需求，编制《软件需求规格说明书》。

（4）需求确认：项目组和客户、干系人，共同对《软件需求规格说明书》进行评审，双方对需求达成共识后做出承诺。

3 需求获取

大部分用户需求并不能一蹴而就获得。而且，大部分被调研的用户无法完整地讲述其需求，或者讲述的需求含糊不清。需求从无到有，从概要到详细，需要需求分析人员多次调研、考察、对比、分析、确认，才能的获得完整、真实，准确的需求。

软件需求是一个逐步细化的过程。在不同的项目阶段，需求定义的颗粒度要求有所不同。

在项目前期，由于项目/产品还在总体规划阶段，大部分需求定义较为笼统，仅用于界定项目范围，及估算大致成本。所以在项目前期，需求往往缺少细节。

在项目立项，正式启动后。项目范围已框定，用户需求可以进一步细化和完善，并清晰定义。因此，项目正式立项后，涉及的与之相关的需求均须要进行全面调研和分析，产出的需求成果，务必达到可以指导开发的颗粒度。

通常，获取需求有以下途径和方法：

（1）用户访谈

用户访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对性地进行；非结构化是只列出一个粗略的想法，根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。

用户访谈是较为常用的需求获取方式，具有很好的灵活性。但客户访谈需要需求分析师有很强的沟通能力，同时也要求需求分析师有足够的相关业务领域知识，且用户有充分时间沟通。访谈的方式可选择面对面，或视频会议，电话语音，或借助即时通讯的方式。

（2）调查问卷

用户调查的方式是通过设计提问问题形成调查问卷，然后下发到相关调研对象手中，让他们填写并收集答案，从而获取用户需求。

该方法适合面向用户群体较为广泛的市场调研，用于初步需求收集。缺点是缺乏灵活性，所获取的信息量较有限，或得到的信息可能不准确。在实际调研中，可以先采用调查问卷的方式收集一定量的需求，分析后再针对性地开展细化用户访谈。

（3）现场考察

正所谓“百闻不如一见”。对于一些较为复杂的流程、工序，言语和文字难以表达时，可以采用到用户工作环境直接观摩用户实际作业、旁听客户讲解的方式，从而更直观的了解客户需求。

（4）从行业标准、规范中提取需求

如果用户要求所开发的软件或产品必须满足一定的行业标准和业务规则时，需求分析人员可以通过阅读政策法规、业务规则以及行业标准等各类相关的文档，并与相关领域的业务专家进行业务交流来了解客户的需求。

这种方法要求需求分析师有一定的行业从业经验，能够了解行业的发展动向。

（5）考古分析

对于一些数据关系比较复杂，细则繁多，工作表单量大的项目，有时又难以通过用户描述或者现场考察的方式了解其中需求细节。这个时候就可以通过对历史存留的一些文档、数据、旧系统进行考察研究的方式。该方法重点是通过现存的已经完成的带有数据的文件、表单、报告、旧系统，来获得所需信息，如提炼计算公式、数据关系、业务规则、执行条件等。

（6）竞品分析

收集并获取市场上已有的同类竞品，对竞品的相关功能进行分析、分解，提炼竞品功能需求，参考竞品需求方案，或提出比竞品更优的需求方案。

（7）需求讨论会

通过协调和召集相关干系人组织需求会，可组织：关键客户代表，分析人员，开发人员，共同讨论需求。

这是一种较为直接有效的获取需求，或确认需求的方式。需要提前协调相关干系人到会，同时，并事先准备的讨论主题/问题、或需求方案、或系统demo/原型页面、或评审材料等，在会上共同商议得到最终需求，及解决方案。此种方式适合于已有部分成果、或现有阶段成果，需要召集各方，对成果进行讨论，并确定最终需求方案的情况。

（8）原型分析法

原型即把系统主要功能和接口通过快速开发制作为“软件样本”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的成果之一，可方便于沟通。原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。

上文所述是较为常用的获取需求的方法，可按项目实际情况，多种方式灵活结合使用。

4 需求分析

需求分析是指，需求分析人员将获得的记录与资料的分析与整理，在项目组内组织软件的需求分析工作，如：建立各需求元素之间的关系，明确软件需求、需求的分类、需求的优先级等工作。需求分析一般按“自顶向下、逐层分解”的思想对需求进行分析。可借助UML建模工具，如流程图、实体-关系图、活动图、判定表/树、数据流图、数据字典等。

需求分析人员需要兼顾项目方方面面的需求，然后进行全方位需求分析，防止遗漏，减少后期需变更风险。通常需要分析包括如下方向：

（1）需求目标识别

业务驱动是需求开发工作的核心思想，就是站在用户的角度，处在业务处理的视角开展需求工作。比如，针对业务目标，提出实现或优化方案；或者针对业务的问题，提出解决方案。所以需求分析人员首先要明确项目及其各模块的需求目标是什么，或者解决的问题是什么。后续的需求开发工作就是围绕目标和问题来开展。当然这个需求目标不能是笼统的或者不切实际的目标。

（2）干系人识别和分析

干系人识别不仅仅用于项目管理，同样在需求开发工作中也非常关键。这些干系人，有可能是后续开展需求调研工作的对象。如果干系人识别不全，有可能会遗漏需求。

需求分析人员需要列出与项目业务相关的干系人清单，关联的业务有哪些，了解关系人的职权、岗位及影响力，另外，在将干系人清单中，列他们出对业务的关注点，冲突点，和影响程度。以便在访谈和需求调研时，有目的的解决干系人的需求。

另外，部分干系人参与系统业务作业，需要对该部分的干系人进行用户角色分析。

（3）业务流程分析

在如今分工日渐明细的社会，各工作岗位协同工作在所难免，支持业务流程是信息系统的核心价值之一。业务流程其实就是协作活动。例如：人机协作关系，或用户间的协同作业。

业务流程分析就是对这种协作活动的固化、优化进行分析。首先需要先从需求中识别业务流程、区分主干流程、分支流程、可变流程；识别流程活动顺序、业务规则、协作关系、产出物、异常处理等。需要逐项识别和分析。业务流程需求可使用流程图将各业务流程进行记录和描述。

另外业务流程的建立，也会衍生出对流程的管控需求。建立业务流程的目的除了按标准固化工作流程，减少错误之外。同时也可以是提高执行效率为目的。大部分的业务流程建立完善后，业务管理着需要对流程的执行率，错误率、时效进行管控。例如，某部分按流程执行时效进行个人绩效考核。在做需求开发和分析时，需要兼顾，并按业务流程管控目的进行有效分析。

（4）业务数据分析

有人将数据比喻为信息系统的血液，是这一个形象的比如，因为系统的运作，伴随着数据的传输和运算。所以对数据的分析是需求工作的重中之重。

提到数据分析，应该会有不少人就会直接联想到字段构成及数据间的关系。但是，除了数据构成、数据关系，还有另外一个最重要的因素往往被忽略，那就是数据应用分析。即是数据如何产生、如何在业务中流转，数据应用在哪些场景。

业务离不开数据，而数据从业务流转中产生并发生作用，本文所说的业务数据分析，包含两层意思，一是数据结构分析，二是数据应用分析。

数据结构分析就是上文提到的，数据字段，数据关系，这是最基础的，可以从用户需求中获取，或数据应用分析中产生。

而数据应用分析需要使用建模工具，建模工具更能清晰描述一个业务场景中各数据逻辑和的数据关系。一般在实际项目实践中，我们使用E/R图和类图对数据进行分析。E/R图一般只能描述关联关系。用的更广泛的是类图，类图能够表示更多的关系。

建模时，首先识别主业务流程/场景，针对各主要业务流程/场景绘制出类图，如果分支流程有必须要，同样画出类图。对于一个包含大量业务数据的系统，或场景来说，要把整个领域类图绘制出来比较困难，可以采用“自底向上”的逻辑，找出所有主要流程，针对没个流程绘制领域类图片对，然后将它们合并成一个整体的领域模块。

（5）业务接口

业务接口，可以是系统向外部提供数据接口，或从外部系统获取数据。也可能是线上系统接口，或线下人机交互。也不管是那种方式，在需求开发过程中，业务接口识别和分析是十分重要的。也是较为困难的工作，因为需要多方协调接口对接工作。

业务接口在项目需求调研初期就应该尽早识别出所有与项目相关系统的业务接口。、涉及外部的接口的，需要提前协调资源，避免外部资源不满足导致项目延期的风险。然后再逐步对业务接口的需求进行分解和分析，逐步明确其数据参数、约束条件、交互过程、数据处理逻辑等，形成技术文档，并与接口对接方确认、达成一致意见。

（6）交互界面分析

对于展示类和操作较多的系统，对UI和交互设计均有较高的要求。比如门户网站，面向大众的APP，小程序等。此类系统项目建议使用原型法。获取到基本需求后，先制作原型，与用户方进行多次沟通，确定最终原型DEMO后，再进行后端代码开发。这样可以降低后期变更的风险。

（7）非功能需求识别和分析

细节决定成败，需求分析人员或项目经理对各类需求均要兼顾。除了上述提到的功能性需求，需要考虑其他非功能性需求。如性能需求、质量需求、运维管理需求等，每项目需求的侧重点不同，这些需求不一定都需要兼顾，但是需要充分被考虑，再召集项目组一起进行做权衡取舍。

5 需求定义

需求定义目的是根据需求获取和需求分析的结果，进一步定义软件需求。需求分析人员在需求分析过程中根据分析步骤逐步编制成《软件需求规格说明书》。该《软件需求规格说明书》可用于指导设计和开发。

需求定义的过程，就是将用户需求转化为实际功能的过程。

部分需求分析人员容易将《用户需求说明书》与《软件需求规格说明书》混淆。

一般而言，《用户需求说明书》是需求调研过程中产出，是对用户需求如实记录，仅是对收集到的所有需求信息进行分类整理，消除错误，归纳与总结共性的用户需求。描述的是问题级，或现象级的内容。这些内容需要进一步分析后才可用于指导设计和开发。

而《软件规格需求说明书》在需求调研和需求分析之后产出，是对《用户需求说明书》中各用户需求的响应，描述的是分析之后的方案级的内容，其中包括了设计和开发过程中需要注意的技术实现细节和要求，内容更全面、更具体、更准确，可用于指导设计和开发。

《软件需求规格说明书》的编写一般有如下要求：

• 
  
  • 
    

  • 相关的需求都得到了识别与描述，以确保需求的完整性；

  • 各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；

  • 正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；

  • 定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；

  • 使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；

  • 确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；

  • 考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。

6 需求确认

需求确认是指项目组、客户、用户、业主、项目负责人等关系人共同对已经完成的《软件需求规格说明书》及相关材料进行评审并签字确认，要求双方对需求达成共识后做出承诺。

需求确认有两个目的：

• 
  
  • 
    

  • 核实需求阶段产出成果和交付物，并签字确定最终需求，双方做出“需求承诺”，以所确认的《软件需求规格说明书》版本，作为后续需求基线进行设计开发；

  • 更好的控制需求变更，任何一方变更，均有据可循。后续的变更需要提出申请，双方再此确认后，在以新版本作为需求基线。

在对《软件需求规格说明书》进行需求确认之前，项目组内部建议先进行内审查，从需求内容上、技术可行性上、项目周期、成本、质量要求等多方面进行评估，确保需求方案双方共赢，或利于项目组的开发和实施。然后再与客户方等相关干系人进行外部评审并确认。

需求确认应该贯穿项目的始终，只要发生需求变更，项目组应与客户方进行一次需求确认，对变更后的需求达成共识，承诺其变更内容。另外，需求变更后，与变更内容相关的设计方案等关联交付物也需要更新。

7 综述

需求开发过程贯穿项目周期的始终，无论在软件生命周期的哪个阶段，都会不可避免的遇到需求开发。做好项目的需求开发，是项目成功的第一步，也是极为关键的一步。需求开发没有捷径，无论是产品型软件开发，还是项目型软件开发，无论在哪个项目阶段，必须认真仔细的从需求获取、需求分析、需求定义、需求确认四个步骤一步一步完成需求开发工作。同时，完善和规范化软件需求开发过程体系，也是对软件需求有效管控的前提保障。

在实际的需求开发过程中，文中提到的各种需求获取途径、需求分析方法和工具，需要依据实际项目情况灵活使用。

参考文献

[1] 张传波.火球：UML大战需求分析[M].北京:中国水利水电出版社,2012:3.

[2] 徐锋.有效需求分析[M].北京:电子工业出版社,2017:3.

4 /4