软件体系结构的质量特性
软件体系结构5_软件体系结构的质量属性
软件体系结构5_软件体系结构的质量属性
1. 性能（Performance）：性能是衡量软件体系结构完成特定任务所需的时间和资源的能力。
在性能方面，主要关注的指标包括响应时间、吞吐量和资源利用率。
一个好的体系结构应能够支持大规模并发用户使用，而不会因为系统负载增加而导致性能下降。
2. 可用性（Availability）：可用性是指软件体系结构在特定时间内处于可操作状态的能力。
可用性主要与系统的可靠性、容错性和可恢复性相关。
一个可靠的软件体系结构应能够及时响应用户需求，并尽量减少停机时间和故障恢复时间，提供稳定、可靠的服务。
3. 可靠性（Reliability）：可靠性是指软件体系结构在给定的时间内正确执行其功能的能力。
可靠性与系统的错误率和故障率相关。
一个可靠的软件体系结构应能够预防和容忍异常情况，以确保正确的运行，保证数据的完整性和准确性。
4. 安全性（Security）：安全性是指软件体系结构在防止未经授权的访问和保护用户数据等方面的能力。
软件体系结构应能够识别和阻止潜在的安全威胁，如恶意攻击、非法访问和数据泄露等。
安全性要求通常包括认证、授权、加密和审计等功能。
5. 可扩展性（Scalability）：可扩展性是指软件体系结构能够在不同规模和负载下进行水平或垂直扩展的能力。
一个可扩展的软件体系结构应能够动态调整资源，并能够在需要时自动增加或减少处理能力，以适应不断变化的用户需求。
总之，软件体系结构的质量属性是衡量软件体系结构能力和性能的关键指标。
在设计软件体系结构时，需要充分考虑这些质量属性，以确保软件能够满足用户的需求，并具有高性能、可靠性、安全性和可扩展性。
软件体系结构5 第5章 软件质量属性
外部质量
易用性
易用性是指用户使用软件的容易程度。 现代人的生活节奏快，做什么事都想图个方便。所以把易用性作为 重要的质量属性对待无可非议。导致软件易用性差的根本原因 ： 理工科大学教育存在缺陷：没有开设人机工程学、美学、心理学这 些必修课，大部分开发人员不知道如何设计易用的软件产品。开发 人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就 会满意。软件的易用性要让用户来评价。当用户真的感到软件很好 用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便 易用”等词来评价软件产品。
外部质量
兼容性
兼容性是指不同产品（或者新老产品）相互交换信息的能力。例如 两个字处理软件的文件格式兼容，那么它们都可以操作对方的文件， 这种能力对用户很有好处。兼容性又称为互操作性。 兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者 应当避免被兼容，否则市场将被瓜分。金山软件公司的WPS与微 软的Word之争。WPS一定要与Word兼容，否则活不下去。但是 Word绝对不会与WPS兼容，除非WPS又在中国占有绝对优势。 中国联通和中国移动的手机互联互通问题。（互联网的价值与用户 数量的平方成正比）
质量目标与商业目标
质量定义
古时候人们ห้องสมุดไป่ตู้为长得结实、饭量大就是健康，这显然是不科 学的。现代人总是通过考察多方面的生理因素来判断是否健 康，如测量身高、体重、心跳、血压、血液、体温等。如果 上述因素都合格，那么表明这人是健康的。如果某个因素不 合格，则表明此人在某个方面不健康，医生会对症下药。 软件质量是许多质量属性的综合体现，各种质量属性反映了 软件质量的方方面面。人们通过改善软件的各种质量属性， 从而提高软件的整体质量。
响应度量(Response Measure)：以某种方式对其进行度量，对 需求进行测试。
软件体系结构知识点复习
一、什么是软件系统结构软件体系结构也称为软件构架（有时简称构架），是系统的一个或多个结构，它包括：软件的组成元素（组件），这些元素（组件）的外部可见特性，以及这些元素（组件）之间的相互关系。
含义：(1)系统由一个或多个结构组成，其中任何一个结构并不能与构架等同。
(2)每个系统都有一个体系结构。
(3)软件体系结构是系统的抽象。
(4) 构架定义了软件元素以及各元素间的交互关系。
(5) 以往作为体系结构传递的线框图，事实上并等同于体系结构。
二、构架商业周期(ABC)1.构架由什么决定？构架是否由系统需求决定？×软件构架是技术、商业和社会因素共同作用的结果。
2. 构架从哪里来？(影响构架的因素)影响构架的因素主要包括：❑系统涉众（stakeholder）、主要有：管理者：成本要低，人人都得干活营销人员：特性突出、投放市场快、成本低、可与同类产品相匹敌｡终端用户：行为、性能、安全性、可靠性、易用性｡维护人员：可修改性强｡客户：成本低、及时交付、不要频繁修改｡❑开发组织・组织内对现存构架的重用・对某个基础设施进行长期的商业投资以实现某些战略目标・开发组织本身的机构也会影响构架的形成❑构架师的素质和经验构架师先前的一些经验、教育、培训以及所接触到过的成功构架模式都会影响到他们对某种构架的选择。
❑技术环境当前技术发展水平代表了某个时代的构架师的普遍素质和经验，对架构有很大的影响力。
❑其它因素其它如社会、法律、人文环境等都会对构架产生影响。
3.构架的反影响力・构架会影响开发组织的结构・构架会影响开发组织的目标・构架会影响客户对下一个系统的要求・构建系统的过程丰富了整个开发团队的经验，从而将影响设计师对后继系统的设计・一些系统会影响并实际改变软件工程的环境，也就是系统开发人员学习或实践的技术环境。
4.构架的商业周期软件构架是技术、商业和社会等诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响未来的软件构架。
软件质量的6个特征
软件质量的6个特征1.功能特征
与⼀组功能及其指定性质有关的⼀组属性，这⾥的功能是满⾜明确或隐含的需求的那些功能。
2.可靠特征
在规定的⼀段时间和条件下，与软件维持其性能⽔平的能⼒有关的⼀组属性。
3.易⽤特征
由⼀组规定或潜在的⽤户为使⽤软件所需作的努⼒和所作的评价有关的⼀组属性。
4.效率特征
与在规定条件下软件的性能⽔平与所使⽤资源量之间关系有关的⼀组属性
5.可维护特征
与进⾏指定的修改所需的努⼒有关的⼀组属性。
6.可移植特征
与软件从⼀个环境转移到另⼀个环境的能⼒有关的⼀组属性。
软件质量特性
ISO/IEC9126的软件质量模型包括6个质量特性和21个质量子特性。
（1）功能性(Functionality)功能性是指与软件所具有的各项功能及其规定性质有关的一组属性，包括：■适合性（Suitability）：与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。
适合程度的例子是面向任务系统中由子功能构成功能是否合适、表容量是否合适等。
■准确性（Accuracy）：与能否得到正确或相符的结果或效果有关的软件属性。
此属性包括计算值所需的准确程度。
■互操作性（互用性，Interoperability）：与同其他指定系统进行交互的能力有关的软件属性。
为避免可能与易替换性的含义相混淆，此处用互操作性（互用性）而不用兼容性。
■依从性（Compliance）：使软件遵循有关的标准、约定、法规及类似规定的软件属性。
■安全性（Security）：与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。
（2）可靠性(Reliability)可靠性是指在规定运行条件下和规定时间周期内，与软件维护其性能级别的能力有关的一组属性。
可靠性反映的是软件中存在的需求错误、设计错误和实现错误，而造成的失效情况。
包括：■成熟性（Maturity）：与由软件故障引起失效的频度有关的软件属性。
■容错性（Fault tolerance）：与在软件故障或违反指定接口的情况下，维持规定的性能水平的能力有关的软件属性。
指定的性能水平包括失效防护能力。
■可恢复性（Recoverability）：与在失效发生后，重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和努力有关的软件属性。
（3）可用性(Usability)可用性是指根据规定用户或隐含用户的评估所作出的关于与使用软件所需要的努力程度有关的一组属性。
包括：■可理解性（Understandability）：与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。
软件体系架构的质量属性
软件体系架构的质量属性摘要：软件架构（及软件架构设计师）重点关注的是质量属性。
本⽂从常见的六个质量属性，即可⽤性、可修改性、性能、安全性、可测试性、易⽤性写起，使读者对其有初步的认识和了解。
解决了在具体的软件开发环境中的质量属性是什么，怎么⽤，如何⽤好的问题。
只⽤遵循质量属性的原则，才能有好的设计思想，才能开发出好的软件产品。
关键字：质量属性、软件体系架构、架构设计软件属性包括功能属性和质量属性，但是软件架构重点关注的是质量属性。
架构的基本需求主要是在满⾜功能属性的前提下，关注软件质量属性。
软件的质量属性可列举很多，也有各种不同的分类法和不同的表述。
⼀般将质量属性分为3类：系统的质量属性。
可⽤性，可修改性，性能，安全性，可测试性和易⽤性。
受架构影响的商业属性（上市时间）。
与架构本⾝相关的⼀些质量属性（如概念完整性），它们会间接影响其他质量属性，如可修改性。
1. 可⽤性（Availability）可⽤性与系统故障及其相关后果有关。
当系统不再提供其规范中所说明的服务时，就出现了系统故障。
所关注的⽅⾯有：（1）如何检测系统故障（2）系统故障发⽣的频度（3）出现故障时会发⽣什么情况（4）允许系统有多长时间⾮正常运⾏（5）什么时候可以安全地出现故障（6）如何防⽌故障的发⽣以及故障时要求进⾏哪种通知在计算可⽤性时，通常不考虑预定的停机时间（即停⽌服务），因为根据定义是”不需要“系统的。
这就导致会出现这种情况：系统停⽌运⾏，⽤户等待系统提供服务，但因为停机时间是预定的，因此不计⼊故障时间，也就不会影响可⽤性的数值。
可⽤性定义：可⽤性是指系统正常运⾏时间的⽐例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运⾏的速度来衡量的。
可⽤性⼀般场景：所关注的⽅⾯包括系统故障发⽣的频率、出现故障时会发⽣什么情况、允许系统有多长是将⾮正常运⾏、什么时候可以安全地出现故障、如何防⽌故障的发⽣以及发⽣故障时要求进⾏哪种通知。
软件工程6 软件体系结构
软件工程6 软件体系结构在当今数字化的时代，软件已经成为我们生活和工作中不可或缺的一部分。
从智能手机上的各种应用程序，到企业内部复杂的业务系统，软件的质量和性能直接影响着用户的体验和业务的效率。
而软件体系结构作为软件工程中的一个重要领域，对于软件的成功开发和维护起着至关重要的作用。
那么，什么是软件体系结构呢？简单来说，软件体系结构就是软件系统的高层结构和组织方式。
它描述了软件系统中的组件、组件之间的关系以及它们如何协同工作来实现系统的功能。
就好比盖房子，软件体系结构就是房子的设计蓝图，决定了房子的布局、结构和各个部分的连接方式。
一个好的软件体系结构具有许多重要的特性。
首先，它应该具有可扩展性。
随着业务的发展和用户需求的变化，软件系统需要能够方便地进行功能的增加和修改。
如果体系结构设计得不合理，可能会导致在添加新功能时牵一发而动全身，需要对整个系统进行大规模的重构，这不仅费时费力，还可能引入新的错误。
其次，软件体系结构应该具有高可靠性和容错性。
软件系统在运行过程中难免会遇到各种故障和错误，一个良好的体系结构能够确保系统在出现部分故障时仍能继续运行，或者能够快速地从错误中恢复，从而保证系统的稳定性和可用性。
再者，性能也是软件体系结构需要考虑的重要因素。
这包括系统的响应时间、吞吐量、资源利用率等方面。
通过合理的体系结构设计，可以优化系统的性能，提高系统的运行效率，满足用户对于系统速度和效率的要求。
软件体系结构的设计过程并不是一蹴而就的，它需要综合考虑多种因素。
首先，要对系统的需求进行深入的分析和理解。
这包括了解系统的功能需求、性能需求、安全需求等。
只有清楚地知道系统需要做什么，才能设计出合适的体系结构。
在需求分析的基础上，选择合适的体系结构风格也是非常关键的一步。
常见的体系结构风格有分层架构、客户端服务器架构、微服务架构等。
每种风格都有其特点和适用场景，例如分层架构将系统分为不同的层次，每层完成特定的功能，具有结构清晰、易于维护的优点；客户端服务器架构则适用于分布式环境下的系统，能够有效地实现资源共享和负载均衡；微服务架构则将系统拆分成多个独立的服务，每个服务可以独立开发、部署和扩展，提高了系统的灵活性和可扩展性。
软件质量体系标准
软件质量体系标准
软件质量体系标准主要包括以下几个方面：
1. 功能性：软件应该提供满足用户需求的功能，并且正确、准确地完成各项任务。
2. 可靠性：软件在各种情况下都能稳定运行，不会出现突然崩溃或数据丢失等问题。
3. 易用性：软件的用户界面友好，操作简单易懂，符合用户习惯。
4. 效率性：软件能够快速响应用户操作，处理速度满足用户需求。
5. 维护性：软件的代码结构清晰，易于修改和维护。
6. 兼容性：软件可以与各种不同型号、不同配置的硬件和软件进行兼容。
7. 可扩展性：软件可以适应业务发展和用户需求的变化，方便地进行升级和扩展。
8. 安全性：软件采取必要的安全措施，保护用户数据和隐私。
以上标准可以通过制定相应的质量保证计划、进行代码审查、测试验收、上线部署等环节来保证实现。
同时，持续改进也是软件质量体系标准的重要一环，通过不断优化和改进，可以提高软件的质量水平，提升用户体验。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件体系结构的质量特性摘要：众所周知的是，为了降低风险和减少构建软件系统的困难，人们在软件开发过程的早期应该首先考虑质量问题。
此外，系统的结构驱动着整个开发过程。
备用的结构中非功能性质量需求的实现决定了选择衔接整个系统的便利结构。
这一议题在可靠的变革的应用程序构建中非常重要。
软件开发的思想并没有在这一重要阶段给与很多细节关注。
这篇文章详述了软件体系结构的质量特性，并且介绍了一种基于✋ 标准的技术。
✋模型的质量特性被精炼成为一种属性。
而这种属性可被度量以增加体系结构的信息。
我们的技术通过比较各自的质量属性的值从一组候选中挑选出适当的体系结构。
并以一个关于监制系统技术应用程序为例说明。
我们的方法有助于在体系结构分析过程中正确选择的决定。
它可以很容易的被并入一般软件开发的过程或者一种特别的体系结构设计思想。
简介：在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。
但是，系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。
另一方面，质量需求在软件设计阶段需要平衡☯♋❍♋⏹ ♏♦ ♋● 。
仅仅在最近，精确的软件体系结构设计的重要性（并不是局限于笔纸图画符号的设计方式）为了可靠的系统结构而蓬勃的发展起来☯♋♍♒❍♋⏹⏹ ♏♦ ♋● ☯☐♦♍♒ ☯ ❒◆♦♍♒♏⏹ 。
那些包括♓♦♦❒♓♌◆♦♓☐⏹ ♋♎♋☐♦♋♌♓●♓♦⍓ ♓⏹♦♏❒☐☐♏❒♋♌♓●♓♦⍓ ♍☐❍☐☐⏹♏⏹♦ ❒♏◆♦♋♌♓●♓♦⍓ ♋⏹♎ ❒♏♋●♦♓❍♏ ♓♦♦◆♏♦ 现代的应用软件需要一个早期的体系结构的 定义来满足可维护行和可靠性之类的质量需求。
这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。
特殊的，使用网络服务的新的信息系统，比如基于网络的电子商务应用程序，没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。
此外，此种产品的质量不在讨论范围之内。
然而，当一个☟❆☹页面在浏览器端显示出来的时候，我们马上就能意识到我们是否使用了一个好的或者坏的网络应用程序。
像可用性，可靠性或有效性等的因素涉及到这个快速的评估。
事实上，自从系统开发之初，软件开发者们对网络应用程序的质量特性就没有一个清晰的描述，正如我们所指出的，软件工程的范例通常被忽略。
比如，即使当应用程序数据的语义与描述分离是一个可接受的范例，☟❆☹ ♓♦ ⏹☐❒❍♋●●⍓ ◆♦♏♎ ❒♏♑♋❒♎●♏♦♦ ☐♐ ♦♒♓♦ ♓♦♦◆♏，直到最近，✠☹才被接受。
于是，质量需求的详述就成为了一个有趣的问题。
在功能需求的详述过程中，质量需求可能会隐藏的出现，比如在一个纯文本用例或一个方案中。
但是在标准的面向对象思想中没有直接的指导方法和清晰的建模原理来捕获或详细描述质量需求。
并且我们直到软件体系结构的设计不是一个独立的行为，而是软件产品开发和改良过程中的更进一步的阶段。
软件体系结构应该作为一个主要的侧重点以建立更清晰可重用的软件框架♐☐❒ ♑◆♋❒♋⏹♦♏♏♓⏹♑ ♦☐ ♋ ♍♏❒♦♋♓⏹ ♏⌧♦♏⏹♦ ♦♒♏ ☐❖♏❒♋●● ❑◆♋●♓♦⍓ ☐♐ ♦♒♏ ❒♏♦◆●♦♓⏹♑ ♦☐♐♦♦♋❒♏ ☐❒☐♎◆♍♦♦ 本篇文章的主要目的是介绍（建议）一种基于✋ ☯✋✋☜ 标准的技术来描述相应的软件质量特性，而这种技术为品质等级或其他可测量的要素所精确描述，并参与软件体系结构的设计过程之中。
作为体系结构设计阶段中，质量特性的详细说明和规范度量是软件体系结构改进过程的基础，而这些改进过程允许对最初设计进行改进和增加。
这种基于系统的某些关键功能需求而选择的备案在设计过程中不断被转变和改进以达到预期的质量目标，而这些质量目标正是系统应当达到的质量需求的价值所在。
在这一过程中为了最终的系统，质量需求经常被转化为隐性的功能需求☯ ☐♦♍♒ ，比如最终的系统把这些需求表达为附加的机制。
但是，在一般习惯性的软件分析和设计思想中，这些质量特性的详述和评估的表述仅仅基于设计者的经验。
✌❆❆（基于构架的权衡分析方法）☯ ♋ ❍♋⏹ ♏♦ ♋● 与我们的方法有一些共同之处。
它使用了一种称之为◆♦♓●♓♦⍓ ☎♦⍓♦♦♏❍ ♑☐☐♎⏹♏♦♦✆ ♦❒♏♏的质量特性详述标准来将基于精确质量特性的方案分清主次。
体系结构和属性的信息被收集到✌✌（✌♦♦❒♓♌◆♦♏ ♋♦♏♎ ✌❒♍♒♓♦♏♍♦◆❒♋● ♦⍓●♏）框架中☯ ●♏♓⏹ ♋⏹♎ ♋ ❍♋⏹ 。
但是如何获得质量视图是如此描述和为何仅有一个描述等级的◆♦♓●♓♦⍓ ♦❒♏♏并不清楚，并且质量特性的解释并不标准。
◆♦♓●♓♦⍓ ♦❒♏♏通过一组可被驱动的体系结构测试方案来给与方案优先权来确定关键之处。
特性的测量通过♦♦♓❍◆●♓，参数和响应来显示。
我们的方法使用根据✋ 标准的质量模型来考虑质量需求的详述。
这个在结构上接近✌❆✌质量树的等级模型对于软件体系结构很合适。
✋质量模型现在是软件工业的标准并且它通过高度抽象的层次来解释。
它由内部和外部因素和使用品质特性视图的质量决定的。
这种质量特性（✌❆✌的特性）恰好被很标准的解释，并且特性的度量通常很普遍，它可以为详细的应用做更进一步的解释。
软件运行环境的质量是由用例模型的质量决定的，也就是在上下文的使用中，用户对于质量的观点。
此篇文章中我们只关心有关内外因素质量模型，而这个质量模型分别描述了用户和开发者的观点。
为了完备使用的质量，这个系统必须达到内部和外部的目标。
在软件开发过程中出现如下情况：当软件作为电脑系统中的一部分和内部软件评估或是实体属性测量的结果时，质量特性常常被详细描述为显现的外在子特性。
在我们的例子中，不得不把这些属性转化或翻译成称之为媒介软件产品的软件体系结构。
在软件开发过程中获得的特性的值可被用来校验内部的质量目标，而这些内部的质量目标有助于确认最终软件系统要求的外部目标☯ ✋☜ 。
拥有质量特性详细描述这样的事实为体系结构详细说明增加了更多的信息，这样有助于为解决特定设计问题而挑选体系结构的设计过程。
除了介绍和结论，；论文的主要部分如下：——为详述软件体系结构的质量特性，给出了一个基于✋ 标准的通用质量模型的描述。
——一个实例的研究，在这个实例中，我们将获得的通用质量模型来进行使用网络设备的实时监视系统软件体系结构的选择。
、为软件体系结构而修改的✋ 质量模型。
✋ 质量模型：根据✋ 标准☯✋✋☜ ，质量被描述为一组产品或服务的特色或特性，而这些特色和特性是基于自己的能力来满足显性或隐性的需求。
同时，对于质量定义的不同看法也应被尊重：从用户角度来看，它是最终产品的质量；从开发者的角度来看，它是在开发过程中由不同的项目相关人员生产的中间产品的质量。
从终端管理者角度来看，它是营销的需求。
所有产品的质量都可以被不同观点的集合所表达。
在我们的文章中，用户和开发者（架构师）的观点角度将会被采纳。
✌☹☹的工作区分了两类质量特性：因素和标准。
前者不能直接被测量而后者可以被主观的测量。
这启发了✋ 模型。
基于这个标准，✋ 更进一步的将 ♍♋●●的模型化简为✋ 质量模型，现在它在广泛的艺术级的产品质量说明书中被接受。
它提议了一组六个相互独立的高阶的质量特性。
而这些质量特性被定义为其质量已被描述和评估的软件产品的质量特性。
在开发的各种阶段，质量特性被作为外部质量确认和内部质量审查的目标。
当获得特性和可测量的实体时，他们被描述成子特性。
在文中度量和测量标准被定义为一个测量方法或测量手段来获取一个值。
这种关系如图 所示：在开发过程中，为了监视和控制软件质量外部的质量需求会转变或转化成在开发活动中获得的中间产品的质量需求。
表 ：✋质量模型的特性。
子特性如图 所示：注意：符合性意味着与标准，协议或者规则的联系。
它被解释为所有特性的子特性之一☯✋ ✋☜ 。
这里我们仅把它认为是功能性来精简它的描述。
注意：符合性子特性的出现意味着特性中其余的部分已经被偶些选定的标准完全测量了。
软件体系结构标准质量模型的制定：为了定制✋质量模型，我们必须了解这些成分。
他们是体系结构或者软件系统所基于的一般框架所期盼的成分。
我们把它当作是软件开发过程的中间产品。
因此，一个特别的在深层次上被构建所解释的体系结构，必须满足✋的全部或部分特性，而连接器连接着这些构件，结构和拓扑。
每个与属性相关联的特性都应被测量。
这些属性应当完全与体系结构或者构件和连接器有关。
质量特性的测量应被量化。
起先，它们被定义为特定符号的公式，接下来就使用标准的语言来定义☯ ♋❒♍♋⏹☐ ♏♦ ♋● 。
在这个逐步的体系结构定义过程中，我们也许能够估计体系结构的精华是否提高了质量特性，但此问题在本文中不予讨论。
对于最终产品的每项属性来说，都有需要达到或是超越的质量目标值。
当这些质量目标值被达到或是超越后，我们便说这个体系结构符合质量特性的需求。
这些目标值是在质量需求中所确定的。
接下来我们通过对每个属性给与相应的标准来解释质量需求如何被精确到相应的子特性及属性上，以及它们如何与体系结构相适应。
注意，这里的特性及子特性被认为是相互独立的。
、功能性特性：（ ）、子特性——适应性： 拥有符合特定任务需求的足够的功能。
它包括两个方面：存在：任务已被详细说明，比如以用例的方式。
每一个任务必须存在一个特定的功能去完成它。
正确：正确的解释任务的详细说明。
比如必须满足图 的次序图。
从软件体系结构的层次上说明：♋系统的功能性必须被确定。
在此种情况下，子特性被解释成拥有是【 】或者否【 】这样值的属性。
注意，存在着值介于离散数字【⏹⑤❍】之间的属性，比如【 ⑤】代表着不存在或存在。
这种标准是一种获取级别水平的度量。
♌由功能需求所获得的次序图必须被详细精化。
在拥有一个体系结构说明书的情况下，特定的功能被分解成与构件有关的子功能，并且这些子功能都应符合系统的功能性需求。
图 ：系统需求向软件体系结构的转化（ ）、子特性——正确性：以需要的精确程度来制定正确或一致的结果。
它可以被基于源码的属性所度量。
它以构建为代表，而这些构建定义了度量值的功能。
从软件体系结构的层次上说明：、经过可靠估计的功能组件的认定。
（功能性的组件）、由以下的规则对属性进行估算。
（ ）、子特性——互用性：在一个系统内或多个系统间相互作用的能力。
注意：为了避免模糊化，它与可替代性一起用来取代兼容性。