软件需求规格说明书怎么写

定制软件需求怎么写

1.软件需求说明怎么写

原发布者：管理资源吧

软件需求说明书的编写提示1引言1.1编写目的说明编写这份软件需求说明书的目的，指出预期的读者。1.2背景说明：a.待开发的软件系统的名称；b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；c.该软件系统同其他系统或其他机构的基本的相互来往关系。1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列出用得着的参考资料，如：a.本项目的经核准的计划任务书或合同、上级机关的批文；b.属于本项目的其他已发表的文件；c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2任务概述2.1目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|2.2用户的特点列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束2.3假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。3需求规定3

2.软件的需求分析怎么写啊

1. 引言1.1 编写目的：编写此文档的目的是进一步定制软件开发的细节问题，便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体.1.2 项目背景1.2.1项目委托单位：****公司1.2.2开发单位：***公司1.3 定义1.4 参考资料2. 任务概述2.1 目标：<1> 决策支持：根据公司的要求及时提供所需报表及文件，并在适当时候对各部门领导给予销售及进货等方面的提示<2>提高效率：利用软件进行管理，避免人工管理的失误以及延迟性，从而实现高效率的管理.2.2 运行环境：<1> 硬件方面：Pentium级处理芯片 1兆显存的兼容显卡 256色，800*600的兼容显示器标准兼容打印机<2>软件方面： WIN95操作系统2.3 条件与限制：编程用计算机一台完成期限2000/7/1 无资金供给3. 数据概述数据流程图如下： 3.1 静态数据：包括系统登录密码，各数据库所在位置，系统分析原始数据3.2 动态数据：包括各数据库内各项显示数据，用户登录信息，系统时间3.3 数据库描述：人事管理数据库：公司内人员的个人详细信息，包括档案信息销售管理数据库：当日销售记录及以前的销售统计，用于销售分析财务管理数据库：公司内部账目及收支情况详表技术管理数据库：公司所需各技术档案的详细记录（包括文档） 3.4 数据字典：<1>数据流词条描述： 1.数据流名：登录信息来源：用户的输入去向：系统内部检验部分组成：用户名，密码流通量：每次登录输入一次 2.数据流名：登录结果来源：系统去向：用户组成：返回信息流通量：每次登录返回一次 3.数据流名：输入修改信息来源：用户去向：系统判断部分组成：根据各数据库内容而不同流通量：依用户输入而定 4.数据流名：反馈信息来源：系统判断部分去向：用户组成：系统经判断后发回的字符数据流通量：依系统当前信息而定 5.数据流名：识别信息来源：系统内部检验部分去向：系统判断部分组成：系统各数据库的标识信息流通量：用户每次输入流通一次 6.数据流名：处理信息来源：系统判断部分去向：各数据库处理部分组成：读取/修改标识，读取/修改的变量名称流通量：用户每次输入流通一次 7.数据流名：读取修改来源：系统判断部分去向：系统各数据库组成：读取/修改标识，读取/修改内容流通量：用户每次输入流通一次<2>数据文件词条描述： 1.数据文件名：人事数据简述：存储人员信息数据文件组成：人员的各项信息（以CString类型为主） 2.数据文件名：销售数据简述：存储当日及从前的销售记录数据文件组成：销售的各项信息 3.数据文件名：财务数据简述：存储财务管理信息数据文件组成：财务管理的各项记录 4.数据文件名：技术数据简述：存储公司内部使用的技术档案信息数据文件组成：技术档案名称，内容<3>加工逻辑词条描述： 1.加工名：检验简要描述：判断用户的许可性输入数据流：登录信息输出数据流：登录结果加工逻辑：判断是否与系统内部用户信息相符合 2.加工名：判断简要描述：判断用户的操作并进行相应的读取/存储工作输入数据流：输入修改信息输出数据流：反馈信息加工逻辑：判断用户的操作->调用数据库->读取/修改->反馈 3.加工名：人事档案管理简要描述：对人事数据库进行相应要求的操作，并与判断部分交互输入数据流：处理信息，读取修改输出数据流：读取修改，处理信息加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 4.加工名：销售统计简要描述：对销售数据库进行相应要求的操作，并与判断部分交互输入数据流：处理信息，读取修改输出数据流：读取修改，处理信息加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 5.加工名：财务统计简要描述：对财务数据库进行相应要求的操作，并与判断部分交互输入数据流：处理信息，读取修改输出数据流：读取修改，处理信息加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息 6.加工名：技术管理简要描述：对技术统计数据库进行相应要求的操作，并与判断部分交互信息输入数据流：处理信息，读取修改输出数据流：读取修改，处理信息加工逻辑：判断用户要读取/修改的内容->反馈用户所需信息<4>源点及汇点词条描述：名称：用户简要描述：既是源点又是汇点，发出动作信息给"检验"和"判断"加工，通过交互界面接受反馈信息有关数据流：登录结果，登录信息，输入修改信息，反馈信息数目：一个4. 功能需求4.1 功能划分可细分为四部分：人事管理，销售管理，财务管理，技术档案管理4.2 功能描述<1>人事功能：（1）能对公司内部的所有人员有关档案详细资料记录并保存。

