需求分析与解决方案设计ch.ppt
- 文档编号:2178750
- 上传时间:2022-10-27
- 格式:PPT
- 页数:27
- 大小:261.50KB
需求分析与解决方案设计ch.ppt
《需求分析与解决方案设计ch.ppt》由会员分享,可在线阅读,更多相关《需求分析与解决方案设计ch.ppt(27页珍藏版)》请在冰豆网上搜索。
第10章编写需求文档4需求开发的最终成果是,在客户和开发人员对所要开发的产品达成共识后,所编写的具体的文档SRS。
4我们可以采用以下几种方式来表示软件需求:
文档用结构合理的自然语言来精心编写需求文档。
用结构合理的自然语言来精心编写需求文档。
图形化模型这些模型可以描绘转换过程、系统状态和它们之间这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或者对象类及其关系。
的变化、数据关系、逻辑流或者对象类及其关系。
形式化规格说明使用数学上精确的形式逻辑语言来定义需求。
使用数学上精确的形式逻辑语言来定义需求。
110.1软件需求规格说明4软件需求规格说明,有时也称为功能规格说明(functionspecification)、产品规格说明(productspecification)、需求文档(requirementsdocument)或系统规格说明(systemspecification)。
210.1软件需求规格说明4必须使用软件需求规格说明的受众有以下几类:
客户、市场部和销售人员需要了解他们期望得到什么样的产品。
项目经理根据产品描述来估计项目的进度、工作量和所需资源。
开发团队根据软件需求规格说明了解需要开发什么样的产品。
测试小组使用软件需求规格说明来开发测试计划、测试用例和测试过程。
软件维护和支持人员根据软件需求规格说明了解产品的每一部分的功能是什么。
文档编写人员根据软件需求规格说明和用户界面设计来编写用户手册和帮助屏幕。
培训人员根据软件需求规格说明和用户文档来编写培训材料。
公司律师要确保该需求遵守相应的法律法规。
分包商根据软件需求规格说明来进行工作,当然这要在合法的基础上。
310.1软件需求规格说明4组织并编写软件需求规格说明时应使涉众各方都能够理解它。
关于几点有关需求可读性的建议:
对节、小节和单个需求的标记格式必须一致。
在右边部分留下文本注释区,而不要在两边全部写满。
允许不受限制地使用空白。
灵活明智地使用各种可视强调标志(例如,黑体、下划线、斜体和不同字体)。
创建目录表,也许还需要创建索引,这有助于读者找到他们所需要的信息。
对所有图和表进行编号,并且给出标题,根据编号来引用这些图和表。
使用字处理程序的交叉引用功能来引用文档中的其他位置,而不是通过页码或节号进行引用。
使用超链接使读者可以跳到软件需求规格说明或其他文档的相关部分。
使用合适的模板来组织所有的必要信息。
410.1.1需求的标识为了满足可跟踪性和可修改性的质量标准,必须对每个功能性需求进行惟一而永久的标识,可以在变更请求、修改的历史记录、交叉引用或需求的跟踪矩阵中引用特定的需求。
下面介绍几种不同的需求标识方法:
1.序列号2.层次型编号3.层次型文本标签如:
Print.confirmcopies(打印部分的确认打印)510.1.2处理不完整性4有时,我们清楚自己缺少特定需求的某些信息。
在解决这个不确定性之前,我们可能必须与客户商议、检查外部接口描述或者构建一个原型。
4使用“待确定”(tobedetermined,TBD)符号来标记这些尚未确定的需求。
4在实现一个需求集之前,必须解决所有的TBD问题,因为任何遗留的不确定问题都会提高开发人员或测试人员出错及不得不进行返工的风险。
610.1.3用户界面和软件需求规格说明4把用户界面的设计纳入软件需求规格说明中既有好处也有坏处。
不足之处是,屏幕图像和用户界面构架描述的是解决方案(设计),而不是需求。
好处是,对可能的用户界面(例如,工作原型)进行研究会使需求无论对用户还是对开发人员都是实实在在的。
4一个合理的折中方法是,将所选择的用户界面概念草图写入到软件需求规格说明中,而在实现时并不要求精确地遵循这些草图模型。
710.2软件需求规格说明模板4每个软件开发组织都应该在它们的项目中采用一种或多种标准的软件需求规格说明模板。
4图10.1软件需求规格说明模板改写自IEEE830标准。
8图10.1软件需求规格说明模板1.引言1.1目标1.2文档约定1.3读者对象和阅读建议1.4项目范围1.5参考资料2.总体描述2.1产品前景2.2产品特性2.3用户类及其特征2.4运行环境2.5设计和实现上的约束2.6用户文档2.7假设和依赖3.系统特性3.1系统特性X3.x.1描述和优先级描述和优先级3.x.2激励激励/响应序列响应序列3.x.3功能性需求功能性需求4.外部接口需求4.1用户界面4.2硬件接口4.3软件接口4.4通信接口5.其他非功能性需求5.1性能需求5.2防护性需求5.3安全性需求5.4软件质量属性6.其他需求7.附录A:
术语表8.附录B:
分析模型9.附录C:
待确定问题的清单图10.19模板各部分的说明对图10.1中各部分的详解:
1.引言提供了一个概述,帮助读者理解软件需求规格说明的组织方式和使用方式。
(1)目标确定需求在文档中定义的产品和应用程序,包括修订版本或发布版本号。
(2)文档约定描述编写文档时所采用的标准或印刷上的约定,包括文本样式、强调形式或具有特殊意义的表示符号。
(3)读者对象和阅读建议列举软件需求规格说明面向的不同读者对象。
(4)项目范围对软件及其的作用的简短描述。
把软件与用户或公司的目标相关联,把软件与业务目标和策略相关联。
也可以使用单独的前景和范围文档来描述。
(5)参考资料列举编写软件需求规格说明时所参考的所有文档或其他资源。
可使用超文本链接。
10模板各部分的说明2.总体描述从总体上描述产品及其运行环境,以及产品用户对象和已知的约束、假设和依赖关系。
(1)产品前景描述产品的背景和起源
(2)产品特性列出产品所具有的主要特性或者产品可实现的重要功能。
(3)用户类及其特征描述可能使用该产品的各种用户类和他们的相关特征。
(4)运行环境描述产品的运行环境,包括硬件平台、操作系统,以及用户、服务器和数据库的地理位置等。
(5)设计和实现上的约束描述限制开发人员进行有效选择的所有因素,以及每一种约束的基本原理。
(6)用户文档列出将要交付的用户文档组件以及可执行软件,包括用户手册、联机帮助和教程。
(7)假设和依赖描述假设的情况和项目对外部因素的所有依赖关系。
11模板各部分的说明3.系统特性模板可以根据系统特性来组织,也可以按照用例、操作模式、对象类或功能层次结构等来组织。
总之应该选择一种使读者易于理解产品预期功能的方式。
系统特性X用简短的语言说明特性的名称。
每一个特性都包括:
3.x.1描述和优先级描述和优先级提供对该特性的简短描述,并指出该特性的优先级是高、中提供对该特性的简短描述,并指出该特性的优先级是高、中或低。
或低。
3.x.2激励激励/响应序列响应序列列出输入激励序列和系统响应序列。
列出输入激励序列和系统响应序列。
3.x.3功能性需求功能性需求逐相列出与该特性相关的详细功能性需求。
逐相列出与该特性相关的详细功能性需求。
12模板各部分的说明4.外部接口需求
(1)用户界面描述系统所需的每个用户界面的逻辑特征。
可能包括以下条目:
l对图形界面(GUI)标准的引用或将要采用的产品系列的样式指南。
l有关字体、图标、按钮标签、图像、颜色选择方案常用控件等的标准。
l屏幕布局或解决方案的约束。
l每个屏幕中将出现的标准按钮,功能或导航链接。
l快捷键。
l消息显示约定。
l便于软件定位的布局标准。
l满足视力有问题的用户要求。
应该将用户界面设计的细节写入单独的用户界面规格说明中,而不能写入软件需求规格说明中,软件需求规格说明中应写入屏幕模型。
(2)硬件接口描述系统中软件和硬件组件之间每一接口的特征。
包括支持的设备类型、软件和硬件之间的数据和控制交互以及所用的通讯协议等。
(3)软件接口描述该产品与其他软件组件之间的链接,包括数据库、操作系统、工具、库和集成的商业组件等。
(4)通信接口描述产品将使用的所有通讯功能的需求。
13模板各部分的说明5.其他非功能性需求
(1)性能需求声明各系统操作特定的性能需求,并解释其原理以指导开发人员做出合理的设计选择。
(2)防护性需求声明与产品使用过程中可能发生的损失、破坏或危害相关的需求。
(3)安全性需求指定与安全性、完整性或保密性问题相关的所有需求。
(4)软件质量属性声明对客户或开发人员至关重要的其他产品质量特性。
14模板各部分的说明6.其他需求定义在此软件需求规格说明中其他部分未出现的所有其他需求,例如国际化需求(货币、日期格式、语言、国际规则以及文化和政治上的问题)及法律上的需求。
7.附录A:
术语表定义读者需要了解的所有专门术语(包括缩略词),以便他们能够正确地理解软件需求规格说明。
8.附录B:
分析模型它包括或指向相关的分析模型,例如:
数据流图、类图、状态转换图实体关系图(参见第11章)。
9.附录C:
待确定问题的清单这些问题包括标记为“待确定”(tobedetermined,TBD)的需求、悬而未决的决策以及有待解决的冲突等。
15本次课小结表示软件需求的几种方式有关需求可读性的几点建议软件需求规格说明模板模板各部分的说明1610.3编写需求文档的原则编写软件需求文档时,应牢记以下几点建议:
1.使用语法、拼写和标点正确的完整句子,使语句和段落简短明了。
2.采用主动语态的表达方式。
3.使用的术语应该与术语表中定义的术语保持一致,要特别注意同义词和近义词。
4.将含糊不明确的顶层需求分解成足够详细的几个需求,以便充分阐明这一需求,并消除歧义。
5.需求声明应该具有一致的风格。
1710.3编写需求文档的原则6.当以“用户将”的形式来声明需求时,无论什么时候,只要可能,就要确定特定的参与者(例如,“购买者将”)。
7.使用列表、数字、图和表来表示信息,使其易于阅读。
8.强调最重要的信息。
9.有歧义的语言会导致需求无法验证,因此,要避免使用语义不清的主观术语。
1810.4改进前后的需求示例高质量的需求陈述的几个基本特征:
完整性、正确性、可行性、必要性、具有优先级、无歧义和可验证性。
不具备这些特征的需求会导致混淆,针对每个需求,需要纠正其中所存在的问题。
以下是几个改进需求的范例。
19例1改进前:
“后台任务管理器(BTM)必须在固定的时间间隔内提供状态消息,并且每次时间间隔不得小于60秒”改进后:
1.后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。
1.1在后台任务启动之后,消息必须每间隔6010秒更新一次。
1.2消息应该保持持续可见性。
1.3后台任务管理器在每次可以与后台任务进程进行通讯时,都应该显示后台任务已完成的百分比。
1.4当后台任务完成时,后台任务管理器应该显示一个“已完成(done)”的消息。
1.5如果后台任务终止执行,那么后台任务管理器应该显示一个出错误的消息。
20例2改进前:
改进前:
“xmlxml编辑器必须在显示和隐藏非打印字符之编辑器必须在显示和隐藏非打印字符之间进行瞬间切换间进行瞬间切换”改进后:
用户在编辑文档时,通过激活特定的触发机制,能够在显示和隐藏所有xml标签之间进行切换。
改变显示方式所需的时间为0.1秒或更短。
2110.5数据字典4数据字典是一个共享存储库,用于定义应用程序中使用的所有数据元素或属性的含义、数据类型、长度、格式、需要的精度以及数据允许的取值范围或数据值的列表。
4数据字典中的信息把各种需求表式绑定在一起。
4可以使用简单的符号法来表示数据字典中的数据项。
要定义的数据项显示在等号的左边,而其定义显示在等号的右边。
(这种符号表示法可定义基本数据元素、由多个数据元素组成的结构、可选的数据项、迭代(重复)的数据项以及某个数据项值的列表。
)常用符号:
=表示”等价于“或”定义为“+连接两个数据元素表示”或“表示”重复“()表示”可选“221.基本数据元素基本数据元素基本数据元素是不可能或没有必要进一步分解的元素如:
请求标识号=*系统生成的6位顺序整数,以1开头,并能唯一标识每个请求*2.组合结构组合结构一个数据结构或记录包含多个数据项。
如果某个元素是可选的,就把它用一对园括号括起来。
结构中的所有数据项必须在数据字典中进
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 分析 解决方案 设计 ch