软件工程需求分析文档模板

最新推荐文章于 2022-04-15 14:29:59 发布

jiangcl207504

最新推荐文章于 2022-04-15 14:29:59 发布

阅读量1.5w

点赞数 6

文章标签：文档产品工作数据库任务 actor

本文链接：https://blog.csdn.net/jiangcl207504/article/details/5467285

版权

需求分析类文档模板

编者说明：

许多有经验的开发团队在开始需求调查的时候，总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户，让客户明确其权利与义务，将会对需求调研、分析的工作带来意想不到的效果，你可以一试。

软件客户需求权利书

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

2.要求分析人员了解客户系统的业务及目标；

3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。

4.要求开发人员对需求过程中所产生的工作结果进行解释说明；

5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度；

6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。

7.描述产品使其具有易用、好用的特性；

8.可以调整需求，允许重用已有的软件组件；

9.当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估；

10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

软件客户需求义务书

1.给分析人员讲解业务及说明业务方面的术语等专业问题；

2.抽出时间清楚地说明需求并不断完善；

3.当说明系统需求时，力求准确详细；

4.需要时要及时对需求做出决策；

5.要尊重开发人员的成本估算和对需求的可行性分析；

6.对单项需求、系统特性或使用实例划分优先级；

7.评审需求文档和原型；

8.一旦知道要对项目需求进行变更，要马上与开发人员联系；

9.在要求需求变更时，应遵造开发组织确定的工作过程来处理；

10.尊重需求工程中开发人员采用的流程（过程）。

软件项目视图和范围

编者说明：

项目所涉及的内容与所解决的问题都是有限的，而且项目应该是十分有目的性的，是为了实现某个可度量的目标而做的。因此，在需求分析的前期应该将“项目的目标与范围”这一项目的本质文档化，让每一个项目成员对其达成共识。该文档是十分重要，但却又是十分容易被忽视的。该文档模板比较适用于定制开发项目。

1.业务需求

[业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同产品可能会有不同的侧重点。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购卖者带来的利益。]

1.1 背景

[在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。]

1.2 业务机遇

[描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。]

1.3 业务目标

[用一个定量和可测量的合理方法总结产品总结产品所带来的重要商业利润。关于给客户带来的价值在后面阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。]

1.4 客户或市场需求

[描述一些典型客户的需求，包括不满足现在市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写到列表中，可以反过来跟踪调查特殊用户和功能需求。]

1.5 提供给客户的价值

[确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：

Ø 提高生产效率，减少返工；

Ø 节省开支；

Ø 业务过程的流水线化；

Ø 先前人工劳动的自动化；

Ø 符合相关标准和规则；

Ø 与目前的应用产品相比较，提高了可用性或减少了失效程度。]

1.6 业务风险

[总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。]

2.项目视图的解决方案

[文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。这部分不包括详细的功能需求和项目计划信息。]

2.1 项目视图陈述

[编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场企业框架。组织的战略方向和资源局限性为基础。]

[如："化学制品跟踪系统"可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。系统可随时了解公司每一个化学制品容器所处的位置，容器中所剩余的药品剂量，任何时候每个容器所处的位置和用法的历史记录。通过充分利用公司内部的可用化学制品，废弃极少量已使用或过期失效的化学制品，使用标准的化学制品的购买过程等将在化学制品上节省25%开支。"化学制品跟踪系统"还能产生符合政府部门规定所要求的全部报表，包括化学制品的使用、存储和废弃等报表。]

2.2 主要特征

[包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。]

2.3 假设和依赖环境

[在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。如果你把它们都记录下来，并加以评论，就能对项目内部隐含的基本假设达成共识。比如，"化学制品跟踪系统"的开发者假设：该系统可以替代现有的仓库存货系统，并能与有关采购部门的应用相连接。把这些都记录下来以防止将来可能的混淆和冲突。还有，记录项目所依赖的主要环境，比如：所使用的特殊的技术、第三方供应商、开发伙伴及其它业务关系。]

3.范围和局限性

[项目范围定义了所提出的解决方案和概念和适用领域，而局限性则指出产品所不包括的某些性能。如果一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。记录这些需求以及拒绝它们的原因，以待查。]

3.1 首次发行的范围

[总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。应当避免将想到的每一个特性都包括到1.0版本产品中去。开发者应把重点放在能提供最大价值、花花费最合理的开发费用及普及率最高的产品上。]

3.2 随后发行的范围

[如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。]

3.3 局限性和专用性

[明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。]

4.业务环境

[这一部分总结了一些项目的业务问题。]

4.1 客户概貌

[客户概述明确了这一产品的不同类型客户的一些本质特点，以及目标市场部门和在这些部门中的不同客户的特征。对于每一种客户类型，概述要包括：

Ø 各种客户类型将从产品中获得的主要益处；

Ø 它们对产品所持的态度；

Ø 感兴趣的关键产品的特性；

Ø 哪一类型客户能成功使用；

Ø 必须适应任何客户的限制。]

4.2 项目的优先级

[一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。在所给的项目中，其每一方面应与下面三个因素之一相适应。

Ø 一个驱动----一个最高级别的目标；

Ø 一个约束----项目管理者必须操纵一个对象的限制因素；

Ø 一个自由度----项目管理能权衡其它方面，进而在约束限制的范围内完成目标的一个因素。

未必所有的因素都能成为驱动，或所有的因素都能成为约束因素。在项目开始时记录和分析哪一个因素适用于哪一类型，将有助于使每一个人的努力和期望与普遍认可的优先级相一致。]

5.产品成功的因素

[明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括我部素。如果可能，可建立测量的标准，用于评价是否达到业务目标，如：市场股票、销售量及收入、客户满意度、交易处理量和准确度。]

项目构想[XuFeng1]

编者说明：

这个文档模板与“软件项目视图与范围”文档的功能十分接近，只不过该文档更适合于产品型项目。其注重对项目的用户、市场进行分析，紧抓项目相关人员（也叫做风险承担者）的需求的本质。

1.文档简介

[软件需求规格说明书的整个内容还是锁定于整个系统的操作、使用层面之上的功能性需求，只是解决了How的问题，而并未回答Why的问题。这使得系统在开发过程中，开发团队经常陷入知其然，而不知其所以然的困境，造成了不必要的误解与错误。因此，需要一个侧重于对项目的风险承担者、目标用户需要的文档，不仅要了解他们需要的功能，还要找到他们提出这些需求的原因。这就是“项目构想”文档所要描述的重要内容。]

[本节的内容主要是提供项目构想文档的目的、范围、定义、参考资料以及对其的摘要性概述。]

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.其他产品需求

[一些要求符合的标准、硬件基础要求、软件基础要求、环境要求等。]