A New Standard for Quality Requirements
ISO近期公布ISO/IEC25030，一個與IEEE軟體和系統品質要求之標準整合的新軟體品質要求之標準。
有鑑於恰當地辨別、闡明要求對於一個軟體產品的成敗至關重要，以上三個標準的重要性因而凸顯出來。
許多公司注意到了這一點，並逐漸加強對於軟體產品要求的解釋。
不幸的是，他們重視產品之功能性要求的程度，遠大於對於品質要求的程度。品質要求中包含產品之易使用性、產品之可維修性、產品之可依賴性（產品在正常使用的情況下，在給定的時間中，有多少機率可以持續提供被要求的功能性）、產品之可攜性、產品之效能。
在2001年，ISO欲將品質要求設為一項標準。它藉由連動兩個欲修改的標準（ISO/IEC 9126和ISO/IEC 14598）來實現這個想法。 ISO/ IEC JTC1 SC7委員會將品質要求之標準列入SQuaRE這一系列標準中（編號為25000）。SQuaRE包含五個向度，品質管理、品質模型、品質量測、品質要求、品質評估。在品質要求的向度中，新增了ISO/IEC25030的標準。
委員會的成員很快地理解到，你無法在不考量系統層面的情形下，制定一個軟體要求的標準。軟體通常都是一個系統的一部份，所以你必須將軟體要求看成系統要求的一部份。
因此我們從系統的解釋上著手。我們想要發展出一個系統模型，其必須能夠包含軟體的品質要求，同時是容易使人理解且依然能夠將重點放在品質上的。
一個系統是由有互動關係的元素組織起來，並能夠去完成特定功能的一個組合體。當考量到軟體品質時，電腦系統是一個最簡單的系統。它是由硬體、軟體（包含作業系統與其他應用程式）、資料所組成的。這個系統模型包含跑在獨立電腦上的軟體，且已經被當成考量到軟體品質的概念模型很多年了。
然而，電腦系統並不是一個切實際的模型。軟體通常會分散在許多電腦系統上，如client-server systems和Internet applications。我們需要建立一個系統模型，其包含電腦系統之間的溝通，還有嵌入式系統。為此，我們加入許多和機械有關的部分，其包含動力學、電子學、水力發電等。這件事使我們提供一套能涵蓋大型應用的系統描述模型。
但現實世界中的情況更加複雜，並非所有的事物都是自動化的。所以我們也增加了人為介入的因素。整個系統模型包括彼此進行溝通的電腦系統們、動力構件、人為介入。
這個相對簡單的架構式系統模型，滿足我們從系統觀點描述軟體品質的需求。
除了系統模型之外，我們也需要一個軟體品質模型去描述品質要求。最顯而易見的就是ISO9126的品質模型，它辨別了一系列的品質特徵與子特徵。這個標準在1991年被發表，並於2001年後增加了一些項目，現在已經成為業界和學術界最知名的模型了。
我想，ISO9126品質模型最大的優勢在於它是一個國際標準且提供全世界都接受的對於軟體品質之專有名詞。
ISO9126品質模型三種不同看待品質的觀點。內部觀點與外部觀點共用相同的六種特徵與二十六種子特徵。第三種觀點，使用的品質，有其自有的四種特徵。
內部觀點主要關心的是軟體產品各個單獨部分的靜止屬性，包括設計、程式碼的結構與複雜度。開發者在開發的早期便可以去量測這些品質屬性。一個內部度量的典型例子是 Shyam Chidamber 和 Chris Kemerer開發的套件，此套件針對的是對於物件導向軟體的CK度量。包含 weighted methods per class (WMC), depth of the inheritance tree (DIT), number of children (NOC), coupling between object classes (CBO), response for a class (RFC), and lack of cohesion in methods (LCOM)。
外部觀點關心的是完成後的軟體在實際電腦硬體運行並處理資料時的狀況。在這個觀點下，軟體的動態層面扮演一個很重要的角色。一個典型的外部度量為平均連續無故障時間。這個量質和軟體品質中的可依賴性有關。
使用品質關心的是特定使用者在真實環境下使用軟體去執行特定工作的狀況。這個觀點通常測量的是終端用戶的生產力與是否可以將事情做對。
這些不同的觀點彼此支援著彼此。內部品質影響外部品質，外部品質影響使用品質。內部品質的測量結果可以當作外部品質的早期指標。舉例來說，如果程式碼的複雜度很高，類別彼此間的耦合性也很高，則軟體將會較難維護。同樣的外部品質的測量結果可以當作使用品質的早期指標，若軟體效率很差，使用者的生產力也會不好。
內部品質的度量自己本身也是有意義的。然而其與外部品質的度量的狀況不同，後者還需要考慮到電腦硬體、資料、和其他有可能的因素。舉例來說，一個有效率的演算法實作，不一定是一隻有效率的程式，因為如果電腦硬體太慢，跑出來的效果就不好。當我們考慮到使用品質，我們或許還需要考慮到機械性的部分與人為介入的部分。整個系統各個單獨部分的品質在我們對於軟體品質的概念中扮演很重要的角色。因此，我們必須考量到電腦硬體、資料、和機械有關的部分、人為介入等因素的品質。
要闡明軟體品質要求之前，我們必須清楚地了解產品的品質所代表的真正意義。這裡有兩個觀點：
1.滿足規定上的要求
2.滿足對於一些目的，已經闡述或暗示的需求
這兩個觀點只有在要求的規定能反映所有股東對於所有應用的需求時，才會被看成是一體。但這種情況多數不切實際。許多股東無法清楚表達他們的需求，甚至連自己真正的需求是甚麼也不清楚。更甚者，股東彼此之間的需求也會互相衝突。收購軟體公司的公司或供應商通常對於"滿足規定上的要求"感興趣。而終端用戶或者當局者通常對於"滿足需求"感興趣。前者專注的點是軟體產品，後者專注的點是整個系統的運行。
這兩個觀點都很重要，所以我們的標準將同時將兩者列入考量。在ISO的品質模型中，一個軟體品質特徵被定義成一個會影響軟體品質的軟體品質屬性們所構成的類別。一個屬性是能夠被測量的，例如size，可以用程式碼有多少行數來測量。我們可以透過一個軟體產品固有的屬性來決定其行為，也可以透過一個軟體產品的各種品質屬性來決定其品質。所以軟體的量測成為了軟體品質模型與軟體品質之間的橋樑。我們可以透過量測來量化軟體的品質。
這暗示著我們可以透過提供一系列品質量測，與其相關的目標數值，來具體指出軟體品質要求。一個例子是有報告生產功能的線上行政系統。其可能的軟體品質要求是：
品質特徵：效率(時間行為)
屬性：生產報告的時間
量測：在正常系統使用下，生產一份報告所需要的秒數。測量10次。
當軟體完成後，我們可以測量品質屬性，並比較測量得到的值跟目標值，來檢視是否達到品質要求。制定品質要求這件事情很重要，以至於我們可以在適當的時間和精力下表明對於品質要求的履行。怎樣是適當的，取決於對於要求的嚴格性和想要的應用。如果是高風險的應用，我們傾向花更多的時間和精力來評估品質。
當考量到ISO9126軟體品質模型時，有許多困難點也出現。特別是，我們不清楚開怎麼去詮釋"functionality"。它是指軟體的實用性嗎？如果是這樣，實用的這個要求將會變成品質要求的一部份。然而，我們決定將所有品質特徵詮釋為一隻程式與其函式表現得有多好。也就是說我們將重點放在函式的可依賴性、易使用性、效率。當看到functionality的五個子特徵時，我們更能明白。
模型的大小也會使其變得更複雜。具體指出一個軟體產品的品質要求至如此等級的細節，將會成為一個主要的工作項目。幸運的是，在多數情況下，這通常是不必要的。舉例來說，一架飛機的引擎是一個嵌入式系統，它沒有直接的終端用戶。所以我們不期望它有太多的易使用性要求，相對的有更嚴格的可依賴性要求。所以開發者必須使用品質模型來當作清單，確保他們已經將所有重要的要求列入了。當特定的品質有存在的必要，開發者必須標記他們，並具體指出有關連的品質要求。避免指出過多或太嚴格的品質要求也是同等重要的。太嚴格的品質要求是一種對時間和金錢的浪費，因為要滿足嚴格的要求代價是很高的。
再一次舉飛機引擎軟體的例子。軟體是非常關鍵的，所以它的開發與測試需要巨量的努力。表明對於嚴格的可依賴性要求之滿足，也需要投入顯著的努力。如果對前面提過的線上行政系統，也使用同樣嚴格的可依賴性要求並投入大量努力去表明它的可依賴性將會是沒有意義的。我的建議是定好正確等級的品質，不過多也不過少。
ISO9126的模型主要和電腦系統相關。只有使用品質的特徵套用在整個系統上，且是從較狹隘的觀點來看待。Figure 2 shows the quality models for the other system parts in addition to the ISO quality model. ISO/IEC 25030 points out the relations between various quality models. However, it’s still a research issue to define and integrate the different quality models into a coherent system quality model.
當要產生要求時，我們必須考量到整個系統。大多數的股東不在乎他們的需求是在軟體、硬體、在機械運作中、在人工操作中被實作的。股東只想要整個系統能滿足他們的需求即可，這就是"fit-for-purpose"的觀點。
在開發者收集、分析、整合、同意股東們的需求後，他們必須著手高層級架構的設計去決定軟體將會實現甚麼。接著分析所有軟體相關的要求。如同先前提到的，開發者必須根據目標值和量測值制定這些要求。 Figure 3 shows this two-step approach, which complies with the system life-cycle processes defined in ISO/IEC 15288.This standard defines a set of processes categorized as either project, enterprise, or agreement processes.技術流程是專案開發過程的一部份，包括要求定義的階段：定義可以在特定環境下提供滿足使用者需求之服務的要求。
分析階段：將股東要求驅動的觀點轉換成產品的技術面觀點。
軟體品質要求的技術面觀點就是符合規格。也就是你可以客觀地去測量證實這些要求。
ISO/IEC 15288和 ISO/IEC 25030最主要的差別在於前者重視過程後者重視產品本身 ，也就是定義品質要求。這個觀點和two IEEE requirements standards相似。However, the IEEE standards focus primarily on functional requirements, although they also include quality aspects. For example, IEEE 830 specifically mentions performance (which isn’t considered a quality feature), reliability, availability, security, maintainability, and portability
國際標準遵從特定的由ISO定義的範本。
第一個條款呈現的是使用範圍和目標。這個標準對於收購公司和供應商都適用。且提供對於品質要求明定的要求和建議。其對以下皆特別有用
1.規範（合約或招標）
2.規劃(包含可行性分析)
3.開發(包含早期對於潛在品質問題的辨認)
4.評估(包含客觀評估和對於軟體產品品質的證明)
第五和六個條款呈現的是標準的本體。第五個條款較有資訊性，不包含任何要求，描述品質的觀念，例如建模型、測量，以及這些觀念彼此間有甚麼關聯。
第六個條款包含規範的要求。講明需要滿足這些要求來遵守這個標準。(這個標準在第二個條款中聲明了通用的遵守要求)。然而這個標準的用處不因為需要遵守規則而被限制。它就像對於定義軟體品質要求的通用指南一樣好用。
6.1條款包含普遍的假設。它聲明這個標準不假設或需要特定的軟體開發模型。此外，它提供有用的相關標準參考，如 ISO 9001，這個標準聲明，最頂級的管理應該確保客人的需求被確定，且將目標訂在提高客人的滿意度。 ISO 9001更詳細地指出客人的需求，包含那些客人沒有講，但在特定或計畫的使用下必定會用到的。當然也包括產品相關的義務與監管需求。ISO/IEC 25030更進一步詳細說明這些需求。
6.2條款提供定義股東之要求的建議和要求。首先標準的使用者必須描述系統的目的。這個條款特別強調在辨認股東的合法性與描述他們的角色。股東包含用戶、組織（收購公司或開發者組織）、還有法定與監管機關。股東可能有互相衝突的需求，而且他們的需求變來變去。這個標準並不推動特定的制定方式或技巧，但提供普遍可應用的指導，可以和特定方法一起使用。這個條款從系統觀點切入，因為stakeholders並不都關心實作。這個標準著重在將客戶的需求、願望、慾望寫成紀錄的需要性。即便這些需求願望慾望可能互相衝突、太過崇高、太過不切實際。
6.3條款提供軟體品質要求的建議與要求。這個標準假設做了高層級的架構決策，有關於如何去實作出系統的要求，以及那些部分要在軟體中實作。這幫助了開發者辨別利害關係者對於軟體的品質要求。開發者必須根據軟體度量和相關的目標值來制定要求。
the software requirements in terms of measures and target values forces the involved parties to carefully consider which quality requirements are necessary. Developers can use the software quality requirements to monitor and control software quality during development as well as to evaluate the final product. The standard emphasizes having relevant stakeholders verify and formally agree on the list of quality requirements.
有鑑於恰當地辨別、闡明要求對於一個軟體產品的成敗至關重要，以上三個標準的重要性因而凸顯出來。
許多公司注意到了這一點，並逐漸加強對於軟體產品要求的解釋。
不幸的是，他們重視產品之功能性要求的程度，遠大於對於品質要求的程度。品質要求中包含產品之易使用性、產品之可維修性、產品之可依賴性（產品在正常使用的情況下，在給定的時間中，有多少機率可以持續提供被要求的功能性）、產品之可攜性、產品之效能。
在2001年，ISO欲將品質要求設為一項標準。它藉由連動兩個欲修改的標準（ISO/IEC 9126和ISO/IEC 14598）來實現這個想法。 ISO/ IEC JTC1 SC7委員會將品質要求之標準列入SQuaRE這一系列標準中（編號為25000）。SQuaRE包含五個向度，品質管理、品質模型、品質量測、品質要求、品質評估。在品質要求的向度中，新增了ISO/IEC25030的標準。
委員會的成員很快地理解到，你無法在不考量系統層面的情形下，制定一個軟體要求的標準。軟體通常都是一個系統的一部份，所以你必須將軟體要求看成系統要求的一部份。
因此我們從系統的解釋上著手。我們想要發展出一個系統模型，其必須能夠包含軟體的品質要求，同時是容易使人理解且依然能夠將重點放在品質上的。
一個系統是由有互動關係的元素組織起來，並能夠去完成特定功能的一個組合體。當考量到軟體品質時，電腦系統是一個最簡單的系統。它是由硬體、軟體（包含作業系統與其他應用程式）、資料所組成的。這個系統模型包含跑在獨立電腦上的軟體，且已經被當成考量到軟體品質的概念模型很多年了。
然而，電腦系統並不是一個切實際的模型。軟體通常會分散在許多電腦系統上，如client-server systems和Internet applications。我們需要建立一個系統模型，其包含電腦系統之間的溝通，還有嵌入式系統。為此，我們加入許多和機械有關的部分，其包含動力學、電子學、水力發電等。這件事使我們提供一套能涵蓋大型應用的系統描述模型。
但現實世界中的情況更加複雜，並非所有的事物都是自動化的。所以我們也增加了人為介入的因素。整個系統模型包括彼此進行溝通的電腦系統們、動力構件、人為介入。
這個相對簡單的架構式系統模型，滿足我們從系統觀點描述軟體品質的需求。
除了系統模型之外，我們也需要一個軟體品質模型去描述品質要求。最顯而易見的就是ISO9126的品質模型，它辨別了一系列的品質特徵與子特徵。這個標準在1991年被發表，並於2001年後增加了一些項目，現在已經成為業界和學術界最知名的模型了。
我想，ISO9126品質模型最大的優勢在於它是一個國際標準且提供全世界都接受的對於軟體品質之專有名詞。
ISO9126品質模型三種不同看待品質的觀點。內部觀點與外部觀點共用相同的六種特徵與二十六種子特徵。第三種觀點，使用的品質，有其自有的四種特徵。
內部觀點主要關心的是軟體產品各個單獨部分的靜止屬性，包括設計、程式碼的結構與複雜度。開發者在開發的早期便可以去量測這些品質屬性。一個內部度量的典型例子是 Shyam Chidamber 和 Chris Kemerer開發的套件，此套件針對的是對於物件導向軟體的CK度量。包含 weighted methods per class (WMC), depth of the inheritance tree (DIT), number of children (NOC), coupling between object classes (CBO), response for a class (RFC), and lack of cohesion in methods (LCOM)。
外部觀點關心的是完成後的軟體在實際電腦硬體運行並處理資料時的狀況。在這個觀點下，軟體的動態層面扮演一個很重要的角色。一個典型的外部度量為平均連續無故障時間。這個量質和軟體品質中的可依賴性有關。
使用品質關心的是特定使用者在真實環境下使用軟體去執行特定工作的狀況。這個觀點通常測量的是終端用戶的生產力與是否可以將事情做對。
這些不同的觀點彼此支援著彼此。內部品質影響外部品質，外部品質影響使用品質。內部品質的測量結果可以當作外部品質的早期指標。舉例來說，如果程式碼的複雜度很高，類別彼此間的耦合性也很高，則軟體將會較難維護。同樣的外部品質的測量結果可以當作使用品質的早期指標，若軟體效率很差，使用者的生產力也會不好。
內部品質的度量自己本身也是有意義的。然而其與外部品質的度量的狀況不同，後者還需要考慮到電腦硬體、資料、和其他有可能的因素。舉例來說，一個有效率的演算法實作，不一定是一隻有效率的程式，因為如果電腦硬體太慢，跑出來的效果就不好。當我們考慮到使用品質，我們或許還需要考慮到機械性的部分與人為介入的部分。整個系統各個單獨部分的品質在我們對於軟體品質的概念中扮演很重要的角色。因此，我們必須考量到電腦硬體、資料、和機械有關的部分、人為介入等因素的品質。
要闡明軟體品質要求之前，我們必須清楚地了解產品的品質所代表的真正意義。這裡有兩個觀點：
1.滿足規定上的要求
2.滿足對於一些目的，已經闡述或暗示的需求
這兩個觀點只有在要求的規定能反映所有股東對於所有應用的需求時，才會被看成是一體。但這種情況多數不切實際。許多股東無法清楚表達他們的需求，甚至連自己真正的需求是甚麼也不清楚。更甚者，股東彼此之間的需求也會互相衝突。收購軟體公司的公司或供應商通常對於"滿足規定上的要求"感興趣。而終端用戶或者當局者通常對於"滿足需求"感興趣。前者專注的點是軟體產品，後者專注的點是整個系統的運行。
這兩個觀點都很重要，所以我們的標準將同時將兩者列入考量。在ISO的品質模型中，一個軟體品質特徵被定義成一個會影響軟體品質的軟體品質屬性們所構成的類別。一個屬性是能夠被測量的，例如size，可以用程式碼有多少行數來測量。我們可以透過一個軟體產品固有的屬性來決定其行為，也可以透過一個軟體產品的各種品質屬性來決定其品質。所以軟體的量測成為了軟體品質模型與軟體品質之間的橋樑。我們可以透過量測來量化軟體的品質。
這暗示著我們可以透過提供一系列品質量測，與其相關的目標數值，來具體指出軟體品質要求。一個例子是有報告生產功能的線上行政系統。其可能的軟體品質要求是：
品質特徵：效率(時間行為)
屬性：生產報告的時間
量測：在正常系統使用下，生產一份報告所需要的秒數。測量10次。
當軟體完成後，我們可以測量品質屬性，並比較測量得到的值跟目標值，來檢視是否達到品質要求。制定品質要求這件事情很重要，以至於我們可以在適當的時間和精力下表明對於品質要求的履行。怎樣是適當的，取決於對於要求的嚴格性和想要的應用。如果是高風險的應用，我們傾向花更多的時間和精力來評估品質。
當考量到ISO9126軟體品質模型時，有許多困難點也出現。特別是，我們不清楚開怎麼去詮釋"functionality"。它是指軟體的實用性嗎？如果是這樣，實用的這個要求將會變成品質要求的一部份。然而，我們決定將所有品質特徵詮釋為一隻程式與其函式表現得有多好。也就是說我們將重點放在函式的可依賴性、易使用性、效率。當看到functionality的五個子特徵時，我們更能明白。
模型的大小也會使其變得更複雜。具體指出一個軟體產品的品質要求至如此等級的細節，將會成為一個主要的工作項目。幸運的是，在多數情況下，這通常是不必要的。舉例來說，一架飛機的引擎是一個嵌入式系統，它沒有直接的終端用戶。所以我們不期望它有太多的易使用性要求，相對的有更嚴格的可依賴性要求。所以開發者必須使用品質模型來當作清單，確保他們已經將所有重要的要求列入了。當特定的品質有存在的必要，開發者必須標記他們，並具體指出有關連的品質要求。避免指出過多或太嚴格的品質要求也是同等重要的。太嚴格的品質要求是一種對時間和金錢的浪費，因為要滿足嚴格的要求代價是很高的。
再一次舉飛機引擎軟體的例子。軟體是非常關鍵的，所以它的開發與測試需要巨量的努力。表明對於嚴格的可依賴性要求之滿足，也需要投入顯著的努力。如果對前面提過的線上行政系統，也使用同樣嚴格的可依賴性要求並投入大量努力去表明它的可依賴性將會是沒有意義的。我的建議是定好正確等級的品質，不過多也不過少。
ISO9126的模型主要和電腦系統相關。只有使用品質的特徵套用在整個系統上，且是從較狹隘的觀點來看待。Figure 2 shows the quality models for the other system parts in addition to the ISO quality model. ISO/IEC 25030 points out the relations between various quality models. However, it’s still a research issue to define and integrate the different quality models into a coherent system quality model.
當要產生要求時，我們必須考量到整個系統。大多數的股東不在乎他們的需求是在軟體、硬體、在機械運作中、在人工操作中被實作的。股東只想要整個系統能滿足他們的需求即可，這就是"fit-for-purpose"的觀點。
在開發者收集、分析、整合、同意股東們的需求後，他們必須著手高層級架構的設計去決定軟體將會實現甚麼。接著分析所有軟體相關的要求。如同先前提到的，開發者必須根據目標值和量測值制定這些要求。 Figure 3 shows this two-step approach, which complies with the system life-cycle processes defined in ISO/IEC 15288.This standard defines a set of processes categorized as either project, enterprise, or agreement processes.技術流程是專案開發過程的一部份，包括要求定義的階段：定義可以在特定環境下提供滿足使用者需求之服務的要求。
分析階段：將股東要求驅動的觀點轉換成產品的技術面觀點。
軟體品質要求的技術面觀點就是符合規格。也就是你可以客觀地去測量證實這些要求。
ISO/IEC 15288和 ISO/IEC 25030最主要的差別在於前者重視過程後者重視產品本身 ，也就是定義品質要求。這個觀點和two IEEE requirements standards相似。However, the IEEE standards focus primarily on functional requirements, although they also include quality aspects. For example, IEEE 830 specifically mentions performance (which isn’t considered a quality feature), reliability, availability, security, maintainability, and portability
國際標準遵從特定的由ISO定義的範本。
第一個條款呈現的是使用範圍和目標。這個標準對於收購公司和供應商都適用。且提供對於品質要求明定的要求和建議。其對以下皆特別有用
1.規範（合約或招標）
2.規劃(包含可行性分析)
3.開發(包含早期對於潛在品質問題的辨認)
4.評估(包含客觀評估和對於軟體產品品質的證明)
第五和六個條款呈現的是標準的本體。第五個條款較有資訊性，不包含任何要求，描述品質的觀念，例如建模型、測量，以及這些觀念彼此間有甚麼關聯。
第六個條款包含規範的要求。講明需要滿足這些要求來遵守這個標準。(這個標準在第二個條款中聲明了通用的遵守要求)。然而這個標準的用處不因為需要遵守規則而被限制。它就像對於定義軟體品質要求的通用指南一樣好用。
6.1條款包含普遍的假設。它聲明這個標準不假設或需要特定的軟體開發模型。此外，它提供有用的相關標準參考，如 ISO 9001，這個標準聲明，最頂級的管理應該確保客人的需求被確定，且將目標訂在提高客人的滿意度。 ISO 9001更詳細地指出客人的需求，包含那些客人沒有講，但在特定或計畫的使用下必定會用到的。當然也包括產品相關的義務與監管需求。ISO/IEC 25030更進一步詳細說明這些需求。
6.2條款提供定義股東之要求的建議和要求。首先標準的使用者必須描述系統的目的。這個條款特別強調在辨認股東的合法性與描述他們的角色。股東包含用戶、組織（收購公司或開發者組織）、還有法定與監管機關。股東可能有互相衝突的需求，而且他們的需求變來變去。這個標準並不推動特定的制定方式或技巧，但提供普遍可應用的指導，可以和特定方法一起使用。這個條款從系統觀點切入，因為stakeholders並不都關心實作。這個標準著重在將客戶的需求、願望、慾望寫成紀錄的需要性。即便這些需求願望慾望可能互相衝突、太過崇高、太過不切實際。
6.3條款提供軟體品質要求的建議與要求。這個標準假設做了高層級的架構決策，有關於如何去實作出系統的要求，以及那些部分要在軟體中實作。這幫助了開發者辨別利害關係者對於軟體的品質要求。開發者必須根據軟體度量和相關的目標值來制定要求。
the software requirements in terms of measures and target values forces the involved parties to carefully consider which quality requirements are necessary. Developers can use the software quality requirements to monitor and control software quality during development as well as to evaluate the final product. The standard emphasizes having relevant stakeholders verify and formally agree on the list of quality requirements.
留言
張貼留言