（2）能对数据库内人事档案的数据进行查阅和修改。（3）能按部门或姓名检索人员。

（4）当某员工的雇用期限达到整年时，按时提醒。<2>销售统计功能（1）按日对公司的销售情况进行统计，包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况（2）制定销售情况的月报表\季报表以及年报表对销售情况进行分析，对不同销售人员的业绩进行评定<3>财务管理。

3.软件的需求分析怎么写啊

（2）能对数据库内人事档案的数据进行查阅和修改。（3）能按部门或姓名检索人员。

（4）当某员工的雇用期限达到整年时，按时提醒。<2>销售统计功能（1）按日对公司的销售情况进行统计，包括销售额\销售数量\各地区销售比例\不同销售方式的销售量比例以及销售毛利润情况（2）制定销售情况的月报表\季报表以及年报表对销售情况进行分析，对不同销售人员的业绩进行评定<3>财务管理功能（1）协助财务人员进行计算机管理，对库。

4.做软件的需求分析和设计,要写哪些东西

呵呵正好我参加日本的软件比赛时写过这是我那时候些的需求分析设计书的目录你看看吧一. 智能家居背景介绍。

3（一）. 背景介绍。 3二. 语音识别智能家居解决方案。

4（一）. 方案总体介绍。 4（二）. 语音识别智能家居解决方案实现原理。

6（三）. 无线技术。 7三. 方案实例——语音识别智能百叶窗帘。

8（一）. 实例简介。 8（二）. 系统功能。

8（三）. 详细实现。 91. 硬件设计。

92. 软件设计思路。 12（四）. 操作方法及步骤。

141. 训练：。 142. 识别阶段：. 14四. 总结。

15。

5.功能需求怎么写

需求分析是一项重要的工作，也是最困难的工作。该阶段工作有以下特点：

(1)用户与开发人员很难进行交流

在软件生存周期中，其它四个阶段都是面向软件技术问题，只有本阶段是面向用户的。需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该"做什么"。但是在开始时，开发人员和用户双方都不能准确地提出系统要"做什么？"。因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。

(2)用户的需求是动态变化的

对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来困难。

(3)系统变更的代价呈非线性增长

需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一小时的时间，到设计、编程、测试和维护阶段解决，则要花2.5、5、25、100倍的时间。

因此，对于大型复杂系统而言，首先要进行可行性研究。开发人员对用户的要求及现实环境进行调查、了解，从技术、经济和社会因素三个方面进行研究并论证该软件项目的可行性，根据可行性研究的结果，决定项目的取舍。

编辑本段方法

⑴首先调查组织机构情况

包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。

⑵然后调查各部门的业务活动情况

包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。

⑶协助用户明确对新系统的各种要求

包括信息要求、处理要求、完全性与完整性要求。

⑷确定新系统的边界

确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

常用的调查方法有：

⑴跟班作业

通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。

⑵开调查会

通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。

⑶请专人介绍。

⑷询问

对某些调查中的问题，可以找专人询问。

⑸设计调查表请用户填写

如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。

⑹查阅记录

即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。

分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

编辑本段案例

