面向对象的需求规格说明文档研究

陈杨杨 蒋建民

摘要：需求分析是软件开发过程中最重要的阶段，包括需求获取、分析、验证、需求规格说明等部分，其中需求规格说明是需求获取、分析、验证最终得到的结果描述，也是需求工程师、用户及系统设计师分析与理解软件系统的文档。统一建模语言（UML）是面向对象的标准建模语言，可利用其对系统进行需求分析。由于许多软件工程师和研究者对该语言有不同认识，导致采用UML建模的需求规格说明文档存在不同结构和内容，从而使相互交流变得困难。为避免该问题出现，提出面向对象的需求规格说明文档结构应遵从问题分析的逻辑性，并给出具体分析步骤及文档模板，解释了该模板中的每部分内容。最后利用提出的方法，以物流系统项目为例，详细说明了物流软件需求规格文档结构。

关键词：面向对象;需求规格说明;文档模板;UML;软件工程

DOI： 10. 11907/rjdk.191662

开放科学（资源服务）标识码（OSID）：

中图分类号：TP302

文献标识码：A

文章编号：1672-7800（2020）004-0102-05

Object-oriented Requirement Specification Documents

CHEN Yang-yang ， JIANG Jian-min

（Department o.[So.ftware Engineerirzg ， Fujian Normal University . Fuzhou 350007.Ch.ina ）Abstract ： Requirements analysis is the most iruportant phase in software development， which includes requiremenfs elicitation ， analy-sis.verification . and requirements specification. Requirements specification is the result of' requireiuents elicitation. analysis， and ver-ification. It is the document by ，，-hich requirement engineers. users and system designers to analyze and understand software system.The unified modeling language （UML） is a standard modeling language. Since dif'ferent sofh，-are engineers and researchers have theiro，，'n understanding， they offer the requirement specif'ication documents of different structures and contents with UML. This case canmake coruruunications more difficult. To solve the problem， this paper presents that the structure of' the object-oriented specif'icationdocument should comply with the logic of the analysis probleru ， and gives the specific analy sis steps and the docuruent teruplate， andexplains each part of the content of' the teruplate. rinally ， the proposed method is used to analyze the requirements document in detailby taking the logistics system project as an example.Key Words ： obj ect-oriented ; requirement specification ; document template ; UML ; software engineering

O 引言

需求分析在整個软件开发过程中起着关键性作用，需求分析阶段包括需求获取、需求建模、需求验证，以及最终的需求规格说明形成。目前已有文献研究多集中于需求获取、需求建模及需求验证[1-6]，很少有学者对需求规格说明文档进行深入研究。

需求规格说明文档是软件分析人员通过理解用户需求，采用文字、图形等方式表达出用户真实要求而形成的文档。软件需求是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，这些期望必须被所有开发人员理解、接受，才能进行设计、编码等开发活动。然而，用户需求多种多样，文字叙述与图表说明可能千差万别，并且这些描述方式、方法可能在软件开发过程中导致错误。为准确、完整地理解用户期望，人们通常采用一些标准化建模工具对其加以描述，从而形成开发人员和用户都能理解、接受的文档材料，这就是需求规格说明。需求规格说明文档在软件开发过程中是最重要的文档之一，不同的软件组织、公司都有白己的文档格式和内容要求，因而导致了很多问题，比如因难以相互理解从而限制了交流等。特别是采用面向对象的开发方法，同时利用统一建模语言（UMI[7]）工具，导致相关问题更加突出。国标GB9385-1988[8]和GB/T 8567-2006[9]也没有给出可行的具体规范。本文通过大量实验研究，给出基于UML的面向对象的需求规格说明文档模板，并讨论该文档模板结构与内容，以及其在文档中的排列顺序。

1 相关工作

软件开发过程涉及很多重要因素，比如设计前的需求分析、项目策划、过程管理等。针对软件开发过程，不同文献关注点不同。文献[10]注重软件开发库管理，并提出一系列策划方案;文献[II]对项目策划到项目实现全过程进行分析;朱锐等[12]。研究软件开发过程中的数据挖掘方法，但这些都未涉及到需求分析。

软件需求是软件项目开发的基础与起点，在整个软件开发过程中至关重要。文献[2]论述了软件需求的重要性，软件需求分析与管理对后续开发工作起到了引领作用，是项目成功的关键。

目前众多学者对需求分析方法进行了研究，如文献[1]论述了UML建模设计;文献[3]研究利用白然语言和必要图形进行需求分析，并使用一般人不易理解的软件需求分析T具避免需求的二义性;邱会鲁等[4]提出一种基于业务驱动的需求分析方法;文献[5]利用UML进行建模，但采用结构化方法进行需求分析;文献[6]介绍如何在网站信息系统中进行需求分析。然而，在需求分析时也会出现一些问题，文献[13]指出需求分析过程出现的一些问题及应对策略;文献[14]同样从需求工程出发，总结相关问题，同时介绍一些验证准则。当需求获取与建模结束后，需求分析文档尤为重要，其能够帮助需求工程师、用户、系统设计师理解系统功能。目前，大部分需求分析研究关注点都集中在需求获取与建模上，而很少对需求文档规范进行研究。因此，本文提出一种面向对象的需求文档书写规格，对利用UML建模的文档按照问题分析的逻辑性进行规范论述，从而使软件开发者更好地理解项目需求。

2 文档可读性与问题分析逻辑性

文字的主要功能是向大众传达作者意图及各种信息，要达到这一目的，必须考虑文字的整体表达效果，给人以清晰的视觉印象。因此，任何文档中的文字均应避免繁杂零乱，使人易认、易懂，切忌为了写文档而写，忘记了文字的根本目的是为更好、更有效地传达作者意图，表达某方面主题和构想。

好的文档应具有良好的结构和可读性，软件开发文档也不例外，但软件开发文档具有一定特殊性。因此，文档应如何写作？怎样布局？采用哪些现有工具辅助表达撰写人员意图和现实情况？解决这些问题都是非常困难的。统一建模语言（UML）是面向对象的标准建模语言，虽然有当今最完善的建模T具，但其并没有介绍如何在需求规格说明和系统没计说明中利用这些工具。不同专家在撰写软件工程书籍时都有白己理解，因此不同书籍中提供的需求规格说明与系统设计说明文档的结构和内容存在较大差别。研究还发现，很多文档存在结构不清、内容表达不完整的情况，且使用UML 工具的先后顺序也较为混乱。

为解决这些问题，需要有大家能接受的统一标准度量的文档结构和内容，以下将论述文档可读性与问题分析逻辑性是否能作为确定文档结构和内容的依据。文档可读性是指文档能尽快让读者了解作者文档撰写的意图，而分析问题的逻辑性则是人们分析问题时思维的先后顺序。软件设计的特殊性在于要求人们认识世界不能从单一视角对待问题，不同视角之间并没有直接逻辑关系。比如需要了解某件实物（如茶杯），从结构上看知其外部和内部形状，也知道外观颜色，但人们描述它是先描述颜色还是先描述结构，这是很难把握的。同样，软件分析和设计工具有许多是不同视角的建模工具，软件开发人员也很难在使用建模工具上作出正确决定。例如，设计一个两部电梯协同工作的系统，很多书籍最喜欢用状态图进行建模，但可以用活动图建模或其它方式建模吗？该问题仍然比较难以回答。但通过分析问题的逻辑关系，也许能够作出正确决定。本文以一個UML中顺序图（sequence diagrams）[7]为例，顺序图中有对象和类，很多人对先识别类还是先识别对象存在分歧，但从分析问题步骤来看，只有找到所有对象后，才能将相似对象归为同一类，从而确定类。由于建立类的主要目的是重用，显然需要先识别对象，再确定类。同样，必须先画对象图，再作类图。由此可见，软件文档可以人们分析、理解问题的先后逻辑关系为主线，作为文档结构。

另一方面，文档每部分内容可以用UML T具（图）和其它图形或表格进行简要描述，引导读者从总体上尽快把握该部分内容，并尽快理解其中感兴趣的部分，进而花费较少时间即能读懂整个文档，这就是文档的可读性。

面向的需求规格说明文档模板是按分析问题的逻辑性建立的文档结构.具体表现为：①收集用户要求，即了解项目业务过程;②使用用例视图获取需求;③通过分析用户要求和用例视图识别出对象，建立对象图;④通过分析将相似对象归为同一类，进而识别出类，并建立类图。

该步骤作为需求规格说明文档结构的主线，考虑了运行需求、界面需求、性能需求等其它需求，从而形成文档模板结构。在内容方面，整个文档与每部分都是按照“先总体、后具体”的要求安排内容，从而提高文档的可理解性与可读性，便于用户和软件开发人员阅读。该模板的格式和内容不仅能系统、精确、全面地展示用户需求，而且还考虑了以下目标：①方便用户、分析人员和设计人员理解与交流;②支持需求的快速确认;③能控制需求进化过程，即增加需求不会改变文档整体结构。3模板结构

中文需求规格说明文档模板一般来白国标GB9385 -1988。81和GB/T8567-2006[9]，英文需求规格说明文档模板来白标准化组织，如IEEE、ANSI等，而一些教科书[15]及公司也根据白己的需求提出了不同模板。在合适的时候，每个组织都应根据实际情况开发出适合自身文化、所期望的读者、软件系统类型等各方面情况的需求规格说明文档[16]。

需求规格说明文档模板定义了文档结构，并给出针对文档中每一节内容的详细指南，这些指南便于开发人员按步骤进行书写，对于准确、完整地表达用户需求有着十分重要的意义。笔者经过多年研究，结合上述标准，并参考其它模板，提出完全符合面向对象思想的需求规格说明书，图l给出了该模板整体框架。

3.1项目引言

需求规格说明文档的项目引言要求说明编写目的、该文档位于哪一个软件配置基线之上、项目关键术语定义与标识，以及参考引用资料。

编写目的需要说明项目要达到的目的和范围，并指出预期读者。

目前开发过程一般是迭代过程，需求规格说明文档不是仅有一份，而是随着迭代过程轮转需要有多个版本的需求分析文档，每次撰写文档前需要说明该文档是基于以前哪个版本的文档改进或提高的，这就是基线说明。

在特定情况和条件下，人们对文档中使用的专业术语有不同称谓，该情况可能导致对文档内容的错误理解，从而影响设计与编码。为避免该情况出现，需要对专门术语名称进行定义与标识，使所有阅读该文档的读者有统一认识。

引用的参考资料是根据国标GB/T8567-1988[13]所述，可能包括：①本项目经核准的计划任务书或合同、上级机关批文;②属于本项目其它已发表的文件;③本文件中各处引用的文件、资料，以及所用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源，但其中更重要的是本项目会议纪要、备忘录和内部涉及本项目的其它义档，这些参考资料是用户提出需求的基础和系统分析人员的分析依据，缺一不可。

3.2需求概述

需求概述是从总体上描述需求，叙述该软件开发意图、应用目标、作用范围以及其它应向读者说明的软件开发背景材料;说明被开发软件与其它相关软件之间关系;列出本软件的最终用户特点，充分说明操作人员、维护人员的教育水平和技术专长，并为识别行为者（ Actor）17作准备。该部分也需要列出本软件开发工作的经费限制、开发期限等方面内容。

3.3需求规定

该部分是需求的核心，包括功能需求、数据需求、运行需求及其它需求4部分。

一般而言，功能需求是软件需求最核心的部分，只有确定了功能需求才能确定其它需求，如数据、性能等方面需求。本规格说明要求先简明扼要地叙述总体功能要求，并采用总体用例图进行描述。紧接着具体、详细地叙述每个用例，其格式一般参照Cockburn[17]格式：①用例名称，以动词开头命名为宜;②简要描述，说明该用例主要功能;③执行者（Actor）;④前置条件;⑤事件流;⑥后置条件。

其中，复杂的事件流一般利用有“泳道”的活动图进行辅助描述，该描述有利于导出设计阶段的顺序图。

这里需要说明的是，顺序图不适用于需求阶段建模，主要是因为很难被用户理解，并且其包含设计思想，也不利于需求获取。

数据需求主要确定业务数据，即确定业务对象和业务类，可以用对象图和类图进行建模，但这些图不是业务数据的完整定义，每个业务对象或类需要作进一步解释、说明，特别是对象和类的属性内容应该作重点描述。一些专家认为数据需求就是识别出实体类及其关系，但该观点存在片面性，一般认为其它非实体类也必须加以考虑，这是因为需求越详细越好，非常详细的需求必然会涉及到一些非实体对象，因此这些非实体对象也会被描述。数据需求在模板中包括3部分内容：①用例、对象与类的关系;③类的描述;③类与类的关系。用例与对象可以用一个表格列出每个用例可能由哪些对象承担功能，从而识别出对象，再根据对象找到类，该表格如表1所示。但考虑到对象实例数目较多，可以简化对对象的描述。

“类的描述”部分内容特别需要以文字说明对象和类的属性及其之间的关系。类图可以表明类的结构和类与类的关系，但也需要详细的文字说明。也即是说，对象图和类图在文档中仅是辅助文字说明，这一点需要引起重視。

在叙述功能需求和数据需求后，其在软件总体结构和运行时的相对位置是怎样的？这就是运行需求问题，包括硬件方面的网络和设备情况，以及软件方面的软件支撑系统和该产品可能的部署情况。该部分能使用户从物理结构上了解本产品将来的具体情况，从而更好地提出需求。可以采用UML部署图进行描述，也需要用传统网络拓扑图表明产品在网络上的可能运行情况。

其它需求部分内容很多，界面需求和性能需求通常是其中的重点。如今界面需求也越来越多样化[19]，并且有一系列标准[20]。界面需求可定义产品如何与用户交互，该部分能帮助用户更快地理解产品。可以说需求阶段的界面就是本产品最初的原型，根据原型开发模型，需求界面能帮助软件开发人员获取需求，同时界面必须与需求分析时的用例建模保持一致，文献[21]说明了这一点的重要性。界面需求首先需要用图形表明各界面关系，比如如何从登录界面进入主界面，以及从主界面进入其它界面。该界面关系图没有统一格式，可以根据具体情况白由处理，只要简洁、直观即可。针对每个界面需要有必要的文字说明，说明进入该界面与进入其它界面的条件。

不同应用领域对性能的要求不同。从狭义上讲，性能需求是指软件产品完成各种任务的速度。从广义上讲，性能需求包括系统的可靠性、有效性、吞吐量等方面。安全性需求是指用户在系统控制下对信息的存取权限，用户可以被赋予数据受限存取或操作系统行为的权利。其它需求约束是指政策、法律等方面需求。

3.4尚未解决的问题

该部分是叙述任何影响项目成功，但在文档其它部分没有讨论的问题，既可以包括当前系统范围外的一些在今后需要实现的需求，也可以是系统在一定条件下可能导致的潜在问题或失误，比如部署不正确可能引发灾难性后果等。这些问题可能是开放性问题，无法解决，但必须列出以供阅读者参考，令其加以重视。

3.5 附录

附录A的术语表不但包含第一部分的定义和标识涉及到的术语，而且包含正文中需要重视的常用术语。术语表是一个词汇表，其定义了需求文档中的术语、简称和缩写。这些术语有助于理解文档中的其它有用信息，对术语的错误解释和理解都是非常有害的。

附录B是需求的原始资料目录。一般来说，用户提供的原始资料是多种多样的，需要整理并编目保存，为了便于查询，在此给出目录，供阅读规格说明文档的人员参考。

4应用实例

福建省某大型物流集团ERP系统是本文研究团队参与开发的一个具体软件项目，该项目进行了近半年的需求调研与分析，形成了较为完善的需求规格说明，该需求规格说明就是遵循本文模板的基本结构和主要思想撰写而成的。由于商业秘密限制，本文只给出中间版本的一部分，没有给出最终版本。下面提供文档的目录结构。

第一章项日引言…….

…………..5

一编写目的～……….

…………..5

二基线…….

…………..5

三参考资料………….

…………..5

第二章需求概述…….

…………..5

一系统目标………….

…………一5

二组织状况………….

…………..6

（一）组织机构总体结构图…….

…………..6

（二）各部门人员与职责……….

…………..7

三用户的特点……….

…………..13

四假定的约束……….

…………..13

第三章需求规定…….

…………..14

一总体需求………….

…………..14

（一）软件总体结构….

…………一l4

（二）业务流、资金流和信息流需求…………………l5

（三）决策支持需求….

…………..19

二功能需求………….

…………..21

（一）业务部………….

…………..2l

（二）配送中心……….

…………..45

（三）仓储部………….

…………..69

（四）统计部………….

……-94

（五）结算部………….

…………..109

（六）客服部………….

…………..119

（七）集团车管部…….

…………一l35

（八）安全办………….

…………..150

（九）保险中心……….

…………..160

（十）市场部………….

…………一l75

（十一）办公室和人事部……….

…………一l88

三数据需求………….

…………一l89

（一）基础数据要求….

…………..189

（二）主要表单……….

…………一l95

四运行需求………….

…………..200

（一）网络和设备需求………….

……-200

（二）支持软件与部署需求……，

……-202

五其它需求………….

……-202

（一）界面需求……….

…………..202

（二）性能需求……….

……-203

（三）安全需求……….

……-203

（四）操作需求……….

…………..205

（五）其它需求约束….

…………..205

第四章尚未解决的问题……….

…………..206

一需求问题………….

…………..206

二技术问题………….

…………..206

三附录…….

…………..206

（一）附录A：业务术语….

……..206

在该ERP系统中仅软件合同金额即达近百万元，历时近3年才最终完成。尽管最终完成的系统仍存在一些问题，但需求分析文档描述的业务过程是非常完善的。需求分析规格说明至今成为系统维护的重要文档之一。

5 结语

本文通过讨论文档可读性与分析问题逻辑性的关系，提出面向对象的需求规格说明文档结构应遵从分析问题的逻辑性，从而使读者以一种容易接受的思维方式阅读需求规格说明文档;接着给出了文档模板，该模板列出需求文档的写作顺序与包含的主要内容，实际上是给出需求规格文档的主要目录，详细解释了模板中每部分内容，以及写作要求与注意事项;最后用一个具体软件开发项目进行了实验验证。

该面向对象的需求规格说明文档不但利用UML中的用例图、对象图、类图、部署图进行建模，而且利用了非UML图和表格，如网络拓扑图、界面调用关系图和用例、对象与类的关系表格进行建模。需要补充说明的是，评价需求规格说明文档好坏的标准有正确性、无歧义性、完全性、可验证性、一致性、可理解性、可修改性和可追溯性等方面，在需求分析的文档结构和内容中已有考虑，但还需加强。

参考文献：

[1]李俊，王加阳.基于UML规范的建模工具研究与设计[J].软件导刊，2009，8 （4）：44-46

[2]金铁，张勇，杨涛.软件需求管理方法研究[J].軟件导刊，2012，11

（4）：13-14.

[3]傅瑞军，张明安，李春雷，等.一种快速需求分析方法[J].软件导刊，2012，11（4）：42-44

[4]邱会鲁，赵卫东，邵秀秀，等基于业务驱动的需求获取方法[J].软

件导刊，2015，14 （1）：4-7

[5]唐翠娥，陈小文.LML用例建模在信息管理系统需求分析中的应

用[J].软件导刊，2016，15（ 2）：115-117.

[6]林龙健.网站信息需求分析[J].软件导刊，2016（11）：165-167

[7]RLMBALCH J，JACOBSON I，BOOCH G.OMC unified modelinglanguage【OMC U ML）[Z]. Superstructure， Version 2.5.1， 2015

[8]国家标准化管理委员会GB9385-1988计算机软件需求规格说明编制指南[M].北京：中国标准出版社，1988.

[9]国家标准化管理委员会GB/T8567-2006计算机软件文档编制规范[M].北京：中国标准出版社，2006.

[10] 章文娟，李涛，陈红，等.一种软件开发库的工具化管理方法[J].软件导刊，2018，17（ 5）：46-48.

[11]戴牡红.软件开发过程训练的平台构建[J].软件工程，2018（1）：32-34.

[12]朱锐数据驱动的双层次软件过程挖掘方法[J]软件学报，2018，29（11）：221-249.

[13]戴昌裕，杨增强.软件需求工程中常见问题及解决办法[J].软件导刊，2009（3）：39-40

[14]杨洁.软件项目管理中的关键问题分析及对策[J].计算机产品与流通，2017（9）：38-38.

[15] LESZEK A M.需求分析与系统设计（用UML开发信息系统） [M]金芝，译北京：机械工业出版社，2003

[16]中华人民共和国信息产业部.SJ/T 11291-2003面向对象的软件系统建模规范第3部分：文档编制[M]北京：电子工业出版社，2003.

[17]COCKBURN A. Writing E⑧ective use cases[M]. Addison Wesley，New York.2001

[18]国家标准化管理委员会GB/T8567-1988计算机软件文档编制规 范[M].北京：中国标准出版社，1988.

[19]孙馨露.基于用户情感需求的电子商务网站界面设计探究[J].通讯世界，2017（ 11）：23-24.

[20]何文，谢晨晖地铁运营服务设备人机界面需求标准[J]都市快轨交通，2017（4）：110-113.

[21]SINNIG D. CHALIN P. KHENDEK F. Use case and task models： anintegrated development methodology and its formal foundation[J]ACM Transactions on Software Engineering and Methodology

（责任编辑：黄健）

收稿日期：2019-05-08

基金项目：国家自然科学基金项目（61772004）;福建省自然科学基金项目（2018J01777）

作者简介：陈杨杨（1994-），女，福建师范大学软件工程系硕士研究生，研究方向为形式化方法;蔣建民（1972-），男，博士，福建师范大

学软件工程系教授、硕士生导师，研究方向为形式化方法。