集团办公自动化系统需求文档.docx

集团办公自动化系统需求文档.docx

《集团办公自动化系统需求文档.docx》由会员分享，可在线阅读，更多相关《集团办公自动化系统需求文档.docx（50页珍藏版）》请在冰豆网上搜索。

集团办公自动化系统需求文档

需求分析类文档模板

编者说明：

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

软件客户需求权利书

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项目视图陈述

[编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。

项目视图陈述将考虑权衡有不同需求客户的看法。

它可能有点理想化，但必须以现有的或所期待的客户市场企业框架。

组织的战略方向和资源局限性为基础。

]51aspx提供下载

[如：

"化学制品跟踪系统"可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。

系统可随时了解公司每一个化学制品容器所处的位置，容器中所剩余的药品剂量，任何时候每个容器所处的位置和用法的历史记录。

通过充分利用公司内部的可用化学制品，废弃极少量已使用或过期失效的化学制品，使用标准的化学制品的购买过程等将在化学制品上节省25%开支。

"化学制品跟踪系统"还能产生符合政府部门规定所要求的全部报表，包括化学制品的使用、存储和废弃等报表。

]

2.2主要特征

[包括新产品将提供的主要特性和用户性能的列表。

强调的是区别于以往产品和竞争产品的特性。

可以从用户需求和功能需求中得到这些特性。

]

2.3假设和依赖环境

[在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。

通常一方所持的假设应与另一方不同。

如果你把它们都记录下来，并加以评论，就能对项目内部隐含的基本假设达成共识。

比如，"化学制品跟踪系统"的开发者假设：

该系统可以替代现有的仓库存货系统，并能与有关采购部门的应用相连接。

把这些都记录下来以防止将来可能的混淆和冲突。

还有，记录项目所依赖的主要环境，比如：

所使用的特殊的技术、第三方供应商、开发伙伴及其它业务关系。

]

3.范围和局限性

[项目范围定义了所提出的解决方案和概念和适用领域，而局限性则指出产品所不包括的某些性能。

如果一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。

记录这些需求以及拒绝它们的原因，以待查。

]

3.1首次发行的范围

[总结首次发行的产品所具有的性能。

描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。

应当避免将想到的每一个特性都包括到1.0版本产品中去。

开发者应把重点放在能提供最大价值、花花费最合理的开发费用及普及率最高的产品上。

]

3.2随后发行的范围

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

]

3.3局限性和专用性

[明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。

列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。

]

4.业务环境

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

]

4.1客户概貌

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

对于每一种客户类型，概述要包括：

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

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

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

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

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

]

4.2项目的优先级

[一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。

达到这一目的的一个途径是考虑软件项目的五个方面：

性能、质量、计划、成本和人员。

在所给的项目中，其每一方面应与下面三个因素之一相适应。

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

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

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

未必所有的因素都能成为驱动，或所有的因素都能成为约束因素。

在项目开始时记录和分析哪一个因素适用于哪一类型，将有助于使每一个人的努力和期望与普遍认可的优先级相一致。

]

5.产品成功的因素

[明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。

不仅要包括组织直接控制的范围内的事务，还要包括我部素。

如果可能，可建立测量的标准，用于评价是否达到业务目标，如：

市场股票、销售量及收入、客户满意度、交易处理量和准确度。

]

项目构想

编者说明：

这个文档模板与“软件项目视图与范围”文档的功能十分接近，只不过该文档更适合于产品型项目。

其注重对项目的用户、市场进行分析，紧抓项目相关人员（也叫做风险承担者）的需求的本质。

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 项目相关人员一览表

[使用下面的表格，对项目相关人员进行分析。

]

人