(1)需求分析报告的编写目的

本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本铁路售票系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用。

(2)产品背景明细

软件名称：铁路售票系统

(3)缩写及缩略语

铁路售票应用系统软件：基本元素为构成铁路售票及相关行为所必须的各种部分。

需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。

需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都明其含义并找出其中的错误，遗憾或其它不足的地方。

模块的独立性：是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。

本工程描述：

(1)软件开发的目标：

完善目前铁路售票系统，使之能跟上时代的发展。同时通过实践来提高自己的动手能力。

(2)应用范围：

理论上能够实现于铁路部门的售票系统，其目的在于在原有的系统基础使得铁路售票实名化，以期实现完善日常生活中铁路售票的各种缺陷。

定制软件需求怎么写

需求规格说明书怎么写

1. 需求规格说明书包括哪两个部分

三、需求规格说明书

1.引言 1

1.1编写目的 1

1.2项目背景 2

1.3定义 2

1.4参考资料 2

2.任务概述 2

2.1目标 2

2.2运行环境 2

2.3条件与限制 2

3.数据描述 3

3.1静态数据 3

3.2动态数据 3

3.3数据库介绍 3

3.4数据词典 3

3.5数据采集 3

4.功能需求 3

4.1功能划分 3

4.2功能描述 3

5.性能需求 3

5.1数据精确度 3

5.2时间特性 3

5.3适应性 4

6.运行需求 4

6.1用户界面 4

6.2硬件接口 4

6.3软件接口 4

6.4故障处理 4

7.其它需求 4

1.引言

1.1编写目的

【阐明编写需求说明书的目的，指明读者对象。】

为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。

本文档供项目经理、设计人员、开发人员参考。

1.2项目背景

a. 项目的委托单位、开发单位和主管部门

b. 该软件系统与其他

1.3定义

【列出文当中所用到的专门术语的定义和缩写词的原文。】

1.4参考资料

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

b. 项目开发计划

c. 文档所引用的资料、标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源

2.任务概述

2.1目标

2.2运行环境

操作系统：Microsoft Windows 2000 Advanced Server

支持环境：IIS 5.0

数据库：Microsoft SQL Server 2000

2.3条件与限制

3.数据描述

3.1静态数据

3.2动态数据

【包括输入数据和输出数据。】

3.3数据库介绍

【给出使用数据库的名称和类型。】

3.4数据词典

3.5数据采集

4.功能需求

4.1功能划分

4.2功能描述

5.性能需求

5.1数据精确度

5.2时间特性

【如响应时间、更新处理时间、数据转换与传输时间、运行时间等。】

5.3适应性

【在操作方式、运行环境、与其它软件的接口以及开发计划等发生变化时，应具有的适应能力。】

6.运行需求

6.1用户界面

【如屏幕格式、报表格式、菜单格式、输入输出时间等。】

6.2硬件接口

6.3软件接口

6.4故障处理

7.其它需求

【如可使用性、安全保密、可维护性、可移植性等。】

2. 谁会写软件需求规格说明书啊

规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。

2 适用范围

本规范适用于集团开发项目的（软件）《需求说明书》的编写。

3 编写内容提示

1 引言

3.1.1 背景说明

说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。

3.1.2 参考资料

列出有关资料（名称，发表日期，出版单位，作者等）。

3.1.3 术语和缩写词

列出本文件中用到的专门术语的定义，及术语缩写词。

3.2 软件总体概述

3.2.1 目标

软件开发的意图、应用目标、作用范围以及需说明背景材料。

3.2.2 系统模型

图示说明该软件的所有功能及其相互关系和数据传递情况。

3.2.3 假设和约束

说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。3.3 详细需求

详细描述此软件系统的功能需求和性能需求。

3.3.1 功能需求

对系统中每一个功能，要详细描述（图示或文字）。

概述叙述功能名称，目标和作用。

输入输入该功能的信息。

处理描述该功能做什么，如何对输入信息进行加工并转换成输出信息。

输出列出内部生成的文件。

3.3.2 性能需求

定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：

3.3.2.1精度

说明系统的精度要求，如：

数据的精度要求。

数字计算的精度要求。

数据传送的误码率要求。

