規格

規格

來自 呢圖網 的圖片

中文名；規格 外文名；specifications; 讀音；guīgé 釋義；設計規定的標準、要求或條件

常指生產的成品或所使用的原材料等規定的質量標準，常用在製造學和物理學中。

(1) [specifications;standards;norms]

(2) 工廠對產品和使用料所規定的型式和標準；

他們試煉的六爐鋼,質量完全合乎規格；

(3) 泛指規定的標準、要求或條件；

這次接待外賓按什麼規格?

(4) 程序設計規定的標準、要求或條件

目錄

詳細解釋

1.規範；格局。

《三國志·魏志·夏侯玄等傳論》：「 玄 以規格局度，世稱其名，然與 曹爽 中外繾綣；榮位如斯，更未聞匡弼其非，援致良才。」

唐 歐陽詹 《送裴八侃茂才卻東遊序》：「十二斯冠，才氣卓異，身猶三尺，交友四海，著文數篇，其措意規格，儲乎遠大。」

宋 孟元老 《東京夢華錄·民俗》：「其賣藥賣卦，皆具冠帶。至於乞丐者，亦有規格。稍似懈怠，眾所不容。」

清 周亮工 《書影》卷一：「 元 人作劇，專尚規格，長短既有定數，牌名亦有次第。」

2.生產的成品或所使用的原材料等規定的質量標準。如：這些產品，經過鑑定，完全合乎規格。

3.指一般工業產品的物理形狀，一般包括體積，長度，形狀，重量等。

4.指動畫分鏡頭台本里鏡頭的大小，用規格號表示。

製造學名詞

規格：金屬材料是指同一種或同一型號金屬材料的不同尺寸。一般尺寸不同，其允許偏差也不同。在產品標準中，品種的規格通常按從小到大，有順序地排列。

物理學名詞

.指一般工業產品的物理形狀，一般包括體積，長度，形狀，重量等。在標準化生產的今天，產品的規格是很嚴格的。通常一種產品採用一種規格衡量標準，主要是為了區分類似產品。比如鋼筋，通常用直徑的大小來區分，買房子通常用面積來衡量，買飲料有大瓶裝和小瓶裝就是因為二者的容量不同。由於規格的衡量標準不同，所以規格的表達方式不同，主要有數字和單位兩個部分組成，比如一瓶易拉罐可樂的規格通常是355ml。即使衡量標準相同，表達方式也可能不一樣。比如一塊土地，如果是方形，通常要寫成長乘以寬的形式以表達其大體形狀，如果是圓形，則需要表達為直徑或半徑的形式。也就是說，面積的表達通常以間接地形式表達。還有體積，如你會發現，家裡買電視機的盒子上表明了XX*XX*XX mm的形式，就是表明盒子的長寬高。

計算機科學名詞

規格可以被用於程序開發的任何階段。在需求分析階段，規格可以幫助具體化客戶模糊的要求，並且找出需求中矛盾，模糊和沒有說明的地方。在程序設計中，規格可以嚴格地明確不同模塊之間的接口。每一個接口的規格接口規格都提供給用戶足夠的信息，讓他們可以在不了解模塊內部實現的前提下使用這個模塊，並且讓模塊的實現者在實現模塊的時候不必考慮使用者的信息。在程序驗證中，規格是正確的程序所應該滿足的狀態，而在程序正確性檢驗中，規格應該被用來生成黑箱測試的測試樣例。和程序一樣，規格可以被用作路徑測試，單元測試，和集成測試。最後，規格還可以用來作為程序文檔，不過這只是可選的，因為它太過於抽象了，更多地還是用作程序行為的描述。

為什麼在軟件行業發展了這麼多年之後，人們發展出了軟件需求規格? IEEE 830標準甚至定義了一個好的軟件需求規格的好處:

在軟件的開發者和需求者之間制訂了協議來明確要開發什麼樣的軟件。由規格書寫者書寫的完整的功能描述將能夠幫助潛在的使用者來判斷這個軟件是否滿足他們的需求，或者這個軟件將怎樣被修改才能滿足他們的需求。

減輕了開發負擔，規格的書寫迫使需求者組織的各個相關團隊在設計開始之前仔細地考慮所有的需求以減少代碼的重構，重寫和重新測試。仔細地覆核規格中的需求可以在開發周期剛開始問題還很好解決的時候找出疏忽，誤解和矛盾。

提供了一個基礎用來評估花費和日程安排。軟件需求規格所描述的產品開發過程是評估項目項目花費的現實基礎，還可以被用來作為獲得投資的憑證或者價值評估。

提供了驗證和確認的基本標準。團隊根據一個好的軟件需求規格可以制定出更加有效的驗證和確認計劃。作為開發協議的一部分，軟件需求規格提供了一個應該被服從的基本標準。

促進了項目對象的轉移。軟件需求規格讓軟件產品被新用戶接受或者在新的機器上運行更加容易。用戶可以更加容易地讓團隊的其它部分用上這個軟件，而開發者可以更容易地將它提供給新的用戶。

作為進一步開發的基礎。因為規格僅僅只關心產品而不是開發這個產品的項目，因此規格可以用作最終產品提高的基礎。規格有可能被改變，但它仍然可以作為評估被繼續開發出來的產品的基礎標準。

程序規格可能涉及到三個方面:

對程序需求的陳述

一個程序的設計的完整表述

一個程序能夠被驗證是否正確運行的標準狀態的描述。

程序規格的幾個要素:

一致性--規格的邏輯是否自洽？

可實現性—這個規格實際上是否可行？

完備性—規格是否完整表述了書寫者的意圖？

確定性—規格是否正確表述了書寫者的意圖？

正確性每個人當然都是希望規格是正確的，沒人會寫出錯誤的規格，但也沒人保證自己的規格永遠是對的，這裡有個原則,當你發現規格和程序不符之後已經要更新已經失效的規格。

重要性排序通常一個新的系統的一些需求是市場真正需要的，而有的需求可能是不可實現的，軟件需求規格中提供這些信息是很重要的。

可檢驗的不要提出像這樣的需求:「它的反應速度應該要很快」，或者，「系統在任何情況下都不應該崩潰」，需求應該定量表達：「每一次鍵盤事件應該在100ms內對用戶做出回應」

可修改的在很多地方有一模一樣的需求規格可能不會錯，但是會使文檔難以維護

可追溯的大多數情況這在不標準環境中是不重要的，然而，在大多數團隊中，將規格中的需求追溯到一個更高的級別是有用的--為什麼我們需要這個功能？