【系统分析师】高分论文：论软件需求验证方法及应用

【摘要】
本文以我参与的某某清算平台建设项目为例，探讨了软件需求验证的方法及应用。该项目的目标是将第三方支付公司和银行之间的数据交互隔离并解耦，以利于央行对支付数据的风险监控诉求。该项目存在影响范围广、涉及单位多、性能要求高等难度挑战。在此项目中，我担任了系统分析师及架构师，参与了该项目的需求开发、系统设计和实现等工作。需求验证包括需求测试和需求评审，它们的工作是否科学、充分对需求开发阶段的工作影响很大，直接决定了系统开发的目标和可行性。需求验证分为需求测试和需求评审。系统分析师可以根据项目的特点和体量，来选取最合适的验证方法。在项目中熟练运用附求验证方法，才能保证需求的完整性、一致性和高服量，为后线续的系统设计、实现和测试提供足够的保障。基于我们的需求分析和验证上的工作，加之项目组我行上的不断努力，用户的全力配合，项目完成非常成功。

【正文】
随着电子商务的发展，线上支付领城在最近十年获得了爆发式增长，尤其是微信支付、支付宝两大巨头的出现，深刻影响了 人们的移动支付方式。“双十一”“618”等商峰场景的出现，标惠著互联冈支付领城己成为代表中因互联网发展规模的與型代表。公而，各支付公司为了发展代扣用户银行账户余额的业务，几乎接入了每一家大大小小的银行。支付公司和银行之间形成了“网状，的数据通信，引发了央行的特续关注，认为这种“网状”的数据通信不利于资金的监管、风险调控等，进而提出要在支付公司和银行之间设立“某某清算平台”，解糯并隔离银行和支付公司的直按通信，并设立风控机构，以期解决上述提出的各项问题。2023 年8月，作为系统分析师及架构师，我有幸参与并主导了这个国家级重点工程，并在项目中实践了软件需求验证方法及应用，得到了项目组成员的认可。下面重点闸述我在本项目中的实验及心得。

项目在经过需求开发的需求获取、需求分析、需求定义三个阶段后，得到了一份需求规格说明书 SRS，即进入了需求验证阶段。该阶段的目的是检查 SRS 中包含需求的正确性、完整性，避免在开发后期才发现需求存在问题，导致修复需求错误而产生额外的大量工作。目前需求验证的方法主要分为以下两个大类：
（1）需求测试。
由于需求开发阶段还没有真正可执行的系统，所以以功能为基础（SA 方法）或者从用例派生出来（00 方法）的测试用例可以帮助发现需求的许多问题。比如 SRS 中的纰漏、二义性、不一致性等。概念测试用例源于用户需求，重点反胦用例描述，完全独立于实现，以主备事件流的方式，把所有需求串起来，直至覆盖所有需求点。需求测试具体过程为：根据概念测试用例进行“概念”执行：根据测试结果快速修改对应的需求文档。
（2）需求评审。
需求评审是需求开发阶段结束前进行的技术评审，为项目的干系人提供在需求问题上达成共识的方法。评审类型分为正式评审和非正式评审。正式评审通常以集中会议的形式展开，邀请项目的所有干系人参会，一起对 SRS 中的所有需求描述做最后的审核和校验，其过程分为：计划、准备、评审、处理结果。而非技术评审是通过各种分散的形式“异步”进行评审，比如电子邮件、文件汇签等形式。

具体实际实践中，系统分析师会根据项目的大小和特点，实施不同的验证方法。由于网联平台项目本身是一个涉及面比较广泛、影响比较大的国家级工程；而且支付行业存在着复杂度高，业务广，用户基础规模大的特点。所以作为支付公司和银行的中间交易转接平台和清算平台，包含的功能点数量是巨大的。经过前期的需求定义阶段，产出的需求规格说明书 SRS 长达 500页。因此项目组经过讨论，决定采用了多种验证方法，互相结合使用来实施需求验证。具体实施过程如下：

