需求规格说明书模版经典文档格式.docx
《需求规格说明书模版经典文档格式.docx》由会员分享，可在线阅读，更多相关《需求规格说明书模版经典文档格式.docx（48页珍藏版）》请在冰豆网上搜索。
10.观感需求20
10.1.外观需求20
10.2.风格需求20
11.易用性和人性化需求21
11.1.易于使用的需求21
11.2.个性化和国际化需求21
11.3.学习的容易程度22
11.4.可理解性和礼貌需求23
11.5.可用性需求23
12.执行需求23
12.1.速度和延迟需求23
12.2.安全性至关重要的需求24
12.3.精度需求24
12.4.可靠性和可访问性需求25
12.5.健壮性或容错需求25
12.6.容量需求25
12.7.可伸缩性和可扩展性需求26
12.8.寿命需求26
13.操作需求26
13.1.预期的物理环境26
13.2.与相邻系统接口的需求27
13.3.产品化需求27
13.4.发布需求27
14.可维护性和支持需求28
14.1.可维护性需求28
14.2.支持需求28
14.3.适应能力需求28
15.安全性需求29
15.1.访问控制需求29
15.2.完整性需求29
15.3.隐私需求30
15.4.审计需求30
15.5.免疫力需求30
16.文化和政策需求31
16.1.文化需求31
16.2.政策需求31
17.法律需求32
17.1.合法需求32
17.2.标准需求32
18.开放式问题33
19.立即可用的解决方案33
19.1.已经做好的产品33
19.2.可复用的组件33
19.3.可以复制的产品33
20.新问题34
20.1.对当前环境的影响34
20.2.对已实施的系统的影响34
20.3.潜在的用户问题34
20.4.预期的实现环境会存在什么限制新产品的因素35
20.5.后续问题35
21.任务35
21.1.项目计划35
21.2.开发阶段计划36
22.迁移到新产品36
22.1.迁移到新产品的需求36
22.2.为了新系统，哪些数据必须修改或转换36
23.风险37
24.费用37
25.用户文档和培训38
25.1.用户文档需求38
25.2.培训需求38
26.后续版本需求39
27.关于解决方案的设想39
1.项目的目标
1.1.该项目工作的用户业务或背景
内容
内容、动机、例子和考虑。
对开展的业务、它的上下文以及触发开发工作的情况的简短描述。
同时也应描述用户希望用提交的软件来完成怎样的工作。
动机
没有这项陈述，项目就失去了理由和方向。
考虑
应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。
1.2.项目的目标
用一句话或很少的几句话来说明“我们希望该产品做什么？
”在这里指出开发该产品的真正原因。
存在这样的危险，即在开发过程中迷失这个目标。
随着开发工作的进行，随着顾客和开发者不断发现更多的可能性，系统可能在建造过程中偏离最初的目标。
这不是件好事，除非客户有意要改变目标。
有可能需要指定一个人作为目标的管理员，但是，将目标公开并定期提醒开发人员注意这些目标可能就足够了。
在每次复查会议上都应该强制承认这些目标。
例子
“我们希望对顾客通过电话下订单订购我们的产品做出立即和完整的响应”
“我们希望能够预报天气”
测试指标
任何合理的目标都必须可能评估。
如果希望测试项目是否成功，这一点是必需的。
评估指标必须对业务通过这个项目所获得的好处进行量化。
如果项目值得去做，就必须有过硬的业务理由。
例如，如果这个项目的目标是：
我们必须问一下这个目标给组织机构带来的好处。
如果立刻得到的反应是让顾客更满意，那么必须量化这种满意。
例如，应该测量回头业务的增长（基于“开心的顾客会再次光顾”这一事实）、调查表中顾客满意评分的增加、回头顾客所带来的收入增加等。
稳定建立起这个目标，目标合理并且可以评估，这对于后续开发是至关重要的。
2.客户、顾客和其他风险承担者
2.1.客户
这一项给出了客户的姓名。
有多个姓名是允许的，但是如果姓名超过3个，本项就会失去意义。
客户对接受该产品有最终决定权，因此必须对提交的产品满意。
可以认为顾客是对产品进行投资的人。
如果产品是作为内部使用来开发的，客户和顾客的角色由相同的人来担当。
如果无法找到一个客户的姓名，那么也许就不应该构建该产品。
如果为外部用户构建一个软件包或产品，客户是市场部门，在这种情况下，来自于市场部门的一个人必须人作为客户，并记下姓名。
2.2.顾客
打算购买该产品的人。
对内部使用的开发来说，顾客和客户是相同的人。
本节包含有可能购买该产品的人的分类描述。
顾客最终决定是否从客户那里购买该产品。
只有理解了顾客以及他在使用产品时的期望，才能收集到正确的需求。
2.3.其他风险承担者
其他的一些人或组织机构的角色和名称（如果可以得到），他们或者受到产品的影响，或者需要他们提供输入信息以便构建产品。
例如，风险承担者可能包括：
●发起人；
●测试人员；
●业务分析师；
●技术专家；
●系统设计人员；
●市场专家；
●法律专家；
●领域专家；
●易用性专家；
●外部机构的代表。
对于每一类风险承担者，提供下面的信息：
●风险承担者标识（角色、职务、人名和组织机构名称的组合）
●项目需要的知识
●风险承担者/知识组合的涉及程度
●风险承担者/知识组合的影响程度
●在相同知识方向具有兴趣的风险承担者之间处理冲突的协议。
不能找齐所有的风险承担者会导致遗漏需求。
3.产品的用户
3.1.产品的直接操作用户
产品的特殊类型的风险承担者列表——潜在用户或操作员的列表。
针对每种类型的用户，提供以下信息：
●用户姓名/分类：
最可能是一个用户团体的名称，如学校里的儿童、道路工程师或项目经理；
●用户工作的角色：
总结用户的职责；
●主题相关的经验：
总结用户在业务方面的知识，按照新手、熟练工或专家来评级；
●技术经验：
描述用户在相关技术方面的经验，按照新手、熟练工或专家来评级；
●其他用户特征：
描述任何可能对产品的需求和最终设计产生影响的其他特征。
例如：
身体能力/障碍、智力能力/障碍、对工作的态度、对技术的态度、教育程度、语言技能、年龄段、性别等。
用户为了完成工作而与产品交互的人。
利用用户的特征来确定产品的易用性需求。
用户也被称为参与者。
用户的来源可能很广，有时甚至预料不到。
考虑用户可能是办公室职员、商店职员、经理、接受过专门训练的操作员、普通公众、随意的用户、过路人、文盲、手工艺人、学生、测试工程师、外国人、儿童、律师、远程用户、通过电话线或因特网使用该产品的人、救险工作人员等。
3.2.对用户设定的优先级
在每类用户后面附上一个优先级，用于区别用户的重要性和优先地位。
按以下优先级划分用户：
●关键用户：
这些用户对产品的后续成功是至关重要的。
由这类用户提出的需求有更高的重要性。
●次要用户：
他们将使用该产品，但他们的意见对产品的长期成功并无影响。
如果次要用户的需求和关键用户的需求发生冲突，应该优先考虑关键用户的需求。
●不重要的用户：
这类用户的优先级是最低的，这包括不常用的、未授权的和没有技能的用户，以及误用了该产品的用户。
这种类型的用户所占的百分比——目的是评估这类用户要考虑多少。
如果认为某些用户对产品或组织更重要，那么应该写明，因为这会影响设计该产品的方式。
例如，我们需要知道，是否有一个很大的顾客曾经特别询问过该产品，并且如果他们得不到想要的东西，结果会造成严重的业务损失。
某些用户可能被列为对产品没有重要影响的类别，这表示这类用户会使用该产品，但在产品中没有被赋予利益。
换言之，这些用户不会报怨，也不会对产品做出什么贡献。
来自于这些用户的任何特殊需求都只有较低的设计优先级。
3.3.用户参与程度
如果合适，在每一类用户后面附上参与程度的说明，用户将以这样的程度参与提供需求。
描述希望这些用户提供的贡献——例如，业务知识、界面原型，或易用性需求等。
如果可能，评估为了能够确定完整的需求，这些用户至少必须花多少时间。
许多项目因为缺少用户参与而失败，有时候是因为要求的参与程序没有明确。
如果用户必须在完成他们的日常工作和进行新项目之间进行选择，日常工作通常处于优先位置。
这项需求从一开始就明确，具体的用户资源必须分配给用户。
3.4.维护用户和服务技术人员
维护用户是特殊类型的直接操作用户，他们的需求集中在产品的维护和变更上。
许多这类需求将通过考虑不同类型的维护需求来发现，确定了维护人员的特征，就有助于触发一些可能遗漏的需求。
4.强制的限制条件
本节描述对产品最终设计的限制条件。
除了限制条件是强制的以外，其他的一样。
通常在项目的开始就知道这些限制条件。
限制条件有描述、理由和验收标准，编写的格式一般与功能性需求和非功能性需求的格式一样。
4.1.解决方案的限制条件
明确限制条件，规定解决问题必须采取的方式。
描述强制使用的技术或解决方案。
包括适用的版本号，还应该解释使用该技术的原因。
动机是确定指导最终产品的限制条件。
客户、顾客或用户可能有一些设计偏好，或者只有特定的解决方案才可以接受。
如果不满足这些限制条件，解决方案将不会被接受。
限制条件与其他原子需求的写法一样（属性可参考白雪卡）。
每项限制条件都要有理由和验收标准，这很重要，因为有助于暴露出假限制条件（解决方案冒充限制条件）。
同时，通常也会发现限制条件会影响整个产品，而不是一个或几个产品用例。
描述：
产品应该使用目前的双向无线电系统与卡车中的驾驶员通讯。
理由：
客户不会花钱买新的无线电系统，也没有其他与驾驶员通讯的方式。
验收标准：
产品产生的所有信息号都要通过他们的双向无线电系统让所有驾驶员听到并理解。
产品应该使用windowsXP操作系统。
客户使用XP，不愿意更换。
产品应该由MS测试小组认证是与XP兼容的。
产品应该是一个手持设备。
产品将销售给徒步旅行者和登山者。
产品应该不超过300克重，没有哪一维超过15厘米，应该不需要外部电源。
我们希望定义一个边界，在此边界范围内我们可以解决问题。
注意，任何人如果有在某项技术方面的经验，都会倾向于从该项技术的角度来看需求。
这种倾向性导致人们出于错误的原因强加一些解决方案限制条件，假限制条件很容易就潜入到需求规格说明书中。
解决方案限制条件应该只限于那些绝对不可商榷的解决方案。
换言之，不论如何解决这个问题，都必须使用这种特定的技术，其他任何解决方案都是不可接受的。
4.2.当前系统的实现环境
描述安装产品的技术环境和物理环境。
这包括自动的、机械的、组织的和其他设备，以及非人员的相邻系统。
动机是描述产品必须适应的技术环境。
该环境成为产品的设计限制条件。
需求规格说明书的这一部分为设计者提供了足够的环境信息，以使产品能成功地与它周围的技术实现互操作。
操作需求是从这部分导出的。
当前系统的所有组织部分，无论是何种类型，都应该包含在实现环境的描述中。
如果产品将会影响当前组织，或对当前组织很重要，在此处将包括一张组织机械图。
4.3.伙伴应用或协作应用
描述那些不属于产品的一部分的应用程序，但产品必须与这些应用程序协作。
这些可能是外部应用程序、商业软件包或已存在的内部应用程序。
动机是提供由于伙伴应用程序引起的设计限制条件信息。
通过描述这些伙伴应用或对它们建模，将发现潜在的集成问题并对它们加以重视。
这一部分可以通过包含书面的描述、模型或对其他规格说明书的引用来完成。
描述必须包含对产品有影响的所有接口的完整规格说明。
查看工作上下文范围模型，以确定是否某个相邻系统应该被作为伙伴应用对待。
也可能需要查看某些工作细节来发现相关的伙伴应用。
4.4.立即可用的软件
描述商业的、开源的、或其他立即可用的软件（OTS），这些软件必须用于实现产品的某些需求。
也包含采用非软件的立即可用的构件，如硬件或其他商业产品，作为解决方案的一部分。
动机是确定描述商业的、免费的、开源的或其他产品，它们将成为最终产品的一部分。
这些产品的特征、行为和接口是设计的限制条件。
这一部分可以通过包含书面的描述、模型或对提供者的规格说明书的引用来完成。
在收集需求时，您可能会发现需求与该OTS软件的行为和征有冲突。
请记住使用OTS产品是在全部需求已知之前就强制决定的。
因为这一发现，必须考虑该OTS软件是否是一个可行的选择。
如果使用该OTS软件是不可商榷的，那么冲突的需求必须放弃。
注意，发现需求的策略会受到使用OTS的决定的影响。
在这种情况下，调查工作上下文范围和比较OTS产品的能力是并行进行的。
根据OTS软件的全面程度，也许可以去发现匹配和不匹配之处，而不必以原子细节的方式编写每项业务需求。
不匹配之处就是要确定的需求，这样就可以决定是通过修改OTS软件来满足这些需求，还是修改这些业务需求。
既然在软件领域有如此之多的诉讼，就应该考虑使用OTS是否会让自己卷入法律诉讼。
4.5.预期的工作地点环境
描述用户工作和使用该产品的工作地点。
此处应该描述任何可能对产品设计产生影响的工作地点特征，以及工作地点的社会和文化环境。
动机是确定工作地点的特点，这样产品可以为补偿一些困难条件而设计。
打印机离用户的桌子有一定的距离。
这个限制条件暗示不应该强调打印输出。
工作场地比较嘈杂，所以声音信号可能不起作用。
工作场地在户外，所以产品必须适应各种天气状况，显示信息要在阳光下也能看得见，如果有纸张输出，应该考虑风的影响。
产品将用在图书馆中，它必须特别安静。
产品是一台影印机，用在特别关心环境的机构中，它必须能使用再生纸。
用户会站立工作，或者会拿着该产品工作。
这意味着应该是一个手持产品，但只有仔细研究了用户的工作和场地后，才能提供确定操作需求所需的输入信息。
物理工作环境限制了工作完成的方式。
产品应该克服存在的任何困难，但是可以考虑重新设计工作场地，而不是让产品来满足它。
4.6.进度计划限制条件
任何已知的最后期限，或商业机会的时限，都应该在此处说明。
动机是确定会影响产品需求的关键时间和日期。
如果最后期限的时间很短，那么需求必须保持在构建时间允许的范围之外。
●为了按时发布软件；
●可能有其他部分的业务或其他软件产品依赖于该产品；
●市场商业机会的时限；
●计划好的业务变更将使用这个产品。
例如，组织机构将启用一个新工厂，在开始生产之前需要该产品。
通过给出日期并描述为什么它是关键的，说明存在最后期限。
同时也会确定最后期限之前的一些日期，在这些日期里应该可以提供产品的某些部分用于测试。
也应该对不能遵守最后期限所带来的影响问一些问题：
●如果我们不能在XXX之前完成构建产品，会发生什么？
●如果我们不能在XXX之前拥有该产品，在财务上会发生什么冲击？
4.7.该产品的财务预算是多少
该产品的预算，以金钱或可得资源的形式来说明。
需求不能超出预算。
这可能限制了产品能包含的需求的数量。
在预算范围内构建产品是否实际？
如果答案是否定的，则要么客户并没有真正下决心构建该产品，要么是客户没有在该产品上投入足够的价值。
不论哪种情况，都应该考虑是否值得继续下去。
5.命名惯例和定义
5.1.定义在项目中使用的所有术语，包括同义词
一个词汇表，包括在需求规格说明书中使用的所有名称的含义。
选择名称要小心，避免不同的、不希望的含义。
这个词汇表反映出工作领域当前使用的术语。
也可以基于在您的行业中使用的标准名称。
对于每一项，编写一个简洁的定义。
相应的风险承担者必须同意这个定义。
避免使用缩写，因为缩写会带来二义性，需要额外的解释，有可能在试图理解需求的人的头脑中引起误解。
要求需求分析师用正确的术语取代所有的缩写。
这用字处理软件是很容易做到的。
如果定义中有完全的解释，同义词是可以接受的。
名称十分重要，它们能反映含义，如果定义得好，可以省掉数小时的解释。
在项目的这个阶段注意名称将有助于尽早澄清一些误解。
在需求阶段得到的词汇表将在整个项目中使用并不断补充。
卡车：
在冬季，将除冰物质散布到道路上的运输工具。
“卡车”不是指运送货物的运输工具。
BIS：
商务智能服务。
StevenPeter管理的部门，对机构的其他部门应用商务智能。
利用已有的参考资料和数据字典。
显示，最好不要对已有的术语进行重命名，除非它们很模糊，容易引起歧义。
在项目的开始就要强调避免有二义性的词和同义词，解释它们会增加项目的成本。
5.2.所有包含模型的数据字典
字典定义了模型中使用的所有流动和存储的信息。
特别应该考虑定义上下文模型中所有信息流的数据属性。
这一节也应该包含上下文模型中展示的所有接口的技术规格说明。
上下文范围图提供了要研究的工作的范围或要构建的产品的范围的准确定义。
只有确定了范围边界上的信息流的数据属性，这个定义才能完全准确。
道路除冰调度计划=问题编号+{路段标识符+处理开始时间+关键开始时间+卡车标识符}+车库标识符
在编写需求规格说明的过程中，可详细定义每个基本术语。
字典提供了需求分析师与实现者之间的联系。
实现者为字典中的术语加上实现细节，确定数据将如何实现。
同时，实现者还会加入由于选择的技术而存在的术语，这些术语与业务需求无关。
6.相关事实和假设
6.1.事实
事实是可能对产品产生影响的因素，但不是强制性的需求限制条件。
它们可以是业务规则、组织系统，或任何对这个产品有影响的活动。
事实是希望规格说明书的读者都知道的事情。
相关事实为规格说明书的读者提供了背景信息，可能对需求有所贡献。
它们将对该产品的最终设计产生影响。
●一吨除冰物质将处理3英里的单车道路面；
●现存应用程序是用10000行C代码组成的。
6.2.假定
开发者所做的假字的清单。
这些假定可能是关于预期的操作环境的，也可以是任何对产品有影响的事情。
作为管理预期的一部分，假定还包含关于产品不会做什么的说明。
让人们声明他们所做的规定。
同时，让项目中的每个人意识到所做的假定。
●关于新的法律或政策决定的假定；
●关于开发者预期到时候会准备好供他们使用的东西的假定。
例如，产品的其他部分、其他项目的完成、软件工具、软件组件等；
●关于产品将操作的技术环境的假定，这些假定应该突出那些期望兼容的领域；
●开发者可获得的软件组件；
●可与本产品同时开发的其他产品；
●采购的组件的可获得性和能力；
●对此项目以外的计算机系统或人员的依赖性；
●产品不会特别实现的那些需求。
我们常常无意识地做出假定。
有必要与项目团队的成员交谈，以发现他们所做的任何无意识的假定。
询问风险承担者（包括技术上的和业务相关的）以下问题：
●预计会得到哪些软件工具？
●会有任何新的软件产品吗？
●预计会用一种新的方式来使用现有的一个产品吗？
●是否认为我们将能够处理一些业务变更？
在项目早期声明这些假定是很重要的。
也可以考虑假定正确的可能性，如果可能的话，列出假如假定没有发生时可以采取的其他选择。
这些假定应该是暂时性的，也就是说，在规格说明书发布时，它们应该都得到澄清——假定应该成为一项需求或一项限制条件。
例如，如果假定与一个伙伴产品的功能有关，那么这种功能应该已经证实是具备的，这成为使用它的一项限制条件。
相反，如果购买的产品不合适，那么构建所需的功能就会成为项目团队的一项需求。
7.工作的范围
7.1.当前的状况
这是对原有业务处理过程的分析，包含人工的和自动的处理过程，这些过程可能被新产品取代或改变。
作为项目业务用例分析的一部分，业务分析师可能已经完成了这方面的调研。
如果项目打算对原有的人工或自动化系统进行变更，那么就需要理解建议的变更所带来的影响。
研究当前的状况为理解建议所带来的影响并选择最佳的替代方案提供了基础。
7.2.工作的上下文范围
工作上下文范围图确定了构建该产品需要调查的工作。
注意这包括的范围超出了目标产品。
如果我们不了解产品将支持的工作，就不太可能构建与它的环境无缝集成的产品。
动机是清楚地定义工作研究和需求工作的边界。
如果没有这种定义，我们就不太可能构建与它的环境无缝集成的产品。
上下文范围图中使用的名称应该与前面所提及的命名惯例和数据字典定义保持一致。
如果没有这些定义，上下文范围模型就缺少必需的严格性，有可能被误解。
相关的风险承担者必须同意上下文模型中展示的接口的定义。
下图中的相邻系统（例如气象预报服务）说明了需要理解的其他主题相关的领域（系统、人和组织）。
相邻系统与工作上下文范围之间的接口说明了为什么我们对相邻系统有兴趣。
对地区气象预报服务来说，我们关心它何时、如何、在何处、为谁、怎样以及为何产生地区天气预报信息。
7.3.工作切分
一个事件清单，确定工作系统要响应的所有业务事件，如下表所示。
业务事件是真实世界中发生的对工作产生影响的事情。
当到了工作做某事的时间时，也会发生业务事件——例如，产生每周的报表，提醒没有付款的顾客，检查设备的状态等。
对每个事件的反应被称为一个业务用例，它代表了一部分工作，对整体工作的功能做出贡献。
该事件清单包括下列元素：
●事件名称；
●来自相邻系统的输入；
●对相邻系统的输出；
●对业务用例的简单总
升级会员 