1引言
需求规格说明是软件分析人员通过理解用户的需求，采用文字和图形等方式表达出用户的真实要求而形成的文档。软件需求是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，这些期望必须被所有开发人员理解、接受，才能进行设计、编码等开发活动。然而用户的需求多种多样，文字叙述与图表说明可能千差万别，并且这些描述方式、方法可能在软件开发过程中导致错误。为准确、完整理解用户的期望，我们通常采用一些标准建模工具来描述，从而形成开发人员和用户都能理解、接受的文档材料，这就是需求规格说明。
面向对象的需求需求规格说明文档在软件开发过程中是最重要的文档之一，不同的软件组织、公司有自己的文档格式和内容要求，这会产生很多问题，比如很难相互理解，从而限制交流。特别是采用面向对象的开发方法，同时利用统一建模语言（UML[2]）工具，这些问题更加突出。国标GB-[5]和GB/T-[3]也没有给出可行具体规范。本文通过大量的实验和研究，给出了基于UML的面向对象的需求规格说明文档模板，并讨论了该文档模板结构和内容，以及它们在文档中排列先后顺序的原因。
2文档可读性与分析问题的逻辑性
文字的主要功能是在视觉中向大众传达作者的意图和各种信息，要达到这一目的必须考虑文字的整体表达效果，给人以清晰的视觉印象。因此，任何文档中的文字应避免繁杂零乱，使人易认，易懂，切忌为了写文档而写，忘记了文字的根本目的是为了更好、更有效的传达作者的意图，表达某方面的主题和构想。
好的文档具有良好的结构和可读性，软件开发文档也不例外。但软件开发文档也具有特殊性，是一种高智力设计文档，由于这种特殊性存在，文档如何写作？怎样布局？采用哪些现有工具来辅助表达撰写人员的意图和现实事实？解决这些问题都是非常困难的。总所周知，统一建模语言（UML）是集大成者，虽然有当今最完善的建模工具，但是它并没有统一思想介绍如何在需求规格说明和系统设计说明中利用这些工具，不同的专家在撰写软件工程书籍时都有自己理解，因此不同的书籍中提供的需求规格说明和系统设计说明文档的结构和内容存在较大差别。经过我们研究，发现很多文档存在结构不清，其内容可能表达不完整，使用UML工具的先后顺序也较为混乱。
为解决这些问题，一般认为需要有大家能接受的统一的标准来度量文档的结构和内容。这里我们提供一个问题：文档的可读性与分析问题的逻辑性是否能作为确定文档结构和内容的依据？
文档的可读性就是文档能尽快让读者知道撰写文档的作者的意图，而分析问题的逻辑性则是人们分析问题时思维的先后顺序，即步骤。软件设计的特殊性在于要求我们认识世界不能从单一的视角对待问题，不同的视角之间并没有直接的逻辑关系。比如需要了解某件实物（如，茶杯），从结构上看知道其外部形状和内部形状，也知道外观颜色，但我们描述它，是先描述颜色，还是先描述结构？这很难把握。同样，软件的分析和设计工具有许多是不同视角的建模工具，软件开发人员也很难在使用建模工具上做出正确的决定。例如，设计一个两部电梯协同工作的系统，很多书籍最喜欢用状态图来建模，可以用活动图建模或其它的建模吗？这个问题仍然比较难回答。但是从分析问题的逻辑关系，我们也许能做出正确的决定。这里我们举一个关于UML中顺序图（sequencediagrams)[2]的例子。顺序图中有对象和类，很多人对先识别类还是先识别对象存在分歧，但从分析问题的步骤来看，只有我们找到所有的对象后，再将相似的对象归为同一类，从而确定类。大家都知道，建立类的主要目的是重用。显然，我们需要先识别对象，再确定类。同样，我们只有先画对象图，再作类图。由此可见，软件文档可以以我们分析、理解问题先后逻辑关系为主线，作为文档的结构。
另一方面，文档的每部分内容可以用UML工具（图）和其它图形或表格从总体上简要描述该部分的内容，使读者从总体上尽快把握该部分内容，引导他们对其中感兴趣部分尽快理解，进而让他们花费很少时间读懂整个文档。这就是文档的可读性。
面向的需求规格说明文档模板是按分析问题的逻辑性建立的文档结构，具体表现为:
（1）收集用户要求，即了解项目的业务过程；
（2）使用用例视图获取需求；
（3）通过分析用户要求和用例视图识别出对象，建立对象图；
（4）通过分析将相似的对象归为同一类，进而识别出类，并建立类图。
该步骤作为需求规格说明文档结构的主线，并考虑了运行需求、界面需求、性能需求等其它需求，从而形成了下面的文档模板结构。在内容方面，整个文档与每部分都是按“先总体、后具体”的要求安排内容，使文档的可理解性和可读性都有所提高，更利于用户和软件开发人员阅读。该模板的格式和内容不仅能系统、精确和全面地展示用户需求，而且还考虑了以下目标：（1）方便用户、分析人员和设计人员理解和交流；（2）支持需求快速确认；（3）能控制需求进化过程，即增加需求，不会改变文档的整体结构。
3模板结构
中文的需求规格说明文档模板一般来自国标GB-[5]和GB/T-[3]，英文的需求规格说明文档模板来自标准化组织，如IEEE、ANSI等。而一些教科书（比如[7]）和一些公司也根据自己的需要提出不同的模板。在合适的时候，每个组织都应该根据实际情况开发适合自身实践、文化、所期望的读者、软件系统类型等情况的需求规格说明文档（比如[6]）。
需求规格说明文档模板定义了文档的结构，并给出了关于文档中每一节内容的详细指南，这些指南便于开发人员按步骤书写，对于准确地、完整地表达用户的需求有十分重要的意义。我们通过多年的研究，结合上述标准，并参考了其它模板，提出了完全符合面向对象思想的需求规格说明书。表1给出了这个模板的整体框架，对其中内容的解释将在下面进行。
表1：需求分析模板
3.1项目引言
需求规格说明文档的项目引言要求说明编写目的、该文档位于哪一个软件配置基线之上、对该项目的关键术语进行定义与标识，以及参考引用的资料。
编写目的的内容需要说明项目要达到的目的和范围，并要指出预期的读者。
目前的开发过程一般是迭代过程，需求规格说明文档不是仅仅一份，随迭代过程轮转需要有多个版本的需求分析文档，每次撰写文档之前需要说明该文档基于以前哪个版本的文档改进或提高的，这就是基线说明。
由于特定的情况和条件，人们对文档中用到的专业术语有不同的称谓，这种情况可能导致对文档内容的错误理解，从而影响设计和编码，为避免该情况出现，需要对专门术语名称进行定义和标识，使所有阅读该文档的读者有统一的认识。注意这里的术语一般该项目特定的术语，是附录中术语表的子集。
引用的参考资料是基于国标GB/T-[4]所述，可能包括，a.本项目的经核准的计划任务书或合同、上级机关的批文；b.属于本项目的其他已发表的文件；c.本文件中各处引用的文件、资料、包括所用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源，但更重要的为本项目的会议纪要、备忘录和内部涉及本项目的其它文档，这些参考资料是用户提出需求的基础和系统分析人员分析的依据，缺一不可。
3.2需求概述
需求概述是从总体上描述需求，叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料；说明被开发软件与其他有关软件之间的关系；列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长；特别要为识别行为者（Actor）[2]作准备。该部分也需要列出制约本软件开发工作的经费限制、开发期限等方面的内容。
3.3需求规定
该部分是需求的核心，包括功能需求、数据需求、运行需求和其他需求四部分。
一般说来，功能需求是软件需求最核心的部分，只有确定了功能需求才能确定其他需求，如数据、性能等方面的需求。本规格说明要求先简明扼要地叙述总体功能要求，并用总体用例图来描述。紧接着分别具体、详细地叙述每个用例，其格式一般参照Cockburn[1]格式：
（1）用例名称，以动词开头命名为宜；
（2）简要描述，说明该用例的主要功能；
（3）执行者（actor）；
（3）前置条件；
（4）事件流；
（5）后置条件。
其中，复杂的事件流，一般用有“泳道”的活动图来辅助描述，这样描述有利于导出设计阶段的顺序图。
这里需要说明的是，顺序图不宜用于需求阶段建模，主要是因为它很难被用户理解，并且它包含设计思想，也不利于需求获取。
数据需求主要确定业务数据，即确定业务对象和业务类，可以用对象图和类图来建模，但这些图不是业务数据的完整定义，每个业务对象或类需要进一步解释、说明，特别是对象和类的属性内容应该重点描述。一些专家认为数据需求就是识别出实体类及其关系，这种观点存在片面性，一般认为其它非实体类也必须考虑，这是因为需求越详细越好，非常详细的需求必然会涉及到一些非实体的对象，因此这些非实体对象也会在这里被描述。数据需求在模板中包括三部分内容：（1）用例、对象与类的关系，（2）类的描述，（3）类与类的关系。用例与对象可以用一个表格列出每个用例可能由那些对象来承担功能，从而识别出对象，再根据对象找到类。该表格如下（表2）。但考虑到对象实例数目较多，可以简化对对象的描述。
表2：用例、对象和类的关系
“类的描述”这部分内容特别需要以文字说明对象和类的属性，以及它们的关系。类图可以表明类的结构和类与类的关系，但也需要详细的文字说明。也就是说，对象图和类图在文档中仅仅是辅助文字说明，这一点一定要引起重视。
在叙述了功能需求和数据需求后，这些事物在软件总体结构和运行时的相对位置怎样？这就是运行需求问题。它包括在硬件方面的网络和设备情况，以及在软件方面支撑软件系统和该产品可能的部署情况。该部分能使用户从物理上了解本产品将来的具体情况，从而更好地提出需求。其中可以用UML的部署图来描述，也需要用传统的网络拓扑图表明产品在网络上的可能的运行情况。
其他需求部分内容很多，界面需求和性能需求一般情况下是重点。界面需求是定义产品如何与用户交互，该部分能帮助用户更快地理解该产品。可以说，需求阶段的界面就是本产品的最初的原型，根据原型开发模型，需求界面能帮助软件开发人员获取需求。界面需求首先需要用图形表明各界面的关系，比如从登陆界面如何进入主界面，从主界面如何进入其它界面，这个界面关系图没有统一的格式，可以根据具体情况自由处理，只要简单、直观即可。针对每个界面需要有必要的文字说明，说明进入该界面的条件和进入其它界面的条件。
不同的应用领域，对性能的要求不同。从狭义上讲，性能需求指软件产品的各种任务完成的速度。从广义上讲，性能需求包括系统的可靠性、有效性、吞吐量等方面。安全性需求指用户在系统的控制下对信息的存取权限，用户可以被赋予对数据的受限的存取或对系统行为操作的权利。其它需求约束是指政策、法律等方面的需求。
3.4尚未解决的问题
这部分是叙述任何影响项目成功，但在文档其它部分没有讨论的问题。这里既可以包括当前系统范围之外的一些可以在今后需要实现的需求，也可以是系统在一定条件下可能引发潜在的问题或失误，比如部署不正确可能引发灾难性后果。这些问题可能是开放性问题，无法解决，但必须列出，以供阅读者参考，并使他们重视。
3.5附录
附录A的术语表不但包含第一部分的定义和标识涉及到的术语，而且包含到正文中需要重视的常用术语。术语表是一个词汇表，它定义了需求文档中的术语、简称和缩写。这些术语有助于理解文档中其它有用的信息，对术语的错误解释和理解都是非常有害的。
附录B是需求的原始资料目录。一般来说，用户提供的原始资料是多种多样的，我们需要整理并编目保存，为了便于查询在此给出目录，供阅读规格说明文档的人员参考。
4应用实例
福建省某大型物流集团ERP系统是我们研究团队参与开发的一个具体软件项目，该项目进行了近半年的需求调研和分析，形成了较完善的需求规格说明，该需求规格说明就是遵循本文的模板的基本结构和主要思想撰写而成，可以从下面地址下载。由于商业秘密限制，我们只给出中间版本的一部分，没有给出最终版本。下面提供文档的目录结构。
第一章项目引言...........................................................................5
一编写目的.........................................................................
二基线.................................................................................
三参考资料.........................................................................
第二章需求概述...........................................................................
一系统目标.........................................................................
二组织状况.........................................................................
（一）组织机构总体结构图....................................
（二）各部门人员与职责......................................
三用户的特点...................................................................
四假定的约束.....................................................................
第三章需求规定...........................................................................
一总体需求.........................................................................
（一）软件总体结构..............................................
（二）业务流、资金流和信息流需求....................15
（三）决策支持需求..............................................
二功能需求........................................................................
（一）业务部..........................................................
（二）配送中心......................................................
（三）仓储部............................................................
（四）统计部............................................................94
（五）结算部...........................................................
（六）客服部...........................................................
（七）集团车管部....................................................
（八）安全办................................................
（九）保险中心............................................
（十）市场部................................................
（十一）办公室和人事部............................
三数据需求..............................................................
（一）基础数据要求....................................
（二）主要表单............................................
四运行需求..............................................................
（一）网络和设备需求................................
（二）支持软件与部署需求........................
五其它需求..............................................................
（一）界面需求............................................
（二）性能需求............................................
（三）安全需求............................................
（四）操作需求............................................
（五）其它需求约束....................................
第四章尚未解决的问题...................................................
一需求问题.............................................................
二技术问题.............................................................
三附录.....................................................................
（一）附录A:业务术语............................
该ERP系统仅仅软件合同金额近百万元，历时近三年才最终完成，尽管完成的系统仍存在一些问题，但需求分析文档描述的业务过程是非常成功的。需求分析规格说明至今成为维护的重要文档之一。
5结束语
论文通过讨论文档的可读性与分析问题的逻辑性的关系，提出了面向对象的需求规格说明文档结构应遵从分析问题的逻辑性，这样可以使读者以非常容易接受的思维方式阅读需求规格说明文档；接着给出了文档模板，该模板列出需求文档的写作顺序和包含的主要内容，实际上是给出了需求规格文档的主要目录，详细地解释了模板中每部分的内容，以及写作要求与注意事项；最后用一个具体软件开发项目进行了实验验证。
该面向对象的需求规格说明文档不但是利用了UML中的用例图、对象图、类图、部署图建模，而且利用了非UML图和表格，比如网络拓扑图、界面调用关系图和用例、对象与类的关系表格来建模。这里需要补充说明的是，评价需求规格说明文档好坏的标准有正确性、无歧义性、完全性、可验证性、一致性、可理解性、可修改性和可追溯性等方面的内容，在需求分析文档结构和内容中已有考虑，但还需加强。希望该文档模板能被软件企业和组织采纳，并在实践中进一步完善。
参考文献
[1]A.Cockburn.WritingEectiveUseCases.AddisonWesley,NewYork,
[2]J.Rumbaugh,I.JacobsonandG.Booch.OMGUnifiedModelingLanguage(OMGUML),Superstructure,Version2.5.1,August.
[3]GB/T-计算机软件文档编制规范，北京：中国标准出版社，
[4]GB/T-计算机软件文档编制规范，北京：中国标准出版社，
[5]GB-计算机软件需求规格说明编制指南，北京：中国标准出版社，
[6]SJ/T-面向对象的软件系统建模规范第3部分：文档编制
[7]LeszekA.Maciaszek著，金芝译.需求分析与系统设计（用UML开发信息系统），北京：机械工业出版社，
转载请注明：http://www.0431gb208.com/sjszjzl/3484.html