一、成立需求测试小组，介入需求开发阶段
由于网联平台工程比较大，需求的获取、分析的工作量持续时间也比较长。为了及早发现需求上的问题，避免早期的错误在后期被“放大”导致难以纠正，项目组的测试团队在需求开发阶段，就成立了需求测试小组，并及早介入需求开发阶段。当分析师求分阶段产出成果时，需求测试人员就马上设计概念测试用例，验证产出测试结果，反馈给分析师，以便对问题及时进行修复。所以需求测试的工作提前开始，与需求分析工作并行展开的迭代式演化工作过程，分解了工作内容，很大程度上降低了工作的复杂度。

二、以功能需求为基础，设计概念测试用例
在需求分析阶段，项目系统分析师采用了结构化的分析方法。该方法的特点是自项向下、逐层分解功能点，直到最底层的功能点足够简单并容易解决。所以项目组的需求测试人员也相应地选用了以功能需求为基础的方法，来设计大量的概念测试用例。系统分析师的数据流图 DFD 每个层次，都设计了对应的测试用例描述。对于顶层的一般交易处理过程，相应的概念测试用例也体现出了通用的测试过程。例如交易的安全验证用例、交易的余额不足用例等。对于底层的具体交易处理过程，也有相应的更具体的测试用例，例如退款交易确保有对应的支付交易等。多维度、多层次的用例检查出了需求规格说明书上的一些功能冲突、流程不一致的错误，确保了系统分析工作的正确性，降低了潜在错误带来的成本风险。

三、和相关需求方保持沟通，发邮件进行非正式评审
当需求定义阶段结束，会得到一份需求规格说明书 SRS。由于并行的概念测试工作，SRS 消除了内部基础性的错误。由于网联的需求方包含了众多的银行和支付公司，分散在全国各地，所以有必要先以邮件的方式开展非正式评审，将 SRS 送审到各个需求方单位。得到各 个需求方单位的反馈后，评估各方给出的建议，仔细确定哪些问题需要纠正，哪些问题不需要纠正，并回复邮件给出充分、客观的理由和证据。对于需要纠正的问题，做好了卡片记录，提交到需求变更委员会，进行有效的需求跟踪。经过多轮的非正式评审，一份较完善的 SRS已经完成。

四、邀请央行加入最后的正式评审
在需求验证的最后阶段，SRS 经过多轮内部、内外联合的评审，各方人员基本对所有的需求点达成一致。但由于网联系统关系到央行的金融级风控需求，同时也要评估政策上所有需求点是香合规，以及确定满足央行对网联的期许，所以网联项目组決定发起一场正式评审会议。项目组首先邀请了央行以及支付司多位支付领域的专家加入评审团，并预先发给他们所有的 SRS 及其他资料：同时也再次邀请了关键的银行和支付公司代表参加会议。评审会议上由系统分析师逐顶讲解平台舍项需求，并充分听取央行和支付司专家们的建议。经过三天的议程，项目组对这份 SRS补充了道应政策法规的处理流程，及时纠正了具有潜在的递规风险项，最终网联顶目的需求f方案得到了各方的认可。

综合运用了上述的各项需求验证方法，在时间资源比较紧张的前提下，确定了每个需求的可行性，每个版本迭代的优先级，得出了一份比较完美的需求规格说明书 SRS，成为了项目组开发团队的需求基线，保证了接下来系统架构、系统实现等各阶段工作的顺利实施。网联平台上线以来得到了支付行业内的持续关注，由于功能比较完善，得到央行的认可，支付公司和银行不会有任何顾虑，并顺利地接入了该系统。系统也持续优化并升级扩展机房规模，在近些年的“双十一”和“618” 等场景下，经受了大并发的性能考验。这也充分说明了需求验证做得是否充分、正确，往往成为一个系统是否成功的关键所在。项目完成得比较成功，得到了公司管理层的高度认可，用户对项目也非常满意。