常指生產的成品或所使用的原材料等規定的質量標準，常用在製造學和物理學中。
基本介紹
- 中文名：規格
- 外文名：specifications;
- 讀音：guīgé
- 釋義：設計規定的標準、要求或條件
漢語詞語,基本信息,詳細解釋,製造學名詞,物理學名詞,計算機科學名詞,
漢語詞語
基本信息
(1) [specifications;standards;norms]
(2) 工廠對產品和使用料所規定的型式和標準；
他們試煉的六爐鋼,質量完全合乎規格；
(3) 泛指規定的標準、要求或條件；
這次接待外賓按什麼規格?
(4) 程式設計規定的標準、要求或條件
詳細解釋
1.規範；格局。
唐 歐陽詹 《送裴八侃茂才卻東遊序》：“十二斯冠，才氣卓異，身猶三尺，交友四海，著文數篇，其措意規格，儲乎遠大。”
宋 孟元老 《東京夢華錄·民俗》：“其賣藥賣卦，皆具冠帶。至於乞丐者，亦有規格。稍似懈怠，眾所不容。”
2.生產的成品或所使用的原材料等規定的質量標準。如：這些產品，經過鑑定，完全合乎規格。
3.指一般工業產品的物理形狀，一般包括體積，長度，形狀，重量等。
4.指動畫分鏡頭台本里鏡頭的大小，用規格號表示。
製造學名詞
規格：金屬材料是指同一種或同一型號金屬材料的不同尺寸。一般尺寸不同，其允許偏差也不同。在產品標準中，品種的規格通常按從小到大，有順序地排列。
物理學名詞
.指一般工業產品的物理形狀，一般包括體積，長度，形狀，重量等。在標準化生產的今天，產品的規格是很嚴格的。通常一種產品採用一種規格衡量標準，主要是為了區分類似產品。比如鋼筋，通常用直徑的大小來區分，買房子通常用面積來衡量，買飲料有大瓶裝和小瓶裝就是因為二者的容量不同。由於規格的衡量標準不同，所以規格的表達方式不同，主要有數字和單位兩個部分組成，比如一瓶易拉罐可樂的規格通常是355ml。即使衡量標準相同，表達方式也可能不一樣。比如一塊土地，如果是方形，通常要寫成長乘以寬的形式以表達其大體形狀，如果是圓形，則需要表達為直徑或半徑的形式。也就是說，面積的表達通常以間接地形式表達。還有體積，如你會發現，家裡買電視機的盒子上表明了XX*XX*XX mm的形式，就是表明盒子的長寬高。
計算機科學名詞
規格可以被用於程式開發的任何階段。在需求分析階段，規格可以幫助具體化客戶模糊的要求，並且找出需求中矛盾，模糊和沒有說明的地方。在程式設計中，規格可以嚴格地明確不同模組之間的接口。每一個接口的規格接口規格都提供給用戶足夠的信息，讓他們可以在不了解模組內部實現的前提下使用這個模組，並且讓模組的實現者在實現模組的時候不必考慮使用者的信息。在程式驗證中，規格是正確的程式所應該滿足的狀態，而在程式正確性檢驗中，規格應該被用來生成黑箱測試的測試樣例。和程式一樣，規格可以被用作路徑測試，單元測試，和集成測試。最後，規格還可以用來作為程式文檔，不過這只是可選的，因為它太過於抽象了，更多地還是用作程式行為的描述。
為什麼在軟體行業發展了這么多年之後，人們發展出了軟體需求規格? IEEE 830標準甚至定義了一個好的軟體需求規格的好處:
在軟體的開發者和需求者之間制訂了協定來明確要開發什麼樣的軟體。由規格書寫者書寫的完整的功能描述將能夠幫助潛在的使用者來判斷這個軟體是否滿足他們的需求，或者這個軟體將怎樣被修改才能滿足他們的需求。
減輕了開發負擔，規格的書寫迫使需求者組織的各個相關團隊在設計開始之前仔細地考慮所有的需求以減少代碼的重構，重寫和重新測試。仔細地覆核規格中的需求可以在開發周期剛開始問題還很好解決的時候找出疏忽，誤解和矛盾。
提供了一個基礎用來評估花費和日程安排。軟體需求規格所描述的產品開發過程是評估項目項目花費的現實基礎，還可以被用來作為獲得投資的憑證或者價值評估。
提供了驗證和確認的基本標準。團隊根據一個好的軟體需求規格可以制定出更加有效的驗證和確認計畫。作為開發協定的一部分，軟體需求規格提供了一個應該被服從的基本標準。
促進了項目對象的轉移。軟體需求規格讓軟體產品被新用戶接受或者在新的機器上運行更加容易。用戶可以更加容易地讓團隊的其它部分用上這個軟體，而開發者可以更容易地將它提供給新的用戶。
作為進一步開發的基礎。因為規格僅僅只關心產品而不是開發這個產品的項目，因此規格可以用作最終產品提高的基礎。規格有可能被改變，但它仍然可以作為評估被繼續開發出來的產品的基礎標準。
程式規格可能涉及到三個方面:
- 對程式需求的陳述
- 一個程式的設計的完整表述
- 一個程式能夠被驗證是否正確運行的標準狀態的描述。
程式規格的幾個要素:
- 一致性--規格的邏輯是否自洽？
- 可實現性—這個規格實際上是否可行？
- 完備性—規格是否完整表述了書寫者的意圖？
- 確定性—規格是否正確表述了書寫者的意圖？
- 正確性
每個人當然都是希望規格是正確的，沒人會寫出錯誤的規格，但也沒人保證自己的規格永遠是對的，這裡有個原則,當你發現規格和程式不符之後已經要更新已經失效的規格。 - 重要性排序
通常一個新的系統的一些需求是市場真正需要的，而有的需求可能是不可實現的，軟體需求規格中提供這些信息是很重要的。 - 可檢驗的
不要提出像這樣的需求:“它的反應速度應該要很快”，或者，“系統在任何情況下都不應該崩潰”，需求應該定量表達：“每一次鍵盤事件應該在100ms內對用戶做出回應” - 可修改的
在很多地方有一模一樣的需求規格可能不會錯，但是會使文檔難以維護 - 可追溯的
大多數情況這在不標準環境中是不重要的，然而，在大多數團隊中，將規格中的需求追溯到一個更高的級別是有用的--為什麼我們需要這個功能？
