北京夜场模特领队
如何写需求分析报告（软件需求说明书GB856T-88）
近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。
一、目录：目录要用word的“引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。
二、内容部分。国家标准软件需求说明书G856T-88下载
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）
1.2背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c．该软件系统同其他系统或其他机构的基本的相互来往关系。
（这部分可以将a,b,c分为2部分，例子如下：
1.2.1项目概况
本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。
1.2.2任务分配
a.任务提出者：xxx
b.软件开发者：xx
c.产品使用者：xx
d.文档编写者：xx
e.预期产品使用者：xx
）
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
（这部分很简单，就是描述专业词汇，比如
1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。
2. Word2,解释。。。
）
1.4参考资料
列出用得着的参考资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
（
本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能；等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。
图
图1.该系统的组成同其他各部分的联系和接口
）
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。
xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。
维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。
等等
）
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
（例如：
INPUT输入
PROCESS处理
OUTPUT输出
LOAD负载量
A
预处理,做怎样的动作，
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模块IPO表
对IPO表的简单文字描述。
）
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
（例如：
Xx目标处理：1Byt–10M，包括左右边界值。
yy精度范围：….
ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。
）
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a．响应时间；
b．更新处理时间；
c．数据的转换和传送时间；
d．解题时间；等的要求。
(这部分只要一一列举就可以：
由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下：
a．xx响应时间：xxms左右；
b．yy更新处理时间：yy；
c．zz数据的转换和传送时间：zz；
d．vv解题时间：vv。
等等
)
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
（这部分按列举来即可，由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下：
f．操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。
g．运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；
h．同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；
i．精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。
j．计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。
等等
）
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
（这部分可以把输入输出分为3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。
XXX输出
数据名称：XXX输出数据
实际含义：用于XX,表示XXXX
数据类型：Character(字符串)
数据格式：XX
数据约束：由于xxx,，大小在xx以内
）
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
（
根据实际系统要求列举即可
Name名称
Number数量
Size大小
Increase增长
词典xx
xx
xxxx
并行执行，其大小依据实际xx大文本而增长
）
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。）
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
（例如安全保密性：密钥更换等；预期扩展：扩展兼容等；OS更换：Slackware转SUSE等
）
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
（列举说明即可）
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
（操作系统和版本：xxxx
支撑环境和版本：xxxx
备用IDE环境和版本：xxxx
与该软件有关的软件组件：xxxx
后续可能扩展环境：xxxx
）
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
(例如：
a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。
图2.软件接口调用图
b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx
)
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
(例如：
下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下：
图3 .控制流程图
图3的具体说明情况如下表所示：
Name模块名称
Method运行方式
Signal控制信号
Forward控制去向
主程序模块
运行框架
用户调用或运行
1.调用xx模块
2.调用xx方法
3.调用标准输出模块
xxx模块
xxx
xxx调用
Xxx模块
)
附录：软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88
操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc
测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc
测试计划（GB8567——88）.doc 图1.doc
概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc
开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc
可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc
模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc
软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc
在软件开发中，需求分析阶段产生的主要文档是什么？
当然是需求规格说明书啊。描述客户为什么要做这个软件，描述软件都实现什么功能，如何实现，实现是都需要什么样的条件和数据。以及软件的运行环境及对软件的硬性要求。
什么是 软件项目技术指标
技术指标包含功能指标和非功能指标：
功能指标就是你开发的东西有些什么功能，能不能满足客户或者别人的需求；
非功能指标就是你开发的东西的性能指标，比如平均响应时间、兼容性、可在多平台上运行window及linux等、可扩展性、可靠性（可以容错，能够恢复，平均没有故障时间）等等
怎么写一份APP开发功能需求表
1．1编写目的
· 阐明开发本软件的目的；
1．2项目背景
· 标识待开发软件产品的名称、代码；
· 列出本项目的任务提出者、项目负责人项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户；
· 说明该软件产品与其他有关软件产品的相互关系。
1．3术语说明
列出本文档中所用到的专门术语的定义和英文缩写词的原文。
1．4参考资料（可有可无）
列举编写软件需求规格说明时所参考的资料，包括项目经核准的计划任务书、合
同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档，以及相关产品的软件需求规格说明。
在这里应该给出详细的信息，包括标题、作者、版本号、发表日期、出版单位或资料来源。
2．项目概述
2．1待开发软件的一般描述
描述待开发软件的背景，所应达到的目标，以及市场前景等。
2．2待开发软件的功能
简述待开发软件所具有的主要功能。为了帮助每个读者易于理解，可以使用列表或图形的方法进行描述。使用图形表示，可以采用：
· 顶层数据流图；
· 用例UseCase图；
· 系统流程图；
· 层次方框图。
2．3用户特征和水平（是哪类人使用）
描述最终用户应具有的受教育水平、工作经验及技术专长。
2．4运行环境
描述软件的运行环境，包括硬件平台、硬件要求、操作系统和版本，以及其他的软件或与其共存的应用程序等。
2．5条件与限制
给出影响开发人员在设计软件时的约束条款，例如：
· 必须使用或避免使用的特定技术、工具、编程语言和数据库；
· 硬件限制；
· 所要求的开发规范或标准。
3．功能需求
3．1功能划分
列举出所开发的软件能实现的全部功能，可采用文字、图表或数学公式等多种方法进行描述。
3．2功能描述
对各个功能进行详细的描述。
4．外部接口需求
4．1用户界面
对用户希望该软件所具有的界面特征进行描述。以下是可能要包括的一些特征：
· 将要采用的图形用户界面标准或产品系列的风格；
· 屏幕布局；
· 菜单布局；
· 输入输出格式；
· 错误信息显示格式；
建议采用RAD开发工具， 比如Visio，构造用户界面。
4．2硬件接口
描述系统中软件产品和硬件设备每一接口的特征，以及硬件接口支持的设备、软件与硬件接口之间，以及硬件接口与支持设备之间的约定，包括交流的数据和控制信息的性质以及所使用的通信协议。
4．3软件接口
描述该软件产品与其有关软件的接口关系，并指出这些外部软件或组件的名字和版本号。比如运行在什么操作系统上，访问何种类型的数据库，使用什么数据库连接组件，和什么商业软件共享数据等。
4．4通信接口
描述和本软件产品相关的各种通信需求，包括电子邮件、Web浏览器、网络通信协议等。
4．5故障处理
对可能的软件、硬件故障以及对各项性能而言所产生的后果进行处理。
5．性能需求
5．1数据精确度
输出结果的精度。
5．2时间特性
时间特性可包括如下几方面
·响应时间；
·更新处理时间；
·数据转换与传输时间；
·运行时间等。
5．3适应性
在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，软件的适应能力。
6．其他需求
列出在本文的其他部分未出现的需求。如果不需要增加其他需求，可省略这一部分。
7．数据描述
7．1静态数据
7．2动态数据
包括输入数据和输出数据。
7．3数据库描述
给出使用数据库的名称和类型。
7．4数据字典
对于数据流图、层次方框图中出现的所有图形元素在数据字典中都要作为一个词条加以定义，使得每一个图形元素都有唯一的一个清晰明确的解释。
数据字典中所有的定义必须是严密的、精确的，不可有二意性。
7．5数据采集
·列出提供输入数据的机构、设备和人员
·列出数据输入的手段、介质和设备；
·列出数据生成的方法、介质和设备。
8．附录
包括分析模型，待定问题图表等。
想开发app的话可以联系我 微信号：qidi-27773
论文高手进：软件开发需求分析的认识和理解
应用软件开发中的需求分析及方法 软件工程一般具有以下基本活动：软件描述：软件的功能以及软件操作上的约束定义；软件设计和实现：软件要按照描述来设计；软件有效性验证：软件要被确定是有效的，能完成预期的应用；软件进化：软件按应用需要的变更来进化。其中，软件描述的目标是，确定软件系统需要哪些服务以及开发和运行期间受到哪些约束，对服务和约束的发现、分析、建立文档、验证活动，现在常称为需求工程。为此，笔者谈谈如何进行需求分析及方法。 一、 需求的过程 需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的。 需求工程本身就是一个过程，这个过程将产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。 （一）需求过程的四个主要阶段 1、可行性研究：指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是初步的，结果就是要得出结论，该系统是否值得进行更细致的分析。 2、需求的导出和分析：这是一个通过对现有系统分析、与潜在用户讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。 3、需求描述：需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。 4、需求有效性验证：这个活动检查需求实现、一致和完备。在这个过程中，可发现需求文档中的错误，并加以修正。 当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。 （二）需求的进一步认识 1、软件系统需求 常常分为功能需求、非功能需求和领域需求。 功能需求：包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。 非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求源于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互操作，还包括如安全规章、隐私权利保护等外部因素。 领域需求：这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。 2、软件需求文档 也称软件需求描述（SRS），是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。 二、方法 （一）问题域（应用领域） 是指问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。例如，对一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。 到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。 （二）需求分析 通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。对于这一重要任务其特性如下： 分析关注问题域及对其建立的模型，而不是解系统； 主要目标是要获得对问题域及存在于其中的问题本质的理解； 分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。 （三）方法论 方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面： 问题域的结构，根据其子域及其相互间的关系； 问题域数据，语法和语义方面 问题子域的内在属性和行为； 问题域中的重要事件及现象； 需求，解系统在问题域中应产生的效果。 具体有以下三个方法： 1、结构化分析（SA） 结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。 2、 面向对象分析（OOA） 面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。面向对象分析基本思想是：如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。 OOA（面向对象分析）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计（如果是OOD开发的话）。 OOA的大致方法是：标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类间的关系建模。 3、 面向问题域分析（PDOA） 面向问题域的分析（PDOA）是一种新技术。PDOA更多的强调描述，而较少的强调建模。描述大致划分为两个部分：一部分关注于问题域，而另一部分关注于解系统的待求行为。一般建议同时有两个单独文档：第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表（即需求）；第二文档（规格说明书）包含的是对解系统的待求行为的描述以解决需求。其中第一文档才是通过做分析产生的；第二文档推迟到后续的规格说明任务中。 PDOA整个方法过程的基本步骤： 搜集基本的信息并开发问题框架（一种模型），以建立问题域的类型 在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述 基于以上两点，收集并用文档说明新系统的需求问题框架。问题框架是将问题域建模成一系列互相关联的子域。一个子域可以是那些可能算是精选出来的问题域的任一部分。问题框架的目标就是大量地捕获更多有关问题域的信息。基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类为： 工件系统——系统必须完成针对只存在于系统中的这些对象的直接操作。 控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。 信息系统——系统将提供有关的问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供。 转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。 连接系统——系统必须维持那些相互没有直接连接的子域间的通信。 问题框架法在应用时，建议采用直截了当的策略： 抽象问题域：标识子域；标识子域间的交互；刻画每个子域的特征；生成一个上下文图识别出相关的标准框架；调整框架，尽可能使之适用于问题；使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。 问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。 4、方法的对比 结构化分析（SA）及其相应的派生方法，曾一度风行了许多年。它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。 面向对象分析（OOA）是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。它也继承了很多结构化分析的思想体系。OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。 SA和OOA还有几点相同特性：主要模型是结构模型；通常焦点集中在对解系统的建模上；两中方法都较少地应用于需求获取领域；分析与内部设计之间没有明显差异。 面向问题域分析（PDOA）被认为是一种较为理想的方法。PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还有一定距离。 因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。 三、 总结 在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的进一步进行，我们越来越清晰的认识了软件系统的需求。 虽然应用方法使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。
软件工程的软件需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外，每个系统还有各种非功能需求。
业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求说明书（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
约束（constraint）限制了开发人员设计和构建系统时的选择范围。
行业需求：企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。
非功能性需求都包括哪些方面？
非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。一般不会在用户的业务需求中进行明确的提出，需要分析人员根据实际业务需要进行调研归纳。
例如税务业务系统的非功能性需求，可以从以下几个方面进行分析。
一：性能方面：
1。响应时间：分日常交互类、日常查询类、批量交易分别考虑。
日常交易指传统的大厅交互业务，如纳税申报、发票销售等，以及一次完成多笔业务处理的交易，如批量扣款等，日常交互类业务具有较高的响应要求。 查询类业务如登记资料查询、申报数据查询等。查询业务由于受到查询的复杂程度、查询的数据量大小等因素的影响，需要根据具体情况而定，给出一个参考范围。
批处理业务如会计核算等业务处理，该类业务处理复杂、操作数据量大、处理时间长。
响应时间指标包括：平均响应时间参考值(秒)、峰值响应时间参考值（秒）。
2。用户数：用户数要考虑用户数的增长情况，有以下指标：总用户数、峰值在线用户数、峰值并发用户数、平均在线用户数、平均并发用户数。
3。吞吐量：系统交易量的估算。指标有年交易笔数（笔/年）、高峰期交易笔数（笔/天）。
4。数据存储量：每年的数据存储容量（G）及未来几年该数量的预期（增长）值。指标包括累计存储容量（G）、年增长（G）。
二、系统可靠性：一般是窗口业务应在从星期一到星期五的所有工作日的工作时间是可以使用的；其它业务应满足7×24小时可以使用；
三、可扩展性：可实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。
所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。
对于非功能性需求描述的困难在于很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚，在描述这类需求时候我们经常采用软件性能要好，查询要在多少时间内出结果，软件健壮性要好等较模糊的描述词语。这类描述词语都是脱离了软件的执行环境，人和相关的场景的描述，因此信息很难体现到软件架构设计和具体的实现中。我们在架构设计中关注的安全，系统开发框架，并发和性能，异常日志等不是凭空产生出来的，而是来源于我们对非功能性需求的分析。
一个软件系统必须完整，因此不仅仅包括了可执行的程序，还包括了在线帮助，数据和用户管理，日志异常查询，自动升级等相关功能特征。这些需求不仅仅是为了满足用户的需要，也是为了我们后续维护和监控系统的需要。
系统的可靠性，可维护性和适应性是密不可分的。当系统出现故障和用户出现错误的操作后是否支持恢复，当用户在使用过程中遇到错误的时候是否可以立即定位问题，但业务场景和逻辑发生变化的时候系统是否支持，当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施，这些都是需要在非功能性需求中考虑到的问题。
易用性也是我们在开发非功能性需求中必须要考虑到的问题，易用性同时还涉及到美工和UI界面，人机工程，交互式设计，心理学，用户行为模式等多方面的知识。易用性的三原则就是易见，易学和易用或者叫为发现，易懂，效率。易见就是各种功能操作不要藏得太深，用户很容易找到他们期望进行的各种操作；易学需要软件系统通过在线帮助，导航，向导等各种方式保证软件是可自学习的；易用的重点则在软件在熟练使用后应该可以更快的进行各项操作。这三者相互间也存在冲突，需要平衡，而平衡的一个重点就是真正的做到以用户为中心进行设计，需要去细分场景和用户。
对于非功能性需求的描述，在描述过程中必须要强调到人，业务场景，环境等各方面的内容。强调的目的就是要说明非功能性需求不是无限度的，任何一项非功能性需求的实现往往会付出更大的研发人力成本和硬件网络成本。比如我们在描述一个表单的模糊查询功能的时候，如果简单的描述为所有查询都要在多少秒内完成，那么这种需求将很难得到满足，以下是一些可选的描述方式。
1.估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。
2.在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。
3.当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。
转载请注明出处51数据库 » 软件开发需求响应指标 软件需求说明怎么写
