软件工程之需求规格第11章软件的质量属性
- 格式：pdf
- 大小：439.17 KB
- 文档页数：16
下载文档原格式
合集下载
软件体系结构5_软件体系结构的质量属性
软件体系结构5_软件体系结构的质量属性
1. 性能（Performance）：性能是衡量软件体系结构完成特定任务所需的时间和资源的能力。
在性能方面，主要关注的指标包括响应时间、吞吐量和资源利用率。
一个好的体系结构应能够支持大规模并发用户使用，而不会因为系统负载增加而导致性能下降。
2. 可用性（Availability）：可用性是指软件体系结构在特定时间内处于可操作状态的能力。
可用性主要与系统的可靠性、容错性和可恢复性相关。
一个可靠的软件体系结构应能够及时响应用户需求，并尽量减少停机时间和故障恢复时间，提供稳定、可靠的服务。
3. 可靠性（Reliability）：可靠性是指软件体系结构在给定的时间内正确执行其功能的能力。
可靠性与系统的错误率和故障率相关。
一个可靠的软件体系结构应能够预防和容忍异常情况，以确保正确的运行，保证数据的完整性和准确性。
4. 安全性（Security）：安全性是指软件体系结构在防止未经授权的访问和保护用户数据等方面的能力。
软件体系结构应能够识别和阻止潜在的安全威胁，如恶意攻击、非法访问和数据泄露等。
安全性要求通常包括认证、授权、加密和审计等功能。
5. 可扩展性（Scalability）：可扩展性是指软件体系结构能够在不同规模和负载下进行水平或垂直扩展的能力。
一个可扩展的软件体系结构应能够动态调整资源，并能够在需要时自动增加或减少处理能力，以适应不断变化的用户需求。
总之，软件体系结构的质量属性是衡量软件体系结构能力和性能的关键指标。
在设计软件体系结构时，需要充分考虑这些质量属性，以确保软件能够满足用户的需求，并具有高性能、可靠性、安全性和可扩展性。
12软件的质量属性
1) 通过定义不悦人意行为(一种反向需求)，你可以 设计出强制系统表现出那些行为的测试用例。 2) 如果你不能强制系统，那么你可能达到了你的属 性目标。
这种方法最适用于要求安全性能很高的应用 程序。
SQE-GYG
12/18
第 12 章 软件的质量属性
12.3 属性的取舍
P159
对一些特定的属性对进行取舍是 不可避免地也是必要的。 用户和开发者必须确定哪些属性 比其它属性更为重要，并定出优先 级。
SQE-GYG
5/18
在不成功的项目中，80%是由于质量问题。
第 12 章 软件的质量属性
12.0 质量的定义与意义
P149
软件质量的意义
除功能需求外，软件质量属性的特性，称为系统的 非功能需求。 这些特性包括：系统的易用性、执行速度、可靠性， 处理异常情况的能力与方式等。 在决定系统的成功或失败的因素中，满足非功能需求 往往比满足功能需求更为重要。 如果你在需求的获取阶段不去探索客户对质量的期 望，结果可能是客户失望和开发者沮丧。
对一些特定的属性对进行取舍是不可避免地也是必 要的。
SQE-GYG
17/18
第 12 章 软件的质量属性
体会
必须让参加项目的每个人从进入需求这一刻 就牢牢记住：
软件质量从需求开始。 质量是软件企业的生命线！ 21世纪再不重视软件质量的企业恐 怕连生存的机会都没有。
谢谢大家
SQE-GYG
18/18
在软件中，其自身不能实现质量特性的合理平衡。 在需求获取的过程中，加入对质量属性期望的讨论， 并把你所了解的写入软件需求规格说明中。这样， 才有可能提供满意的产品。
SQE-GYG
16/18
第 12 章 软件的质量属性
这种方法最适用于要求安全性能很高的应用 程序。
SQE-GYG
12/18
第 12 章 软件的质量属性
12.3 属性的取舍
P159
对一些特定的属性对进行取舍是 不可避免地也是必要的。 用户和开发者必须确定哪些属性 比其它属性更为重要，并定出优先 级。
SQE-GYG
5/18
在不成功的项目中，80%是由于质量问题。
第 12 章 软件的质量属性
12.0 质量的定义与意义
P149
软件质量的意义
除功能需求外，软件质量属性的特性，称为系统的 非功能需求。 这些特性包括：系统的易用性、执行速度、可靠性， 处理异常情况的能力与方式等。 在决定系统的成功或失败的因素中，满足非功能需求 往往比满足功能需求更为重要。 如果你在需求的获取阶段不去探索客户对质量的期 望，结果可能是客户失望和开发者沮丧。
对一些特定的属性对进行取舍是不可避免地也是必 要的。
SQE-GYG
17/18
第 12 章 软件的质量属性
体会
必须让参加项目的每个人从进入需求这一刻 就牢牢记住：
软件质量从需求开始。 质量是软件企业的生命线！ 21世纪再不重视软件质量的企业恐 怕连生存的机会都没有。
谢谢大家
SQE-GYG
18/18
在软件中，其自身不能实现质量特性的合理平衡。 在需求获取的过程中，加入对质量属性期望的讨论， 并把你所了解的写入软件需求规格说明中。这样， 才有可能提供满意的产品。
SQE-GYG
16/18
第 12 章 软件的质量属性
软件工程导论第11章
22
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口， 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的，这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时，应该在根类(或适当的基类)中， 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法，则应该把它当作扩充接口。扩充接口与转换接口不同，并 不需要强迫用户在派生类中重新定义它们，相反，如果在派生类中没 有给出扩充接口的新算法，则将继承父类中的算法。当用C++语言实现 时，在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合：指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中，对象是最基本的模块，因此， 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类： (1) 交互耦合： 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散，应遵守下述准则： 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数，降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反，应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类，构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务，从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴：最原始的重用形式。 复制或修改原有代码时可能出错，存在严重的配臵 管理问题，人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含：许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解，修改了库 中源代码之后，所有包含它的程序自然都必须重新 编译。 继承：利用继承机制重用类库中的类时，无须修 改已有的代码，就可以扩充或具体化在库中找出的 类，基本上不存在配臵管理问题。
软件架构与质量属性研究
软件架构与质量属性研究随着软件开发技术的不断发展和进步，软件架构成为了软件开发中不可或缺的一部分。
软件架构作为软件系统设计的指南，对软件系统的结构和性能具有非常重要的影响。
在软件开发过程中，软件架构的选择和设计对软件质量属性的影响也是相当大的。
因此，软件架构和质量属性的研究已经受到了广泛的关注和研究。
一、软件架构与质量属性的关系软件架构是软件系统的基础，它在软件系统中起到了控制和指导的作用。
软件架构的设计和选择对软件系统的各种质量属性有着不同的影响。
软件质量属性是指软件产品必须满足的非功能性需求，它包括性能、可靠性、可维护性、安全性、可移植性等多个方面。
因此，软件架构的设计和选择应该充分考虑到软件质量属性的需求。
1. 性能软件的性能是指它对于用户请求的响应速度和吞吐量的处理能力。
软件架构对软件性能有着直接的影响。
在软件架构设计中，需要考虑到系统的并发性、分布式处理、数据访问的效率和网络通信等因素。
通过合理选择和使用软件架构，可以有效提高软件系统的性能。
2. 可靠性软件的可靠性是指软件在特定环境下的稳定性和可预测性。
软件架构在保证软件可靠性方面扮演着非常重要的角色。
软件架构的合理设计可以有效减少软件系统的错误和故障，从而提高软件系统的可靠性。
3. 可维护性软件的可维护性是指在软件系统上进行修改或增加功能的能力。
软件架构的设计对软件的可维护性也有着很大的影响。
在软件架构的设计中，需要考虑到软件的模块化程度、分层结构、清晰的接口定义和文档等因素。
通过合理地设计软件架构，可以提高软件系统的可维护性，使得软件更加容易进行修改和扩展。
4. 安全性软件的安全性是指保护软件系统免受未经授权访问、利用或破坏等安全威胁的能力。
软件架构在保证软件安全性方面也起着很重要的作用。
在软件架构的设计中，需要考虑到安全策略的定义、输入输出控制、访问控制、数据加密和身份验证等方面。
通过合理地设计软件架构，可以有效提高软件系统的安全性。
软件工程各章名词解释
名词解释一个三分 五个十五分第一章 绪论1. 软件2. 文档3. 软件工程4. 软件工程过程5. 软件生存周期6. 软件生存周期模型第二章 软件可行性研究与项目开发计划1. 投资回收2. 纯收人第三章 软件需求分析1. 需求分析2. 数据流3. 数据字典4. 加工5. 数据流图第四章 软件概要设计1. 模块2. 模块化3. 抽象4. 信息隐蔽5. 模块独立性6. 耦合性7. 无直接耦合8. 数据耦合9. 标记耦合10. 控制耦合11. 公共耦合12. 内容耦合13. 内聚性14. 偶然内聚15. 逻辑内聚16. 时间内聚17. 通信内聚18. 顺序内聚19. 功能内聚第五章 软件详细设计1. PAD2. 过程设计语言(PDL)第六章 软件编码1. 程序设计风格2. 程序可移植性第七章 软件测试1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖5. 条件组合覆盖6. 路径覆盖7. 环路复杂性8. 黑盒测试9. 白盒测试10. 驱动模块11. 桩模块12. 单元测试13. 集成测试14. 确认测试15. 调试第八章 软件维护1. 维护2. 校正性维护3. 适应性维护4. 完善性维护5. 预防性维护6. 软件可维护性第九章 软件开发的增量模型1. 原型第十章 面向对象的方法1. 对象2. 类3. 消息4. 方法5. 继承性6. 单重继承7. 多重继承8. 多态性9. 抽象10. 信息隐藏11. 链12. 关联第十一章 软件质量与质量保证1. 软件可靠性2. 效率3. 可维护性4. 可移植性5. 可互操作性6. 适应性7. 可重用性8. 软件设计质量9. 软件程序质量10. 冗余第十二章 软件工程管理1. 软件配置管理2. 软件配置项3. 基线4. 文档第十三章 软件开发环境1. 软件开发环境2. 软件工具3. CASE4. CASE生存期5. CASE工作台软件工程自考名词解释答案第一章 绪论1. 计算机程序及其说明程序的各种文档.2. 文档是有关计算机程序功能,设计,编制,使用的方案或图形资料.3. 用科学知识和技术原理来定义,开发,维护软件的一门学科.4. 软件工程过程规定了获取,供应,开发,操作和维护软件时,要实施的过程,活动和任务.5. 软件生存周期是指一个软件从得出开发要求开始直到该软件报废为止的整个时期.6. 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型.第二章 软件可行性研究与项目开发计划1. 投资回收期就是使累计的经济效益等于最初的投资费用所需的时间.2. 在整个生存周期之内的累计经济效益(折合成现在值)与投资之差.第三章 软件需求分析1. 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非不甘落后将用户非不甘落后 需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程.2. 数据流是数据在系统内传播的路径,因此由一组成分固定的数据项组成.3. 数据字典(Data Dic onary, 简称DD)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.4. 加工又称为数据处理,是对数据流进行某些操作或变换.5. 数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程.第四章 软件概要设计1. 模块在程序中是数据说明,可执行语句等程序对象的集合,或者是单独命名和编址的元素,在软件的体系结构中,模块是可组合,分解和更换的单元.2. 模块化是指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程.每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个要求的功能.3. 抽象是认识复杂现象过程中使用的思维工具,即抽出事物本质的共同的特性而暂不考虑它的细节,不考虑其他因素.4. 信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不需要这些信息的其他模块来说,是不能访问的.5. 模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单.6. 耦合性也称块间联系.指软件系统结构中各模块间相互联系紧密程序的一种度量.7. 无直接耦合指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息.8. 数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递.9. 标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址.10. 控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关,标志等),被调模块通过该控制变量的值有选择地执行块内某一功能.11. 公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可是是全程变量或数据结构,共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).12. 当一个模块直接使用另一个模块的内部数据,或通过非正常口转入另一个模块内部,这种模块之间的耦合为内容耦合.13. 内聚块又称块内联系指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量.14. 偶然内聚指一个模块内的各处理元素之间没有任何联系.15. 逻辑内聚指模块内执行个逻辑上相似的功能,通过参数确定该模块完成哪一个功能.16. 把需要同时执行的动作组合在一起形成的模块为时间内聚模块.17. 通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据.18. 顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入.19. 功能内聚指模块内所有元素共同完成一个功能,缺一不可.因此模块不能再分割.第五章 软件详细设计1. PAD图指问题分析图(Problem Analysis Diagram),是一咱算法描述工具,它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.2. 过程设计语言(Process Design Language,简称PDL),也称程序描述语言(Program Descrip on Language),又称为伪码.它是一种用于描述模块自法设计和处理细节的语言.第六章 软件编码1. 程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.2. 指程序从一个计算机环境移值到另一个计算机环境的容易程序.第七章 软件测试1. 语句覆盖是指设计足够的测试用例,使被测程序中每个语句至少执行一次.2. 判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次”真”和”假”值,从而使程序的每一个分支至少都通过一次.3. 条件覆盖指设计足够的测试用例,使得判定表达工中每个条件的各种可能的值出现一次.4. 判定/条件覆盖标准指设计足够的测试用例,使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次.5. 条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次.6. 路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径.7. McCabe定义程序图的环路为程序图中区域的个数.区域个数为边和结点圈定的封闭区域数加上图形外的区域数1.8. 黑盒测试是功能测试又称为功能测试或数据驱动测试.9. 白盒测试是对程序中尽可能多和逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致.10. 驱动模块是用来模拟被测模块的上级调用模块的模块,功能要比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被模块,接收被测模块的测试结果并输出.11. 桩模块用来代替被测试模块所调用的模块它的作用是返回被测模块所需的信息.12. 单元测试指对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误.13. 集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行测试,故也称组装测试或联合测试.14. 确认测试又称有效性测试.是为了检查软件的功能与性能是否与需求规格说明书中确定的指标相符合所进行的测试.15. 调试是为了确定错误的原因和位置,并改正错误所进行的工作,因此调试也称为纠错.第八章 软件维护1. 在软件运行/维护阶段对软件产品所进行的修改就是维护.2. 为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护.3. 随着计算机的飞速发展,计算机硬件,软件及数据环境在不断发生变化,为了使应用软件适应这种变化而修改软件的过程称为适应性维护.4. 在犯罪分子件运行时期中,用户往往会对软件提出新的功能要求与性能要求.这种增加软件功能,增强软件性能,提高软件运行效率而进行的维护活动称为完善性维护.5. 为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护.6. 软件可维护性是指软件能够被理解,校正,适应及增强功能的容易程度.第九章 软件开发的增量模型1. 软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性.第十章 面向对象的方法1. 对象是人们要进行研究的任何事物,从最简单的整数到复杂的飞机等均可看作对象,它不仅能表示具体的事物,还能表示抽象的规则,计划或事件.2. 具有相同或相似性质的对象的抽象就是类具有相同或相似性质的对象的抽象就是类3. 对象之间进行通信的构造叫做消息.4. 类中操作的实现过程叫做方法,一个方法有方法名,参数,方法体.5. 继承性是子类自动共享父类数据结构和方法的机制这是类之间的一种关系.6. 在类层次中,子类只继承一个父类的数据结构和方法,称为单重继承.7. 在类层次中,子类继承了多个父亲的数据结构和方法,称为多重继承.8. 多态性是指相同的操作或函数,过程可作用于多用户种类型的对象上并获得不同结果.不同的对象收到同一消息可以产生不同的结果,这种现象称为多态性.9. 抽象是指强调实体的本质,内在的属性,忽略一些无关紧要的属性.10. 信息隐蔽是指所有软件部件内部都有明确的范围以及清楚的外部边界每个软件部件都有友好的界面接口,软件部件的内部实现与外部可访问性分离.11. 链表示对象间的物理与概念联结.12. 关联表示类之间的一种关系,就是一些可能的链的集合.第十一章 软件质量与质量保证1. 软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度.2. 为了完成预定功能,软件系统所需的计算机资源和程序代码数量的程度.3. 找到并改正程序中的一个错误所需代价的程度.4. 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量.5. 将一个系统耦合到另一个系统所需的工作量.6. 修改或改进一个已投入运行的软件所需工作量的程度.7. 一个软件能再次用于其他相关应用的程度.8. 设计的规格说明书要符合用户的要求.9. 程序要按照设计规格说明所规定的情况正确执行.10. 冗余是指实现系统规定功能是多余的那部分资源,包括硬件,软件,信息和时间.第十二章 软件工程管理1. 软件配置管理,简称SCM,是一组管理整个软件生存期各阶段中变更的活动是一组管理整个软件生存期各阶段中变更的活动2. 软件配置项是软件工程中产生的信息项,它是配置管理的基本单位.3. 基线是软件生存期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果.4. 文档是指某种数据媒体和其中所记录的数据.在软件工程中,文档用来表示对需求,工程或结果进行描述,定义,规定,报告或认证的任何书面或图示的信息.它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令.第十三章 软件开发环境1. 软件开发环境是相关的一组软件工具集合,它支持一定的软件开发方法或按照一定的软件开发模型组织而成.2. 软件工具是指为支持计算机软件的开发,维护,模拟,移植或管理而研制的程序系统.3. CASE是一组工具和方法的集合,可以辅助软件开发生命周期各阶段进行软件开发.4. 一个组织中的CASE系统从被始需求到完全废弃这一生存期.5. 一个CASE工作台是一组工具集,支持像设计,实现或测试等特定的软件开发阶段.。
软件需求的质量保证PPT课件
50
12
3.灵活性
• 灵活性就像我们所知道的可扩充性、增加性、 可延伸性和可扩展性一样,灵活性表明了在产品 中增加新功能时所需工作量的大小。
• 灵活性对于通过一系列连续的发行版本,并采用 渐增型和重复型方式开发的产品是很重要的。
• 实例:“一个至少具有6个月产品支持经验的软件 维护程序员可以在4个小时之内为系统添加一 个新格式的打印报表。"
• 为了指定只能以一种方式理解需求需要 做两件事：
– 在规格说明书中对使用的术语进行定义，对 它们的含义进行说明(词汇术语表)。
– 检查每项需求使用术语的方式都与它们的定 义相符。
50
38
5.可验证的需求
• 需求必须是可验证的或“可测试的”。 • “可验证的或可测试的”需要合理的定义良好
的无歧义的需求。 • 如果需求是不可验证的,则说明需求尚不明确，
50
18
9.可维护性
• 可维护性表明了在软件中纠正一个缺陷或做一 次更改的简易程度。
• 可维护性取决于理解软件、更改软件和测试软 件的简易程度,可维护性与灵活性密切相关。
• 高可维护性对于那些经历周期性更改的产品或 快速开发的产品很重要。你可以根据修复一个 问题所花费的平均时间和修复正确的百分比来 衡量可维护性。
50
27
1.正确的需求
• 一个SRS(需求集)是正确的,当且仅当其中 每条需求都代表了要构造系统所要完成 的事物。
• 只是简单地在文档中写一些信息是不能 保证正确的,任何自动设计工具也不能保 证正确。
50
28
需要和需求的全域
• 在一个软件项目中经 常发生的是遗漏区域A 表示的信息,意外地把 C区域表示的信息包括 进来。
软件质量属性
1.阐述软件系统功能性和质量属性之间的关系
2.我们在软件开发实践中通常关心系统的哪几种质量属性
3.请写出性能质量属性的一般质量属性场景
题目解答：
1.软件系统功能性是指系统能够完成所期望的工作的能力，而质量属性则是高
于系统功能基本要求的，它是对多种更高层次需求的抽象描述，如安全、可靠、易用及易于修改等，显然它适用于多个特定系统而非一个。
由此我们可以看出，功能性和质量属性是正交的关系，即对应于相同的功能可以具有不同的质量属性。
2. 我们在软件开发实践中通常所关心的系统的质量属性有以下几种：
1）易用性（Usability）：涉及到构架和非构架两个方面
2)可修改性（Modifiability）：由划分功能的方式（构架）和模块中的编码技巧及注释（非构架）两方面决定
3)系统的性能（Performance）：既受到构架的影响又受到具体算法的影响
4)安全性（Security）
5)可用性（Availability）
3. 性能与事件发生时，将要耗费系统多长时间做出响应有关.对性能进行分析，影响性能的因素包括：事件源的数量和到达模式，而到达系统的事件包括：周期性事件、随机事件或偶然事件。
根据我们所了解的，质量属性场景包括刺激源、刺激、环境、制品、响应和响应度量。
根据各个部分的具体要求结合系统性能，我们可以将性能的一般质量属性场景描述为：。
软件质量属性
软件质量属性软件质量属性司宇明摘要：⼀个软件最为重要的阶段不是开发阶段，⽽是开发前各个阶段的准备。
⽐如需求分析以及软件架构，这些往往能够决定⼀个软件的优劣程度。
对于软件体系架构中⼜有很多重要的地⽅，其中质量属性是可以评价⼀个软件的好坏。
以此对软件架构的质量属性进⾏简单分析，望对软件体系架构有所帮助。
关键字：软件架构；软件质量属性软件质量是指在软件开发过程中形成的软件满⾜明确规定的需求的程度，也是衡量软件好坏的⼀个重要指标。
随着软件规模和复杂性的不断增⼤，如何控制和保证软件的质量已成为⼀个亟需解决的问题。
为了提⾼软件的质量，需要在整个软件开发周期中进⾏有计划的活动，包括对软件的评价。
随着软件体系结构的发展，对软件体系结构系统进⾏深⼊研究将会成为提⾼软件⽣产率和解决软件维护问题的新的最有效的途径。
⼀、什么是软件体系架构1.什么是架构对于架构，并不是软件第⼀个引⽤的，是从其他⾏业的引过来的。
不同的⾏业有不同的架构。
但是其实简单来说架构就是通过分配合作，⼈类⽤少的时间完成更多活动，让⼈类的⼯作更加有效率。
2.什么是软件什么是软件，不同的⼈有不同定义，参考资深架构师王概凯⽼师的架构漫谈随笔⼩⽣有些许的启发，软件只不过是将⼈类的期望或者⾏为加⼊到机器中，以此满⾜⼈类的⼯作期望或者⾏为期望这样都可以称为软件。
3.软件体系架构有了软件，有了架构，总之都是为了⽤更⾼的效率满⾜⼈类的⾏为期望。
因此在这样的基础上需要软件体系架构让这中转换更加有效率，变得更加规律化。
提⾼⼈类的利益。
软件体系结构是国际上软件⼯程研究的⼀个新兴领域，它的研究⽬前还处于初始阶段，对什么是软件体系结构还没有⼀个标准的、为⼤家所普遍接受的定义。
⼀般认为，⼀个软件系统的体系结构定义了组成系统的计算构件和构件之间的相互作⽤关系，在体系结构层次的构件如:客户、服务器、数据库、过滤器等；构件之间的交互可以是⾮常简单的。
⼆、软件架构质量属性分析1.常见质量属性分类常见的软件质量属性有6个，分别为可⽤性、可修改性、性能、安全性、可测试性、易⽤性。
软件工程导论(第11章)
3. 信息隐蔽
在面向对象方法中，信息隐蔽通过对象的封
装性实现：类结构分离了类的接口与类的实
现，从而支持了信息隐蔽。
4. 弱耦合
弱的耦合可以提高软件模块的独立性，避免 某一部分模块发生变化对其它模块有较大的影 响。
一般来说，对象间的耦合有两大类：
A．交互耦合：对象间的耦合通过信息连接来
实现。应使交互耦合尽量松散。
2. 一般—特殊结构的深度应适当
中等规模的系统中，类等级层次数应保持 为7±2。不是必要情况，不应该随意创建派生类；
3. 设计简单的类：设计小而简单的类，便于
开发和管理；
1）避免包含过多的属性； 2）有明确的定义； 3）尽量简化对象之间的合作关系； 4）不要提供太多服务。
4. 使用简单的协议：设计简单的类接口，发送 的消息中参数要少。 5. 使用简单的服务：编写实现每一个服务时， 避免复杂的语句和结构； 6. 把设计变动减至最小。
2.
两个方向的关联都用属性实现，这种方法能 实现快速访问。
3.
用独立的关联对象实现双向关联。关联对象 不属于相互关联的任何一个类，它是独立的 关联类的实例 。
40
41
4、关联对象的实现
关联对象的实现方法取决于关联的阶数：
一对一关联：
• 关联对象可以与参与关联的任一个对象合并。
一对多关联：
• 关联对象可以与“多”端对象合并。
11.9 设计类中的服务 11.9.1 确定类中应有的服务 11.9.2 设计实现服务的方法
1. 设计实现服务的算法
1）算法复杂度；
2）容易理解、容易实现；
3）容易修改；
2. 选择数据结构 3. 定义内部类和内部操作
软件质量属性
软件质量属性1 性能（Performance）指系统的响应能力，既要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。
（经常用单位时间内所能处理的事务的数量或系统完成某个事务处理所需要的时间来定量表示。
性能测试经常要使用基准测试程序。
）2 可靠性（Reliability）指软件系统在应用或错误面前，在意外或错误面前使用的情况下维持软件系统功能特性的基本能力。
（是重要的软件特性之一，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。
通常是MTBF-平均失效间隔时间和MTTF-、平均失效等待时间来衡量。
）3 可用性（Availability）指系统能够正常运行的时间比例。
（经常用两次故障之间时间的长度或者出现故障时系统能够恢复正常的速度来表示。
）4 健壮性（Robustness）是指在处理或环境中，能够承受的压力或变更的能力。
（健壮性并不是说再系统发生错误时能继续运行，而是指系统按照事先定义好的方式运行-事务处理速度）指系统向合法用户提供服务的同时阻止非法用户的使用的企图或拒绝对其服务。
（根据系统可能受到的安全威胁可分为机密性、完整性、不可否认性和可控性等特性。
）6 可修改性只能够快速地以较高的性能价格比对系统进行变更的能力。
（通常以某些具体的变更为基准，通过考察这些变更的代价来衡量。
可修改性包含可维护性、可扩展性、结构重组和可移植性等方面。
）7 可变性指体系结构经扩充或变更为新体系结构的能力。
（这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。
当要将某个体系结构作为一系列相关产品的基础时，可变性尤为重要。
）8 易用性衡量用户使用一个软件完成指定任务的难易程度。
（用户对软件的易使用性、质量、效率以及效果的感觉，是交互的适应性、功能性和有效性的集中体现。
）9 可测试性指软件发生故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计和测试执行（通常，可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明细的软件，而不具有可测试性的软件往往是具有很强的耦合和混乱的逻辑。
软件质量属性
14
作业
从表12.1中确定若干可能对大作业案例项目的用户至关重要 的质量属性。为每个属性构想几个问题，这将有助于用户清 楚地表达他们的期望。根据用户的回答，为每一个重要属性 写出一两个具体的目标。
用Planguage自己编写一条质量属性需求。
15
12.6 实现非功能性需求
质量属性类型
完整性、互操作性、健壮性、易用 性、安全防护性
可能的 技术信 息类别
功能性 需求
可用性、有效性、灵活性、性、易用性
设计限 制
灵活性、可维护性、可移植性、可 靠性、可重用性、可测试性、易用 性
可移植性
设计原 则
实现限 制
虽然质量属性是非功能性 需求，但它们能够导致衍 生的功能性需求、设计原 则或其他类型的技术信息， 这些信息将产生期望的质 量特性。
为了达到产品特性的最佳平衡，我们必须在需求获取阶段识 别、指定相关的质量属性，并且为之确定优先级。如： 如果软件必须在多个平台上运行(可移植性)，那么就不要 期望系统最大程度地满足易用性。 对于高度安全的系统，很难完全测试其完整性需求。可重 用的类组件或与其他应用程序的互操作可能会破坏其安全 机制。 高度健壮的代码将缺乏有效性，因为它要进行数据确认和 错误检查。 13
性能需求的Planguage版本:
AMBITION(目标) SCALE(度量单位) METER(计量) MUST(最低标准) PLAN(一般标准) base user platform DEFINED(定义的基础用户平台)
11
12.5 属性的折中方案
不可避免地要对某些属性 组合进行折中考虑。
3
12.2 定义质量属性
分析人员要求用户代表为每一个属性设一个等级 其范围是从1级(表示不必多加考虑的属性)到5级(表示极 其重要的属性)。
作业
从表12.1中确定若干可能对大作业案例项目的用户至关重要 的质量属性。为每个属性构想几个问题，这将有助于用户清 楚地表达他们的期望。根据用户的回答，为每一个重要属性 写出一两个具体的目标。
用Planguage自己编写一条质量属性需求。
15
12.6 实现非功能性需求
质量属性类型
完整性、互操作性、健壮性、易用 性、安全防护性
可能的 技术信 息类别
功能性 需求
可用性、有效性、灵活性、性、易用性
设计限 制
灵活性、可维护性、可移植性、可 靠性、可重用性、可测试性、易用 性
可移植性
设计原 则
实现限 制
虽然质量属性是非功能性 需求，但它们能够导致衍 生的功能性需求、设计原 则或其他类型的技术信息， 这些信息将产生期望的质 量特性。
为了达到产品特性的最佳平衡，我们必须在需求获取阶段识 别、指定相关的质量属性，并且为之确定优先级。如： 如果软件必须在多个平台上运行(可移植性)，那么就不要 期望系统最大程度地满足易用性。 对于高度安全的系统，很难完全测试其完整性需求。可重 用的类组件或与其他应用程序的互操作可能会破坏其安全 机制。 高度健壮的代码将缺乏有效性，因为它要进行数据确认和 错误检查。 13
性能需求的Planguage版本:
AMBITION(目标) SCALE(度量单位) METER(计量) MUST(最低标准) PLAN(一般标准) base user platform DEFINED(定义的基础用户平台)
11
12.5 属性的折中方案
不可避免地要对某些属性 组合进行折中考虑。
3
12.2 定义质量属性
分析人员要求用户代表为每一个属性设一个等级 其范围是从1级(表示不必多加考虑的属性)到5级(表示极 其重要的属性)。
质量属性
响应度量
根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成
影响的程度
4.性能一般场景。
场景的部分
可能的值
源
大量的独立源中的一个，可能来自系统内部
刺激
定期事件到达；随机事件到达；偶然事件到达
制品
系统
环境
正常模式；超载模式
响应
处理刺激；改变服务级别
响应度量
等待事件、期限、吞吐量、抖动、缺失率、数据丢失
对用户身份进行认证；隐藏用户的身份；阻止对数据或服务的访问；允许访问数据或服务；授予或收回对访问数据或服务的许可；根据身份记录访问/修改或试图访问/修改数据/服务；以一种不可读的格式存储数据；识别无法解释的对服务的高需求；通知用户或另外一个系统，并限制服务的可用性
响应度量
用成功的概率表示，避开安全防范措施所需要的时间/努力/资源；检测到攻击的可能性；确定攻击或访问/修改数据或服务的个人的可能性；在拒绝服务攻击的情况下仍然获得服务的百分比；恢复数据/服务；被破坏的数据/服务和/或被拒绝的合法访问的范围
如果存在缺陷出现故障的概率
执行测试的时间
测试中最长依赖的长度
准备测试环境的时间
7.易用性一般场景
场景的部分
可能的值
源
最终用户
刺激
想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、
在运行时或配置时
响应
系统提供以下一个或多个响应来支持“学习系统特性”
帮助系统与环境联系紧密；界面为用户所熟悉；在不熟悉的环境中，界面是可以使用的系统提供以下一个或多个响应来支持“有效
6.可测试性一般场景。
场景的部分
可能的值
源
开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户
根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成
影响的程度
4.性能一般场景。
场景的部分
可能的值
源
大量的独立源中的一个，可能来自系统内部
刺激
定期事件到达；随机事件到达；偶然事件到达
制品
系统
环境
正常模式；超载模式
响应
处理刺激；改变服务级别
响应度量
等待事件、期限、吞吐量、抖动、缺失率、数据丢失
对用户身份进行认证；隐藏用户的身份；阻止对数据或服务的访问；允许访问数据或服务；授予或收回对访问数据或服务的许可；根据身份记录访问/修改或试图访问/修改数据/服务；以一种不可读的格式存储数据；识别无法解释的对服务的高需求；通知用户或另外一个系统，并限制服务的可用性
响应度量
用成功的概率表示，避开安全防范措施所需要的时间/努力/资源；检测到攻击的可能性；确定攻击或访问/修改数据或服务的个人的可能性；在拒绝服务攻击的情况下仍然获得服务的百分比；恢复数据/服务；被破坏的数据/服务和/或被拒绝的合法访问的范围
如果存在缺陷出现故障的概率
执行测试的时间
测试中最长依赖的长度
准备测试环境的时间
7.易用性一般场景
场景的部分
可能的值
源
最终用户
刺激
想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、
在运行时或配置时
响应
系统提供以下一个或多个响应来支持“学习系统特性”
帮助系统与环境联系紧密；界面为用户所熟悉；在不熟悉的环境中，界面是可以使用的系统提供以下一个或多个响应来支持“有效
6.可测试性一般场景。
场景的部分
可能的值
源
开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户
软件体系结构软件体系结构的质量属性.精选PPT
44可修改性的一般场景生成可修改性的一般场景生成场景的部分可能的值刺激希望增加删除修改改变功能质量属性容量制品系统用户界面平台环境或与目标系统交互的系统环境在运行时编译时构建时设计时响应查找构架中需要修改的位置进行修改且不会影响其它功能对所做的修改进行测试部署所作的修改响应度量根据所影响的元素的数量度量的成本努力资金
下，能保证用户请求不丢失；
当系统出现故障或崩溃时，恢复 时间不超过两小时；
可维护性
修改某个子系统或服务时，不影
响其他子系统或服务；
性能
高峰时系统的平均响应时间控制
在20秒以内；
系统需求的获取
一般两种途径： 用户直接主动地提供的需求。主要是一些功能性需
求和领域知识。
另一条是构架师设计“对话问题”，通过对用户提 问，进一步与他们沟通，从而得到更明确的需求。
被动冗余 (暖重起)
New Data
1
2
Old Data Backup1
Main Component
Old Data
Backup2
Data
3
1. The main component receives new data. 2. The main component sends old data/state to backup components. 3. If fault happens, decision has to be made to what backup component to
Do Some Action 1 Controller
3
2 Process 1
Process 2
Process 3
1. Controller requests processes to do an action. 2. Each process receives request and works on the action. 3. A response is sent back from each process. If there is a fault, a recovery will be very fast. The controller could send out requests to check if a process is down and expect a receipt to show process up.
下，能保证用户请求不丢失；
当系统出现故障或崩溃时，恢复 时间不超过两小时；
可维护性
修改某个子系统或服务时，不影
响其他子系统或服务；
性能
高峰时系统的平均响应时间控制
在20秒以内；
系统需求的获取
一般两种途径： 用户直接主动地提供的需求。主要是一些功能性需
求和领域知识。
另一条是构架师设计“对话问题”，通过对用户提 问，进一步与他们沟通，从而得到更明确的需求。
被动冗余 (暖重起)
New Data
1
2
Old Data Backup1
Main Component
Old Data
Backup2
Data
3
1. The main component receives new data. 2. The main component sends old data/state to backup components. 3. If fault happens, decision has to be made to what backup component to
Do Some Action 1 Controller
3
2 Process 1
Process 2
Process 3
1. Controller requests processes to do an action. 2. Each process receives request and works on the action. 3. A response is sent back from each process. If there is a fault, a recovery will be very fast. The controller could send out requests to check if a process is down and expect a receipt to show process up.
《软件质量属性》PPT课件
精选课件
5
构架和质量属性之间的关系
构架不能独自实现质量属性
构架为质量属性的实现打下了基础，但不关注实现细节的话， 这个基础就失去了意义。
复杂系统中，不能孤立地实现质量属性
例如，为了可靠性，增加冗余处理器和进程，保证不会因单 点故障使系统崩溃。但这样对安全性不利，系统会有更多的 地方可能会遭到入侵
其他如商业属性（上市时间）、概念属性等，在本课 程中不讨论精选课件 Nhomakorabea14
可用性Availability
Availability refers to the ability of a system to mask or repair faults such that the cumulative service outage period does not exceed a required value over a specified time interval
精选课件
16
Hazard analysis：is a technique that attempts to catalog the
hazards that can occur during the operation of a system.
Catastrophic灾难性
This kind of failure may cause a crash. This failure represents the loss of critical function required to safely fly and land aircraft.
质量属性 Quality Attribute
精选课件
1
主要内容
一、质量属性场景 二、理解质量属性 三、实现质量属性的战术 四、设计架构
软件架构的10个质量属性
软件架构的10个质量属性一般地，对于软件系统的需求而言，分为两类：功能性需求和非功能性需求。
软件系统的架构设计既要满足软件的功能性需求，还要满足软件的非功能性需求。
特别地，系统架构对软件非功能性需求的支撑成为架构的质量属性。
本文描述了软件的10个质量属性，但不意味着每个质量属性都会在架构设计中呈现，可以挑选对产品最重要的质量属性，然后进行实现。
1 可伸缩性随着用户或请求数量的增加，系统运行和操作的能力也随之增加。
在云平台上，可伸缩性可以通过机器的水平或垂直缩放或者简单地附加 AutoScalingGroup 来实现。
流量模式:了解系统的交通模式。
尽可能多地产生机器是不划算的，即使它的利用率不高。
•日行模式: 特定地区的交通在早上增加，晚上减少。
•全局/区域模式: 区域大量使用应用程序。
•突发流量: 许多用户都在请求资源，但是只有少数几台机器可以为突发的流量提供服务。
这些可能发生在高峰期或人口密集地区。
自动缩放: 能够迅速产生一些机器，以处理流量的爆发，当需求正在减少时，优雅地收缩。
延迟: 能够尽快为请求提供服务。
这还包括优化算法和在用户位置附近复制系统，以减少请求的往返。
2 可用性它以正常运行时间的百分比来衡量，并定义了系统正常运行和正常工作的时间比例。
可用性受到系统错误、基础设施问题、恶意攻击和系统负载的影响。
部署标记: 部署应用程序组件的多个独立副本，包括数据存储区区域部署: 将后端服务部署到一组地理节点中，每个节点都可以服务任何区域中的任何客户端请求。
3 可扩展性可扩展性度量扩展了系统的能力和实现扩展所需的工作。
扩展可以通过添加新功能或修改现有功能来实现，该原则规定在不损害当前系统功能的情况下进行增强。
模块化/可重用性: 可重用性和可扩展性使得技术可以以更少的开发和维护时间转移到另一个项目，同时增强了可靠性和一致性。
可插拔性: 能够轻松地插入其他组件，比如微内核架构。
4 一致性一致性保证每个读操作返回最近的写操作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件工程之需求规格第二部软件需求工程：第十一章软件的质量属性目录11.1 非功能需求 (3)11.2 质量属性 (4)11.3 定义质量属性 (6)11.4 属性的取舍 (14)第11章软件的质量属性许多年前，我参加了一项工程，在该项目中用新的应用程序替换许多已有的主机（ m a i nf r a m e）应用程序。
根据用户的要求，开发组设计了一个基于窗口的用户界面并定义了新的数据文件，其容量是旧文件的两倍。
虽然新系统满足了技术上的规范，但并没有达到客户可接受的程度。
用户总是抱怨用户界面运行缓慢，并且新的数据文件所占用的磁盘空间太大。
用户没有陈述对新产品的一些特性的期望，这就不能在他们所提出的功能需求中体现出来。
糟糕的是，开发者和用户没有详细地讨论新技术方法所牵涉到可能的性能，从而导致了用户期望与产品实际性能之间的期望差异。
比起仅仅满足客户所要求的功能，软件的成功似乎更为重要。
11.1 非功能需求用户总是强调确定他们的功能、行为或需求—软件让他们做的事情。
除此之外，用户对产品如何良好地运转抱有许多期望。
这些特性包括：产品的易用程度如何，执行速度如何，可靠性如何，当发生异常情况时，系统如何处理。
这些被称为软件质量属性(或质量因素)的特性是系统非功能（也叫非行为）部分的需求。
质量属性是很难定义的，并且他们经常造成开发者设计的产品和客户满意的产品之间的差异。
就像Robert Charette(1990)指出的那样：“真正的现实系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能需求更为重要”。
优秀的软件产品反映了这些竞争性质量特性的优化平衡。
如果你在需求的获取阶段不去探索客户对质量的期望，那么产品满足了他们的要求，这只能说你很幸运。
但更多的可能是客户失望和开发者沮丧。
虽然，在需求获取阶段客户所提出的信息中包含提供了一些关于重要质量特性的线索，但客户通常不能主动提出他们的非功能期望。
用户说软件必须“健壮”，“可靠”或“高效”时，这是很技巧地指出他们所想要的东西。
从多方面考虑，质量必须由客户和那些构造测试和维护软件的人员来定义。
探索用户隐含期望的问题可以导致对质量目标的描述，并且制定可以帮助开发者创建完美产品的标准。
11.2 质量属性虽然有许多产品特性可以称为质量属性(Quality Attribute)，但是在许多系统中需要认真考虑的仅是其中的一小部分。
如果开发者知道哪些特性对项目的成功至关重要，那么他们就能选择软件工程方法来达到特定的质量目标（ Glass 1992; DeGrace and Stahl 1993）。
根据不同的设计可以把质量属性分类（Boehm 1976; DeGrace and Stahl 1993）。
一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开（Bass, Clements and Kazman 1998）。
另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。
那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。
在表11 - 1中，分两类来描述每个项目都要考虑的质量属性；还有其它许多属性（ C h a r e t t e1 9 9 0）。
一些属性对于嵌入式系统是很重要的（高效性和可靠性），而其它的属性则用于主机应用程序（有效性和可维护性）或桌面系统（互操作性和可用性）。
在一个理想的范围中，每一个系统总是最大限度地展示所有这些属性的可能价值。
系统将随时可用，决不会崩溃，可立即提供结果，并且易于使用。
因为理想环境是不可得到的，因此，你必须知道表11 - 1中那些属性的子集对项目的成功至关重要。
然后，根据这些基本属性来定义用户和开发者的目标，从而产品的设计者可以作出合适的选择。
表11-1 软件质量属性产品的不同部分与所期望的质量特性有着不同的组合。
高效性可能对某些部分是很重要的，而可用性对其它部分则很重要。
把应用于整个产品的质量特性与特定某些部分、某些用户类或特殊使用环境的质量属性要区分开。
把任何全局属性需求记录到在第9章所示的软件需求规格说明的第e . 4部分中，并把特定的目标和列在软件需求规格说明第d部分的特性、使用实例或功能需求相联系起来。
11.3 定义质量属性你必须根据用户对系统的期望来确定质量属性。
定量地确定重要属性提供了对用户期望的清晰理解，这将有助于设计者提出最合理的解决方案（ Gilb 1988）。
然而，大多数用户并不知道如何回答诸如“互操作性对你的重要性如何？”或者“软件应该具有怎样的可靠性？”等问题。
在一个项目中，分析员想出了对于不同的用户类可能很重要的属性，并根据每一个属性设计出许多问题。
他们利用这些问题询问每一个用户类的代表，可以把每个属性分成一级（不必多加考虑的属性）到五级（极其重要的属性）。
这些问题的回答有助于分析员决定哪些质量特性用作设计标准是最重要的。
然后，分析员与用户一起为每一属性确定特定的、可测量的和可验证的需求（ R o b e r t s o nand Robertson 1997）。
如果质量目标不可验证，那么就说不清你是否达到这些目标。
在合适的地方为每一个属性或目标指定级别或测量单位，以及最大和最小值。
如果你不能定量地确定某些对你的项目很重要的属性，那么至少应该确定其优先级。
I E E E关于软件质量度量方法的标准提出了一个在综合质量度量基准体系下定义软件质量需求的方法（ IEEE 1992）。
另一个定义属性的方法是确定任何与质量期望相冲突的系统行为（ Voas 1999）。
通过定义不悦人意行为—一种反向需求—你可以设计出强制系统表现出那些行为的测试用例。
如果你不能强制系统，那么你可能达到了你的属性目标。
这种方法最适用于要求安全性能很高的应用程序，在这些应用程序中，系统的差错可能会导致生命危险。
这一节的剩余部分将简要地介绍列在表11 - 1中的每一个质量属性，并提出一些有助于用户陈述他们对质量属性期望的问题。
虽然这些例子有些简单，但提供了由“化学制品跟踪系统”或其他项目总结出的样本目标的陈述。
你将需要选择最好的方法来表达每一个质量属性需求，这样可以指导开发者进行设计选择。
11.3.1 对用户重要的属性1) 有效性有效性指的是在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比。
更正式地说，有效性等于系统的平均故障时间（ M T T F）除以平均故障时间与故障修复时间之和。
有些任务比起其它任务具有更严格的时间要求，此时，当用户要执行一个任务但系统在那一时刻不可用时，用户会感到很沮丧。
询问用户需要多高的有效性，并且是否在任何时间，对满足业务或安全目标有效性都是必须的。
一个有效性需求可能这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到9 9 . 5 %，在下午4点到6点，系统的有效性至少可达到9 9 . 9 5 %。
2) 效率效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的（ Davis 1993）。
如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。
拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性造成威胁，就像一个实时处理系统超负荷一样。
为了在不可预料的条件下允许安全缓冲，你可以这样定义：“在预计的高峰负载条件下， 1 0 %处理器能力和1 5 %系统可用内存必须留出备用。
”在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。
3) 灵活性就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。
如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。
灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。
在我曾经参与的一个图形工程中，灵活性目标是如下设定的：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。
”4) 完整性完整性（或安全性）主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。
完整性对于通过W W W执行的软件已成为一个重要的议题。
电子商务系统的用户关心的是保护信用卡信息， We b的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。
完整性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。
用明确的术语陈述完整性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。
一个完整性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。
”5) 互操作性互操作性表明了产品与其它系统交换数据和服务的难易程度。
为了评估互操作性是否达到要求的程度，你必须知道用户使用其它哪一种应用程序与你的产品相连接，还要知道他们要交换什么数据。
“化学制品跟踪系统”的用户习惯于使用一些商业工具绘制化学制品的结构图，所以他们提出如下的互操作性需求：“化学制品跟踪系统应该能够从C h e m i D r a w和C h e m - S t r u c t工具中导入任何有效化学制品结构图。
”6) 可靠性可靠性是软件无故障执行一段时间的概率（Musa, Iannino and Okumoto 1987）。
健壮性和有效性有时可看成是可靠性的一部分。
衡量软件可靠性的方法包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。
根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理，来定量地确定可靠性需求。
如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。
要求高可靠性的系统也是为高可测试性系统设计的。
我的开发组曾经开发过一个用于控制实验室设备的软件，这些设备全天工作并且使用稀有的、昂贵的化学制品。
用户要求真正与实验相关的那部分软件要高可靠性，而其它系统功能，例如周期性地记录温度数据，则对可靠性要求不高。
对于该系统的一个可靠性需求说明如下：“由于软件失效引起实验失败的概率应不超过5‰”。
7) 健壮性健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。
健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。
当从用户那里获取健壮性的目标时，询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。
我曾经主持过一个叫作图形引擎的可重用软件组件的开发，该图形引擎具有描述图形规划的数据文件，并且把这一规划传送到指定的输出设备上（ Wiegers 1996b）。