模板3信息化项目需求分析说明书13页.docx
《模板3信息化项目需求分析说明书13页.docx》由会员分享，可在线阅读，更多相关《模板3信息化项目需求分析说明书13页.docx（13页珍藏版）》请在冰豆网上搜索。
模板3信息化项目需求分析说明书13页
信息化项目需求分析说明书大纲模板
课本、报刊杂志中的成语、名言警句等俯首皆是,但学生写作文运用到文章中的甚少,即使运用也很难做到恰如其分。
为什么?
还是没有彻底“记死”的缘故。
要解决这个问题,方法很简单,每天花3-5分钟左右的时间记一条成语、一则名言警句即可。
可以写在后黑板的“积累专栏”上每日一换,可以在每天课前的3分钟让学生轮流讲解,也可让学生个人搜集,每天往笔记本上抄写,教师定期检查等等。
这样,一年就可记300多条成语、300多则名言警句,日积月累,终究会成为一笔不小的财富。
这些成语典故“贮藏”在学生脑中,自然会出口成章,写作时便会随心所欲地“提取”出来,使文章增色添辉。
[本章着重讨论信息化项目需求分析（SRS）的每一个基本部分，可以作为一个SRS的大纲。
各开发者和客户应当根据所描述的实际情况，按本模板有关规定编写自己的SRS。
]
要练说，得练看。
看与说是统一的，看不准就难以说得好。
练看，就是训练幼儿的观察能力，扩大幼儿的认知范围，让幼儿在观察事物、观察生活、观察自然的活动中，积累词汇、理解词义、发展语言。
在运用观察法组织活动时，我着眼观察于观察对象的选择，着力于观察过程的指导，着重于幼儿观察能力和语言表达能力的提高。
1前言（编制说明见第1章）
“师”之概念，大体是从先秦时期的“师长、师傅、先生”而来。
其中“师傅”更早则意指春秋时国君的老师。
《说文解字》中有注曰：
“师教人以道者之称也”。
“师”之含义，现在泛指从事教育工作或是传授知识技术也或是某方面有特长值得学习者。
“老师”的原意并非由“老”而形容“师”。
“老”在旧语义中也是一种尊称，隐喻年长且学识渊博者。
“老”“师”连用最初见于《史记》，有“荀卿最为老师”之说法。
慢慢“老师”之说也不再有年龄的限制，老少皆可适用。
只是司马迁笔下的“老师”当然不是今日意义上的“教师”，其只是“老”和“师”的复合构词，所表达的含义多指对知识渊博者的一种尊称，虽能从其身上学以“道”，但其不一定是知识的传播者。
今天看来，“教师”的必要条件不光是拥有知识，更重于传播知识。
[本章提供整个SRS综述。
]
1.1目的（编制说明的1.1条）
1）目的
2）预期的读者
1.2范围（编制说明的1.2条）
[本条应包括：
1）通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源（可能占整个产品开发成本的10%-20%以上）。
可选择：
①用一个名字标识被生产的软件产品。
比如：
×××数据库系统，报表生成程序等等。
②说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么。
2）描述所说明的软件的应用。
应当：
●尽可能精确地描述所有相关的利闪、目的、以及最终目标。
●如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
]
1.3定义、缩写词、略语（编制说明的1.3条）
[本条中必须提供全部需求的术语、缩写词及略语的定义，以便对SRS进行适当的解释。
这些信息可以由SRS的附录提供。
也可以参考其他的文件。
]
1.4参考资料（编制说明的1.4条）
[本条应包括：
1）在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关批文、合同等；
2）列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。
每一个文件、文献要有标题，索引号或文件号，发布或发表日期以及出版单位；
3）详细说明可以得到该参考文件的来源。
这个信息可以通过引用附录或其他文件提供。
]
2项目概述（编制说明的第2章）
本章应描述影响产品和其需求的一般因素，本章不说明具体的需求，而仅使需求更易于理解。
2.1产品描述（编制说明的2.1条）
[这一条是把一个产品用其他有关的产品或项目来描述。
1）如果这个产品是独立的，而且全部内容自含，应在此说明；
2）如果SRS定义的产品是一个较大的系统或项目中的一个组成部分，那么本条应包括如下内容：
●要概述这个较大的系统或项目的每个组成部分的功能，并说明其接口；
●指出该软件产品主要的外部接口。
在这里，不要求对接口详细地描述，详细描述放在SRS其他章条中；
●描述所使用的计算机硬件、外围设备。
这里仅仅是一个综述性描述。
在本条的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
本条既不用来强迫进行设计方案的描述，也不是描述在解决问题时的设计约束。
本条应对在以后具体需求一章中说明的设计约束提供理由。
]
2.2产品功能（编制说明的2.2条）
[本条是为将要完成的软件功能提供一个摘要。
例如，对于一个记帐程序来说，SRS可以用这部分来描述：
客户帐目维护、客户财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。
有时，如果存在较高层次的规格说明时，则功能摘要可直接从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意：
1）编制功能的一种方法是制作功能表，以便客户或者第一次读这个文件的人都可以理解；
2）用方框图来表达不同的功能和它们的关系也是有帮助的。
但要牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。
这一条不用作陈述具体需求，只是对后来SRS中具体需求一章中为什么要描述的某些需求提供理由。
]
2.3用户特点（编制说明的2.3条）
[本条要描述影响具体需求的产品的最终用户的一般特点。
许多人在软件生存周期的操作和维护阶段与系统相关。
而这些人中有用户、操作员、维护人员和系统工作人员。
这些人的某些特点，象教育水平、经验、技术、专长等，都是施加于系统操作环境的重要约束。
如果系统的大多数用户是一些临时用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
这一条的内容不能用来陈述具体需求或强加若干特殊的设计约束，本条应对在SRS的具体需求一章之中的某些具体需求或设计约束的描述提供理由。
]
2.4一般约束（编制说明的2.4条）
[本条对设计系统要限制开发者选择的其他一些项作一般性描述。
而这些项将限定开发者在设计系统时的任选项。
这些包括：
1）管理方针；
2）硬件的限制；
3）与其他应用间的接口；
4）并行操作；
5）审查功能；
6）控制功能；
7）所需的高级语言；
8）通信协议；
9）应用的临界点；
10）安全和保密方面的考虑。
本条不陈述具体需求或具体设计约束：
而对SRS的具体需求一章中为什么要确定某些具体需求和设计约束提供理由。
]
2.5假设和依据（编制说明的2.5条）
[本条列出影响SRS中陈述的需求的每一个因素。
这些因素不是软件的设计约束，但是它们的改变可能影响到SRS中的需求。
例如：
假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，SRS就要进行相应的改变。
]
3具体需求（编制说明的第3章）
[本章应包括软件开发者在建立设计时需要的全部细节。
这是SRS中篇幅最大和最重要的部分。
1）根据本指南第4章所规定的准则（如可验证性、无歧义性等），对每一个需求细节作具体描述；
2）在SRS的前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景；
3）具体需求分类的方法如下：
●功能需求；
●性能需求；
●设计约束；
●属性；
●外部接口需求。
本章中要注意的二点是：
1）符合逻辑的和可读的方式组织；
2）详细描述每个需求，使该需求应达到目标能够用指定的方法进行客观的验证。
]
3.1具体需求的内容
3.1.1功能需求
[本条描述软件产品依据输入怎样变换成输出。
即软件必须完成的基本动作。
对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。
这通常由四个部颁组成：
1）引言
这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。
2）输入
这部分应包括：
●详细描述该功能的所有输入数据，如：
输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）；
●操作员控制细节的需求。
其中有名字、操作员活动的描述、控制台或操作员的位置。
例如：
当打印检查时，要求操作员进行格式调整；
●指明引用接口说明或接口控制文件的参考资料。
3）加工
定义输入数据、中间参数，以获得预期输出结果的全部操作。
它包括如下的说明：
●输入数据的有效性检查；
●操作的顺序，包括事件的时间设定；
●异常情况的响应，例如，溢出、通信故障、错误处理等；
●受操作影响的参数；
●降级运行的要求；
●用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；
●输出数据的有效性检查。
4）输出
这部分应包括：
●详细描述该功能所有输出数据，例如：
输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
●有关接口说明或接口控制文件的参考资料。
此外，对着重于输入输出行为的系统来说，SRS应指定所有有意义的输入、输出对及其序列。
当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。
也就是说，这种情况犹如有限状态机。
3.1.2设计约束
设计约束受其他标准、硬件限制等方面的影响。
1）其他标准的约束：
本项将指定由现有的标准或规则派生的要求。
例如：
报表格式、数据命名、财务处理、审计追踪等等。
2）硬件的限制：
本项包括在各种硬件约束下运行的软件要求，例如，应该包括：
硬件配置的特点（接口数，指令系统等）、内存储器和辅助存储器的容量。
3.1.3属性
[在软件的需求之中有若干个属性，下面指出其中的几个（注意：
对这些决不应理解为是一个完整的清单）。
]
1）可用性：
[可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个确定的可用性级别。
]
2）安全性：
[这里指的是保护软件的要素，以防止各种非法的访问、使用，修改、破坏或者泄密。
这个领域的具体需求必须包括：
]
●利用可靠的密码技术；
●掌握特定的记录或历史数据集；
●给不同的模块分配不同的功能；
●限定一个程序中某些区域的通信；
●计算临界值的检查和。
3）可维护性：
这里规定若干需求以确保软件是可维护的。
例如：
●软件模块所需要的特殊的耦合矩阵；
●对微型装置指定特殊的数据/程序分割要求。
4）可转移/转换性：
[这里规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束等]。
5）警告：
[指定所需属性十分重要，它使得人们能用规定的方法去进行客观的验证。
]
3.1.4外部接口要求
1）用户接口：
[提供用户使用软件产品是地的接口需求。
例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：
●对屏幕格式的要求；
●报表或菜单的页面打印格式和内容；
●输入输出的相对时间；
●程序功能键的或用性。
]
2）硬件接口：
[要指出软件产品和系统硬部件之间每一个接口的逻辑特点。
还可能包括如下事宜：
支撑什么样的设备，如何支撑这些设备，有何约定。
]
3）软件接口：
[在这里应指定需使用的其他软件产品（例如，数据管理系统，操作系统，或者数学软件包），以及同其他应用系统之间的接口。
对每一个所需的软件产品，要提供名字、助记符、规格说明号、版本号、来源等内容。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，这里不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
]
4）通信接口：
[这里指定各种通信接口，例如，局部网络的协议等等。
]
3.1.5其他需求
[根据软件和用户组织的特性等，某些需求放在下面各项中描述。
]
1）数据库：
本项对作为产品的一部分进行开发的数据库规定一些需求，它们可能包括：
●在6.3.1.1条中标识的信息类别；
●用的频率；
●存取能力；
●数据元素和文卷描述符；
●数据元素、记录和文卷的关系；
●静态和动态的组织；
●数据保存要求。
注：
如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。
2）操作：
这里说明用户要求的常规的和特殊的操作。
●在用户组织之中各种方式的操作。
例如，用户初始化操作；
●交互作用操作的同期和无人操作的周期；
●数据处理支持功能；
●后援和恢复操作。
注：
这里的内容有时是用户接口的一部分。
3）场合适应性需求：
这里包括：
●对给定场合、任务或操作方式的任何数据或初始化顺序的需求进行定义。
例如，栅值，安全界限等等。
●指出场合或相关任务的特点，这里可以被修改以使软件适合特殊配制的要求。
3.2具体要求的组织
[本条通常是SRS所有部分中最大并且最复杂的部分。
]
1）可以根据软件实现功能的基本类型，将本条分成若干段。
例如：
考虑一个大的交互记帐系统，在里层可以分为操作软件（它支持近乎实时的事务处理）、支撑软件（联机功能、磁盘备份、装入磁带等等）以及诊断软件（诊断硬件、通信等），外一层是应收款帐以及应付款帐等等；
2）结构细分的目的是提高SRS的可读性，而不是进行概要设计。
对于SRS中的第3章的具体需求部分的最好的组织方案取决于所说明的软件产品的应用范围和性质。
文中最后部分提供了四种可能的组织方案。
1）大纲1中首先说明全部功能需求，然后说明四种类型的接口要求，最后是其他需求；
2）大纲2中，把对应每个特定功能的四种接口需求和该功能需求放在一起描述，然后说明其他需求；
3）大纲3中，与功能需求有关的全部内容放在一起首先说明，然后是其他需求的描述。
对每一种外部接口的需求重复上述过程；
4）大纲4中，接口需求和其余的需求作为每一个功能需求的附属部分来说明。
SRS的具体需求的组织形式必须选择可读性最好的方法来描述。
6.4支持信息
支持信息是指目录表，附录和索引。
以便使SRS易于使用。
1）目录表和索引很重要，而且应按照可以接受的好的文件规则来编写。
2）对一个实际的需求规格说明来说，若有必要应该编写附录。
附录中可能包括：
●输入输出格式样本，成本分析研究的描述或用户调查结果；
●有助于理解SRS的背景信息；
●软件所解决问题的描述；
●用户历史、背景、经历和操作特点；
●交叉访问表。
按先后次序进行编排，使一些不完全的软件需求得以完善（参见4.3.2条和4.3.3条）；
●特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。
3）6.4.3当包括附录时，SRS必须明确地说明附录是不是需求要考虑的部分。
用例说明模板1（经典模板）
编者说明：
随着UML的日益普及，用例（Usecase）分析技术也在需求实践中广泛被采用。
但是也有许多团队在使用该技术时，只画出了用例图，而缺少了用例说明，其实这是一个严重的误区。
而本模板就将指导你编写该说明。
1.用例名称
1.1简要说明
[简要说明用例的作用和目的。
该小节的篇幅不要太长。
]
2.上下文图
[在此小节中，有一个只包括本用例和所有与该用例相关的Actor和其它用例组成的，一个用例图的局部。
]
3.事件流
3.1基本流
[当Actor采取行动时，用例也就随即开始。
用例总是由Actor启动的，用例应说明Actor的行为及系统的响应，可按照Actor与系统进行对话的形式来逐步引入用例。
]
[要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。
如果进行了信息交换，则需指出来回传递的具体信息。
例如，只表述主角输入了客户信息就不够明确。
最好明确地说主角输入了客户姓名和地址。
当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。
]
[如果存在一些相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。
但是如果比较复杂，还是应该单独放在备选流小节中描述。
]
[一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。
]
3.2备选流
3.2.1第一备选流
[正如前面所述，对于较复杂的备选流应单独地说明。
]
3.2.1.1备选支流
[如果能使表达更明确，备选流又可再分为多个支流。
]
3.2.2第二备选流
[在一个用例中很可能会有多个备选流。
为了使表达更清晰，应将各个备选流分开说明。
使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。
应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。
]
4.非功能需求
[在这个小节中，主要对该用例所涉及的非功能性需求进行描述。
由于其通常很难以在事件流中进行表述，因此单列为一小节进行阐述。
这些需求通过包括法律法规、应用程序标准、质量属性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及设计约束等方面的需求。
在这些需求的描述方面，一定要注意使其可度量、可验证，否则就容易流于形式，形同摆设。
]
5.前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。
]
6.后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。
]
7.扩展点
[此用例的扩展点，通常是用例图中的extent关系。
]
用例说明模板2（单列表格式）
编者说明：
如果你觉得文本描述不够清晰，也可以采用如本文档模板所示的表格式的描述方式。
用例#
[用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。
]
使用语境
[用例目标，是一个较长的描述，甚至包括触发条件。
]
范围
[用例的设计范围，在设计时将系统作为一个黑盒来考虑。
]
级别
[概要、用户目标、子功能三者之一。
]
主执行者
[也就是该用例的主Actor，在此应列出其名称，并简要描述。
]
项目相关人员利益
项目相关人员
利益
[项目相关人员名称]
[项目相关人员取得的利益]
……
……
前置条件
[也就是激发该用例，所应该满足的条件。
]
后置条件
[也就是该用例完成之后，将执行什么动作。
]
成功保证
[描述当目标完成后，环境的变化情况。
]
触发事件
[什么引发用例，例如时间事件。
]
描述
步骤
活动
1
[在这里写出触发事件到目标完成以及清除的步骤。
]
2
[……]
3
扩展
步骤
分支动作
1a
[引起分支的条件]
[活动或子用例名称]
技术和数据变化
1
[变化列表]
用例说明模板3（双列表格式）
编者说明：
本模板是对上一模板的补充，如果你想更好地捕捉系统的响应，那么就可以采用本表格所示的格式。
有时，为了更好地捕获系统的响应，对于场景描述（主成功场景、扩展场景）在上表的基础上变成如下表所示的双列：
步骤
用户
系统
用例说明模板4（文本式）
编者说明：
相信用过用例分析技术的，对用例应该多少细有很大的疑问，而AlistairCockburn率先将其进行分级：
概要、用户目标、子功能，如果你对他的思想有认同，则该模板就适合于你。
1.用例名：
[用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。
]
2.使用语境：
[用例目标，是一个较长的描述，甚至包括触发条件。
]
3.范围：
[用例的设计范围，在设计时将系统作为一个黑盒来考虑。
]
4.级别：
[用来表示该用例是在描述哪个级别上的功能，通常包括概要、用户目标、子功能三种。
这三种级别的划分是AlistairCockburn在《编写有效用例》一书是提出的。
]
5.主执行者：
[也就是该用例的主Actor，在此应列出其名称，并给予简要描述。
]
1.项目相关人员利益
[说明该用例对项目相关人员能够带来什么好处。
]
2.前置条件：
[也就是激发该用例，所应该满足的条件。
]
3.后置条件：
[也就是该用例完成之后，将执行什么动作。
]
4.成功保证：
[描述当目标完成后，环境的变化情况。
]
5.触发事件：
[什么引发用例，例如时间事件。
]
6.主成功场景
[在这里写出触发事件到目标完成以及清除的步骤。
]
[步骤编号＃：
动作描述]
[步骤编号＃：
动作描述]
……
7.扩展：
[在这里写出扩展情况，每次写一个扩展，每个扩展都应指向主场景的特定步骤。
]
[被改变步骤条件：
动作或子用例]
[被改变步骤条件：
动作或子用例]
……
8.技术和数据变化列表
[在这里写出场景中因技术或数据变化而引起的可能分支。
]
[步骤或变化编号＃：
变化列表]
[步骤或变化编号＃：
变化列表]
……
9.相关信息
[项目所需要的所有附加信息。
]
升级会员 