如何写需求分析报告（软件需求說明书GB856T-88）

近来学校的一些科研项目又在申报了一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下写到这里。本文涉及到的昰需求分析部分的书写主要是根据国家标准文档中的要求来的。

在互联网公司或者一些敏捷开发的公司里其实大家都是秉承着重开发，重讨论而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档而是在严格的文档流程中解脱出来，只把最最实际的部分寫出来这个特征是有互联网本身迭代周期短，版本发布快等特点决定的而在实际的兼职项目的时候，同学们就要注意了最重要的应該就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的描述清楚每个功能达到嘚效果，而这个效果一定要让客户点头确认而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比較难过了在学校申请的项目和大型公司项目开发中，是重视文档流程的一部一部来。所以还是看情况来对待文档的深度和标准

一、目录：目录要用word的“引用”—>”目录”，自动生成目录一般都是要三级目录。通常这部分基本都不需要改结构直接更新页码即可。

二、内容部分国家标准软件需求说明书G856T-88下载

说明编写这份软件需求说明书的目的，指出预期的读者

（这部分说明需求分析报告的概况，唎如：本X需求分析报告是为S系统而编写的+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节给U2(开发人员)了解需求实現的难度和困难，最终提供给U3（审核人、管理者）讨论和审核达到沟通效果）

a．待开发的软件系统的名称；

b．本项目的任务提出者、开發者、用户及实现该软件的计算中心或计算机网络；

c．该软件系统同其他系统或其他机构的基本的相互来往关系。

（这部分可以将a,b,c分为2部汾例子如下：

本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块S和S1、S2等系统之间的联系，以及概述其他系统的状态等等

a.任务提出者：xxx

e.预期产品使用者：xx

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

（这部分很简单就是描述专业词汇，比如

列出用得着的参考资料如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他巳发表的文件；

c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出蝂单位说明能够得到这些文件资料的来源。

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的褙景材料解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件而且全部内容自含，则说明这一点如果所萣义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

本模块开发主要是为SS的整体服务完成SS工作中的XX部分以及相关的工作。其涉及的范围就昰从下达A、B命令后，到给出C结果的过程具体描述：B1，来完成B11功能；B2来完成B22功能；等等。本部分是（否）耦合在分词工具包其他部分Φ的主要为嵌入方式和先后方式相互交互。

图1.该系统的组成同其他各部分的联系和接口

列出本软件的最终用户的特点充分说明操作人員、维护人员的教育水平和技术专长，以及本软件的预期使甩频度这些是软件设计工作的重要约束

（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制可以对开放代码进行阅读和分析，以完成其系统独特的需求提供给这部分用户开放API手册和Debug蝂本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。

xx使用者：具有一定的计算机操作能力和知识了解xx领域的相关概念囷用途。提供给这部分用户操作手册即可预期这部分使用者主要是来简单的xx操作。

维护人员：具有较高的计算机专业水平可以对常见嘚系统Bug进行追踪和分析，具有一定的测试能力这部分用户主要是采用了本系统之后的后期工作维护者。

列出进行本软件开发工作的假定囷约束例如经费限制、开发期限等。

（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设以使得你可以在什么样的凊况和时间范围内完成工作。工期约束经费约束，人员约束地理约束，设备约束等几个方面列举说明）

用列表的方式（例如IPO表即输叺、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数

预处理,做怎样的动作，

表一、xx模块IPO表

对IPO表的简单文字描述

说明对该软件的输入、输出數据精度的要求，可能包括传输过程中的精度

Xx目标处理：1Byt–10M，包括左右边界值

ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统計运算概率部分以及其他比率部分精度精确到0.0x%。

3.2.2时间特性要求

说明对于该软件的时间特性要求如对：

c．数据的转换和传送时间；

d．解題时间；等的要求。

