北美田哥
需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的
基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细
节。
1)采用软件需求规格说明模版:
采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注
意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准
830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。
1
2
3
4
5
6
A引言
目的
文档约定
预期的读者和阅读建议
产品的范围
参考文献
B综合描述
产品的前景
产品的功能
用户类和特征
运行环境
设计和实现上的限制
假设和依赖附录
C外部接口需求附录
用户界面附录
硬件接口
软件接口
通信接口
D系统特性
说明和优先级
激励/响应序列
功能需求
E 其它非功能需求
性能需求
安全设施需求
安全性需求
软件质量属性
业务规则
用户文档
F其它需求
G附件
词汇表
分析模型
待确定问题的列表
表2 需求规格说明模板
a. 引言
引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。
a . 1 目的
对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。
a.2 文档约定
描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。
a.3 预期的读者和阅读建议
列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。
a.4 产品的范围
提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
Java软件项目需求分析
你这个问题太笼统了。每个项目都会有不同的需求，大致会分这几个部分。给你参考一下。
项目需求分析怎么写
项目需求分析的概念 需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务 简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程 需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法 需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.
项目需求报告要怎么写？
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。
听棠所说到的几点，感受特别深：
“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”
还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。
项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。
客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。
需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。
谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。
设计一个软件，之前需要有需求分析，这个需求分析都包括哪些内容啊？
说白一点就是软件项目的背景啊，要达到什么业务目的啊，然后要满足哪些人的哪些使用需求啊，这个需求的业务流程是怎样的啊，针对这个需求软件需要具备的功能是怎样的啊。除了功能性方面的需求，还有些性能方面的需求，比如响应速度啊并发数啊之类的....
网上可以找到标准的需求文档模版，模版里定义清楚了要包含的内容。
还真没写过这东西，头疼
软件的需求分析怎么写啊？
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>财务管理功能
(1)协助财务人员进行计算机管理,对库存情况\进货情况\销货进行登录和输出
(2) 根据预设的库存情况提醒进货
(3) 对收款情况进行统计,在应收帐款达到预设值时进行提示
<4>技术管理功能
(1)对技术资料进行登录
(2)对维修记录进行登录和统计,按不同型号的机器进行故障整体分析,并作出分析报告
(3)对维修配件的需求进行管理并及时提示备货
5. 性能需求
5.1 数据精确度:因为此数据为公司内部数据,所以要求不能有误差
5.2 时间特性:当日销售统计要求有即时性,马上能反应出存货的问题;同时财务管理数据计算当前存货情况,并对进货情况进行估算
5.3 适应性:此软件只在公司内部管理人员的机器上使用,因此不考虑适应性
6. 运行需求
6.1 用户界面:
屏幕格式:
(1)要求有菜单及工具栏以方便操作
(2)各数据库信息可在屏幕上直接修改
(3)各数据统计结果可在屏幕上显示
(4)进行系统分析后的结果在另一窗口中显示
报表格式:
(1)人事管理报表只要求有个人的普通数据
(2)销售统计报表要求可分别打印当日统计或之前的统计
(3)财务统计报表要求打印出存货及公司帐务详表
(4)技术管理报表要求可以分别打印技术档案总表和任一技术档案文档内容菜单格式:要求菜单项大致与WIN95标准相同,另外附加的功能做到新的单项中输入输出时间:年份以4位数字表示
6.2 硬件接口:需要标准打印机接口进行报表打印
6.3 软件接口:Windows标准接口
7. 其他需求
可使用性:要求容易使用,界面友好
安全保密性:因本数据属于公司内部管理用关键数据,因此除公司管理人员外,其他人员不得访问.要求设有登录密码检验功能,并且此密码可以在以后进行修改
可维护性:要求本软件的维护文档齐全,便于维护
谁帮忙作一个网上聊天系统的需求分析，模板也许
1. 引言
1.1. 背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。
1.2. 参考资料
列出本说明书中引用和参考的资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.3. 假定和约束[可选]
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。
1.4. 用户的特点[可选]
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
2. 功能需求
2.1. 系统范围
明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。
如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选]
以图+文本结合的方式描述系统的总体架构。
以下应提供系统总体架构图：
以下对系统总体架构进行描述：
2.3. 系统总体流程
以图+文本结合的方式说明系统的总体流程。
图一是计划合同管理系统的总体流程图。
图一
2.4. 需求分析
需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？
· 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系
· 描述用例：角色与系统如何交互的规格说明。
2.4.1. XXXXXXX(功能需求名称)
2.4.1.1. 功能描述
功能编号：
功能需求：从用户业务的角度描述功能需求。
2.4.1.2. 业务建模
从可视化的角度--用例图--描述功能需求
图二是综合计划管理系统合同编辑业务的功能需求用例图。
图二
2.4.1.3. 用例描述
以文本的方式描述每一个用例中角色与系统相互交互的规格说明。
1、 XXXXXX(用例名称)
描述对象 描述内容
标识符 用例的唯一标识符
说明 对用例的概要说明
参与者 与该用例相关的参与者列表，以及参与者的特点
频度 参与者访问此用例的频率
状态 通常分为：进行中、等待审查、通过审查或未通过审查
前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足
后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足
被扩展的用例 此用例所扩展的用例（如果存在）
被包含的用例 此用例所包含的用例（如果存在）
基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式
可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径
修改历史记录 修改人 ： 修改日期：修改原因：
问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表
以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述：
描述对象 描述内容
标识符 IPMS0101
说明 增加一条合同记录
参与者 合同编辑人员--熟悉合同管理业务
频度
状态 通过审查
前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价)
后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例
被扩展的用例 无
被包含的用例 无
基本操作流程 请参见图三的合同增加流程
可选操作流程 当用户确认合同增加时发现异常时，系统提示合同增加无效的提示
修改历史记录 修改人 ： 修改日期：修改原因：
问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计
图三 合同增加活动流程
2、XXXXX(用例名称)
……
2.4.1.4. 用户界面
概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。
2.4.2. XXXXXXX(功能需求名称)
……
3. 非功能需求
3.1. 性能要求
3.1.1. 精度[可选]
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.1.2. 时间特性要求
说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。
3.1.3. 输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.2. 数据管理能力要求[可选]
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。
3.3. 安全保密性要求
用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。
3.4. 灵活性要求[可选]
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.5. 其他专门要求[可选]
如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。
4. 运行环境规定
4.1. 设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
4.2. 支持软件
列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。
4.3. 接口[可选]
说明该软件同其他软件之间的接口、数据通信协议等。
4.4. 控制[可选]
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
5. 需求跟踪
需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。
转载请注明出处51数据库 » 软件项目需求分析模板 软件工程需求分析的模板
