需求一致性的软件工程方法

2023-09-17张昱

计算机应用与软件 2023年7期

张昱

(中国科学院空天信息创新研究院北京 100190)

0 引言

需求来源于用户。用户包括系统/软件的使用人员和将系统需求分解为软件需求的系统总体人员。本文中的“用户需求”泛指上述两类用户对软件研发项目组提出的软件需求。用户需求是软件研发工作的输入,也是验收软件研发成果的依据。软件研发的最终目的是交付与用户需求一致的工作产品。为了确保最终工作产品与用户需求一致,中间工作产品以及过程活动也要与用户需求一致。按计划交付了与用户需求一致的工作产品,意味着成功地完成了研发工作。如果工作产品与用户需求出现了不一致,那么一定会降低用户的满意度,影响用户和管理人员对项目的评价。工作产品与用户需求的一致性程度,是评价项目成效的重要指标。

如下两个主要原因导致工程活动和工作产品偏离用户需求:第一,用户需求源于期望和愿景。随着工作开展,用户对需求的认识也在不断地深入和细化。软件研制方如果不能适应和管理用户需求的变化,工作就会逐渐偏离用户的需求。第二,在需求分析、软件设计、编码、测试等多个概念转换及衍生产品的形成过程中,软件研发人员对用户需求的理解和再理解可能出现偏差,工作产品之间可能出现不一致,这些理解偏差和不一致很容易累积起来,影响相关和后续的工作产品,导致交付的工作产品与用户需求不一致。

软件工程引入了需求开发和需求管理的概念。前者关注需求建立的过程;后者管理需求开发形成的工作产品,确保研发人员始终在理解和承诺用户需求的基础上产出与用户需求一致的工作产品。有时,将需求开发和需求管理统称为需求工程。本文侧重研究需求管理。

1 需求管理的目的

GJB5000A-2008《军用软件研制能力成熟度模型》提出,需求管理的目的是“管理项目的产品和产品部件的需求,并标识这些需求与项目的计划和工作产品之间的不一致性”。CMMI 1.3提出,需求管理的目的是“管理项目产品及产品组件的需求,并使需求与项目计划及工作产品之间保持一致”。

总之,需求管理的目的是通过一组工程实践确保需求的一致性。需求一致性包括三个内容:用户需求和用户需求之间一致;最终工作产品、中间工作产品与用户需求一致;工程活动保障上述一致性的达成。其中,第1条主要由需求开发相关活动实现,第2条和第3条主要由需求管理相关活动实现。

从理解用户需要到交付最终软件产品,通常经历了需求分析、软件设计、编码和测试等软件研发阶段,每个阶段都产生了不同的概念模型和工作产品。用户需求使用文字和图表记录,软件设计使用模型和算法表达,软件代码是一系列计算机语言描述的运行逻辑,软件代码被编译为可执行程序。通常,可执行文件和配套文档是最终软件产品。在软件研发过程中,确保每个人对概念模型的理解一致,各种概念模型和衍生工作产品不偏离用户需求,是软件研发人员期待达成却又困难重重的事情。需求管理希望通过一组工程实践,达成各种概念的理解一致、各种中间工作产品和最终工作产品一致,并且所有一致都基于用户需求。

2 需求管理的工程活动

通过理解和承诺需求、建立需求追踪关系、发现和解决不一致、管理需求变更四组工程活动达成需求管理的一致性管理目标。

2.1 理解和承诺需求是需求一致性管理的前提

规范需求提供渠道、建立需求沟通机制、明确需求接收准则和做出需求实现承诺是理解和承诺需求的主要活动内容。

1) 规范需求提供渠道。通常由用户方指定有效的需求提供者,从而建立规范的需求提供渠道。狭义的需求提供者是用户方指定的用户代表。广义的需求提供者还可以是一个由用户、同行专家和研制方代表组成的联合工作组,也可以是一个定期召开的需求研讨会。无论采用哪种形式,目的都是规范化用户需求的提供渠道,从这一渠道提出正式的用户需求。需求提供渠道应在用户方和研制方达成共识后,写入项目计划书或其他有效力的文件中。