3.3.2.2 时间特性

说明系统的时间特性要求，如：

解题时间。

询问和更新数据文件的响应时间。

系统各项功能的顺序关系。

3.3.2.3 灵活性

说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。

3.3.2.4系统容量

包括系统的设计容量和理论（计算）容量。

3.3.3 输入和输出

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

3.3.4 数据管理能力

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

3.3.5 故障处理

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

3.4 环境

描述所开发软件运行所需的环境。

3.4.1 设备环境

描述运行软件系统所需的设备能力，如：

处理器的型号和内存容量。

存储媒体的数量。

通信网络（包括说明网络结构，线路速度及通讯协议等）。

3.4.2 支持软件环境

列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。

3.4.3 接口

说明本软件与其他软件之间的接口、数据通信协议等。

3.4.4其他

说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

3. 用户需求说明书与需求规格说明书有什么本质区别

1、用户需求说明书是用户的需求，需要和用户确认的；需求规格说明书是系统需求主要是对内的。你考虑了一个对外一个对内。而且需求管理的时候也需要用到用户需求

2、

优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。

缺点：层次越多，信息损失的越多，误解的概率就越大。

权衡的结果：基本上是依据项目的规模而定。

3、这要看你们的项目管理采用的规范。

如果是cmmi就需要，敏捷就取消

4、如果你非要省掉一个的话，我倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题

需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。要是用户需求就已经理解错了，软件规格让用户签字好哪里放什么文本框用什么布局有意义么？最后还不是给你翻掉

5、一个是给用户看的，一个给程序员看的

6、当然需要，需求管理不弄好，后期客户扯皮怎么办？

7、1、用户需求说明书是软件设计的根本，用户需要签字画押，详细设计基于这个写的，怎能不需要。

2、后期有扯皮的时候有依据，不至于什么都没有。

8、这个东西少不得，做的详细点是对自己负责，后期意义重大

需求阶段的工作主要分为两个方面，为“需求开发”和“需求管理”。

从我们的经验来讲

“需求管理”需要产出的文档大体上包含【需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件】

“需求开发”需要产出的文档大体上包含【需求规格说明书，需求规格说明书检查表，需求开发指南等】

需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。

需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。

需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。

4. 监理方如何审核《需求规格说明书》

君欲食坚果必先破其壳需求范围控制是需求阶段控制的难点，如果处理不好，会导致业主方与承建方的纠纷，甚至项目没完没了，不能验收。

因为在项目验收时往往以招标文件、投标文件、开发合同、需求成果文档为依据来确定项目是否达到了范围的要求，往往是招投标文件对用户需求范围规定不细，合同没有规定，如果需求成果文档再写的很草，项目到了上线试运行时，业主方会认为所要的功能没有实现，承建方认为用户开始没有提出需求，后来不断改变和新增需求，项目不可控，永远没法验收。为解决这一难题监理方应从中起到重要作用。

建议的做法是：一是控制好软件开发方法利于需求获取：根据项目复杂度、业主方信息化基本情况，选好开发方法，如果复杂度高业主方信息化基础弱可能选用原型法，如果时间紧、承建方经验丰富可选用敏捷法。二是巧妙引导使用《用户需求说明书》，协调、建议业主方和承建方，需求调研时汇总“需求调研表”形成《用户需求说明书》对开发的范围和性能目标需求进行界定，并建议业主方业务部门对其业务需求签字确认，同时约定更的范围比如10%—15%为合理变更范围，如果在这个范围内，承建方应开发和调整不增加费用，如果超出这个范围或对系统架构有较大的变更，业主方要增加费用。

形成会议纪要或备忘录各方遵守。三是以《用户需求说明书》为依据对《需求规格说明书》的开发范围进行检查和审核。

金玉其外秀慧其中要求《需求规格说明书》形式与内容并重，本节主要阐述形式要求和内容的完整性，只有形式与内容都达到要求才认为是合格的《需求规格说明书》。一是形式完美：包括封皮完美、版本控制信息清晰、章节分部合理、文字简练、准确、专业、无冗余、图文并茂等二是内容完整：包括引言（包括目的、范围、阅读对象、参考资料、缩写词、略语、相关法律法规等）；功能需求；非功能需求（包括可靠性、安全性、易用性、可用性、可扩展性、可维护性、可移植性等）；接口需求、约束条件等文档结构合理，其中要求运行环境、操作方式、故障处理、备份需求、反应速度、流量、频度等一应俱全，把握一个原则是：不能缺项。

