工程项目需求分析方法研究

摘  要： 传统工程项目的信息化和数字化日益成为软件开发行业的主要业务，而这类软件工程项目的开发和实施，由于业务方和开发方缺乏有效的沟通方法，其成果经常会有所欠缺。文章提出一套由架构师牵头，以架构设计思想和敏捷开发方法为基础，实战可行的需求分析方法，有效解决工程项目中业务难以沟通、难以深入的问题。

关键词： 软件工程; 需求分析; 架构设计; 敏捷开发

中图分类号：TP311          文献标识码：A     文章编号：1006-8228（2021）01-51-03

Research on requirements analysis of engineering project

Yu Yang

（Power China Huadong Engineering Corporation Limited， Hangzhou， Zhejiang 310014， China）

Abstract： The informatization and digitization in traditional engineering project have become the main business in software development industry. However， as a result of the in effective communication between business and developing aside， the achievement is always not very satisfying. In this paper， a practical method of requirements analysis is proposed， which is led by the architect and complies with the architecture design idea and agile development method， to effectively solve the problem that the business is difficult to communicate in-depth in engineering projects.

Key words： software engineering; requirements analysis; architecture design; agile development

0 引言

近年来，传统工程项目的信息化和数字化日益成为软件开发行业的一个主流方向，而这类软件工程项目的开发和实施，经常会差强人意。造成这一现象的原因，通常归结为两个方面：一方面是由于工程背景的甲方用户，普遍缺乏软件系统开发的通识，较难把自己的需求准确传达给乙方开发者;另一方面，乙方开发者普遍缺乏准确理解甲方需求的专业知识，导致在接收甲方需求的过程中产生偏差。在近年来的开发实践中，虽然甲乙双方越来越多的认识到这两方面原因，并投入了较多的力量来缓解这个问题，然而成效依然良莠不齐。究其原因，问题依然出现在需求分析环节，仅让甲乙双方互相加强对方的专业知识，并未带来显著和稳定的成效，需求分析方法依然存在较大的研究空间。

本文在这一背景下，结合作者自身软件开发经验和项目执行经验，提出了一种深入的需求分析方法，并在实际项目中取得了显著成效。

1 方法概述

对于软件开发团队而言，软件开发的全过程是：做什么->怎么做->做->成果检验->交付部署;其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期[1]。

在实际的软件项目开发中，“做什么”，“怎么做”和“做”这三个环节是紧密结合在一起的。“做”、“成果检验”和“交付部署”通常也会是一个持续交付过程。“成果检验”的内容一定会受到“做什么”的影响，在“做什么”阶段，也要考虑到如何部署和交付[2]。所以，软件开发的全过程，都是紧密结合在一起的[3]，也都离不开需求，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，造成工作的反复，影响整体开发效率。

基于此，需求分析的实施，围绕架構师这一角色开展[4]，基于架构师的视角和能力，将上述软件开发的全过程打造为有机的一体。相应的，以需求深度划分[5]，可以把需求分析分为三个层次：原始需求分析、面向应用的业务架构分析和面向开发的架构分析，经过这三个层次的需求分析后，其成果可以贯穿通用于软件开发的全过程，提供综合研发效能。

2 原始需求分析

原始需求是从用户及业务的角度可见或必须的需求，或项目团队经过初步挖掘后整理出来的、未经进一步提炼的需求。

如果拿做项目与做产品类比，原始需求类似于产品设计中的“用户故事”，由于原始需求既可以是开发者分析出来的，也可以是行业专家或目标客户/用户提出来的，原始需求可以不止步于“用户故事”，在该阶段做一定的业务逻辑的抽取和提炼，对接下来“业务架构”阶段的需求分析也有帮助，这两个阶段没必要确立一个严格的界限。

以多人博客系统为例，原始需求可以梳理如下：①要有所有文章列表;②能点击查阅文章;③能评论文章;④能创建新文章;⑤能编辑删除文章;⑥要有权限机制。