2) 建立需求沟通机制。项目组相关人员与需求提供者建立常态化的沟通交流机制,共同理解需求。项目组的技术负责人、测试负责人和主要管理人员充分理解需求自不待言,用户方的需求提供者也有必要在沟通交流中不断加深对需求的理解,从而将“需要”转变成清晰、合理的需求。沟通交流需求的主要形式是会议,当然也可以是邮件、访谈等其他形式。研制方应尽量使非正式的沟通内容得到需求提供者的正式认可,并保存和管理所有沟通记录。

3) 明确需求接收准则。需求提供者的出发点往往是用户方的“需要”,还要经过充分的分析和思考才能形成用户需求。在用户需求的形成过程中,研制方的观点十分重要,因为研制方关注用户需求的实现可行性、实现成本、验证可行性和内容一致性等要素,而这些要素恰恰是高质量需求不可或缺的特征,也是后期需求一致性管理的前提保障。研制方应将需求的接受准则明确下来,并按照准则讨论和接受需求。研制方可以将疑似不满足准则但暂时无法拒绝的需求标识出来,纳入风险管理。

4) 做出需求实现承诺。项目组成员在充分理解用户需求的基础上承诺其可实现,从而建立并巩固用户方和研制方管理人员对实现需求的信心。承诺用户需求的形式通常有两个:研制方领导或项目组主要成员参与用户需求评审会,在会议上做出正式承诺;在项目组会议上讨论并承诺用户需求。广义的需求承诺是在项目研制过程中,始终确保所有工程活动都围绕着实现用户需求这一目标开展、所有工作产品都与用户需求保持一致,这是用户和研发管理者最想得到的一条承诺。

2.2 建立需求追踪关系是需求一致性管理的主要手段

如何在理解和承诺用户需求的基础上,通过管理手段保障需求分析、软件设计、代码、测试用例、计划与用户需求的一致性呢?业界的普遍做法是以工作产品和用户需求之间的追踪关系为手段。追踪关系的建立可以使用软件工具,也可使用电子表格,两者的原理是一样的。

一致是一种自洽和协调的关系,是矛盾的反面。如果工作产品与用户需求一致,则一定具有可追踪关系,反之则不成立。通过需求追踪关系管理需求一致性的基本方法是:

1) 在工作产品与用户需求之间建立追踪关系,无法建立追踪关系的条目一定不具有一致性。

2) 以追踪关系为线索,进一步识别关联条目之间的不一致。

3) 标识并纠正不一致。

需求追踪关系的表示方法可以是需求跟踪图、超链接,甚至文档注释,最常见的方法是需求跟踪矩阵。简单的需求跟踪矩阵是一张二维表,列是用户需求、依赖用户需求、软件需求分析、软件设计、代码、测试用例和任务计划的编号,行是被追踪的用户需求条目。如果每行用户需求都能分别对应至少一条软件需求分析、软件设计、代码、测试用例和任务计划的编号,那么需求跟踪矩阵满足了纵向追踪关系;如果标识了用户需求和依赖用户需求之间的关联关系,那么需求跟踪矩阵满足了横向追踪关系。当存在较多的“一对多”或“多对多”的追踪关系时,这种简单的二维需求跟踪矩阵就难以维护和检索了。此时可以把简单需求跟踪矩阵的一张二维表拆分成多张二维表,即拆分成:用户需求依赖关系跟踪关系表、用户需求-软件需求分析跟踪关系表、软件需求分析-软件设计跟踪关系表、软件设计-代码跟踪关系表、代码-单元测试跟踪关系表、软件设计-集成测试跟踪关系表、软件需求分析-出所/出厂测试跟踪关系表、用户需求-验收测试跟踪关系表等,每张二维表的行和列分别是被追踪元素和依赖元素,每个单元格可以写入依赖/被依赖的双向追踪关系。使用一张二维表建立追踪关系的方法也称单矩阵追踪,使用多张二维表建立追踪关系的方法也称多矩阵追踪。

解释几个关于需求跟踪矩阵的常见问题:

1) 在需求跟踪矩阵中,对用户需求和工作产品的内容要分解到什么粒度?泛泛而谈,分解到辨识度高、追踪效果好的粒度就可以了。如果进一步追求管理的绩效,那么至少要把关键、易变的需求重点管理起来。关键的需求是影响用户目标达成的高优先级需求,易变的需求是预计可能出现变更的需求。