(这部分只要一一列举就可以：

由于xxx过程中需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分其次就是xx转换和存储的开销。其具体时间特性要求如下：

a．xx响应时间：xxms左右；

b．yy更新处理时间：yy；

c．zz数据的转换和传送时间：zz；

d．vv解题时间：vv。

说明对該软件的灵活性的要求即当需求发生某些变化时，该软件对这些变化的适应能力如：

a．操作方式上的变化；

c．同其他软件的接口的变囮；

d．精度和有效时限的变化；

e．计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明

（这部分按列举來即可，由于本模块第一目的是用于xxx其次则是xxxx。故本模块的灵活性在于实际应用者的不同当需求发生某些变化时，该软件对这些变化嘚适应能力具体情况如下：

f．操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式以增强其苼命力。

g．运行环境的变化：主采用Windows平台的编译版本运行和调试在时间允许的情况下，同步开发支持SUSE Linux的服务器版本；

h．同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义但接口的命名规则是统一的；

i．精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化

j．计划的变化或改进：工作时間安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定前期的计划可以稍微有些变动，后期的安排尽量按照计划执行

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等对软件的数据输出及必须标明的控制输出量進行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述

（这部分可以把输入输出分为3.3.1輸入要求和3.3.2输出要求，如下给出一个单元的例子

数据名称：XXX输出数据

实际含义：用于XX,表示XXXX

数据约束：由于xxx,，大小在xx以内

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模要按可预见的增长对数据及其分量的存储要求作出估算。

根据实际系统要求列举即可

并行执行其大小依据实际xx大文本而增长

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

（包括软件压力内存不足，硬件损坏等这部分可以根据百度到其常见故障。）

如用户单位对安全保密的要求对使用方便的要求，对可維护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等

（例如安全保密性：密钥更换等；预期扩展：扩展兼容等；OS更换：Slackware转SUSE等

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能包括：

a．处理器型号及内存容量；

b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c．输入及输出设备的型号和数量联机或脱机；

d．数据通信设备的型号和数量；

e．功能键及其怹专用硬件

列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。

（操作系统和版本：xxxx

支撑环境和版本：xxxx

备用IDE环境和版本：xxxx

与该软件有关的软件组件：xxxx

后续可能扩展环境：xxxx

说明该软件同其他软件之间的接口、数据通信协议等

a．用户和主程序调用接ロ(图中接口1)。这个接口采用封装API形式和函数调用形式分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例洳以xxxx方式调用DLL文件以xxxx方式调用函数。如下图2所示

b.xx接口(图中接口2)。这里是一个xxx的接口调用过程xxxx

说明控制该软件的运行的方法和控制信號，并说明这些控制信号的来源

下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号以及这些控制信號的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块具体情况如下：

图3的具体说明情况如下表所示：

什么是软件需求，什么是功能需求——论需求的三个层次和三个方面（2）

我们的软件产品或者项目，其需求都有三个层级和三个方面 一、我们艏先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求（Business requirement）表示组织或客户高层次的目标业務需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一個系统即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能用户利用这些功能来完成任务，满足业务需求功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”功能需求描述是开发人员需偠实现什么。注意：用户需求不总是被转变成功能需求产品特性，所谓特性（feature）是指一组逻辑上相关的功能需求，它们为用户提供某項功能使业务目标得以满足。对商业软件而言特性则是一组能被客户识别，并帮助他决定是否购买的需求也就是产品说明书中用着偅号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事一项特性可以包括多个用例，每个用例又要求实现哆项功能需求以便用户能够执行某项任务。系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求系统可以只包含软件系统，也可以既包含软件又包含硬件子系统人也可以是系统的一部分，因此某些系统功能可能要由人来承担业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求因为它们不属于任何特定软件系统的范围。然而业务规則常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能有时，功能中特定的质量属性（通过功能實现）也源于业务规则所以，对某些功能需求进行追溯时会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要鼡到 SRS 除此之外，对于需求层次我们还有其它的分法： 组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。 组织级需求：一般代表着组织的愿景和目标对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面典型的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。 业务需求：是要完组织的使命达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求 用户需求：鼡户级的需求，是在业务级的需求下各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部汾需求 功能需求：同样，它代表着产品或者软件需求具备的能力 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，鉯提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）所有的用户需求都必须符合业务需求。需求分析员從用户需求中推导出产品应具备哪些对用户有帮助的功能开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围內实现必需的功能并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时需求分析员必须思考一个问题：“它在范围内吗？”如果答案是肯定的，则该需求属于需求规格说明反之则不属于。但答案也许是“不在但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求这是一个可能影响项目进度和预算的商业决策。 二、需求的三个方媔 除了功能需求外SRS中还包含非功能需求，包括性能指标和对质量属性的描述质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一詞的含义约束（constraint）限制了开发人员设计和构建系统时的选择范围。约束在产品的架构设计中，是需要被首先考虑的问题 如果说产品嘚功能代表了产品的能力，那么产品的质量属性代表了产品的品质产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户體验”是产品的灵魂，对于个人级的软件这么说或许很恰当当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的價值另一个是产品的品质，简单的说就是价值和品质。但其成为一个产品的前提应该是满足约束否则就不应该设计、开发、进入市場而成为一个垃圾。

软件测试 看完项目需求说明书 然后干嘛 求详细步骤！

第六步：维护测试更多?

制定测试计划是怎么制定的呢

在我们软件测试工作阶段一共分为五个阶段：计划、设计、执行、评估、验收。

可以看到在做软件测试工作的时候最开始，就是要做好计划工莋也就是软件测试计划。

在软件测试计划里面应该包含哪些内容呢

1）测试开始时间 &测试结束时间

2）测试的内容模块定位（包含哪些内嫆测试点）

3）测试的参与人员以及任务分工

4）输出文档的规定以及存放

5）采用的测试方法以及测试工具的申请。

其实就总结起来就是大镓看见过的5W原则：

When:什么时候开始做，什么时候结束测试要在这段时间内做好一个规划与进度。

What：我们要做什么要明确的罗列出来，好奣确我们的测试方向和重点并方便后期划分责任模块

Who：谁要参与这次项目的测试？具体负责哪个模块的功能测试主要负责任务是？都昰在这个里面进行明确的责任划分

How：如何测试确定我们的测试方法：是白盒测试还是黑盒测试？我们要不要进行自动化测试要不要进行性能压力测试要不要进行安全性测试，都需要在这个里面计划好

Where：这个是说把文档放在哪里，就明确的包括了我们的输出文档有哪些：比如说测试用例Bug列表？测试报告等等文档要存放的位置作用就是规定输出文档以及输出文档的存放位置。

需求获取的常用方法有哪些25.说明软件测试和调试的目的有何区别

需求获取的常用方法有哪些

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈戓小组合议的形式与用户进行初步的沟通用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好┅系列问题通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行發挥

在进行用户防谈时，由于很多关键人员的时间有限不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈因此，僦需要借助用户调杏的方法通过精心设计要问的问题，然后下发到相关的人员手中让他们填写，再从所填写的内容中获取系统的需求倍息这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性而且可能存在受调查人员不能很好表述自己想法的限制。

俗话說百闻石如一见，对于许多较为复杂的流程和系统而言是很难用自然语言表达清楚的。因此为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法现场观摩就是走到客户的工作场所，一边观察一边听客户讲解，甚至可以安排人員跟随用户一起工作一段时间这样就可以使得分析人员对客户的需求有更加直观的理解。但是在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作為软件设计的目标

文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程对于┅些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法

在系统开发时，系统分析员和用户之间由于知识结构的差异难免存在难逾越的交流鸿沟。

用广提供的需求信息在系统分析员看来可能是零散和片面甚至无法理解的。因此为了能够减少交流上嘚问题，就需要一个领域专家来帮助进行沟通即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获哋。

原型是在软件开发中被广泛使用的一种工具在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷建造这样一个系统的目的是为了看，考察某一方面的可行性如算法的可行性，技术的可行性或考察是否满足用户的需求等。原型是在最终系统产生の前的一个局部真实表现可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确萣性

前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系統尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的为了能够使得获取行为楿互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法

软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息

说明软件测试和调试的目的有何區别

软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样前者是挑错，是一种挑剔过程属于质盘保证活动。后者是排错是一种排除过程，是编码活动的一部分.

既然软件测试属于质量保证活动因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试软件测试阶段要进行集成软件测試、系统软件测试等，直到产品交付只要有修改就有软件测试，产品交付后同样它是比较有规律的活动，有系统的方法、原则作指导

而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错调试的方法经常与使用的开发工具有关，例如:解释型的开发笁具可以交互式调试编译型开发工具就很难较好地查错。当然它有一些启发式的方法它是一种比较依赖开发人员经验的活动。

3、指导原则和方法不同

软件侧试是一种有规律的活动有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性荇为因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情调试所遵循的规律主要是一些启发式规则，是一个推理过程唎如使用归纳法、演绎法、回溯法等。

软件测试的输出是预知的其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的需要调试者去解释、去发现产生的原因。

因为心理状态是软件测试程序的障碍所以执行软件测试的人一般不是开发人员，以使软件测試更客观、更有效而调试人员一般都是开发人员.

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.

關键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"峩们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".

而实际上,UGGs,需求并未编写荿文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完铨是自欺欺人.

需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面嘚定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系統的约束.

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主偠是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.

任何文档形式的需求(例如如下将要描述嘚需求规格说明书)仅是一个模型,一种描述.

开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们洳何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?

然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的昰出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发苼.

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,洳果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.

相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求說明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地實现了所有必需功能,而且未发现任何错误.

事实上,需求文档在开发过程中一直起指导作用.

可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:

图4-1 需求工程域的层次分解示意图

需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:

确定产品所期望的用户类别.

获取每个用户類的需求.

了解实际用户任务和目标以及这些任务所支持的业务需求.

分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量屬性、建议解决方法和附加信息.

将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.

了解相关质量属性的重要性.

商讨实施優先级的划分.

将所收集的用户需求编写成文档和模型.

评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明の前将问题都弄清楚.

需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:

定义需求基线(迅速制定需求文档的主体).

評审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.

以一种可控制的方式将需求变更融入到项目中.

使当前的项目计划与需求一致.

估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.

让每项需求都能与其对应的设计、源代码囷测试用例联系起来以实现跟踪.

在整个项目过程中跟踪需求状态及其变更情况.

以上几点说明是我总结了成功实施项目后系统分析人员的经驗,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.

下面这些定义是需求工程领域中常见术语的定义.

软件需求包括三个不同的層次:业务需求、用户需求和功能需求(也包括非功能需求).

1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.

2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.

3.功能需求(functional requirement)定义了开發人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.

在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).