而对于更有经验的人而言，原始需求可能更加体系化：多人博客系统由前台展示子系统和后台管理子系统构成，两个子系统的功能分别分析。

⑴ 前台子系统

前台子系统对任何人可见，该子系统至少包含以下页面或功能：①文章列表+概要页面;②文章详情页面;③作者主页;④文章评论功能;⑤文章搜索功能;⑥侧边栏的目录、tag等博客经典功能。

⑵ 后台子系统

后台子系统只对登录用户开放，对多人博客而言，该子系统应该分用户组，为不同类型用户分配不同的权限，该子系统至少包含以下页面或功能：①用户登录或注册功能;②根据不同用户的权限，登录后看到不同的页面或功能;③创建新文章;④修改或删除文章;⑤维护博客名称描述等内容的功能。

原始需求分析的目标是需求的收集、整理和简单分析，为业务架构分析奠定基础。

3 面向应用的业务架构分析

面向应用的业务架构（下文简称业务架构）分析，是对原始需求的抽象和再提炼，在形成业务架构之前，首先要梳理清楚非功能需求和功能需求。非功能需求可以为接下来的面向开发的业务架构分析和软件架构设计铺路。功能需求又分为“显式的功能需求”和“潜在的功能需求”。如上一节列出的需求，均为显式功能需求;潜在的功能需求要从多个角度去考虑，如整理出用户组、权限对应的完整业务逻辑，属于可以推测并进一步开展工作的潜在功能需求，修改密码、个人信息、用户管理和忘记密码等功能，是上面漏掉的、但又会影响到系统完整性的潜在需求，而提供一个系统初始化接口的功能需求，是站在运维实施角度提出来的潜在需求。

做好业务架构，是为整个软件项目迈出坚实的第一步。业务架构是需求分析中最重要的阶段，经历了业务架构分析的过程，系统需求才能完成初步梳理。业务架构对软件系统开发也有重要影响。开发软件系统，通常要求具备充分的可扩展性[6]，而可扩展性，在需求分析阶段就奠定了基础，需求分析做的充分，系统可扩展性在很大程度上就确定了，当增加新功能时，系统能否扩展功能，还是系统的某些功能要打破重来，业务架构阶段就能看出端倪。比如，若要在多人博客系统中增加用户社交功能，可以把该功能插入到用户模块和个人模块中去，也可以新增社交模块，前者会打破原有业务逻辑，从而改变已有功能的代码实现，而后者更多是在新的模块中梳理业务逻辑，开发新功能，前者重构多于扩展，而后者扩展多于重构。所以如果业务架构设计的具有扩展性，相当于软件系统先天具备较强的可扩展能力。

4 面向开发的业务架构分析

业务架构为软件系统的开发奠定了基础，在实际的软件开发项目中，通常可以在此基础上让需求分析再往前迈一步，将“做什么”和“怎么做”紧密联系起来，承上启下，这个阶段的需求分析可以称之为“面向开发的业务架构分析”，下文简称开发架构。

开发架构也可以纳入“怎么做”的环节，但笔者认为把它作为需求分析的最后阶段，对整个项目过程而言更有效率。这部分工作依然是围绕需求分析展开的，前文所述的需求分析工作通常开发者也会参与，面向应用和开发这两阶段的需求分析本身就是衔接在一起的连续过程，如果把这一步工作从需求分析中抛离，项目进行到“怎么做”或“做”的阶段时，发现现实（代码逻辑和系统实施）和理想（业务逻辑）不一致的概率会更大，开发过程中可能会有更多关于“需求分析没做到位”的扯皮，甚至不得不重新返回需求分析阶段再次梳理需求，这都会带来本可避免的项目进度延误。

开发架构作为需求分析的最后一步，能有效减少因为没有“向后看”带来的需求分析不充分问题，能够把需求和实现更紧密的结合在一起，它在一定程度上对业务架构做了进一步的细化，也在一定程度上影响了业务架构的最终成果。