2) 需求跟踪矩阵的作用是什么?需求跟踪矩阵管理横向和纵向追踪关系。纵向追踪是用户需求与需求分析、软件设计、代码、测试用例等工作产品及计划之间的追踪关系;横向追踪是用户需求和用户需求之间的关联关系。纵向追踪可以发现工作产品是否覆盖了全部用户需求,以及帮助识别是否存在不一致。横向追踪可以在需求发生变更时,与纵向追踪关系一起评估需求变更的影响范围。此外,还可以通过需求追踪关系识别复用程度高的需求和模块,并在项目监控时通过需求的状态掌握项目进展。

3) 横向追踪是不是必须的?纵向追踪关系是需求一致性的必要条件,横向追踪关系既不是需求一致性的充分条件,也不是必要条件。业界对需求纵向追踪的必要性是毫无异议的,对横向追踪的必要性则有不同意见。笔者认为,是否有必要进行横向追踪,要看需求横向追踪的作用——横向追踪关系主要用于需求变更时评估变更的影响范围。如果研发人员在需求分析时充分分析了需求之间的接口关系并记录在需求分析文档中,那么即使没有在需求跟踪矩阵中进行横向追踪,也不会妨碍需求变更时的影响分析。

4) 什么时候更新需求跟踪矩阵?一种观点是在策划、需求分析、软件设计、编码、测试等活动完成时更新需求跟踪矩阵,另一种观点是随时更新需求跟踪矩阵。笔者建议项目管理人员、需求分析人员、软件设计人员、软件实现人员、软件测试人员根据工作进展及时更新需求跟踪矩阵,在相关工作产品评审时一并评审需求跟踪矩阵。

5) 使用单矩阵追踪还是多矩阵追踪?笔者建议使用多矩阵追踪。通常,多条测试用例对应一个功能模块,一条用户需求被分解为多个设计和实现模块。需求跟踪矩阵显然是多对多的关系,对于多对多的关系应使用多矩阵追踪。此外,只有多矩阵追踪才能真正实现正向和反向的双向追踪。

2.3 发现和解决不一致是需求一致性管理的重点

需求管理以理解和承诺为前提,以建立追踪关系为主要手段,目的是发现和解决需求不一致,从而确保工作产品和活动始终不偏离用户需求。

1) 发现需求不一致。发现不一致不仅要建立需求追踪关系,还要主动基于追踪关系进行识别和判断。发现不一致并不局限在需求追踪关系建立和维护时,还应该在平时、例会、评审活动时注意捕捉需求不一致的各种迹象。不一致的表现主要包括:矛盾、不完整、冗余、不可追踪。针对不同工作产品又有不同的表现特点:

(1) 软件需求分析和用户需求之间的不一致主要出现在理解和表达上,表现为软件需求分析文档没有完整地描述用户需求或者描述有歧义。

(2) 软件设计和软件需求分析之间不一致的情形主要表现为功能需求过度设计、技术方案不合理、接口设计不完备、非功能需求设计不充分等。软件设计与软件需求分析之间的不一致情形较多,也较难发现,需要引起特别的重视。

(3) 软件代码和软件设计之间的不一致通常要延迟到测试阶段才能被发现。但是,如果测试用例的设计工作和需求分析、软件设计同步开展,那么编码人员凭借对测试用例的了解,可能主动规避一些不一致的问题。

(4) 不同级别的测试用例与软件需求分析、软件设计、代码的不一致主要表现为未按运行场景组织测试、测试用例的覆盖性和有效性不足等。测试人员对需求的理解程度会影响测试的有效性。很多组织要求测试人员积极参与需求沟通和理解,同时鼓励用户代表参与测试设计和测试活动,采取这些措施的目的是“加固”需求一致性管理的最后一道防线,在测试阶段尽量多地发现需求不一致这类深层次的问题。

2) 解决需求不一致。项目管理人员应该认识到,所有涉及“需求不一致”的问题都是影响产品交付和项目成败的严重问题。个人、小组、质量保证人员、用户代表、同行专家在任何场合发现的需求不一致都应转成问题,由软件项目负责人组织解决,由质量保证人员监督解决。不一致的解决策略有三种:

(1) 变更工作产品或计划。

(2) 变更用户需求。

(3) 在用户、利益相关方知悉和认可的前提下,暂时搁置不一致。

2.4 管理需求变更是需求一致性管理的难点

在研制的整个生命周期——包括运行维护阶段——都可能发生需求变更。随着研制工作的深入开展,用户方和研制方都可能在概念上“重塑”早期形成的需求。经验表明,在需求发生变更时,更容易出现不一致的情形。这些不一致情形发生的原因,除了工程水平之外,主要是需求管理的变更影响分析出现了问题。

从配置管理的角度看,需求变更是纳入功能基线后的变更。功能基线形成后,工程活动继续推进,需求变更不仅影响到相关需求的变更,而且涉及到后续相关工作产品的变更。因此,评估需求变更的影响范围,既要横向评估受影响的其他需求,也要纵向评估与变更需求相关的工作产品与计划。需求变更的影响范围评估直接影响到需求变更的有效性,也是进一步开展变更活动的工作量估算、计划变更、管理控制和变更确认等活动的依据。

完整的需求变更过程至少包括如下几项活动:

1) 理解变更需求。

2) 评估需求变更的影响范围。

3) 重新承诺需求。

4) 待变更工作产品出库。

5) 一致性地变更工作产品(包括需求跟踪矩阵)。

6) 对变更进行确认。

7) 变更工作产品入库,变更基线。

很多组织把需求变更管理纳入配置管理的基线变更管理规程。无论是将需求变更单独管理,还是纳入配置管理一并管理,都应该认识到变更管理的共同之处:所有的变更都强调一致性,否则就是无效的变更。一致性的变更,狭义的理解是所有的变更都与变更的初衷并行不悖,广义的理解是所有的变更都要与用户需求保持一致。如果统一到这个认识上来,那么完全可以将需求变更管理作为变更管理的一项特例。

迭代开发可以降低需求变更的影响。迭代开发分批投入研发成本,每次研发成本投入时都实现当时最明确的一部分需求。迭代开发虽然没有减少需求变更,但是能够降低需求变更对研发成本的影响。

3 需求管理的软件工具

使用Word和Excel管理需求的好处是简单,弊端是效率提升不显著,并且不便于在多人和多团队之间协作。目前国内外流行的商业和开源需求管理工具有数十种之多,通常它们具有如下功能:

(1) 对需求进行结构化管理。所谓需求的结构化是指赋予需求必要的属性,并按照结构化数据的组织形式进行存储和管理。需求的结构化属性包括:标识、标题、版本号、接收时间、来源、类型、状态、优先级、内容、变更履历等。需求条目结构化以后,可以根据属性对需求进行分类、检索和分析。

(2) 对需求进行层次化管理。所谓需求的层次化是将需求分解为更细粒度的条目,形成层次化的结构关系。例如,可以将需求分解为史诗、故事、子故事或者系统需求、软件需求、部件需求、模块需求等。底层需求条目默认继承上级条目的依赖关系,修改下级条目的依赖关系会同步更新上级条目。

(3) 建立和显示需求追踪关系。工具能够存储和维护需求追踪关系,并用多种视图直观地显示局部或整体的关联关系。某些工具还具有变更建议功能,当某一个条目被更改后,能够根据追踪关系自动地搜索关联条目,提示或通知用户。

(4) 管理变更。工具能够在不同角色之间定义流程和表单,实现完整的需求变更申请、审批和通知流程。某些工具还具有基线管理功能,能够对比基线差异。

(5) 状态统计。工具能够跟踪和统计需求的状态(例如:已提出、已接受、已批准、已实现、已验证、已删除、已否决等),生成统计图表,便于管理人员从需求实现的角度掌握项目进展。

在商业竞争和开源社区的推动下,需求管理工具推陈出新。一些需求管理工具是项目管理套件的一部分,另一些工具支持扩展,能够与其他管理软件协同实现需求到任务计划、需求到测试、需求到缺陷的跟踪管理功能。一些工具向云端应用和移动端应用延伸。一些工具是DevOps工具链的组成部分。很多工具采用Web架构从而支持异地多团队协作开发。企业和组织可以根据自身需要,选择合适的需求管理工具。