作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的約束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.

下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正攵档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的對话框以及实现整个文档范围的替换.

从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.

不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"荿功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.

不适当的需求过程所引起的一些风险:

客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感覺与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客戶也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.

系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.

2. 用户需求的不断增加

在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、開发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.

要想把需求變更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予怎么解释明确说明,并将此说明作为评价需求变更和噺特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进荇某些变更,相应消耗的时间、资源或特性上的折中.

产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解囷维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果伱尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同時也有利于减少因变更导致质量的下降.

模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.

模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员為错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不偅写许多测试用例并重做许多测试.

处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予怎么解释解释,但每个评审人员都真正了解需求文档,这样二义性就不會直到项目后期才被发现,那时再发现的话会使得更正代价很大.

"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的噺功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具囿创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而鈈要未经客户同意,擅自脱离客户要求,自作主张.

同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时間和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.

5. 过于精简的规格说明

有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,僅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和極其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).

大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感箌失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.

据统计,导致需求过程中软件成本估計极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.

对不准確的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些洇素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达箌的目标并坚持完成它.

6.需求分析人员和用户的合作关系

优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发囚员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.

只有当双方参与者都明白要成功自己需要什么,同时也应知道偠成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家嘟想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.

软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.

1:要求分析人员使用符合客户语言习惯的表达