开发架构不必刻意设计的与业务架构不同，但其关注点已经是为“怎么做”和“做”这两阶段铺路了，“怎么做”是架构师负责的，本阶段的需求分析也由架构师来牵头和落实更合适。

开发架构分析的主要内容有两点：①再次提炼和抽象业务功能;②确认和完善非功能需求。

⑴ 再次提炼和抽象业务功能

简单的系统，业务架构和开发架构可能基本上是一致的，而复杂系统，业务架构分析所提炼的业务功能，是有可能被再次提炼的，如OA系统中，我们从业务架构的视角看，可以整理出如“计划管理”、“任务管理”和“表单管理”等模块，这些模块的业务流程都会包含“审批流程”、“短信通知”、“邮件通知”等基础功能，这些功能在每个业务模块中，功效类似，但在业务架构的视角和颗粒度上，不一定能清晰的表达出来，但梳理功能架构的时候，可以将此作为从相关业务模块的核心业务逻辑中剥离的非核心业务逻辑，作为基础功能模块放到功能架构的恰当位置。

OA系统中，可能还存在一些功能模块，涉及到上传附件、预览或下载附件等功能，我们可以把“文件存储管理”独立出来作为基础功能模块来实现;架构师还会进一步分析，文件有大有小，大文件存储、管理和消费的业务逻辑和零散小文件类似业务逻辑的实现及性能上可能会有很大差别，导致不同的应用场景对应不同的实现方案，文件存储管理要可能会设计为多个模块。

因此，面向应用的业务架构分析阶段，虽然能够做到把业务需求和逻辑完整的整理出来，但不一定能把构成每个业务逻辑的单位功能一一提炼和组织起来，也可能会因为缺乏功能开发和系统性能上的背景知识，忽视某些需要单独处理的功能或模块的特殊性，为系统的稳定性和可扩展性埋下隐患，所以，在面向应用的业务架构分析之后，在开发之前，一定要做“面向开发的业务架构分析”。

⑵ 确认和完善非功能需求

非功能需求，通常要考虑系统的存储能力、吞吐能力和容错能力等，最常见的就是我们常说的“日活”或“并发”，这些性能指标会影响到我们的软件架构。确立非功能需求，一方面是为了保证我们的软件架构能够支撑起我们的业务量，另一方面也是为了防止我们对软件架构做过度设计，为系统开发带来不必要的复杂度。另外，这也为系统的性能测试提供了依据。

5 结束语

工程项目的软件开发，需求分析由架构师牵头，按照原始需求分析、面向应用的业务架构分析和面向开发的业务架构分析三步走，是一种可应用于实践的需求分析方法，能有效解决业务方和开发方难以准确沟通业务、难以深入分析和实现业務的问题。

该方法已应用于笔者的软件工程实践中，相比于笔者以往的工程项目开发经历，应用该方法后，需求分析成果能切实深入到位，既能满足业主的预期，也让研发更容易理解到位，很大程度上避免了甲乙双方在需求认知上的偏差，有效提高了软件交付物的实际成效。

参考文献（References）：

[1] 张祎.软件生命周期中的需求分析方法论建构[J].电子科学技术，2017.4（3）：37-40

[2] 吴争荣，包新晔，尹立彬，梁耀文.基于敏捷开发理念的软件系统持续交付研究[J].电子世界，2020.7：80-81

[3] 谢鹏飞.敏捷开发在项目开发和管理中的实践和应用[J].电子世界，2020.7：80-81

[4] 孙昌爱，金茂忠，刘超，田丽从.一种基于UML的面向对象需求分析方法[J].航空学报，2003.1：75-78

[5] 周绍景，唐艳，邱发林.浅谈软件需求分析方法[J].科技信息，2007.2：37-37，119

[6] 赵承乾.软件需求分析方法创新分析[J].计算机光盘软件与应用，2013.3：61-61

收稿日期：2020-09-04

作者简介：于洋（1987-），男，山东泰安人，硕士研究生，工程师，主要研究方向：计算机软件开发，系统架构。