软件体系结构的质量特性
软件体系结构5_软件体系结构的质量属性
软件体系结构5_软件体系结构的质量属性
1. 性能（Performance）：性能是衡量软件体系结构完成特定任务所需的时间和资源的能力。
在性能方面，主要关注的指标包括响应时间、吞吐量和资源利用率。
一个好的体系结构应能够支持大规模并发用户使用，而不会因为系统负载增加而导致性能下降。
2. 可用性（Availability）：可用性是指软件体系结构在特定时间内处于可操作状态的能力。
可用性主要与系统的可靠性、容错性和可恢复性相关。
一个可靠的软件体系结构应能够及时响应用户需求，并尽量减少停机时间和故障恢复时间，提供稳定、可靠的服务。
3. 可靠性（Reliability）：可靠性是指软件体系结构在给定的时间内正确执行其功能的能力。
可靠性与系统的错误率和故障率相关。
一个可靠的软件体系结构应能够预防和容忍异常情况，以确保正确的运行，保证数据的完整性和准确性。
4. 安全性（Security）：安全性是指软件体系结构在防止未经授权的访问和保护用户数据等方面的能力。
软件体系结构应能够识别和阻止潜在的安全威胁，如恶意攻击、非法访问和数据泄露等。
安全性要求通常包括认证、授权、加密和审计等功能。
5. 可扩展性（Scalability）：可扩展性是指软件体系结构能够在不同规模和负载下进行水平或垂直扩展的能力。
一个可扩展的软件体系结构应能够动态调整资源，并能够在需要时自动增加或减少处理能力，以适应不断变化的用户需求。
总之，软件体系结构的质量属性是衡量软件体系结构能力和性能的关键指标。
在设计软件体系结构时，需要充分考虑这些质量属性，以确保软件能够满足用户的需求，并具有高性能、可靠性、安全性和可扩展性。
软件体系结构5 第5章 软件质量属性
外部质量
易用性
易用性是指用户使用软件的容易程度。 现代人的生活节奏快，做什么事都想图个方便。所以把易用性作为 重要的质量属性对待无可非议。导致软件易用性差的根本原因 ： 理工科大学教育存在缺陷：没有开设人机工程学、美学、心理学这 些必修课，大部分开发人员不知道如何设计易用的软件产品。开发 人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也就 会满意。软件的易用性要让用户来评价。当用户真的感到软件很好 用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便 易用”等词来评价软件产品。
外部质量
兼容性
兼容性是指不同产品（或者新老产品）相互交换信息的能力。例如 两个字处理软件的文件格式兼容，那么它们都可以操作对方的文件， 这种能力对用户很有好处。兼容性又称为互操作性。 兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者 应当避免被兼容，否则市场将被瓜分。金山软件公司的WPS与微 软的Word之争。WPS一定要与Word兼容，否则活不下去。但是 Word绝对不会与WPS兼容，除非WPS又在中国占有绝对优势。 中国联通和中国移动的手机互联互通问题。（互联网的价值与用户 数量的平方成正比）
质量目标与商业目标
质量定义
古时候人们ห้องสมุดไป่ตู้为长得结实、饭量大就是健康，这显然是不科 学的。现代人总是通过考察多方面的生理因素来判断是否健 康，如测量身高、体重、心跳、血压、血液、体温等。如果 上述因素都合格，那么表明这人是健康的。如果某个因素不 合格，则表明此人在某个方面不健康，医生会对症下药。 软件质量是许多质量属性的综合体现，各种质量属性反映了 软件质量的方方面面。人们通过改善软件的各种质量属性， 从而提高软件的整体质量。
响应度量(Response Measure)：以某种方式对其进行度量，对 需求进行测试。
软件体系结构的质量特征ISO9126
摘要在软件开发过程中，软件的质量是一个重要的因素，而软件体系结构在整个过程中显得尤为重要。
软件的质量需求是在开发初期的非功能性需求，对软件的体系结构影响很大。
但是并不意味着一味的追求质量，必须在效率和质量之间寻求一个平衡点。
为了实现高的软件质量，软件体系结构必须具有良好地可移植性，可靠性，可维护性，适应性，互用性，组件复用和实时性等方面的要求。
ISO/IEC 9126-1 :软件产品评估—质量特性及其使用指南纲要。
在此标准中，定义了六种质量特性，并且描述了软件产品评估过程的模型。
该技术将质量这一大的特性细化到属性级别或可测项。
这样，就可以通过比较这些属性、可测项从一系列候选体系结构中选择出一个合适的来开发软件。
在此标准中，定义了六种质量特性，27个子特性,并且描述了软件产品评估过程的模型。
1.功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力，即适合性；并且能够得到正确或相符的结果或效果，即准确性；拥有能够和其他指定系统进行交互的能力，即互用性；防止对程序或数据的未经授权访问的能力，即安全性。
2.可靠性：在指定条件下使用时，软件产品维持规定的性能水平的能力。
其中包括成熟性，指软件产品避免因软件中错误发生而导致失效的能力；容错性：是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能水平的能力；易恢复性：是指在失效发生的情况下，软件产品重建规定的性能水平并恢复受直接影响的数据的能力。
3.易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
4.效率：是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。
其中，时间特性：是指在规定条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的能力；除此之外，资源利用性：是指在规定条件下，软件产品执行其功能时，所使用的资源数量及其使用时间。
5.可维护性：是指软件产品可被修改的能力，修改可能包括修正，改进或软件适应环境、需求和功能规格说明中的变化。
软件质量特性
软件质量特性：功能性、可靠性、可用性、效率、可维护性、可移植性（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）如何防⽌故障的发⽣以及故障时要求进⾏哪种通知在计算可⽤性时，通常不考虑预定的停机时间（即停⽌服务），因为根据定义是”不需要“系统的。
这就导致会出现这种情况：系统停⽌运⾏，⽤户等待系统提供服务，但因为停机时间是预定的，因此不计⼊故障时间，也就不会影响可⽤性的数值。
可⽤性定义：可⽤性是指系统正常运⾏时间的⽐例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运⾏的速度来衡量的。
可⽤性⼀般场景：所关注的⽅⾯包括系统故障发⽣的频率、出现故障时会发⽣什么情况、允许系统有多长是将⾮正常运⾏、什么时候可以安全地出现故障、如何防⽌故障的发⽣以及发⽣故障时要求进⾏哪种通知。
软件体系结构的质量特性
软件体系结构的质量特性摘要：众所周知的是，为了降低风险和减少构建软件系统的困难，人们在软件开发过程的早期应该首先考虑质量问题。
此外，系统的结构驱动着整个开发过程。
备用的结构中非功能性质量需求的实现决定了选择衔接整个系统的便利结构。
这一议题在可靠的变革的应用程序构建中非常重要。
软件开发的思想并没有在这一重要阶段给与很多细节关注。
这篇文章详述了软件体系结构的质量特性，并且介绍了一种基于ISO 9126-1标准的技术。
ISO模型的质量特性被精炼成为一种属性。
而这种属性可被度量以增加体系结构的信息。
我们的技术通过比较各自的质量属性的值从一组候选中挑选出适当的体系结构。
并以一个关于监制系统技术应用程序为例说明。
我们的方法有助于在体系结构分析过程中正确选择的决定。
它可以很容易的被并入一般软件开发的过程或者一种特别的体系结构设计思想。
简介：在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。
但是，系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。
另一方面，质量需求在软件设计阶段需要平衡[Kazman et al. 2000]。
仅仅在最近，精确的软件体系结构设计的重要性（并不是局限于笔纸图画符号的设计方式）为了可靠的系统结构而蓬勃的发展起来[Bachmann et al.1996], [Bosch 2000], [Krutchen 2000].。
那些包括istribution, adaptability, interoperability, component reusability and real-time issues 现代的应用软件需要一个早期的体系结构的定义来满足可维护行和可靠性之类的质量需求。
这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。
特殊的，使用网络服务的新的信息系统，比如基于网络的电子商务应用程序，没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。
软件体系结构之质量属性
Creating the architecture
• Architects primarily work by using previouslytried solutions – Large scale: Patterns and styles – Small scale: Tactics • Styles, patterns, and tactics represent conceptual tools in the architect‘s ―tool bag.‖ • Professional architects always keep their tool bag up to date.
Patterns and styles
• Independent component patterns – Communication-processes – Event systems • Implicit invocation •Virtual machine patterns • Explicit invocation •Interpreters • Data flow patterns •Rule-based systems – Batch sequential •Call-return patterns – Pipe-and-filter •Main program and – Layers subroutine • Data-centered patterns •Object oriented – Blackboard – repository
• A tactic is a design decision that influences the control of a quality attribute response. We call a collection of tactics an architectural strategy.
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
盛年不重来，一日难再晨。
及时宜自勉，岁月不待人。
软件体系结构的质量特性摘要：众所周知的是，为了降低风险和减少构建软件系统的困难，人们在软件开发过程的早期应该首先考虑质量问题。
此外，系统的结构驱动着整个开发过程。
备用的结构中非功能性质量需求的实现决定了选择衔接整个系统的便利结构。
这一议题在可靠的变革的应用程序构建中非常重要。
软件开发的思想并没有在这一重要阶段给与很多细节关注。
这篇文章详述了软件体系结构的质量特性，并且介绍了一种基于ISO 9126-1标准的技术。
ISO模型的质量特性被精炼成为一种属性。
而这种属性可被度量以增加体系结构的信息。
我们的技术通过比较各自的质量属性的值从一组候选中挑选出适当的体系结构。
并以一个关于监制系统技术应用程序为例说明。
我们的方法有助于在体系结构分析过程中正确选择的决定。
它可以很容易的被并入一般软件开发的过程或者一种特别的体系结构设计思想。
简介：在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。
但是，系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。
另一方面，质量需求在软件设计阶段需要平衡[Kazman et al. 2000]。
仅仅在最近，精确的软件体系结构设计的重要性（并不是局限于笔纸图画符号的设计方式）为了可靠的系统结构而蓬勃的发展起来[Bachmann et al.1996], [Bosch 2000], [Krutchen 2000].。
那些包括istribution, adaptability, interoperability, component reusability and real-time issues 现代的应用软件需要一个早期的体系结构的定义来满足可维护行和可靠性之类的质量需求。
这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。
特殊的，使用网络服务的新的信息系统，比如基于网络的电子商务应用程序，没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。
此外，此种产品的质量不在讨论范围之内。
然而，当一个HTML页面在浏览器端显示出来的时候，我们马上就能意识到我们是否使用了一个好的或者坏的网络应用程序。
像可用性，可靠性或有效性等的因素涉及到这个快速的评估。
事实上，自从系统开发之初，软件开发者们对网络应用程序的质量特性就没有一个清晰的描述，正如我们所指出的，软件工程的范例通常被忽略。
比如，即使当应用程序数据的语义与描述分离是一个可接受的范例，H TML i sn o r m a ll y u se d r e g a r d l e ss o f t h i s i ssue，直到最近，XML才被接受。
于是，质量需求的详述就成为了一个有趣的问题。
在功能需求的详述过程中，质量需求可能会隐藏的出现，比如在一个纯文本用例或一个方案中。
但是在标准的面向对象思想中没有直接的指导方法和清晰的建模原理来捕获或详细描述质量需求。
并且我们直到软件体系结构的设计不是一个独立的行为，而是软件产品开发和改良过程中的更进一步的阶段。
软件体系结构应该作为一个主要的侧重点以建立更清晰可重用的软件框架f o r gu a r a n t ee i ng t o a c e r t a i n e x t e n t,t h e o v e r a ll qu a li t y o f t h e r e su l t i ng so f t w a r e p r o du ct s.本篇文章的主要目的是介绍（建议）一种基于ISO 9126-1 [ISO/IEC 1998]标准的技术来描述相应的软件质量特性，而这种技术为品质等级或其他可测量的要素所精确描述，并参与软件体系结构的设计过程之中。
作为体系结构设计阶段中，质量特性的详细说明和规范度量是软件体系结构改进过程的基础，而这些改进过程允许对最初设计进行改进和增加。
这种基于系统的某些关键功能需求而选择的备案在设计过程中不断被转变和改进以达到预期的质量目标，而这些质量目标正是系统应当达到的质量需求的价值所在。
在这一过程中为了最终的系统，质量需求经常被转化为隐性的功能需求[B o sch2000]，比如最终的系统把这些需求表达为附加的机制。
但是，在一般习惯性的软件分析和设计思想中，这些质量特性的详述和评估的表述仅仅基于设计者的经验。
ATMT（基于构架的权衡分析方法）[K a z m a n e t a l.2000]与我们的方法有一些共同之处。
它使用了一种称之为u t ili t y(sy s t e m g oo dn e ss)t r ee的质量特性详述标准来将基于精确质量特性的方案分清主次。
体系结构和属性的信息被收集到ABAS（A tt r i bu t e-B a se d A r ch i t e ct u r a l S t y l e）框架中[K l e i n a nd K a z m a n1999].。
但是如何获得质量视图是如此描述和为何仅有一个描述等级的utility tree并不清楚，并且质量特性的解释并不标准。
utility tree通过一组可被驱动的体系结构测试方案来给与方案优先权来确定关键之处。
特性的测量通过stimuli，参数和响应来显示。
我们的方法使用根据ISO 9126-1标准的质量模型来考虑质量需求的详述。
这个在结构上接近ATAM质量树的等级模型对于软件体系结构很合适。
ISO质量模型现在是软件工业的标准并且它通过高度抽象的层次来解释。
它由内部和外部因素和使用品质特性视图的质量决定的。
这种质量特性（ATAM的特性）恰好被很标准的解释，并且特性的度量通常很普遍，它可以为详细的应用做更进一步的解释。
软件运行环境的质量是由用例模型的质量决定的，也就是在上下文的使用中，用户对于质量的观点。
此篇文章中我们只关心有关内外因素质量模型，而这个质量模型分别描述了用户和开发者的观点。
为了完备使用的质量，这个系统必须达到内部和外部的目标。
在软件开发过程中出现如下情况：当软件作为电脑系统中的一部分和内部软件评估或是实体属性测量的结果时，质量特性常常被详细描述为显现的外在子特性。
在我们的例子中，不得不把这些属性转化或翻译成称之为媒介软件产品的软件体系结构。
在软件开发过程中获得的特性的值可被用来校验内部的质量目标，而这些内部的质量目标有助于确认最终软件系统要求的外部目标[SO/I E C1998].。
拥有质量特性详细描述这样的事实为体系结构详细说明增加了更多的信息，这样有助于为解决特定设计问题而挑选体系结构的设计过程。
除了介绍和结论，；论文的主要部分如下：——为详述软件体系结构的质量特性，给出了一个基于ISO 9126-1标准的通用质量模型的描述。
——一个实例的研究，在这个实例中，我们将获得的通用质量模型来进行使用网络设备的实时监视系统软件体系结构的选择。
2、为软件体系结构而修改的ISO 9126-1质量模型。
ISO 9126-1质量模型：根据ISO 9126-1标准[ISO/IEC, 1998]，质量被描述为一组产品或服务的特色或特性，而这些特色和特性是基于自己的能力来满足显性或隐性的需求。
同时，对于质量定义的不同看法也应被尊重：从用户角度来看，它是最终产品的质量；从开发者的角度来看，它是在开发过程中由不同的项目相关人员生产的中间产品的质量。
从终端管理者角度来看，它是营销的需求。
所有产品的质量都可以被不同观点的集合所表达。
在我们的文章中，用户和开发者（架构师）的观点角度将会被采纳。
MCCALL的工作区分了两类质量特性：因素和标准。
前者不能直接被测量而后者可以被主观的测量。
这启发了I SO9126-1模型。
基于这个标准，ISO 9126-1更进一步的将McCall的模型化简为ISO 9126-1质量模型，现在它在广泛的艺术级的产品质量说明书中被接受。
它提议了一组六个相互独立的高阶的质量特性。
而这些质量特性被定义为其质量已被描述和评估的软件产品的质量特性。
在开发的各种阶段，质量特性被作为外部质量确认和内部质量审查的目标。
当获得特性和可测量的实体时，他们被描述成子特性。
在文中度量和测量标准被定义为一个测量方法或测量手段来获取一个值。
这种关系如图1所示：在开发过程中，为了监视和控制软件质量外部的质量需求会转变或转化成在开发活动中获得的中间产品的质量需求。
表1：ISO9126质量模型的特性。
子特性如图2所示：注意：符合性意味着与标准，协议或者规则的联系。
它被解释为所有特性的子特性之一[I SO/I E C1998]。
这里我们仅把它认为是功能性来精简它的描述。
注意：符合性子特性的出现意味着特性中其余的部分已经被偶些选定的标准完全测量了。
软件体系结构标准质量模型的制定：为了定制ISO质量模型，我们必须了解这些成分。
他们是体系结构或者软件系统所基于的一般框架所期盼的成分。
我们把它当作是软件开发过程的中间产品。
因此，一个特别的在深层次上被构建所解释的体系结构，必须满足ISO9126的全部或部分特性，而连接器连接着这些构件，结构和拓扑。
每个与属性相关联的特性都应被测量。
这些属性应当完全与体系结构或者构件和连接器有关。
质量特性的测量应被量化。
起先，它们被定义为特定符号的公式，接下来就使用标准的语言来定义[M a r c a n o e t a l.2000]。
在这个逐步的体系结构定义过程中，我们也许能够估计体系结构的精华是否提高了质量特性，但此问题在本文中不予讨论。
对于最终产品的每项属性来说，都有需要达到或是超越的质量目标值。
当这些质量目标值被达到或是超越后，我们便说这个体系结构符合质量特性的需求。
这些目标值是在质量需求中所确定的。
接下来我们通过对每个属性给与相应的标准来解释质量需求如何被精确到相应的子特性及属性上，以及它们如何与体系结构相适应。
注意，这里的特性及子特性被认为是相互独立的。
1、功能性特性：（1）、子特性——适应性：拥有符合特定任务需求的足够的功能。
它包括两个方面：存在：任务已被详细说明，比如以用例的方式。
每一个任务必须存在一个特定的功能去完成它。
正确：正确的解释任务的详细说明。
比如必须满足图3 的次序图。
从软件体系结构的层次上说明：a.系统的功能性必须被确定。
在此种情况下，子特性被解释成拥有是【1】或者否【0】这样值的属性。
注意，存在着值介于离散数字【n…m】之间的属性，比如【0….1】代表着不存在或存在。
这种标准是一种获取级别水平的度量。
b.由功能需求所获得的次序图必须被详细精化。
在拥有一个体系结构说明书的情况下，特定的功能被分解成与构件有关的子功能，并且这些子功能都应符合系统的功能性需求。
图3：系统需求向软件体系结构的转化（2）、子特性——正确性：以需要的精确程度来制定正确或一致的结果。