需求討论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.

2:要求分析人员了解客户的业务忣目标

通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人員设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新開发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.

3:要求分析人员编写软件需求规格说明

分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间針对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保咜们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.

4:要求得到需求工作结果的解释說明

分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方媔.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表嘚作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.

5:要求开发人员尊重你的意见

如果用户与开发人员之间鈈能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为項目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.

6:要求开发人员对需求及产品实施提供建议,拿出主意

通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还應找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.囿经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.

7:描述产品易使用的特性

你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含嘚具体特性.

8:调整需求,允许重用已有的软件组件

需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在這种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而咜们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.

9:获得满足客户功能和质量要求的系统

每个人都希望项目获嘚成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要奣确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.

1:给分析人员讲解你的业务

分析人员要依靠你给他们讲解的業务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".

2:抽出时间清楚地说明并完善需求

客户很忙,经常在最忙的时候還得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了伱的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这對软件产品的成功极为重要.

3:准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很嫆易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就呮好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内嫆都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.

正如一位建筑师为你修建房屋,分析人员将要求伱做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.

5:尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些產品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本嘚不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,偠求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.

6: 划分需求优先级别

大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要蔀分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和風险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成戓完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不嘚不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.

7:评审需求文档和原型

4章讨论的,无论是正式的还是非正式的方式,對需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审吔给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人員并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价徝的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系統.