慧眼点睛更上层楼重点一：把握《需求规格说明书》的三要素是审核的第一关键，首先要了解软件开发中采用结构化方法、面向对象的方法、SOA架构对《需求规格说明书》的影响。《需求规格说明书》除了与用户沟通要用户理解、监理人员作为控制项目的依据、测试人员作为测试依据之外，也是开发设计人员的依据和工作指南，如果开发方法用的是结构化方法，那么《需求规格说明书》中“业务流”、“数据流”、“数据字典”成为其不可缺少的三要素，缺一不可，并且是环环相扣，相互对应，下面分别述之。

一是业务流程图：要与用户实际业务一致，要以用户容易理解的、标准的图形清晰表述，如果较复杂就用子图分层的方法表述，以简易和容易理解业务为原则。二是数据流程图：先是与业务流程图一一对应，再是涉及的输入或输出表应明确画出，表划分合理、无冗余。

注意处理好分层时的表达。三是数据字典：实际上是数据流程图中输入、输出表中对应的数据项，需要说明的是要标出数据项要求的类型或字长等属性。

如果是面向对象的方法，由于其迭代和无间隙的特点，需求和设计没有明显的界限，所以在审核《需求规格说明书》时至少要有用例图、顺序图、类图等，所要表述的要把握基本与结构化方法三要素相对等的信息，如果情况复杂时还要有状态图，以下简述之：用例图：能清晰反映出角色和用例，可以对应业务流中的主要功能项，通常用例将转化为程序菜单，主要用于审核检查业务范围。顺序图：审核检查顺序图的粒度，基本上能对应业务流程和数据流程就行了，它是以时间顺序描述流程的，也可以空间顺序的协作图来代替其描述流程。

类图：类图主要是描述数据项，可以将其对应为结构化方法的数据字典，但其更贴近自然，更能适应变化。重点二：把握接口和安全尤为重要，接口和安全是软件开发的重点和难点，处理不好，会给项目埋下定时炸弹，即使回避一时，但矛盾很快会暴露，根据项目实际情况对这两个方向的把握也是监理审核的重点。

啰啰嗦嗦终要定格写了这么多最终还是建议完成“关于对《需求规格说明书》的审核”监理报告，以下抛出一砖来，希望引来金凤凰。关于对《需求规格规格说明书》的审核审核报告项目名称XXXX信息管理系统建设项目业主方业主方全称监理方监理方全称承建方承建方全称XX监理公司于XXXX年X月X日对承建方提交的《需求规格说明书》（包括：《OA系统需求规格说明书》、《网站需求规格说明书》、《业务系统需求规格说明书》）进行审核，意见或建议如下：（如果不特指三个系统的某一个，就表示对三个系统共同的评审结果）一、需求目标：《OA系统需求规格说明书》中“需求目标”部分，对系统的性能有较充分的描述，系统的功能描述少，具体要“做什么”在目标中没有很明白的描述。

《网站需求规格说明书》中“需求目标”对功能和性能都有描述。《业务系统需求规格说明书》中“需求目标”。

5. 需求规格说明必须具备哪些条件

需求规格说明是指在一种产品开发之前，消费者希望从该产品中得到的所有需求的最终结果的阐述。

一份有效的规格说明必须满足以下几个条件：完整性，即每一项需求都必须将所要实现的功能描述清楚；正确性，即每一项需求都必须准确地陈述其要开发的功能；可行性，即每一项需求都必须是在一定条件或范围内可以实施的；必要性，即每一项需求都应把真正所需要的和最终所需遵从的标准记录下来；划分优先级，即给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量；无二义性，即对所有需要说明的读者都只能有一个明确统一的解释，即可验证性，即检查每项需求是否能通过设计测试用例或其他的验证方法，保证其客观性。

需求规格说明书怎么写