许多有经验的
开发团队在开始需求调查的时候,总会将"软件客户需求权利书"和"软件客户需求义务书"提交给客户,让客户明确其权利与义务,将会对需求调研,分析的工作
带来意想不到的效果,你可以一试.
软件客户需求权利书
1.要求分析人员使用符合客户语言习惯的表达;
2.要求分析人员了解客户系 统的业务及目标;
3.要求分析人员组织需求获取期间所介绍的信息,并编写软件需求规格说明.
4.要求开发人员对需求过程中所产生的工作结 果进行解释说明;
5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度;
6.要求开发人员 产品的实现及需求都要提供建议,拿出主意.
7.描述产品使其具有易用,好用的特性;
8.可以调整需求,允许重用已有的软件组件;
9. 当需要对需求进行变更时,对成本,影响,得失有个真实可信的评估;
10.获得满足客户功能和质量要求的系统,并且这些要求是开发人员同意的.
软件客户需求权利书
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.产品成功的因素
[明确产品的成功是如 何定义和测量的,并指明对产品的成功有巨大影响的几个因素.不仅要包括组织直接控制的范围内的事务,还要包括我部素.如果可能,可建立测量的标准,用于评 价是否达到业务目标,如:市场股票,销售量及收入,客户满意度,交易处理量和准确度.]
项目构想
编者说明:
这个文档模板与"软件 项目视图与范围"文档的功能十分接近,只不过该文档更适合于产品型项目.其注重对项目的用户,市场进行分析,紧抓项目相关人员(也叫做风险承担者)的需求 的本质.
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.其他产品需求
[一些要求符合的标准,硬 件基础要求,软件基础要求,环境要求等.]
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定义
[列出本文件中用到的 专门术语的定义和外文首字母组词的原词组.]
1.4参考资料
[列出用得着的参考资料.]
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版)
编者说明:
Atlantic System Guild(www.atlsysguild.com)公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术, 是一个十分实用,完善的SRS模板.其所提供的Volere需求记录卡也十分实用,强烈推荐.
注:从Atlantic System Guild公司网站www.atlsysguild.com上获得,并稍做修改
1.产品的目标
1.1 该项目工作的用户问题或背景
[对 引发开发任务的工作和情况的描述.同时也应描述用户希望用将要交付的软件来完成的工作.]
[该节内容为该项目提供了合法的理由,你应该考虑用户的 问题是否严重,是否应该解决和为什么应该解决.]
1.2 产品的目标
[用一句话或很少的几句话来说明"我们希望该产品做什么 "换言之,即开发该产品的真正原因.
[项目如果没有一个表述清晰,易于理解的目标,就会迷失在产品开发的沙漠中.产品必须带来某种优势.典型的优 势是产品会增加组织在市场上的价值,减少运作成本,或提供更好的客户服务.这个优势应该是可度量的,这样才能够让您确定交付的产品是否达到目标.]
2. 客户,顾客和其它风险承担者
2.1 客户是为开发付费的人,并将成为所交付产品的拥有者
[这一项必须给出客户的姓名,三个以内是合理 的.]
[客户最终将接受该产品,因此必须对交付的产品满意.如果你无法找到一个客户的姓名,那么也许你就不应该构建该产品.]
2.2 顾客是将花钱购买该产品的人
[也给出姓名和相关的信息]
2.3 其它风险承担者
[其他的一些人或组织的名称,他们或者受到产品的 影响,或影响产品.]
经理或项目负责人;
业务领域专家;
技术人员;
系统开发者;
市场人员;
产品经理;
测 试和质量保证人员;
审查员,诸如安全审查员或审计人员;
律师;
10)易用性专家;
11)你所处行业的专业人员.
3. 产品的用户
3.1 产品的用户
[产品的潜在用户或操作员的列表.针对每种类型的用户,提供以下信息:]
用户分类
用户工作 的任务;
主要相关的经验;
技术经验;
其他用户特征:包括身体,智力,工作态度,对技术的态度,教育程度,语言技能,年龄,性别 等.
[用户是为了完成工作而与产品交互的人,你了解用户,就越可能提交适合用户工作方式的产品.]
3.2 对用户设的优先级
[在 每类用户后面附上一个优先级,这区别了用户的重要性和优先地位:]
关键用户:对产品的后续成功至关重要;
次要用户:他们使用产品,但对产 品的长期成功并无影响;
不重要的用户:不常用,未授权和没有技能的用户.
[如果认为某些用户对产品或组织更重要,那么应该写明,因为它会 影响你设计产品的方式.]
4.需求限制条件
4.1 解决方案限制条件
[此处明确了限制条件,它们规定了解决问题必须采取的方式. 您可以认为它们是指令式的解决方案.仔细描述该解决方案,以及测试是否符合的度量标准.如果可能,您应该解释使用该解决方案的原因.]
[换一句话 说,就是要求软件解决方案满足哪些限制条件!]
4.2 实现环境
[此处描述产品将被实施的技术环境和物理环境.]
[该环境也将成 为设计解决方案时的限制条件之一.]
4.3 伙伴应用
[此处描述那些不属于产品的一部分,但产品却又必须与其协作的应用程序.]
4.4 COTS
[此处描述实现产品需求所必须使用的COTS(商业组件).]
4.5 预期的工作场地环境
[此处描述用户工作和使用该 产品的工作场地.此处应该描述任何可能对产品设计产生影响的工作场地特征.]
4.6 开发者构建该产品需要多少时间
[任何已知的最后期 限,或商业机会的时限,应在此处说明.]
4.7 该产品的财务预算是多少
[该产品的预算,以金钱的形式或可得资源的形式说明.]
5. 命名标准和定义
[定义项目中使用到的所有术语,包括同义词.这里的内容就是一个字典,包括在需求规格说明书中使用的所有名称的含义.这个字典应该 使用你的组织或行业使用的标准名称.这些名称也应该反映出在工作领域中当前使用的术语.该字典包括项目中用到的所有名称.请仔细地选择名称,以避免传达不 同的,不期望的含义.为每个名字写下简明扼要的定义,这些定义必须经过相应的风险承担者同意.]
6.相关事实
[可能对产品产生影响的外部 因素,但不是命令式的需求限制条件.]
7.假定
[列出开发者所做的假设.]
[将所有的假设列在此的目的是让每一个项目成员都意识 到这个假设.]
8.产品的范围
8.1 工作的上下文范围
[上下文范围图用来表示将要开发的系统,产品与其它系统之间的关系,以确 定系统边界.]
8.2 工作切分
[一个事件清单,确定系统要响应的所有业务事件.清单包括:]
事件名称
输入和输出
8.3 产品边界
[你可以使用用例图(use-case)来确定了用户与产品之间的边界.]
9.功能性需求与数据需求
9.1 功能性需求
[对产品必须执行的动作的描述.]
[每个功能性需求必须有一个验收标准.]
9.2 数据需求
[与产品/系统有 密切关系的主题域相关的业务对象,实体,类的说明书.]
[进行问题域建模,生成相应的类图.]
10.观感需求
[一些与产品的用户 界面相关的需求描述.]
11.易用性需求
11.1 易于使用
[描述如何构建符合最终用户期望的产品.]
11.2 学习的容易程序
[学习使用该产品应该多容易的说明.通常是有学习时间来衡量.]
12.性能要求
12.1 速度需求
[明确 完成特定任务需要的时间,这常常指响应时间.]
12.2 安全性的需求
[对可能造成人身伤害,财产损失和环境破坏所考虑到的风险进行量化 描述.]
12.3 精度需求
[对产品产生的结果期望的精度进行量化描述.]
12.4 可靠性和可用性需求
[本节量化产品 所需的可靠性.这常常表述为允许的两次失败之间无故障运行时间,或允许的总失败率.]
12.5 容量需求
[本节明确处理的吞吐量和产品存 储数据的容量.]
13.操作需求
13.1 预期的物理环境
[本节明确产品将操作的物理环境,以及这种环境引起的任何特殊需求.]
13.2 预期的技术环境
[硬件和其它组成新产品操作环境的设备的规范.]
13.3 伙伴应用程序
[对产品必须与之交互的其它应用程序的 描述.]
14.可维护性和可移植性需求
14.1 维护该产品需要多容易
[对产品作特定修改所需时间的量化描述.]
14.2 是否存在一些特殊情况适用于该产品的维护
[关于预期的产品发布周期和发布将采取的形式的规定.]
14.3 可移植性需求
[对产 品必须支持的其他平台或环境的描述.]
15.安全性需求
15.1 该产品是保密的吗
[关于该被授权使用该产品,以及在什么样的 情况下授权等方面的描述.]
15.2 文件完整性需求
[关于需要的数据库和其他文件完整性方面的说明.]
15.3 审计需求
[关 于需要的审计检查方面的说明.]
16.文件和政策需求
[本节包括针对社会和政策的因素的规格说明,这些因素会影响产品的可接受性.如果你 开发的产品是针对外国市场的,可能要特别注意这些需求.]
[问一下是否产品的目标是你所不熟悉的文化环境,是否其它国家的人或其他类型的组织的人 会使用该产品.人们是否有与你的文化不同的习惯,节日,迷信,文化上的社会行为规范.]
17.法律需求
17.1 该产品是否受到某些法律的管制
[明确该产品的法律需求的描述.]
17.2 是否有一些必须符合的标准
[明确适用的标准和参考的详 细标准的描述.]
18.Opend问题
[对未确定但可能对产品产生重要影响的因素的问题描述.按照需求分析的术语还说,就是TBD(To Be Define)的问题.]
19.COTS解决方案
19.1 是否有一些制造好的产品可以购买
[应该调查现存产品清单,这 些产品可以作为潜在的解决方案.]
19.2 该产品是否可使用制造好的组件
[描述可能用于该产品的候选组件,包括采购的和公司自己的产 品.列出来源.]
19.3 是否有一些我们可以复制的东西
[其他相似产品的清单.]
20.新问题
20.1 新产品会在当前环境中带来什么问题
[关于新产品将怎样影响当前的实现环境的描述.]
20.2 新的开发是否将影响某些已实施的系统
[关 于新产品将怎样与现存系统协同工作的描述.]
20.3 是否我们现有的用户会受到新开发的敌对性影响
[关于现有用户可能产生的敌对性反应 的细节.]
20.4 预期的实现环境会存在什么限制新产品的因素
[关于新的自动化技术,新的组织结构方式的任何潜在问题的描述.]
20.5 是否新产品会带来其他问题
[确定我们可能不能处理的情况.]
21.任务
21.1 为提交该产品已经做了哪些事
[用来开 发产品的生命周期和方法的细节.画一个高层的过程图展示各项任务和它们之间的接口,这可能是沟通这方面信息的最好办法.]
21.2 开发阶段
[关 于每个开发阶段和操作环境中的组件的规格说明.]
22.移交
22.1 我们要让已有数据和过程配合新产品,有什么特殊要求
[一个 移交活动的列表,一个实现的时间表.]
22.2 为了新产品,哪些数据必须修改/转换
[数据转换任务清单,同时确定新产品需要转换的数 据.]
23. 风险
23.1 当你开发该产品时,要面对什么风险
23.2 你制定了怎样的偶然紧急情况计划
24.费用
[需 求的其他费用是你必须投入到产品构建中去的钱或工作量.当需求规格说明书完成时,你可以使用一种估算方法来评估费用,然后以构建所需的资金或时间的形式表 述出来.]
25.用户文档
[用户文档的清单,这些文档将作为产品的一部分交付.]
26.后续版本的需求
[这里记录下一些 希望今后版本中实现的需求.]
Volere需求记录卡
编者说明:
正如前面所述,Atlantic System Guild还提供了一个配套的Volere需求记录卡,这个记录卡十分实用.建议大家在需求调查,分析过程中,将需求记录在一系列的Volere需求记录 卡上,这个卡让你能够很好的理清需求之间的关系,需求提出的背景,用户对需求的期望,有了这些素材,整理SRS时将变得更加简单.
注:顾客满意度 是指完成该项功能顾客满意的程度,而顾客不满意度则是指未实现该功能顾客不满意的程度.
软件需求规格说明书
编者说明:
如果在需求 分析时采用了用例(Use case)技术,那么该需求规格说明书将更加符合你的需要.当然,你也可以结合Volere需求规格说明书对该模板进行必要的修改.
1. 文档概述
[该部分主要是对软件需求规格说明书文档进行基本的描述,包括该文档的目的,范围,术语定义,参考资料以及概要.]
[软件需求规 格说明书用来系统,完整地记录系统的软件需求.该软件需求说明书的基础是用例分析技术.因此该文档中应包括用例模型,补充规约等内容.]
1.1目 的
[在此小节中,主要对软件需求规格说明书的目的做一概要性说明,通常软件需求规格说明书应详细地说明应用程序,子系统的外部行为,还要说明非功 能性需求,设计约束,以及其它的相关因素.]
1.2范围
[系统是有范围的,而不是无限扩展的,对于无限扩展的需求是无法进行描述的.因 此,在本小节应该对该说明书所涉及的项目范围进行清晰的界定.指定该规格说明书适用的软件应用程序,特性或者其它子系统分组,其相关的用例模型.当然在此 也需要列出会受到该文档影响的其它文档.]
1.3 定义,首字母缩写词和缩略语
[与其它文档一样,该文档也需要将本文档中所涉及的所有术 语,缩略语进行详细的定义.还有一种可简明的做法,就是维护在一个项目词汇表中,这样就可以避免在每个文档中都重复很多内容.]
1.4参考资料
[在 这一小节中,应完整地列出该文档引用的所有文档.对于每个引用的文档都应该给出标题,标识号,日期以及来源,为阅读者查找这些文档提供足够详细的信息.]
1.5 概述
[在本小节中,主要是说明软件需求规格说明书各个部分所包含的主要内容,就像一个文章摘要一样.同时也应该对文档的组织方式进行解释.]
2. 整体说明
[在本节中,将对整个软件需求进行总体性的描述,以期让读者对整个软件系统的需求有一个框架性的认识.也就是说,该节中主要包括影响产 品及其需求的一般因素,而不列举 具体的需求.主要包括产品总体效果,产品功能,用户特征,约束,假设与依赖关系,需求子集等方面的内容.]
2.1 用例模型
[在本小节中,将列出该软件需求的用例模型,该模型处于系统级,对系统的特性进行宏观的描述.在此应该列出所有的用例和Actor的名称 列表,并且对其做出简要的说明,以及在图中的各种关系.]
2.2 假设与依赖关系
[在软件系统的开发过程中,存在许多假设和依赖关系.在 本小节中应列举出所有的重要的技术可行性假设,子系统或构件可用性假设,以及一些可行性的假设.]
3. 具体需求
[如果说第二章节是框 架,那么本节就是血肉.在本节中,应该详细列出所有的软件需求,其详细程序应使设计人员能够充分理解并且进行设计的要求,同时也应该给予测试人员足够的信 息,以帮助他们来验证系统是否满足了这些需求.整个需求的组织可以采用用例描述进行.]
3.1用例描述
[如果你使用用例建模技术,那么你 已经通过用例定义了系统的大部分功能性需求和一些非功能性需求.因此,在软件需求规格说明书只需将这些具体的用例描述,整理在一起,全部放在该小节之中. 当然也可以将用例描述做为附件,在此列出引用,只是这样做并不利于阅读.建议在组织形式上采用以"软件需求"为线索,在每个需求中,填入对应的1个或几个 用例描述.]
3.2补充需求
[由于用例毕竟主要针对功能性需求,因此还会有一些其它的补充需求遗漏,因此在本小节中就是将这些东西补充出 来.这些补充需求大部分集中在非功能需求之上,包括以下几个方面的内容:]
易用性:例如指出普通用户和高级用户要高效地执行某个特定操作所需的培 训时间;指出典型任务的可评测任务次数;或者指出需要满足的可用性标准(如IBM的CUA标准,Microsoft的GUI标准.
可靠性:包括系 统可用性(可用时间百分比,使用小时数,维护访问权,降纸模式操作等);平均故障间隔时间(MTBF,通常表示为小时数,但也可表示为天数,月数或年 数);平均修复时间(MTTR,系统在发生故障后可以暂停运行的时间);精确度(指出系统输出要求具备的精密度,分辨率和精确度);最高错误或缺陷率(通 常表示为bugs/KLOC,即每千行代码的错误数目或 bugs/function-point,即每个功能点的错误数目);错误或缺陷率(按照小错误,大错误和严重错误来分类:需求中必须对"严重"错误进行 界定,例如:数据完全丢失或完全不能使用系统的某部分功能).
性能:包括对事务的响应时间(平均,最长);吞吐量(例如每秒处理的事务数);容量 (例如系统可以容纳的客户或事务数);降级模式(当系统以某种形式降级时可接受的运行模式);资源利用情况:内存,磁盘,通信等.
其它:包括用户 界面要求,联机帮助系统要求,法律许可,外购构件,以及操作系统,开发工具,数据库系统等设计约束.
4.支持信息
[支持信息用于使软件需 求规格说明书更易于使用.它包括:目录,索引,附录等.]
计算机软件需求说明编制指南
编者说明:
软件需求规格说明是十分重要的文 档,因此为开发团队提供一份详细的编制指南是十分有意义和必要的.本文档就是一个编制指南的例子,你可以根据该指南,结合自己的实际情况进行修改.
1. 引言
1.1 目的和作用
本指南为软件需求实践提供了一个规范化的方法.本指南不提倡把软件需求说明(Software Requirements Specifications,以下简称SRS)划分成等级,避免把它定义成更小的需求子集.
本指南适用对象:
1) 软件客户(Customers),以便精确地描述他们想获得什么样的产品.
2)软件开发者(Suppliers),以便准确地理解客户需要什么 样的产品.
对于任一要实现下列目标的单位和(或)个人:
1)要提出开发规范化的SRS提纲;
2)定义自己需要的具体的格式 和内容;
3)产生附加的局部使用条款,如SRS质量检查清单或者SRS作者手册等.
SRS将完成下列目标:
在软件产品完成 目标方面为客户和开发者之间建立共同协议创立一个基础.对要实现的软件功能做全面描述,帮助客户判断所规定的软件是否符合他们的要求,或者怎样修改这种软 件才能适合他们的要求;
提高开发效率.编制SRS的过程将使客户在设计开始之前周密地思考全部需求,从而减少事后重新设计,重新编码和重新测试 的返工活动.在SRS中对各种需求仔细地进行复查,还可以在开发早期发现若干遗漏,错误的理解和不一致性,以便及时加以纠正;
为成本计价和编制 计划进度提供基础.SRS提供的对被开发软件产品的描述,是计算机软件产品成本核算的基础,并且可以为各方的要价和付费提供依据.SRS对软件的清晰描 述,有助于估计所必须的资源,并用作编制进度的依据;
为确认和验证提供一个基准.任何组织将更有效地编制他们的确认和验证计划.作为开发合同的 一部分,SRS还可以提供一个可以度量和遵循的基准(然而,反之则不成立,即任一有关软件的合同都不能作为SRS.因为这种文件几乎不包括详尽的需求说 明,并且通常不完全的);
便于移植.有了SRS就便于移值软件产品,以适应新的用户或新的机种.客户也易于移植其软件到其他部门,而开发者同样 也易于把软件移植到新的客户;
作为不断提高的基础.由于SRS所讨论的是软件产品,而不是开发这个产品的设计.因此SRS是软件产品继续提高的 基础.虽然SRS也可能要改变,但是原来的SRS还是软件产品改进的可靠基础.
1.2 范围
本指南适用于编写软件需求规格说明,它描 述了一个SRS所必须的内容和质量,并且在第6章中提供了SRS大纲.
2.引用标准
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 11457 软件工程术语
3.定义
GB/T 11457所列术语和下列定义适用于本指南.
合同(contract):是由客户和开发者共同签署的具有法律约束力的文件.其中包括产品的技 术,组织,成本和进度计划要求等内容.
客户(customer):指个人或单位,他们为产品开发提供资金,通常(但有时也不必)还提出各种需 求.文件中的客户和开发者也可能是同一个组织的成员.
语言(language):是具有语法和语义的通信工具,包括一组表达式,惯例和传递信息 的有关规则.
分割(partitioning):把一个整体分成若干部分.
开发者(supplier):指为客户生产某种软件产品的 个人或集团.在本指南中,客户和开发者可能是同一个组织的成员.
用户(user):指运行系统或者直接与系统发生交互作用的个人或集团.用户和 客户通常不是同一些人.
4.编写SRS的背景信息
4.1 SRS的基本要求
SRS是对要完成一定功能,性能的软件产品,程 序或一组程序的说明.对SRS的描述有两项基本要求:
1)必须描述一定的功能,性能;
2)必须用确定的方法叙述这些功能,性能.
4.2 SRS的环境
必须认识到SRS在整个软件开发规范(见GB 8566)所规定的有关阶段都起作用.正因为如此,SRS的起草者必须特别注意不要超出这种作用的范围.这意味着要满足下列要求:
SRS必须正 确地定义所有的软件需求;
除设计上的特殊限制之外,SRS中一般不描述任何设计,验证或项目管理细节.
4.3 SRS的特点
4.3.1 无歧义性
当且仅当它对每一个需求只有一种解释时,SRS者是无歧义的.
要求最终产品的每一个特性用某一术语描述;
若某一 术语在某一特殊的行文中使用时具有多种歧义,那么对该术语的每种含义作出解释并指出其适用场合.
需求通常是用自然语言编写的,使用自然语言的 SRS起草者必须特别注意消除其需求的歧义性.提倡使用形式化需求说明语言.
4.3.2 完整性
如果一个SRS能满足下列要求,则该 SRS就是完整的:
包括全部有意义的要求,无论是关系到功能的,性能的,设计约束的,还是关系到属性或外部接口方面的需求;
对所有可 能出现的输入数据的响应予以定义,要对合法和非合法的输入值的响应做出规定;
要符合SRS要求.如果个别章节不适用,则在SRS中要保留章节 号;
填写SRS中的全部插图,表,图示标记和参照,并且定义全部术语和度量单位.
4.3.2.1 关于使用"待定"一词的规定
任 何一个使用"待定"的SRS都是不完全的.
若万一遇到使用"待定"一词时,作如下处理:
对产生"待定"一词的条件进行描述,使得问题 能被解决;
描述必须干什么事,以删除这个"待定";
包含有"待定"一词的任何SRS的项目文件应该:
标识与此特定文件有关的版 本号或叙述其专门的发布号;
拒绝任何仍标识为"待定"一词的SRS章节的许诺.
4.3.3 可验证性
当且仅当SRS中描述 的每一个需求都是可以验证的,该SRS才是可以验证的;当且仅当在某一性能价格比可取的有限处理过程,人或机器能通过该过程检查软件产品能否满足需求时, 才称这个需求是可以验证的.
4.3.4 一致性
当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的.
4.3.5 可修改性
如果一个SRS的结构和风格在需求有必要改变时是易于实现的,完整性的,一致的,那么这个SRS就是可以修改的.可修改性要求SRS具 备以下条件:
具有一个有条不紊的易于使用的内容组织,具有目录表,索引和明确的交叉引用表;
没有冗余.即同一需求不能在SRS中出现 多次.
冗余本身不是错误,但是容易发生错误.冗余可增加SRS的可读性,但是在一个冗余文件被更新时容易出现问题.例如:假设一个明确的需求在 两个地方详细列出,后来发现这个需求需要改变,若只修改一个地方,于是SRS就变得不一致了.
不管冗余是否必须,SRS一定要包含一个详细的交 叉引用表,以便SRS具备可修改性.
4.3.6 可追踪性
如果每一个需求的源流是清晰的,在进一步产生和改变文件编制时,可以方便地 引证每一个需求,则该SRS就是可追踪的.建议采用如下两种类型的追踪:
向后追踪(即向已开发过的前一阶段追踪).根据先前文件或本文件前面的 每一个需求进行追踪.
向前追踪(即是向由SRS派生的所有文件追踪).根据SRS中具有唯一的名字和参照号的每一个需求进行追踪.
当 SRS中的一个需求表达另一个需求的一种指派或者是派生的,向前,向后的追踪都要提供.例如:
从总的用户响应时间需求中分配给数据库操作响应时 间;
识别带有一定功能和用户接口的需求的报告格式;
支持法律或行政上需要的某个软件产品(例如,计算税收).在这种情况下,要指出软 件所支持的确切的法律或行政文件.
当软件产品进入运行和维护阶段时,SRS的向前可追踪性显得特别重要.当编码和设计文件作修改时,重要的是要 查清这些修改所影响的全部需求.
4.3.7 运行和维护阶段的可使用性
SRS必须满足运行和维护阶段的需要,包括软件最终替换.
维 护常常是由与原来开发无联系的人来进行的.局部的改变(修正)可以借助于好的代码注释来实现.对于较大范围的改变.设计和需求文件是必不可少的,这里隐含 了两个作用:
如4.3.5 条指出,SRS必须是可修改的;
SRS中必须包括一个记录,它记录那些应用于各个成分的所有具体条文.例 如:它们的危急性(如故障可能危及完全或导致大量财政方面和社会方面的损失);它们仅与暂时的需要相关(如支持一种可立即恢复原状的显示);它们的来源 (如某功能是由已存在的软件产品的全部拷贝复制而成).
要求在SRS中清楚地写明功能的来源和目的,因为对功能的来源和引入该功能的目的不清楚 的话,通常不可能很好地完成软件的维护.
4.4 SRS的编制者
软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始 的.这种协议要使用SRS的形式,应该由双方联合起草.这是因为:
客户通常对软件设计和开发过程了解较少,而不能写出可用的SRS;
开 发者通常对于客户的问题和意图了解较少,从而不可能写出一个令人满意的系统需求.
4.5 SRS的改进
软件产品的开发过程中,在项目 的开始阶段不可能详细说明某些细节,在开发过程中可能发现SRS的缺陷,缺点和错误之类的问题,所以可能要对SRS进行改进.
在SRS的改进 中,应注意如下事项:
尽管可以预见校正版本的开发以后不可避免,而对需求还必须尽可能完全,清楚地描述.
一旦最初识别出项目的变化, 应引入一个正式的改变规程来标识,控制,追踪和报告项目的改变.批准了的需求改变,用如下的方法编入SRS之中:
提供各种改变后的正确的,完全 的审查记录;
允许对SRS当前的和被替代部分的审查.
4.6 SRS的编制工具
编制SRS最显而易见的方法是用自然语言来 描述.尽管自然语言是丰富多彩的,但不易精确,用形式化的方法较好.
4.6.1 形式化说明方法
在SRS中是否使用形式化方法要依据 下列因素:
1) 程序规模和复杂性;
2) 客户合同中是否要求使用;
3) SRS是否是一个合同工具或仅仅是一个内部文件;
4) SRS文件是否成为设计文件的根据;
5) 具有支持这种方法的计算机设备.
4.6.2 生产工具
软件产品生产中有多种生产工具.比如,计算机的字处理器就是非常有用的生产辅助工具.一个SRS通常有若干作者.可能经历若干版本, 并且要进行多次重新组织内容.故生产工具是必要的.
4.6.3 表达工具
在SRS中有许多词汇,特别是许多名词和动词,专门涉及到系 统的实体和许多活动,所以表达SRS需要若干工具.比如:
1) 可以验证实体或活动,无论在SRS中什么地方都是同一名字.
2) 可以标识一个特殊的实体或动作在规格说明中的描述位置.
此外,可以使用若干种形式化方法,以便允许自动处理SRS内容,只要作某些限制就可以做 到:
用一些表格或图示法来显示需求.
用详细分层体系自动检查SRS的需求,这里每一个分层自身是完全的,但是也可以扩展为下一层,或是 上一层的一个组成成分.
自动检查SRS具有在4.3条描述的部分或全部特点.
5 软件需求
SRS中每一个软件需求是要求开发 软件产品的某些基本功能和性能的一个陈述.
5.1 表达软件需求的方法
软件需求可以用若干种方法来表达:
1)通过输入,输 出说明;
2)使用代表性的例子;
3)用规范化的模型.
5.1.1 输入,输出说明
用输入输出序列来描述一个软件 产品所要求的特性是很有效的.
5.1.1.1 途径
根据被描述的软件的性质,至少有三种不同的途径:
有些软件产品(如报表 系统)要求着重说明输出.一般情况下,致力于输出的系统主要是在数据文卷上操作.用户的输入通常是致力于提供控制信息和启动数据文卷的处理;
有 些软件产品需要着重说明输入,输出特性.关注输入,输出的系统主要是在当前的输入上操作,要求生成与输入相匹配的输出(类似于数据转换例行程序或一个数学 函数包);
还有一些系统(如过程控制系统)要求记忆它们的状态.可以根据本次输入和上一次输入进行应答.也就是说,它的行为如同一个有限状态 机.在此种情况下,既要关注输入/输出对,又要关注这些输入/输出对的次序.
5.1.1.2 困难
多数软件产品可能接收无限的序列作 为输入,于是,为了通过输入输出序列完整地说明产品的特性,就要求SRS包括一个无限长的输入和所需的输出充列.然而,用这样的途径不可能完整地描述软件 所要求的一切特性.
5.1.2 典型例子
一种选择是用典型例子来说明要求的特性.例如,假设一个系统中当接收"0"时用"1"来回 答.显然,要列出全部输入和输出序列是不可能的.然而,用典型的序列可以十分清楚地理解系统的特性.下面是一组四种对话的典型的例子,用它描述系统特性.
0101
010101010101
01
010101
这些对话仅提供了要求的输入和输出之间的关系,但 是不能完全描述系统的特性.
5.1.3 模型
另一种表达需求的方法是模型的方式,这是表达复杂需求的精确和有效方法. 至少可以提出三种可供使用的通用模型:数学型,功能型,计时型.应注意区别各种模型的应用场合,参考5.1.3.5.
5.1.3.1 数学模型
数学模型是使用数学关系描述软件特性的模型.数学模型对某些特殊应用领域是特别有用的.例如,导航,线性规划,计量经济,信号处理和气象分析 等.
用数学模型能够对5.1.2中所讨论的典型例子描述如下:
(01)*.
这里,"*"号表示括号内的字符串可以重复一次 或多次.
5.1.3.2 功能模型
功能模型是提供从略语以输出映象的模型.象有限状态机或Petri网,这些功能模型可以有助于标识 和定义软件的各种特点,或者可以表示系统所要进行的操作.
对前面用数学模型描述的例子.可用图1所示的有限状态机形式的功能模型来描述.图中进 入的箭头表示启动状态.双线的方框表示接收状态.在各线记号x/y的含义是:x代表接受的输入,而y是产生的输出.
5.1.3.3 计时模型
计 时模型是一种增加了时间限制的模型.这种模型对于表达软件特性的形式和细节特别有用.尤其是实时系统或考虑人为因素的系统.
计时模型可以把下列 限制加到图1的模型中去:
1)激活因素0将在进入S1状态30S之内出现;
2)响应1将在进入S2状态2S之内出现.
5.1.3.4 其他模型
除了上面提及的模型外.对一些特殊的应用还有一些特别有用的模型.例如,编译程序的说明可以使用属性文法,工资单系统可以使用表格. 要注意的是,对SRS使用形式需求语言,通常含有使用特殊模型的意思.
5.1.3.5 警告
无论使用哪一类型的模型,都要在SRS中 或在SRS涉及到的一个文件中对它严格定义.这个定义应该规定:
1)模型中的参数所要求的范围;
2)使用时的限定值;
3) 结果的精确度;
4)负载的能力;
5)要求的执行时间;
6)缺省或失败时的响应.
必须注意,在需求的定义域内要保 持一个模型定义.每当一个SRS使用一个模型时:
1)它意味着此模型提供一个十分有效和精确的方法说明需求;
2)并不意味着软件产品 的实现必须基于这个模型.
一个模型用于解释文件所写的需求是有效的,但是对于实际软件的实现可能并不是最适宜的.
5.2 软件需求的注释
有关软件产品的所有需求,并不是同等重要的.某些需求可能是基本的,例如是对于生命攸关的应用.而另一些可能并不那么重要.
SRS 中每一个需求必须进行注释,以便区别其重要的程度.
有这种方法注释需求,可以:
帮助客户对每个需求给予更周密的考虑,通常可以在需求 中澄清隐藏的假设;
帮助开发者做出正确的设计决定,并对软件产品不同部分作出相应的努力.
5.2.1 稳定性
注释需求的一 种方法是使用稳定性量纲.当一个需求在软件预期的生存期间内描述不改变的话,可以认为该需求是稳定的,否则可以认为是易变的.
5.2.2 必要性等级
注释的另一种方法是把需求分成必须保证级,期望级和任选级.
必须保证是指软件必须和这些需求相一致,否则该软件不可能被接 受;
期望是指这些需求将提高软件产品的功能,但如果缺省的话也是可接受;
任选是给开发者一个机会,可以提供某些超出SRS规定的目 标.
5.2.3 注意事项
在注释需求之前,必须彻底理解这种注释的实质性含义.
5.3 在表达需求时遇到的共同弊病
SRS 的基本点是它必须说明由软件获得的结果,而不是获得这些结果的手段.编写需求的人必须描述的基本问题是:
功能――所设计的软件要做什么;
性 能――是指软件功能在执行过程中的速度,可使用性,响应时间,各种软件功能的恢复时间,吞吐能力,精度,频率等等;
强加于实现的设计限制――在 效果,实现的语言,数据库完整性,资源限制,操作环境等等方面所要求的标准;
属性――可移植性,正确性,可维护性及安全性等方面的考虑因素;
外 部接口――与人,硬件,其他软件和其他硬件的相互关系.
编写需求的人应当避免把设计或项目需求写入SRS之中,应当对说明需求设计约束与规划设 计两者有清晰的区别.
5.3.1 在SRS中嵌入了设计
在SRS中嵌入设计说明,会过多地约束软件设计,并且人为地把具有潜在危险的 需求放入SRS中.
SRS必须描述在干什么数据上,为谁完成什么功能,在什么地方,产生什么结果.SRS应把注意力集中在要完成的服务目标上. 通常不指定如下的设计项目:
把软件划分成若干模块;
给每一个模块分配功能;
描述模块间的信息流程或者控制流程;
选 择数据结构.
把设计完全同SRS隔离开来始终是不现实的.安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求.例如:
在一 些分散的模块中保持某些功能;
允许在程序的某些区域之间进行有限的通讯;
计算临界值的检查和.
通常应考虑到,若要为软件选 择高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:
不顾本指南的警告,在SRS中描述了设 计.这意味着,或者将一个潜在不适当的设计作为一个需求进行描述(因为,若要得到好的设计,所花费的时间是不够的),或者在需求阶段花费了过多的时间(因 为在SRS完成之前整个设计分析都要完成);
采用本指南中5.1.3条中的建议,用模型设计描述需求,这种模型设计只用于辅助描述需求,而不使 之成为实际的设计.
5.3.2 在SRS中嵌入了一些项目要求
SRS应当是描写一个软件产品,而不是描述生产软件产品的过程.
项 目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解(因此不应当包括在SRS中)例如:
成本;
交货进度;
报表处 理;
软件开发方法;
质量保证;
确认和验证的标准;
验收过程.
项目需求在另外文件中描述.在SRS中提 供的只是关于软件产品本身的需求.
6 SRS大纲
本章着重讨论SRS的每一个基本部分,可以作为一个SRS的大纲.表1给出该大纲目录, 表2至表5给出大纲中第3章的具体需求内容.各开发者和客户应当根据所描述的实际情况,按本指南有关规定编写自己的SRS.
6.1 前言(SRS第1章)
本章提供整个SRS综述.
6.1.1 目的(SRS的1.1条)
在这一条包括下列内容:
1) 描述实际SRS的目的;
2)说明SRS所预期的读者.
6.1.2 范围(SRS的1.2条)
通常应考虑到,若要为软件选择 高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:
用一个名字标识被生产的软件产品.比 如:×××数据库系统,报表生
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.产品成功的因素
[明确产品的成功是如 何定义和测量的,并指明对产品的成功有巨大影响的几个因素.不仅要包括组织直接控制的范围内的事务,还要包括我部素.如果可能,可建立测量的标准,用于评 价是否达到业务目标,如:市场股票,销售量及收入,客户满意度,交易处理量和准确度.]
项目构想
编者说明:
这个文档模板与"软件 项目视图与范围"文档的功能十分接近,只不过该文档更适合于产品型项目.其注重对项目的用户,市场进行分析,紧抓项目相关人员(也叫做风险承担者)的需求 的本质.
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.其他产品需求
[一些要求符合的标准,硬 件基础要求,软件基础要求,环境要求等.]
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定义
[列出本文件中用到的 专门术语的定义和外文首字母组词的原词组.]
1.4参考资料
[列出用得着的参考资料.]
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版)
编者说明:
Atlantic System Guild(www.atlsysguild.com)公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术, 是一个十分实用,完善的SRS模板.其所提供的Volere需求记录卡也十分实用,强烈推荐.
注:从Atlantic System Guild公司网站www.atlsysguild.com上获得,并稍做修改
1.产品的目标
1.1 该项目工作的用户问题或背景
[对 引发开发任务的工作和情况的描述.同时也应描述用户希望用将要交付的软件来完成的工作.]
[该节内容为该项目提供了合法的理由,你应该考虑用户的 问题是否严重,是否应该解决和为什么应该解决.]
1.2 产品的目标
[用一句话或很少的几句话来说明"我们希望该产品做什么 "换言之,即开发该产品的真正原因.
[项目如果没有一个表述清晰,易于理解的目标,就会迷失在产品开发的沙漠中.产品必须带来某种优势.典型的优 势是产品会增加组织在市场上的价值,减少运作成本,或提供更好的客户服务.这个优势应该是可度量的,这样才能够让您确定交付的产品是否达到目标.]
2. 客户,顾客和其它风险承担者
2.1 客户是为开发付费的人,并将成为所交付产品的拥有者
[这一项必须给出客户的姓名,三个以内是合理 的.]
[客户最终将接受该产品,因此必须对交付的产品满意.如果你无法找到一个客户的姓名,那么也许你就不应该构建该产品.]
2.2 顾客是将花钱购买该产品的人
[也给出姓名和相关的信息]
2.3 其它风险承担者
[其他的一些人或组织的名称,他们或者受到产品的 影响,或影响产品.]
经理或项目负责人;
业务领域专家;
技术人员;
系统开发者;
市场人员;
产品经理;
测 试和质量保证人员;
审查员,诸如安全审查员或审计人员;
律师;
10)易用性专家;
11)你所处行业的专业人员.
3. 产品的用户
3.1 产品的用户
[产品的潜在用户或操作员的列表.针对每种类型的用户,提供以下信息:]
用户分类
用户工作 的任务;
主要相关的经验;
技术经验;
其他用户特征:包括身体,智力,工作态度,对技术的态度,教育程度,语言技能,年龄,性别 等.
[用户是为了完成工作而与产品交互的人,你了解用户,就越可能提交适合用户工作方式的产品.]
3.2 对用户设的优先级
[在 每类用户后面附上一个优先级,这区别了用户的重要性和优先地位:]
关键用户:对产品的后续成功至关重要;
次要用户:他们使用产品,但对产 品的长期成功并无影响;
不重要的用户:不常用,未授权和没有技能的用户.
[如果认为某些用户对产品或组织更重要,那么应该写明,因为它会 影响你设计产品的方式.]
4.需求限制条件
4.1 解决方案限制条件
[此处明确了限制条件,它们规定了解决问题必须采取的方式. 您可以认为它们是指令式的解决方案.仔细描述该解决方案,以及测试是否符合的度量标准.如果可能,您应该解释使用该解决方案的原因.]
[换一句话 说,就是要求软件解决方案满足哪些限制条件!]
4.2 实现环境
[此处描述产品将被实施的技术环境和物理环境.]
[该环境也将成 为设计解决方案时的限制条件之一.]
4.3 伙伴应用
[此处描述那些不属于产品的一部分,但产品却又必须与其协作的应用程序.]
4.4 COTS
[此处描述实现产品需求所必须使用的COTS(商业组件).]
4.5 预期的工作场地环境
[此处描述用户工作和使用该 产品的工作场地.此处应该描述任何可能对产品设计产生影响的工作场地特征.]
4.6 开发者构建该产品需要多少时间
[任何已知的最后期 限,或商业机会的时限,应在此处说明.]
4.7 该产品的财务预算是多少
[该产品的预算,以金钱的形式或可得资源的形式说明.]
5. 命名标准和定义
[定义项目中使用到的所有术语,包括同义词.这里的内容就是一个字典,包括在需求规格说明书中使用的所有名称的含义.这个字典应该 使用你的组织或行业使用的标准名称.这些名称也应该反映出在工作领域中当前使用的术语.该字典包括项目中用到的所有名称.请仔细地选择名称,以避免传达不 同的,不期望的含义.为每个名字写下简明扼要的定义,这些定义必须经过相应的风险承担者同意.]
6.相关事实
[可能对产品产生影响的外部 因素,但不是命令式的需求限制条件.]
7.假定
[列出开发者所做的假设.]
[将所有的假设列在此的目的是让每一个项目成员都意识 到这个假设.]
8.产品的范围
8.1 工作的上下文范围
[上下文范围图用来表示将要开发的系统,产品与其它系统之间的关系,以确 定系统边界.]
8.2 工作切分
[一个事件清单,确定系统要响应的所有业务事件.清单包括:]
事件名称
输入和输出
8.3 产品边界
[你可以使用用例图(use-case)来确定了用户与产品之间的边界.]
9.功能性需求与数据需求
9.1 功能性需求
[对产品必须执行的动作的描述.]
[每个功能性需求必须有一个验收标准.]
9.2 数据需求
[与产品/系统有 密切关系的主题域相关的业务对象,实体,类的说明书.]
[进行问题域建模,生成相应的类图.]
10.观感需求
[一些与产品的用户 界面相关的需求描述.]
11.易用性需求
11.1 易于使用
[描述如何构建符合最终用户期望的产品.]
11.2 学习的容易程序
[学习使用该产品应该多容易的说明.通常是有学习时间来衡量.]
12.性能要求
12.1 速度需求
[明确 完成特定任务需要的时间,这常常指响应时间.]
12.2 安全性的需求
[对可能造成人身伤害,财产损失和环境破坏所考虑到的风险进行量化 描述.]
12.3 精度需求
[对产品产生的结果期望的精度进行量化描述.]
12.4 可靠性和可用性需求
[本节量化产品 所需的可靠性.这常常表述为允许的两次失败之间无故障运行时间,或允许的总失败率.]
12.5 容量需求
[本节明确处理的吞吐量和产品存 储数据的容量.]
13.操作需求
13.1 预期的物理环境
[本节明确产品将操作的物理环境,以及这种环境引起的任何特殊需求.]
13.2 预期的技术环境
[硬件和其它组成新产品操作环境的设备的规范.]
13.3 伙伴应用程序
[对产品必须与之交互的其它应用程序的 描述.]
14.可维护性和可移植性需求
14.1 维护该产品需要多容易
[对产品作特定修改所需时间的量化描述.]
14.2 是否存在一些特殊情况适用于该产品的维护
[关于预期的产品发布周期和发布将采取的形式的规定.]
14.3 可移植性需求
[对产 品必须支持的其他平台或环境的描述.]
15.安全性需求
15.1 该产品是保密的吗
[关于该被授权使用该产品,以及在什么样的 情况下授权等方面的描述.]
15.2 文件完整性需求
[关于需要的数据库和其他文件完整性方面的说明.]
15.3 审计需求
[关 于需要的审计检查方面的说明.]
16.文件和政策需求
[本节包括针对社会和政策的因素的规格说明,这些因素会影响产品的可接受性.如果你 开发的产品是针对外国市场的,可能要特别注意这些需求.]
[问一下是否产品的目标是你所不熟悉的文化环境,是否其它国家的人或其他类型的组织的人 会使用该产品.人们是否有与你的文化不同的习惯,节日,迷信,文化上的社会行为规范.]
17.法律需求
17.1 该产品是否受到某些法律的管制
[明确该产品的法律需求的描述.]
17.2 是否有一些必须符合的标准
[明确适用的标准和参考的详 细标准的描述.]
18.Opend问题
[对未确定但可能对产品产生重要影响的因素的问题描述.按照需求分析的术语还说,就是TBD(To Be Define)的问题.]
19.COTS解决方案
19.1 是否有一些制造好的产品可以购买
[应该调查现存产品清单,这 些产品可以作为潜在的解决方案.]
19.2 该产品是否可使用制造好的组件
[描述可能用于该产品的候选组件,包括采购的和公司自己的产 品.列出来源.]
19.3 是否有一些我们可以复制的东西
[其他相似产品的清单.]
20.新问题
20.1 新产品会在当前环境中带来什么问题
[关于新产品将怎样影响当前的实现环境的描述.]
20.2 新的开发是否将影响某些已实施的系统
[关 于新产品将怎样与现存系统协同工作的描述.]
20.3 是否我们现有的用户会受到新开发的敌对性影响
[关于现有用户可能产生的敌对性反应 的细节.]
20.4 预期的实现环境会存在什么限制新产品的因素
[关于新的自动化技术,新的组织结构方式的任何潜在问题的描述.]
20.5 是否新产品会带来其他问题
[确定我们可能不能处理的情况.]
21.任务
21.1 为提交该产品已经做了哪些事
[用来开 发产品的生命周期和方法的细节.画一个高层的过程图展示各项任务和它们之间的接口,这可能是沟通这方面信息的最好办法.]
21.2 开发阶段
[关 于每个开发阶段和操作环境中的组件的规格说明.]
22.移交
22.1 我们要让已有数据和过程配合新产品,有什么特殊要求
[一个 移交活动的列表,一个实现的时间表.]
22.2 为了新产品,哪些数据必须修改/转换
[数据转换任务清单,同时确定新产品需要转换的数 据.]
23. 风险
23.1 当你开发该产品时,要面对什么风险
23.2 你制定了怎样的偶然紧急情况计划
24.费用
[需 求的其他费用是你必须投入到产品构建中去的钱或工作量.当需求规格说明书完成时,你可以使用一种估算方法来评估费用,然后以构建所需的资金或时间的形式表 述出来.]
25.用户文档
[用户文档的清单,这些文档将作为产品的一部分交付.]
26.后续版本的需求
[这里记录下一些 希望今后版本中实现的需求.]
Volere需求记录卡
编者说明:
正如前面所述,Atlantic System Guild还提供了一个配套的Volere需求记录卡,这个记录卡十分实用.建议大家在需求调查,分析过程中,将需求记录在一系列的Volere需求记录 卡上,这个卡让你能够很好的理清需求之间的关系,需求提出的背景,用户对需求的期望,有了这些素材,整理SRS时将变得更加简单.
注:顾客满意度 是指完成该项功能顾客满意的程度,而顾客不满意度则是指未实现该功能顾客不满意的程度.
软件需求规格说明书
编者说明:
如果在需求 分析时采用了用例(Use case)技术,那么该需求规格说明书将更加符合你的需要.当然,你也可以结合Volere需求规格说明书对该模板进行必要的修改.
1. 文档概述
[该部分主要是对软件需求规格说明书文档进行基本的描述,包括该文档的目的,范围,术语定义,参考资料以及概要.]
[软件需求规 格说明书用来系统,完整地记录系统的软件需求.该软件需求说明书的基础是用例分析技术.因此该文档中应包括用例模型,补充规约等内容.]
1.1目 的
[在此小节中,主要对软件需求规格说明书的目的做一概要性说明,通常软件需求规格说明书应详细地说明应用程序,子系统的外部行为,还要说明非功 能性需求,设计约束,以及其它的相关因素.]
1.2范围
[系统是有范围的,而不是无限扩展的,对于无限扩展的需求是无法进行描述的.因 此,在本小节应该对该说明书所涉及的项目范围进行清晰的界定.指定该规格说明书适用的软件应用程序,特性或者其它子系统分组,其相关的用例模型.当然在此 也需要列出会受到该文档影响的其它文档.]
1.3 定义,首字母缩写词和缩略语
[与其它文档一样,该文档也需要将本文档中所涉及的所有术 语,缩略语进行详细的定义.还有一种可简明的做法,就是维护在一个项目词汇表中,这样就可以避免在每个文档中都重复很多内容.]
1.4参考资料
[在 这一小节中,应完整地列出该文档引用的所有文档.对于每个引用的文档都应该给出标题,标识号,日期以及来源,为阅读者查找这些文档提供足够详细的信息.]
1.5 概述
[在本小节中,主要是说明软件需求规格说明书各个部分所包含的主要内容,就像一个文章摘要一样.同时也应该对文档的组织方式进行解释.]
2. 整体说明
[在本节中,将对整个软件需求进行总体性的描述,以期让读者对整个软件系统的需求有一个框架性的认识.也就是说,该节中主要包括影响产 品及其需求的一般因素,而不列举 具体的需求.主要包括产品总体效果,产品功能,用户特征,约束,假设与依赖关系,需求子集等方面的内容.]
2.1 用例模型
[在本小节中,将列出该软件需求的用例模型,该模型处于系统级,对系统的特性进行宏观的描述.在此应该列出所有的用例和Actor的名称 列表,并且对其做出简要的说明,以及在图中的各种关系.]
2.2 假设与依赖关系
[在软件系统的开发过程中,存在许多假设和依赖关系.在 本小节中应列举出所有的重要的技术可行性假设,子系统或构件可用性假设,以及一些可行性的假设.]
3. 具体需求
[如果说第二章节是框 架,那么本节就是血肉.在本节中,应该详细列出所有的软件需求,其详细程序应使设计人员能够充分理解并且进行设计的要求,同时也应该给予测试人员足够的信 息,以帮助他们来验证系统是否满足了这些需求.整个需求的组织可以采用用例描述进行.]
3.1用例描述
[如果你使用用例建模技术,那么你 已经通过用例定义了系统的大部分功能性需求和一些非功能性需求.因此,在软件需求规格说明书只需将这些具体的用例描述,整理在一起,全部放在该小节之中. 当然也可以将用例描述做为附件,在此列出引用,只是这样做并不利于阅读.建议在组织形式上采用以"软件需求"为线索,在每个需求中,填入对应的1个或几个 用例描述.]
3.2补充需求
[由于用例毕竟主要针对功能性需求,因此还会有一些其它的补充需求遗漏,因此在本小节中就是将这些东西补充出 来.这些补充需求大部分集中在非功能需求之上,包括以下几个方面的内容:]
易用性:例如指出普通用户和高级用户要高效地执行某个特定操作所需的培 训时间;指出典型任务的可评测任务次数;或者指出需要满足的可用性标准(如IBM的CUA标准,Microsoft的GUI标准.
可靠性:包括系 统可用性(可用时间百分比,使用小时数,维护访问权,降纸模式操作等);平均故障间隔时间(MTBF,通常表示为小时数,但也可表示为天数,月数或年 数);平均修复时间(MTTR,系统在发生故障后可以暂停运行的时间);精确度(指出系统输出要求具备的精密度,分辨率和精确度);最高错误或缺陷率(通 常表示为bugs/KLOC,即每千行代码的错误数目或 bugs/function-point,即每个功能点的错误数目);错误或缺陷率(按照小错误,大错误和严重错误来分类:需求中必须对"严重"错误进行 界定,例如:数据完全丢失或完全不能使用系统的某部分功能).
性能:包括对事务的响应时间(平均,最长);吞吐量(例如每秒处理的事务数);容量 (例如系统可以容纳的客户或事务数);降级模式(当系统以某种形式降级时可接受的运行模式);资源利用情况:内存,磁盘,通信等.
其它:包括用户 界面要求,联机帮助系统要求,法律许可,外购构件,以及操作系统,开发工具,数据库系统等设计约束.
4.支持信息
[支持信息用于使软件需 求规格说明书更易于使用.它包括:目录,索引,附录等.]
计算机软件需求说明编制指南
编者说明:
软件需求规格说明是十分重要的文 档,因此为开发团队提供一份详细的编制指南是十分有意义和必要的.本文档就是一个编制指南的例子,你可以根据该指南,结合自己的实际情况进行修改.
1. 引言
1.1 目的和作用
本指南为软件需求实践提供了一个规范化的方法.本指南不提倡把软件需求说明(Software Requirements Specifications,以下简称SRS)划分成等级,避免把它定义成更小的需求子集.
本指南适用对象:
1) 软件客户(Customers),以便精确地描述他们想获得什么样的产品.
2)软件开发者(Suppliers),以便准确地理解客户需要什么 样的产品.
对于任一要实现下列目标的单位和(或)个人:
1)要提出开发规范化的SRS提纲;
2)定义自己需要的具体的格式 和内容;
3)产生附加的局部使用条款,如SRS质量检查清单或者SRS作者手册等.
SRS将完成下列目标:
在软件产品完成 目标方面为客户和开发者之间建立共同协议创立一个基础.对要实现的软件功能做全面描述,帮助客户判断所规定的软件是否符合他们的要求,或者怎样修改这种软 件才能适合他们的要求;
提高开发效率.编制SRS的过程将使客户在设计开始之前周密地思考全部需求,从而减少事后重新设计,重新编码和重新测试 的返工活动.在SRS中对各种需求仔细地进行复查,还可以在开发早期发现若干遗漏,错误的理解和不一致性,以便及时加以纠正;
为成本计价和编制 计划进度提供基础.SRS提供的对被开发软件产品的描述,是计算机软件产品成本核算的基础,并且可以为各方的要价和付费提供依据.SRS对软件的清晰描 述,有助于估计所必须的资源,并用作编制进度的依据;
为确认和验证提供一个基准.任何组织将更有效地编制他们的确认和验证计划.作为开发合同的 一部分,SRS还可以提供一个可以度量和遵循的基准(然而,反之则不成立,即任一有关软件的合同都不能作为SRS.因为这种文件几乎不包括详尽的需求说 明,并且通常不完全的);
便于移植.有了SRS就便于移值软件产品,以适应新的用户或新的机种.客户也易于移植其软件到其他部门,而开发者同样 也易于把软件移植到新的客户;
作为不断提高的基础.由于SRS所讨论的是软件产品,而不是开发这个产品的设计.因此SRS是软件产品继续提高的 基础.虽然SRS也可能要改变,但是原来的SRS还是软件产品改进的可靠基础.
1.2 范围
本指南适用于编写软件需求规格说明,它描 述了一个SRS所必须的内容和质量,并且在第6章中提供了SRS大纲.
2.引用标准
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 11457 软件工程术语
3.定义
GB/T 11457所列术语和下列定义适用于本指南.
合同(contract):是由客户和开发者共同签署的具有法律约束力的文件.其中包括产品的技 术,组织,成本和进度计划要求等内容.
客户(customer):指个人或单位,他们为产品开发提供资金,通常(但有时也不必)还提出各种需 求.文件中的客户和开发者也可能是同一个组织的成员.
语言(language):是具有语法和语义的通信工具,包括一组表达式,惯例和传递信息 的有关规则.
分割(partitioning):把一个整体分成若干部分.
开发者(supplier):指为客户生产某种软件产品的 个人或集团.在本指南中,客户和开发者可能是同一个组织的成员.
用户(user):指运行系统或者直接与系统发生交互作用的个人或集团.用户和 客户通常不是同一些人.
4.编写SRS的背景信息
4.1 SRS的基本要求
SRS是对要完成一定功能,性能的软件产品,程 序或一组程序的说明.对SRS的描述有两项基本要求:
1)必须描述一定的功能,性能;
2)必须用确定的方法叙述这些功能,性能.
4.2 SRS的环境
必须认识到SRS在整个软件开发规范(见GB 8566)所规定的有关阶段都起作用.正因为如此,SRS的起草者必须特别注意不要超出这种作用的范围.这意味着要满足下列要求:
SRS必须正 确地定义所有的软件需求;
除设计上的特殊限制之外,SRS中一般不描述任何设计,验证或项目管理细节.
4.3 SRS的特点
4.3.1 无歧义性
当且仅当它对每一个需求只有一种解释时,SRS者是无歧义的.
要求最终产品的每一个特性用某一术语描述;
若某一 术语在某一特殊的行文中使用时具有多种歧义,那么对该术语的每种含义作出解释并指出其适用场合.
需求通常是用自然语言编写的,使用自然语言的 SRS起草者必须特别注意消除其需求的歧义性.提倡使用形式化需求说明语言.
4.3.2 完整性
如果一个SRS能满足下列要求,则该 SRS就是完整的:
包括全部有意义的要求,无论是关系到功能的,性能的,设计约束的,还是关系到属性或外部接口方面的需求;
对所有可 能出现的输入数据的响应予以定义,要对合法和非合法的输入值的响应做出规定;
要符合SRS要求.如果个别章节不适用,则在SRS中要保留章节 号;
填写SRS中的全部插图,表,图示标记和参照,并且定义全部术语和度量单位.
4.3.2.1 关于使用"待定"一词的规定
任 何一个使用"待定"的SRS都是不完全的.
若万一遇到使用"待定"一词时,作如下处理:
对产生"待定"一词的条件进行描述,使得问题 能被解决;
描述必须干什么事,以删除这个"待定";
包含有"待定"一词的任何SRS的项目文件应该:
标识与此特定文件有关的版 本号或叙述其专门的发布号;
拒绝任何仍标识为"待定"一词的SRS章节的许诺.
4.3.3 可验证性
当且仅当SRS中描述 的每一个需求都是可以验证的,该SRS才是可以验证的;当且仅当在某一性能价格比可取的有限处理过程,人或机器能通过该过程检查软件产品能否满足需求时, 才称这个需求是可以验证的.
4.3.4 一致性
当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的.
4.3.5 可修改性
如果一个SRS的结构和风格在需求有必要改变时是易于实现的,完整性的,一致的,那么这个SRS就是可以修改的.可修改性要求SRS具 备以下条件:
具有一个有条不紊的易于使用的内容组织,具有目录表,索引和明确的交叉引用表;
没有冗余.即同一需求不能在SRS中出现 多次.
冗余本身不是错误,但是容易发生错误.冗余可增加SRS的可读性,但是在一个冗余文件被更新时容易出现问题.例如:假设一个明确的需求在 两个地方详细列出,后来发现这个需求需要改变,若只修改一个地方,于是SRS就变得不一致了.
不管冗余是否必须,SRS一定要包含一个详细的交 叉引用表,以便SRS具备可修改性.
4.3.6 可追踪性
如果每一个需求的源流是清晰的,在进一步产生和改变文件编制时,可以方便地 引证每一个需求,则该SRS就是可追踪的.建议采用如下两种类型的追踪:
向后追踪(即向已开发过的前一阶段追踪).根据先前文件或本文件前面的 每一个需求进行追踪.
向前追踪(即是向由SRS派生的所有文件追踪).根据SRS中具有唯一的名字和参照号的每一个需求进行追踪.
当 SRS中的一个需求表达另一个需求的一种指派或者是派生的,向前,向后的追踪都要提供.例如:
从总的用户响应时间需求中分配给数据库操作响应时 间;
识别带有一定功能和用户接口的需求的报告格式;
支持法律或行政上需要的某个软件产品(例如,计算税收).在这种情况下,要指出软 件所支持的确切的法律或行政文件.
当软件产品进入运行和维护阶段时,SRS的向前可追踪性显得特别重要.当编码和设计文件作修改时,重要的是要 查清这些修改所影响的全部需求.
4.3.7 运行和维护阶段的可使用性
SRS必须满足运行和维护阶段的需要,包括软件最终替换.
维 护常常是由与原来开发无联系的人来进行的.局部的改变(修正)可以借助于好的代码注释来实现.对于较大范围的改变.设计和需求文件是必不可少的,这里隐含 了两个作用:
如4.3.5 条指出,SRS必须是可修改的;
SRS中必须包括一个记录,它记录那些应用于各个成分的所有具体条文.例 如:它们的危急性(如故障可能危及完全或导致大量财政方面和社会方面的损失);它们仅与暂时的需要相关(如支持一种可立即恢复原状的显示);它们的来源 (如某功能是由已存在的软件产品的全部拷贝复制而成).
要求在SRS中清楚地写明功能的来源和目的,因为对功能的来源和引入该功能的目的不清楚 的话,通常不可能很好地完成软件的维护.
4.4 SRS的编制者
软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始 的.这种协议要使用SRS的形式,应该由双方联合起草.这是因为:
客户通常对软件设计和开发过程了解较少,而不能写出可用的SRS;
开 发者通常对于客户的问题和意图了解较少,从而不可能写出一个令人满意的系统需求.
4.5 SRS的改进
软件产品的开发过程中,在项目 的开始阶段不可能详细说明某些细节,在开发过程中可能发现SRS的缺陷,缺点和错误之类的问题,所以可能要对SRS进行改进.
在SRS的改进 中,应注意如下事项:
尽管可以预见校正版本的开发以后不可避免,而对需求还必须尽可能完全,清楚地描述.
一旦最初识别出项目的变化, 应引入一个正式的改变规程来标识,控制,追踪和报告项目的改变.批准了的需求改变,用如下的方法编入SRS之中:
提供各种改变后的正确的,完全 的审查记录;
允许对SRS当前的和被替代部分的审查.
4.6 SRS的编制工具
编制SRS最显而易见的方法是用自然语言来 描述.尽管自然语言是丰富多彩的,但不易精确,用形式化的方法较好.
4.6.1 形式化说明方法
在SRS中是否使用形式化方法要依据 下列因素:
1) 程序规模和复杂性;
2) 客户合同中是否要求使用;
3) SRS是否是一个合同工具或仅仅是一个内部文件;
4) SRS文件是否成为设计文件的根据;
5) 具有支持这种方法的计算机设备.
4.6.2 生产工具
软件产品生产中有多种生产工具.比如,计算机的字处理器就是非常有用的生产辅助工具.一个SRS通常有若干作者.可能经历若干版本, 并且要进行多次重新组织内容.故生产工具是必要的.
4.6.3 表达工具
在SRS中有许多词汇,特别是许多名词和动词,专门涉及到系 统的实体和许多活动,所以表达SRS需要若干工具.比如:
1) 可以验证实体或活动,无论在SRS中什么地方都是同一名字.
2) 可以标识一个特殊的实体或动作在规格说明中的描述位置.
此外,可以使用若干种形式化方法,以便允许自动处理SRS内容,只要作某些限制就可以做 到:
用一些表格或图示法来显示需求.
用详细分层体系自动检查SRS的需求,这里每一个分层自身是完全的,但是也可以扩展为下一层,或是 上一层的一个组成成分.
自动检查SRS具有在4.3条描述的部分或全部特点.
5 软件需求
SRS中每一个软件需求是要求开发 软件产品的某些基本功能和性能的一个陈述.
5.1 表达软件需求的方法
软件需求可以用若干种方法来表达:
1)通过输入,输 出说明;
2)使用代表性的例子;
3)用规范化的模型.
5.1.1 输入,输出说明
用输入输出序列来描述一个软件 产品所要求的特性是很有效的.
5.1.1.1 途径
根据被描述的软件的性质,至少有三种不同的途径:
有些软件产品(如报表 系统)要求着重说明输出.一般情况下,致力于输出的系统主要是在数据文卷上操作.用户的输入通常是致力于提供控制信息和启动数据文卷的处理;
有 些软件产品需要着重说明输入,输出特性.关注输入,输出的系统主要是在当前的输入上操作,要求生成与输入相匹配的输出(类似于数据转换例行程序或一个数学 函数包);
还有一些系统(如过程控制系统)要求记忆它们的状态.可以根据本次输入和上一次输入进行应答.也就是说,它的行为如同一个有限状态 机.在此种情况下,既要关注输入/输出对,又要关注这些输入/输出对的次序.
5.1.1.2 困难
多数软件产品可能接收无限的序列作 为输入,于是,为了通过输入输出序列完整地说明产品的特性,就要求SRS包括一个无限长的输入和所需的输出充列.然而,用这样的途径不可能完整地描述软件 所要求的一切特性.
5.1.2 典型例子
一种选择是用典型例子来说明要求的特性.例如,假设一个系统中当接收"0"时用"1"来回 答.显然,要列出全部输入和输出序列是不可能的.然而,用典型的序列可以十分清楚地理解系统的特性.下面是一组四种对话的典型的例子,用它描述系统特性.
0101
010101010101
01
010101
这些对话仅提供了要求的输入和输出之间的关系,但 是不能完全描述系统的特性.
5.1.3 模型
另一种表达需求的方法是模型的方式,这是表达复杂需求的精确和有效方法. 至少可以提出三种可供使用的通用模型:数学型,功能型,计时型.应注意区别各种模型的应用场合,参考5.1.3.5.
5.1.3.1 数学模型
数学模型是使用数学关系描述软件特性的模型.数学模型对某些特殊应用领域是特别有用的.例如,导航,线性规划,计量经济,信号处理和气象分析 等.
用数学模型能够对5.1.2中所讨论的典型例子描述如下:
(01)*.
这里,"*"号表示括号内的字符串可以重复一次 或多次.
5.1.3.2 功能模型
功能模型是提供从略语以输出映象的模型.象有限状态机或Petri网,这些功能模型可以有助于标识 和定义软件的各种特点,或者可以表示系统所要进行的操作.
对前面用数学模型描述的例子.可用图1所示的有限状态机形式的功能模型来描述.图中进 入的箭头表示启动状态.双线的方框表示接收状态.在各线记号x/y的含义是:x代表接受的输入,而y是产生的输出.
5.1.3.3 计时模型
计 时模型是一种增加了时间限制的模型.这种模型对于表达软件特性的形式和细节特别有用.尤其是实时系统或考虑人为因素的系统.
计时模型可以把下列 限制加到图1的模型中去:
1)激活因素0将在进入S1状态30S之内出现;
2)响应1将在进入S2状态2S之内出现.
5.1.3.4 其他模型
除了上面提及的模型外.对一些特殊的应用还有一些特别有用的模型.例如,编译程序的说明可以使用属性文法,工资单系统可以使用表格. 要注意的是,对SRS使用形式需求语言,通常含有使用特殊模型的意思.
5.1.3.5 警告
无论使用哪一类型的模型,都要在SRS中 或在SRS涉及到的一个文件中对它严格定义.这个定义应该规定:
1)模型中的参数所要求的范围;
2)使用时的限定值;
3) 结果的精确度;
4)负载的能力;
5)要求的执行时间;
6)缺省或失败时的响应.
必须注意,在需求的定义域内要保 持一个模型定义.每当一个SRS使用一个模型时:
1)它意味着此模型提供一个十分有效和精确的方法说明需求;
2)并不意味着软件产品 的实现必须基于这个模型.
一个模型用于解释文件所写的需求是有效的,但是对于实际软件的实现可能并不是最适宜的.
5.2 软件需求的注释
有关软件产品的所有需求,并不是同等重要的.某些需求可能是基本的,例如是对于生命攸关的应用.而另一些可能并不那么重要.
SRS 中每一个需求必须进行注释,以便区别其重要的程度.
有这种方法注释需求,可以:
帮助客户对每个需求给予更周密的考虑,通常可以在需求 中澄清隐藏的假设;
帮助开发者做出正确的设计决定,并对软件产品不同部分作出相应的努力.
5.2.1 稳定性
注释需求的一 种方法是使用稳定性量纲.当一个需求在软件预期的生存期间内描述不改变的话,可以认为该需求是稳定的,否则可以认为是易变的.
5.2.2 必要性等级
注释的另一种方法是把需求分成必须保证级,期望级和任选级.
必须保证是指软件必须和这些需求相一致,否则该软件不可能被接 受;
期望是指这些需求将提高软件产品的功能,但如果缺省的话也是可接受;
任选是给开发者一个机会,可以提供某些超出SRS规定的目 标.
5.2.3 注意事项
在注释需求之前,必须彻底理解这种注释的实质性含义.
5.3 在表达需求时遇到的共同弊病
SRS 的基本点是它必须说明由软件获得的结果,而不是获得这些结果的手段.编写需求的人必须描述的基本问题是:
功能――所设计的软件要做什么;
性 能――是指软件功能在执行过程中的速度,可使用性,响应时间,各种软件功能的恢复时间,吞吐能力,精度,频率等等;
强加于实现的设计限制――在 效果,实现的语言,数据库完整性,资源限制,操作环境等等方面所要求的标准;
属性――可移植性,正确性,可维护性及安全性等方面的考虑因素;
外 部接口――与人,硬件,其他软件和其他硬件的相互关系.
编写需求的人应当避免把设计或项目需求写入SRS之中,应当对说明需求设计约束与规划设 计两者有清晰的区别.
5.3.1 在SRS中嵌入了设计
在SRS中嵌入设计说明,会过多地约束软件设计,并且人为地把具有潜在危险的 需求放入SRS中.
SRS必须描述在干什么数据上,为谁完成什么功能,在什么地方,产生什么结果.SRS应把注意力集中在要完成的服务目标上. 通常不指定如下的设计项目:
把软件划分成若干模块;
给每一个模块分配功能;
描述模块间的信息流程或者控制流程;
选 择数据结构.
把设计完全同SRS隔离开来始终是不现实的.安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求.例如:
在一 些分散的模块中保持某些功能;
允许在程序的某些区域之间进行有限的通讯;
计算临界值的检查和.
通常应考虑到,若要为软件选 择高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:
不顾本指南的警告,在SRS中描述了设 计.这意味着,或者将一个潜在不适当的设计作为一个需求进行描述(因为,若要得到好的设计,所花费的时间是不够的),或者在需求阶段花费了过多的时间(因 为在SRS完成之前整个设计分析都要完成);
采用本指南中5.1.3条中的建议,用模型设计描述需求,这种模型设计只用于辅助描述需求,而不使 之成为实际的设计.
5.3.2 在SRS中嵌入了一些项目要求
SRS应当是描写一个软件产品,而不是描述生产软件产品的过程.
项 目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解(因此不应当包括在SRS中)例如:
成本;
交货进度;
报表处 理;
软件开发方法;
质量保证;
确认和验证的标准;
验收过程.
项目需求在另外文件中描述.在SRS中提 供的只是关于软件产品本身的需求.
6 SRS大纲
本章着重讨论SRS的每一个基本部分,可以作为一个SRS的大纲.表1给出该大纲目录, 表2至表5给出大纲中第3章的具体需求内容.各开发者和客户应当根据所描述的实际情况,按本指南有关规定编写自己的SRS.
6.1 前言(SRS第1章)
本章提供整个SRS综述.
6.1.1 目的(SRS的1.1条)
在这一条包括下列内容:
1) 描述实际SRS的目的;
2)说明SRS所预期的读者.
6.1.2 范围(SRS的1.2条)
通常应考虑到,若要为软件选择 高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:
用一个名字标识被生产的软件产品.比 如:×××数据库系统,报表生
扫一扫
1684
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