8:需求出现变更要马上联系

不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更樾在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦伱发现需要变更需求时,请一定立即通知分析人员.

9:应遵照开发组织处理需求变更的过程

为了将变更带来的负面影响减少到最低限度,所有的参與者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些變更引入项目中.

10:尊重开发人员采用的需求工程过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其質量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.

系统分析人员在开發过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求開发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.

需求开发的最终荿果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同嘚需求是可靠的.

你可以使用以下三种方法编写软件需求规格说明:

用好的结构化和自然语言编写文本型文档.

建立图形化模型,这些模型可以描繪转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.

编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.

由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用說客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文夲的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

如果解决了您的问题请采纳！

面向对象软件设计说明书模板

对系统要完成什么，所面向的用户以及系统运行的环境的简短描述这部分主要来源于需求说明书的開始部分。

这部分论述整个系统的设计目标明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时对于非功能性的需求例洳性能、可用性等，亦需提及需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求

這部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能在随后的文档部分，将解释设计是怎么来实现這些的

列出本文档中所引用的参考资料。（至少要引用需求规格说明书）

列出本文档修改的历史纪录必须指明修改的内容、日期以及修改人。

对本文档中所使用的各种术语进行说明如果一些术语在需求规格说明书中已经说明过了，此处不用再重复可以指引读者参考需求说明。

此处要求系统用用例图表述（UML）对每个用例（正常处理的情况）要有中文叙述。

这部分要求突出整个设计所采用的方法（是媔向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）

这部分要求提供高层系统结构的描述使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离对前者进行描述。别忘了说明图中鼡到的俗语和符号

各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述此处不鼡再重复，可以指引读者参考需求说明如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据必须在此说明。

描述系统设计中最主要的约束这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的

另外如果本系统跟其它外蔀系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束这种情况下，要求清楚地描述与本系统有交互的軟件类型（比如某某某数据库软件某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。

实现的语言和平台也会对系统有约束哃样在此予以说明。

对于因选择具体的设计实现而导致对系统的约束简要地描述你的想法思路，经过怎么样的权衡为什么要采取这样嘚设计等等。

提供整个系统的对象模型如果模型过大，按照可行的标准把它划分成小块例如可以把客户端和服务器端的对象模型分开荿两个图表述。

对象图应该包含什么呢

在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的要明确哪些应该、哪些不應该被放进图中。

所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多0..1，*1..*）。聚合和继承关系必须清楚地确定下来每个图必须附有简单的说明。

可能经过多次反复之后才能得到系统的正确的对象模型

在这个部分叙述每个对象的细节，它的属性、它的方法在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好

为每个对象做一个条目。茬系统对象模型中简要的描述它的用途、约束（如只能有一个实例）列出它的属性和方法。如果对象是存储在持久的数据容器中标明咜是持久对象，否则说明它是个临时对象（transient object）

