软件工程软件工程软件工程 (34).pdf

《软件工程软件工程软件工程 (34).pdf》由会员分享，可在线阅读，更多相关《软件工程软件工程软件工程 (34).pdf（19页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、软件需求规格说明软件需求规格说明 （So#ware Requirements Specifica4on,SRS)是具有一定法律效力的合同文档 清楚地描述软件在什么情况下，需要做什么，以及不能做什么 以输入/输出、输入到输出之间的转换方式来描述功能性需求 描述经过干系人磋商达成共识的非功能性需求 一般参考需求定义模板，覆盖标准模板中定义的所有条目 作为后续的软件评估依据和变更的基准 需求文档的组织形式需求文档的组织形式 文档需要有逻辑组织结构 例如：参照IEEE的模板 典型的组织形式包括 按系统能够响应的各种外部环境情况来组织 按系统特征来组织 按系统的响应方式来组织 按所管理的外部数据对象来组

2、织 按用户类型来组织 按软件的工作模式来组织 按子系统的划分来组织 软件需求规格说明软件需求规格说明SRS的风格 的风格 描述性的自然语言文本 用户故事 从用例模型产生 用例模型与需求转化可看成可逆的过程 如果需求模型以用例的形式表示，我们可以逆向生成需求的完整集合 从需求数据库中生成 商业需求数据库有内置的功能来生成经过筛选的需求规格说明 从产品线需求规格数据库中生成特定产品的需求规格说明 从混合模型中生成 特征模型和用例模型 以上两种常常通过模板完成的 选择合适的需求规格说明方式选择合适的需求规格说明方式 考虑以下两个具体项目场景:1)小型项目，1名程序猿，2个月的开发周期 程序猿直接和用

3、户对话，写了两页纸的备忘录 2)大型项目，50 名程序猿，2年的开发周期 专门的团队进行需求建模与分析，撰写了500页的需求规格说明?:?B?B?A?生成不同风格生成不同风格SRS的方法总览 的方法总览 方法 方法 使用时机 使用时机 适合 适合 效果 效果 需要的资源 需要的资源 描述性文本 小项目 小产品的非正式说明 中 有良好写作能力的分析师 从用例模型生成 大中型项目 产品线的正式规格描述 中 有建模能力，好的过程标准，建模工具的分析师 从需求数据库生成 大中型项目 产品线的正式规格描述 小 需求数据库，有数据库管理能力的分析师 从混合模型生成 中小型项目 单个产品的定义 中小 有良好

4、协作技巧，需求工程，数据库管理，建模能力的分析师 用户手册作为用户手册作为SRS 撰写用户手册作为一种性价比高的一箭双雕的方法，同时获得SRS和用户手册 用户手册作为SRS对于和用户交互的系统是比较有效的，这样系统由交互驱动 好的手册描述了所有用例的所有场景 Fred Brooks的人月神话中描述了将用户手册作为需求规格说明书的做法 据说在苹果的第一台电脑的编码工作开始之前用户手册就写好了 但是用户手册并没有描述 非功能性需求 不和用户交互的功能性需求 比如：函数计算、过滤器或者翻译工具的时候 用户手册大纲 用户手册大纲 介绍 产品总览及基本原理 术语和基本特征 展示格式与报表格式的总结 手册

5、的大纲 开始 开始指令 帮助模式 样例运行 操作模式:命令行/对话框/报告 高级特性 命令语法和系统选项 需求规格说明的用户 需求规格说明的用户 客户和终端用户 客户和终端用户 市场人员和销售 产品开发人员 测试人员 不同的国家和地区 提供需求提供需求，并保证其满足用户需要 并保证其满足用户需要 根据客户要求定义有竞争力的产品特征管理产品发布 通过需求了解系统要做什么并且开发系统 参照需求进行系统验证，通过测试和用户征询的方式 基于产品的核心部分，补充本地运行所需的特性 高质量需求规格说明 高质量需求规格说明 一个高质量的需求规格说明 是所有需求的集合 描述产品要提供的所有功能 是软件系统解决

6、方案的商业合同的基础 是测试计划的基础 定义产品需求的度量标准 是产品需求跟踪的先决条件 影响开发产品的项目计划 高质量需求规格说明的评价标准 高质量需求规格说明的评价标准 正确性=经过验证的 无歧义 完整的 可测试=可以证明的 可修改的 可跟踪的 易理解 一致的 有序的 项目或产品特定的其他特征 incomplete not understandable ambiguous redundant inconsistent addexplanationsresolvereduceexpandexpandcondenseformalize简洁 简洁 定义：需求描述尽可能简洁 描述了系统的一个独立特

