需求分析类文档模板Word格式文档下载.docx
《需求分析类文档模板Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《需求分析类文档模板Word格式文档下载.docx（48页珍藏版）》请在冰豆网上搜索。
提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。
确定了产品所能运行的软、硬件平台。
定义了较高层次的关键接口或性能要求，但避免设计或实现细节。
把这些要求写到列表中，可以反过来跟踪调查特殊用户和功能需求。
]
1.5提供给客户的价值
实现供货商管理信息与仓库管理信息的及时对接
提高生产效率，减少返工；
节省开支；
业务过程的流水线化；
先前人工劳动的自动化；
符合相关标准和规则；
与目前的应用产品相比较，提高了可用性或减少了失效程度
1.6业务风险
该数据库系统针对企业在市场竞争中及时有效处理信息资源有可靠的技术保障，数据库如若出现数据泄密危险，将自动进行数据备份工作。
2.项目视图的解决方案
该数据库旨在合理规划企业订货业务健康发展。
2.1项目视图陈述
该系统可使用户方便快捷地掌握库存消息，克最大限度降低货物囤积所造成的成本积压和浪费。
2.2主要特征
系统实现了职工、仓库、供应商三方消息的有机统一，一方数据变更则可以顺利实现整个相关数据的更新。
2.3假设和依赖环境
该系统可以替代现有的订货管理系统，并能与有关职工部门的应用相连接。
为确保数据安全性，该系统设置了访问权限。
3.范围和局限性
该系统与其他企业统计系统的兼容性还有待提高。
3.1首次发行的范围
该系统对订货管理数据的处理能力明显优于同类系统，对拥有庞大数据处理任务的企业均适用。
3.2随后发行的范围
3.3局限性和专用性
该系统使用费用较多，且后期维护周期较为频繁，对小型企业可能不太适用。
4.业务环境
[这一部分总结了一些项目的业务问题。
4.1客户概貌
Ø
各种客户类型将从产品中获得的主要益处：
大中型企业可将主要精力投入市场分析而非数据处理
它们对产品所持的态度：
大多数客户对该系统评价均为优良
哪一类型客户能成功使用：
拥有大型数据处理任务的企业
必须适应任何客户的限制
4.2项目的优先级
5.产品成功的因素
该系统的市场占有率是用于评价是否达到业务目标的标准，影响因素包括：
市场股票、销售量及收入、客户满意度、交易处理量和准确度
项目构想
这个文档模板与“软件项目视图与范围”文档的功能十分接近，只不过该文档更适合于产品型项目。
其注重对项目的用户、市场进行分析，紧抓项目相关人员（也叫做风险承担者）的需求的本质。
1.文档简介
1.1
目的
承担使用户快速熟悉该系统的功能
1.2
范围
该文档主要是介绍系统的构造
1.3定义、首字母缩写词和缩略语
无缩略词
1.4参考资料
[在这一小节中，应完整地列出该文档引用的所有文档。
对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。
1.5概述
该文档分析系统的目标客户与市场前景
2.定位
2.1
商业机会
2.2
问题说明
存在的问题
使用成本偏高
受影响的人群
刚刚起步的小型企业
导致的后果
不利于系统市场占有额的扩展
希望的解决方案
等待技术更加成熟后降低运行成本
2.3
产品定位说明
目标市场
数据处理任务复杂的企业
目标客户需求
大多数现代化企业
主要优点
处理数据能力强大
主要竞争对手
与数据处理有关的系统
主要优势
数据安全性能优越
3.项目相关人员和用户说明
企业在忙于获取利润的同时最担心要分配精力在交易数据上，该系统致力于数据管理服务，解除用户后顾之忧
3.1
产品用户分析
随着全球化范围日益扩展，势必急需相关数据处理系统
3.2
项目相关人员一览表
人员类别
代表
作用
数据库开发团队
程序开发师
统领该数据库的开发工作
3.3
用户一览表
用户类型
说明
企业
[简要说明他们在系统中代表的对象和充当的作用]
[列举出代表]
3.4
用户环境
3.5
项目相关人员的简要说明
[列出该类项目相关人员的代表。
[对该类人员进行简要说明。
专业技能
[描述本类人员的技能特长、技术背景以及电脑系统操作的熟练程度（可以分成业务用户、专家用户、熟练用户、初级用户等）]
职责
[描述本类人员对系统开发所承担的职责，以及应享有的利益。
验收标准
[描述验证系统是否满足其职责的标准。
参与方式
[该类人员是否参与系统开发，如果参与将以什么形式参加。
项目成果
[说明该类项目相关人员是否参与项目成果的开发，是否有与其相关的项目成果。
意见/问题
[列出与该类项目成员相关的问题与建议。
3.6用户简要说明
[列出该类用户的代表。
[对该类用户进行简要说明。
[描述该用户的技能特长、技术背景和对计算机系统操作的熟练程度。
[列出该用户对所开发的系统负有的关键职责，如记录详细信息、撰写报告、协调工作等。
[描述验证系统符合用户需求的标准。
[说明该类用户是否参与开发，如何参与。
[说明是否有依赖于该类用户的项目成果。
[列出一些该类用户对系统提出的一个意见与建议，并且收集其认为该系统将遇到的问题。
3.7关键的项目相关人员/用户需要
需求
优先级
要点
目前解决方案
提议的解决方案
3.8备选方案和竞争
[如果是产品型项目，应在此小节列举出客户除了购买该产品这外的选择，其中包括购买竞争对手的产品、自行设计解决方案甚至是维持现状。
对所有潜在的竞争产品做一个列表，并根据客户的实际情况来确认主要优缺点。
[而如果是定制开发型项目，则应该了解竞争对手提供的解决方案，比在此进行相应的比较。
4.产品概述
[本节主要从产品级、系统级的视角，高度概括产品的功能、与其它应用程序的交互以及所需的系统配置等。
4.1
产品总体效果
[本小节主要将产品话在用户环境、使用环境的角度来介绍。
如果是自成一体，则说明用户将如何使用；
如果是与其它的应用系统进行交互的，则在此小节说明如何与这些系统进行交互？
它们之间采用什么样的通讯方式和接口。
在这里最适合的方式是使用UML的部署图，让用户对系统最终的运行环境有一个较宏观的了解。
4.2
主要功能
[本小节不是对系统或产品所有功能的罗列，而是将能够体现系统、产品主要优点和特性功能在此列出。
在内容组织方面，应该直接与“客户能够通过产品获得的好处”相联系，使读者能够将系统的功能与客户的价值直接联系起来，在开发时能够从本质出发，构建出更加符合客户需要的系统。
4.3
假设与依赖关系
[在此小节中，列出所有会影响该文档中所述特性的各种因素。
也就是列举出所有可能让该文档发生变化的假设条件。
4.4
成本与定价
[该小节主要是对该项目的成本进行核算，对给出相应的定价策略。
对于定制开发的项目，其成本主要包括开发的人工成本、公司管理成本、项目额外开支、相关软硬件工具投资等方面。
而对于产品型项目而言，还包括分销成本、用户手册制作、CD制作等方面的成本。
这里的成本核算为最终的合同价格以及产品的销售价值将提供一个基础的依据，因此也是十分重要的。
4.5
许可与安装
[该小节中主要列出影响开发工作的一些许可和安装相关的问题。
例如是否需要加密，如果验证用户合法性，安装界面的要求是什么。
这方面对于产品型项目而言显得更加重要，也是对软件知识产权保护的一个重要措施。
5.产品特性
[在本节中将列出系统或产品的特性，特性是指实现用户价值的系统功能。
每一个特性都是一个所需的服务，通常是通过一系列操作实现预期结果。
在FDD中，也就是特征。
通常一个特征会由一个或多个用例来实现，通常系统的特性应该进行整合打包，以25-99项为合适。
[本小节的描述应该能够让用户、操作人员、外部系统直接从系统的外边感受到每项特性，这些特性应该包括功能性说明以及一些可用性问题。
但是要注意，在这里不要过早地引入设计的内容，这里说明的是What，而不是How。
[另外，因在所有特性的描述中，确定其优先级。
6.约束
[记录用户、项目相关人员提供出的一些约束条件，以及与其它系统之间的依赖关系，这是制订解决方案时必须考虑到的问题。
7.质量要求
[对于整个系统的质量要求，如可靠性、可用性、性能、容错等质量要求，在这此节中详细地定义与描述。
8.其他产品需求
[一些要求符合的标准、硬件基础要求、软件基础要求、环境要求等。
8.1
适用的标准
[列出产品必须符合的所有标准。
其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix等）以及质量和安全标准（UL、ISO、CMM）。
8.2
系统需求
[确定支持该应用程序所必需的任何系统需求。
其中可能包括操作系统、网络环境、系统配置、内存大小、硬盘大小、外围设备和配套软件。
8.3
性能需求
[本节用于详细说明性能需求。
性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。
8.4
环境需求
[对于基于硬件的系统，环境因素可以包括温度、振荡、湿度、辐射等。
对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。
9.
文档需求
[列举用户所需的与该系统或产品相关的文档。
9.1
用户手册
[用户手册的制作说明，例如手册篇幅、详细程序、是否需要图、主要关心的点、要不要建立索引、词汇表，采用教程式还是速查手册式。
9.2
联机帮助
[联机帮助是一种用户界面友好的服务，它可以为用户提供实时的协助。
9.3
安装指南、配置文件、自述文件
9.4
标签与包装
10.功能需求属性
[为了在项目开发过程中，对每个功能需求进行跟踪管理，在此对所有的功能进行一个总体的描述。
[可以生成一张功能需求属性表，每条记录代表一条功能，每个功能包括以下字段：
1）状态：
标识该功能的最新状态。
已提出：
已经提出来，但是还没有经过正式的复审而确定的需求；
已批准：
已经经过正式的渠道复审而确定，准备实施的需求；
已加入：
已经加入到需求管理基线中的特性。
2）利益：
根据客户的态度，确定每个需求的重要程序，也是确定系统开发优先级的基础数据。
关键：
必不可少的特性，缺少这些特性的系统将无法满足客户的要求，这些特性通常会在最早安排到迭代开发中去；
重要：
对于系统来说，该特性是十分重要的，很难以通过其它方式来弥补，如果这些特性没有第一时间实现，将会使得客户满意度大大降低。
因此是第二优先实现的特性；
有用：
这些是一些有效，但使用频率较低的功能特性。
如果没有在第一时间实现，也不会对客户满意度造成很大的影响；
无用：
对于系统来说是“镀金”需求，有也可以，没有也行的。
3）工作量：
根据特性所需的时间和资源进行估算，给出团队开发的工作时间或个人开发的工作时间。
也可以估算出代码行数或功能点数，这也将为迭代开发计划的制定提供良好的基础。
4）风险：
列出该特性开发的最大风险，可以对这些风险进行级别细分，对于影响较大的风险还应该制定相应的应对措施。
5）稳定性：
对该特性需求是否容易变化进行一个预估，以帮助设计人员在设计解决方案时更加有效地避免变化对体系结构的影响，从而节省时间。
6）基线：
确定其是否已经纳入基线；
7）职责分配：
列出负责实现该特性的团队；
8）原因：
列出提出该特性的原因，也可以将与客户交流的记录等资料放在这里，以帮助开发团队更好的理解客户的本意。
需求规格说明书（ISO标准版）
当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。
这是在软件项目过程中最有价值的一个文档。
ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。
1．引言
1.1编写的目的
[说明编写这份需求说明书的目的,指出预期的读者。
1.2背景
a.待开发的系统的名称;
b.本项目的任务提出者、开发者、用户；
c.该系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
[列出用得着的参考资料。
2．任务概述
2.1目标
[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。
解释被开发系统与其他有关系统之间的关系。
2.2用户的特点
[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。
2.3假定和约束
[列出进行本系统开发工作的假定和约束。
3．需求规定
3.1对功能的规定
[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。
3.2对性能的规定
3.2.1精度
[说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
[说明对于该系统的时间特性要求。
3.2.3灵活性
[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。
3.3输入输出要求
[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对系统的数据输出及必须标明的控制输出量进行解释并举例。
3.4数据管理能力要求（针对软件系统）
[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求
[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4．运行环境规定
4.1设备
[列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能，包括：
a.处理器型号及内存容量
b.外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量
c.输入及输出设备的型号和数量，联机或脱机；
d.数据通信设备的型号和数量
e.功能键及其他专用硬件]
4.2支持软件
[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。
4.3接口
[说明该系统同其他系统之间的接口、数据通信协议等。
4.4控制
[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。
需求规格说明书（Volere版）
AtlanticSystemGuild（）公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术，是一个十分实用、完善的SRS模板。
其所提供的Volere需求记录卡也十分实用，强烈推荐。
注：
从AtlanticSystemGuild公司网站上获得，并稍做修改
1.产品的目标
1.1该项目工作的用户问题或背景
[对引发开发任务的工作和情况的描述。
同时也应描述用户希望用将要交付的软件来完成的工作。
[该节内容为该项目提供了合法的理由，你应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。
1.2产品的目标
[用一句话或很少的几句话来说明“我们希望该产品做什么？
”换言之，即开发该产品的真正原因。
[项目如果没有一个表述清晰、易于理解的目标，就会迷失在产品开发的沙漠中。
产品必须带来某种优势。
典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。
这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。
2.客户、顾客和其它风险承担者
2.1客户是为开发付费的人，并将成为所交付产品的拥有者
[这一项必须给出客户的姓名，三个以内是合理的。
[客户最终将接受该产品，因此必须对交付的产品满意。
如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。
2.2顾客是将花钱购买该产品的人
[也给出姓名和相关的信息]
2.3其它风险承担者
[其他的一些人或组织的名称，他们或者受到产品的影响，或影响产品。
1）经理或项目负责人；
2）业务领域专家；
3）技术人员；
4）系统开发者；
5）市场人员；
6）产品经理；
7）测试和质量保证人员；
8）审查员，诸如安全审查员或审计人员；
9）律师；
10）易用性专家；
11）你所处行业的专业人员。
3.产品的用户
3.1产品的用户
[产品的潜在用户或操作员的列表。
针对每种类型的用户，提供以下信息：
1）用户分类
2）用户工作的任务；
3）主要相关的经验；
4）技术经验；
5）其他用户特征：
包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性别等。
[用户是为了完成工作而与产品交互的人，你了解用户，就越可能提交适合用户工作方式的产品。
3.2对用户设的优先级
[在每类用户后面附上一个优先级，这区别了用户的重要性和优先地位：
1）关键用户：
对产品的后续成功至关重要；
2）次要用户：
他们使用产品，但对产品的长期成功并无影响；
3）不重要的用户：
不常用、未授权和没有技能的用户。
[如果认为某些用户对产品或组织更重要，那么应该写明，因为它会影响你设计产品的方式。
4.需求限制条件
4.1解决方案限制条件
[此处明确了限制条件，它们规定了解决问题必须采取的方式。
您可以认为它们是指令式的解决方案。
仔细描述该解决方案，以及测试是否符合的度量标准。
如果可能，您应该解释使用该解决方案的原因。
[换一句话说，就是要求软件解决方案满足哪些限制条件！
4.2实现环境
[此处描述产品将被实施的技术环境和物理环境。
[该环境也将成为设计解决方案时的限制条件之一。
4.3伙伴应用
[此处描述那些不属于产品的一部分，但产品却又必须与其协作的应用程序。
4.4COTS
[此处描述实现产品需求所必须使用的COTS（商业组件）。
4.5预期的工作场地环境
[此处描述用户工作和使用该产品的工作场地。
此处应该描述任何可能对产品设计产生影响的工作场地特征。
4.6开发者构建该产品需要多少时间
[任何已知的最后期限，或商业机会的时限，应在此处说明。
4.7该产品的财务预算是多少
[该产品的预算，以金钱的形式或可得资源的形式说明。
5.命名标准和定义
[定义项目中使用到的所有术语，包括同义词。
这里的内容就是一个字典，包括在需求规格说明书中使用的所有名称的含义。
这个字典应该使用你的组织或行业使用的标准名称。
这些名称也应该反映出在工作领域中当前使用的术语。
该字典包括项目中用到的所有名称。
请仔细地选择名称，以避免传达不同的、不期望的含义。
为每个名字写下简明扼要的定义，这些定义必须经过相应的风险承担者同意。
6.相关事实
[可能对产品产生影响的外部因素，但不是命令式的需求限制条件。
7.假定
[列出开发者所做的假设。
[将所有的假设列在此的目的是让每一个项目成员都意识到这个假设。
8.产品的范围
8.1工作的上下文范围
[上下文范围图用来表示将要开发的系统、产品与其它系统之间的关系，以确定系统边界。
8.2工作切分
[一个事件清单，确定系统要响应的所有业务事件。
清单包括：
1）事件名称
2）输入和输出
8.3产品边界
[你可以使用用例图（use-case）来确定了用户与产品之间的边界。
9.功能性需求与数据需求
9.1功能性需求
[对产品必须执行的动作的描述。
[每个功能性需求必须有一个验收标准。
9.2数据需求
[与产品/系统有密切关系的主题域相关的业务对象、实体、类的说明书。
[进行问题域建模，生成相应的类图。
10.观感需求
[一些与
升级会员 