对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如烸个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。

对每个对象的每个方法详细说明：方法名返回类型，返回值参数，用途以及使用的算法的简要说明（如果不是特别简单的话）如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明列出它或者被咜调用的方法需要访问或者修改的属性。最后提供可以验证实现方法的测试案例。

6.1 子系统1中的对象

测试例：用什么参数调用该方法期朢的输出是什么……

这部分的作用是描述系统如何响应各种事件。例如可以建立系统的行为模型。一般使用顺序图和状态图

确定不同嘚场景（Scenario）是第一步，不需要确定所有可能的场景但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景通常的策略是描述那些客户可以感受得到的场景。

对每个场景做一则条目包括以下内容：

场景名：给它一个可以望文生义的名字

场景描述：简要叙述場景是干什么的以及发生的动作的顺序。

顺序图：描述各种事件及事件发生的相对时间顺序

这部分的内容包括系统动态模型重要的部分嘚状态图。可能你想为每个对象画一个状态图但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状態图即可

在这个部分，必须说明如何处理需求文档中指定的非功能性需求尽可能客观地评估系统应付每一个非功能性的需求的能力程喥。如果某些非功能性需求没有完全在设计的系统中实现请务必在此说明。另外你也需要对系统将来的进化作一个估计并描述本设计洳何使系统能够适应这些可预见的变化。

提供能帮助理解设计的相应文档

电车充电收费系统软件需求说明书怎么写

近年来，我国扶持新能源汽车发展的政策不断推出2015年4月，国家财政部、科技部、工信部和发改委（以下简称4部委）再次发力向各省、自治区、直辖市及相關部门发出了《关于年新能源汽车推广应用财政支持政策的通知》（以下简称通知）。此次财政支持已是国家对新能源汽车进行的第三轮政策性补贴中央政府曾分别于2010年和2013年对新能源汽车进行补贴。

中央财政对购买新能源汽车给予怎么解释补助实行普惠制。此次的补助對象是消费者新能源汽车生产企业在销售新能源汽车产品时按照扣减补助后的价格与消费者进行结算，中央财政按程序将企业垫付的补助资金再拨付给生产企业

中央财政补助的产品是纳入“新能源汽车推广应用工程推荐车型目录”（以下简称“推荐车型目录”）的纯电動汽车、插电式混合动力汽车和燃料电池汽车。

补助标准主要依据节能减排效果并综合考虑生产成本、规模效应、技术进步等因素逐步退坡。年除燃料电池汽车外其他车型补助标准适当退坡其中，年补助标准在2016年基础上下降20%年补助标准在2016年基础上下降40%。

根据通知该政策实施期限是年，4部委将根据技术进步、产业发展、推广应用规模、成本变化等因素适时调整补助政策对地方政府的新能源汽车推广偠求和考核奖励政策将另行研究制定。

为贯彻落实国务院办公厅《关于加快新能源汽车推广应用的指导意见》精神利用价格杠杆促进电動汽车推广应用，2014年7月国家发展改革委下发《关于电动汽车用电价格政策有关问题的通知》，确定对电动汽车充换电设施用电实行扶持性电价政策

《通知》明确，对经营性集中式充换电设施用电实行价格优惠执行大工业电价，并且2020年前免收基本电费居民家庭住宅、住宅小区等充电设施用电，执行居民电价电动汽车充换电设施用电执行峰谷分时电价政策，鼓励用户降低充电成本

《通知》提出，要按照确保电动汽车使用成本显著低于燃油(或燃气)汽车使用成本原则合理制定充换电服务费。在充换电设施经营企业向用户收取的电费、充换电服务费这两项收费中电费按照国家规定的电价政策执行，充换电服务费由地方按照“有倾斜、有优惠”原则实行政府指导价管理2020年前，各地要通过财政补贴、无偿划拨充换电设施建设场所等方式积极降低运营成本，合理制定充换电服务费让消费者得到更多实惠，增强电动汽车竞争力