7、征 除了必需的信息外没有包含其他信息 用清晰、简单、可理解的词表述 避免“应该”、“可以”、“可能”之类的用词 举例:“急救电话的响应应本着先到先响应的原则”相对 “急救电话应按照其拨入的次序存入一个先入先出的等待队列当中，并且按照进入队列的次序逐一应答”是简洁的 需求规格说明生成过程 需求规格说明生成过程 创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它 不直接修改规格说明，修改数据库中的需求并且重新生成规格说明 需求数据库 需求数据库 规格说明生成器 规格说明生成器 文档模板 文档模板 产品规格说明 产品规格说明 需求规格说明的结构 需求规格说明的结构 整体系统 需求 子系统A

8、 规格说明 子系统C 规格说明 子系统B 规格说明 子系统A1 规格说明 子系统A2 规格说明 子系统C1 规格说明 子系统C2 规格说明 子系统A2 硬件规格说明 子系统A2 硬件规格说明 这个分层结构可以包含要开发的硬件模块和软件模块 需求规格说明需求规格说明SRS模板 模板 SRS需要根据预先定义的标准章节模式来组织，即根据模板来撰写 SRS的模板使得撰写统一的SRS变得简单 对于QA人员来说定义SRS指标变得简单 模板也适用于业务需求和系统需求 模板可以被用于半自动地从需求数据库或者用例模型生成SRS IEEE-830 SRS模板大纲 模板大纲 介绍 术语表 用户需求规格说明 系统结构

9、 系统需求规格说明 系统模型 系统的演化 附录 索引 1 IntroductionPurposeScopeDefinitions,acronyms,abbreviationsReference documentsOverview2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies3 Specific RequirementsAppendicesIndexIden4fies the product&applica4on

10、 domain Describes contents and structure of the remainder of the SRS Describes all external interfaces:system,user,hardware,so#ware;also opera4ons and site adapta4on,and hardware constraints Summary of major func4ons,e.g.use cases Anything that will limit the developers op4ons(e.g.regula4ons,reliabi

11、lity,cri4cality,hardware limita4ons,parallelism,etc)All the requirements go in here(i.e.this is the body of the document).IEEE STD provides 8 different templates for this sec4on Source:Adapted from IEEE-STD-830-1993 See also,Blum 1992,p160 IEEE-830 SRS模板第三部分模板第三部分3.1 外部接口 3.1.1 用户接口 3.1.2 硬件接口 3.1.3

12、 软件接口 3.1.4 通信接口 3.2 功能需求描述 按系统的操作模式、用户分类、特征分类来定义:3.2.1 模式 1 3.2.1.1 功能需求 1.1 3.2.2 模式 2 3.2.2.1 功能需求 2.1 .3.2.n 模式 n.3.3 性能需求 要用可度量的方式来表达!3.4 设计约束 3.4.1 标准依从性 3.4.2 硬件限制 etc.3.5 软件质量属性 3.5.1 可靠性 3.5.2 可用性 3.5.3 安全性 3.5.4 可维护性 3.5.5 可移植性 3.6 其他需求 Source:Adapted from IEEE-STD-830-1993.See also,Blum 1

13、992,p160 SRS模板的优缺点 模板的优缺点 优点 模板提高效率 在有模板的情况下，面对一个完整的大纲，不容易遗漏重要的信息 缺点 并非对于所有的系统，模板的章节设计都是类似的 如果仅仅为了满足标准，而填写模板的所有章节，在不相关的章节，会加入一些没有意义的内容 读者很难将这些无意义的文字和真正的需求分开 总结总结 尽快开始写需求 确定哪些属性将被用于分类和细化需求 产生一个初始版本来刺激反馈 询问用户往往比咨询专家更有用 撰写需求时需要遵循的法则：使用简单、直接的语言 撰写可测试的需求 使用定义好的并达成共识的术语 一次只写一项需求 18 随时准备迎接需求变化随时准备迎接需求变化 这是一种态度 越多的干系人参与，将获得越多的需求特征 但不能通过减少干系人的方法来解决这个问题 干系人有改变他们想法的权利 不要问：“这是你最终的需求吗?”请将变化看成机会，而非威胁 19