仕様(技術基準)

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

仕様は、多く の場合、材料、設計、製品、またはサービスによって満たされる一連の文書化された要件を指します。[1]仕様は、多くの場合、一種の技術標準です。

技術仕様またはエンジニアリング仕様(仕様)にはさまざまな種類があり、この用語は技術的な文脈によって使用方法が異なります。多くの場合、特定のドキュメントやその中の特定の情報を参照します。仕様という言葉は、「明示的または詳細に述べる」または「具体的にする」と広く定義されています。

要件仕様は、特定の材料、設計、製品、サービスなどによって満たされる、文書化された要件、または文書化された要件のセットです。[1]これは、多くの分野でエンジニアリング設計および製品開発プロセス の一般的な初期部分です。

機能仕様は一種の要件仕様であり、機能ブロック図を示す場合があります[要出典]

設計または製品仕様は、要件仕様のソリューション機能を説明し、設計されたソリューションまたは最終的に作成されたソリューションのいずれかを参照します。多くの場合、製造/生産をガイドするために使用されます。ここでは、仕様という用語がデータシート(またはスペックシート)に関連して使用されることがありますが、これは混乱を招く可能性があります。データシートには、アイテムまたは製品の技術的特性が記載されており、多くの場合、人々が製品を選択または使用するのを支援するためにメーカーによって発行されます。データシートは、作成方法を通知するという意味での技術仕様ではありません。

稼働中」または「保守仕様は、摩耗や保守(構成変更)の影響を含む、長年の運用後のシステムまたはオブジェクトの状態を指定します。

仕様は、公的部門と民間部門の両方で、さまざまな種類の組織のいずれかによって開発される可能性のある技術標準の一種です組織タイプの例には、企業コンソーシアム(企業の小グループ)、業界団体(業界全体の企業グループ)、政府(さまざまな公的機関、規制当局、国立研究所および研究所を含む)、専門家協会(社会) 、ISOなどの専用の標準化団体、またはベンダー中立で開発された一般的な要件。ある組織が別の組織の基準を参照参照呼び出し引用)するのは一般的です。政府または企業の契約によって採用された場合、自主基準が義務化される可能性があります。

を使用

エンジニアリング製造、およびビジネスでは、サプライヤー購入者、および材料、製品、またはサービスのユーザーがすべての要件を理解し、同意することが不可欠です。[2]

仕様は、契約書や調達文書、またはその他の方法で合意された一連の要件によって参照されることが多い標準を参照する場合があります(ただし、単数形で使用されることがよくあります)。いずれにせよ、それは特定の要件についての必要な詳細を提供します。

仕様の標準は、政府機関、標準化団体(SAEAWSNISTASTMISO / IECCEN / CENELECDoDなど)、業界団体企業などによって提供される場合があります。次の英国規格が仕様に適用されます。

  • BS 7373-1:2001仕様書作成ガイド[3]
  • BS 7373-2:2001製品仕様。製品仕様の基準を特定し、製品の適合性を宣言するためのガイド[4]
  • BS 7373-3:2005、製品仕様。提供するサービスを指定するための基準を特定するためのガイド[5]

設計/製品仕様は、必ずしも製品がすべての状況で正しいまたは有用であることを証明するものではありませアイテムが仕様に準拠していることを確認したり、仕様番号をスタンプしたりする場合があります。これ自体は、アイテムが他の検証されていない用途に適していることを示すものではありません。アイテムを使用する人(エンジニア労働組合など)またはアイテムを指定する人(建築基準法、政府、業界など)は、利用可能な仕様の選択を検討し、正しい仕様を指定し、コンプライアンスを実施する責任があります。アイテムを正しく使用してください。適合性の検証が必要です。

ガイダンスと内容

優れた仕様の作成とフォーマットに役立つガイドまたは標準の操作手順が利用できる場合があります。[6] [7] [8] 仕様には次のものが含まれる場合があります。

構造仕様

北米の建設仕様

北米の仕様は、建物およびインフラストラクチャプロジェクトの建設に付随および管理する契約文書の一部を形成します。仕様は、コード引用と公開された標準を使用して建築材料の品質と性能を説明しますが、図面またはビルディングインフォメーションモデル(BIM)は、材料の量と場所を示します。名前と番号のガイドマスタードキュメントは、MasterFormatの最新版です。これは、Construction SpecificationCanadaと米国に拠点を置くConstructionSpecifications Instituteの 2つの専門組織が共同で後援し、2年ごとに更新されるコンセンサスドキュメントです。

テキスト文書と図面の間に矛盾がある場合、「仕様は図面を無効にする」と信じる傾向がありますが、実際の意図は、所有者と請負業者の間の契約で明示する必要があります。標準のAIA(American Institute of Architects)とEJCDC(Engineering Joint Contract Documents Committee)は、完全な施設に必要な情報を提供するとともに、図面と仕様が補完的であると述べています。海軍施設司令部(NAVFAC)などの多くの公的機関は、仕様が図面を無効にしていると述べています。これは、論争の場合、陪審員(または調停人)が図面よりも言葉を解釈しやすいという考えに基づいています。

構造仕様の標準リストは50の部門に分類されます、または建設に関連する作業タイプと作業結果の幅広いカテゴリ。部門はセクションに細分され、各セクションは建設工事の特定の材料タイプ(コンクリート)または作業成果物(鋼製ドア)に対応しています。作業結果に応じて、特定の材料がいくつかの場所で覆われる場合があります。たとえば、ステンレス鋼は、フラッシングで使用されるシート材料および部門07のシートメタルとしてカバーできます。手すりなど、部門05でカバーされる完成品の一部にすることができます。または、部門08でカバーされている、建物のハードウェアのコンポーネントにすることもできます。仕様部門の元のリストは、外部から内部に至るまでの建設の時系列に基づいており、新しい材料やシステムが建設プロセスへの道。

各セクションは、「一般」、「製品」、「実行」の3つの部分に分かれています。MasterFormatおよびセクションフォーマット[16]システムは、住宅、商業、民間、および工業用の建設にうまく適用できます。多くの建築家は、かなり膨大な商業スタイルの仕様がほとんどの住宅プロジェクトには長すぎると感じているため、独自のより簡略化された仕様を作成するか、ArCHspec(住宅プロジェクト用に特別に作成された)を使用します。マスター仕様システムは、Arcom、Visispec、BSD、Spectextなどの複数のベンダーから入手できます。これらのシステムは、米国全体で言語を標準化するために作成されたもので、通常はサブスクリプションベースです。

仕様は、完成した作業によって達成されなければならないパフォーマンスを示すようにテキストを制限する「パフォーマンスベース」、アイテムに適用可能な製造基準などの特定の基準を指定する「規範的」のいずれかです。独自仕様」。これにより、指定者は、各作業範囲で受け入れられる特定の製品、ベンダー、さらには請負業者を示します。さらに、仕様は特定の製品リストで「クローズ」することも、請負業者による代替を可能にする「オープン」にすることもできます。ほとんどの構造仕様は、パフォーマンスベースのタイプと独自のタイプの組み合わせであり、許容可能なメーカーと製品に名前を付け、満たす必要のある特定の標準と設計基準も指定しています。

北米の仕様は通常、作業の幅広い説明に制限されていますが、ヨーロッパの仕様と土木工事には、部品表のように平方メートル単位で構築される乾式壁面積など、実際の作業量を含めることができますこのタイプの仕様は、スペックライターと積算士の間の共同作業です。このアプローチは、各入札者が図面と仕様の両方に基づいて積算を行う北米では珍しいものです。ヨーロッパ大陸の多くの国では、米国で「仕様」と記載されている可能性のあるコンテンツは、建築基準法または地方自治体法の対象となっています。米国の土木およびインフラストラクチャの作業には、実行する作業の量の内訳も含まれることがよくあります。

仕様書は通常、建築家の事務所によって発行されますが、仕様書の作成自体は、建築家とさまざまなエンジニア、または専門の仕様書作成者によって行われます。仕様書の作成は、多くの場合、明確な専門的取引であり、「Certified Construction Specifier」(CCS)などの専門的な認定はConstruction Specification Instituteから入手でき、Registered Specification Writer(RSW)[17]はConstruction SpecificationCanadaから入手できます。仕様書作成者は、建築家、エンジニア、または建設管理会社の従業員または下請け業者です。仕様書作成者は、建築材料のメーカーと頻繁に会います請負業者が提案につながる見積もりに製品を含めることができるように、今後の建設プロジェクトで製品を指定することを求める人。

2015年2月、ArCHspecは、住宅建築の改善を目的とする全国的なアメリカの建築家専門家協会であるArCH(Architects Creation Homes)から稼働しました。ArCHspecは、SFR(Single Family Residential)建築プロジェクトを設計する際にライセンスアーキテクトが使用するために特別に作成されました。より商業的なCSI(50以上の部門の商業仕様)とは異なり、ArCHspecは、より認識しやすい16の従来の部門に加えて、部門0(スコープと入札フォーム)と部門17(低電圧)を利用します。多くの建築家は、これまで住宅設計の仕様を提供していませんでした。これが、ArCHspecが作成された理由の1つです。つまり、住宅用のよりコンパクトな仕様で業界の空白を埋めるためです。

連邦政府およびその機関の調達管理する米国の連邦調達規則では、図面と仕様のコピーを建設現場で入手できるようにしておく必要があると規定されています。[18]

エジプトの建設仕様

エジプトの仕様は、契約書の一部を形成します。住宅建築国立研究センター(HBRC)は、建設仕様とコードの開発を担当しています。HBRCは、土工、左官工事などの建築活動をカバーする15冊以上の本を出版しています。

英国の建設仕様

英国の仕様は、建物の建設に付随し、それを管理する契約書の一部です。それらは、建築家、建築技術者、構造エンジニア、造園家、建築サービスエンジニアなど建設専門によって作成ますこれらは、以前のプロジェクト仕様、社内ドキュメント、またはNational Building Specification(NBS)などのマスター仕様から作成されます。National Building Specificationは、英国王立建築家協会が所有しています。(RIBA)彼らの商業グループRIBA Enterprises(RIBAe)を通じて。NBSマスター仕様は、幅広く包括的なコンテンツを提供し、指定者がプロジェクトのニーズに合わせてコンテンツをカスタマイズし、最新の状態に保つことを可能にするソフトウェア機能を使用して配信されます。

英国のプロジェクト仕様タイプは、規範的およびパフォーマンスの2つの主要なカテゴリに分類されます。規範的な仕様は、必要なものの一般的または独自の説明を使用して要件を定義しますが、パフォーマンス仕様は、コンポーネントの特性ではなく結果に焦点を合わせます。

仕様はビルディングインフォメーションモデリングの不可欠な部分であり、非幾何学的要件をカバーしています。

食品および医薬品の仕様

医薬品は通常、さまざまな薬局方によってテストおよび認定されます。現在の既存の製薬基準には次のものが含まれます。

上記の基準でカバーされていない医薬品がある場合は、他の国からの薬局方の追加ソース、工業仕様、または次のよう な標準化された処方集によって評価できます。

同様のアプローチが食品製造でも採用されており、コーデックス委員会が最高水準にランク付けされ、次に地域および国の基準がランク付けされています。[19]

ISOによる食品および医薬品基準の適用範囲は現在あまり実りがなく、地域または国の憲法の厳しい制限のために緊急の議題としてまだ提案されていません。[20] [21]

仕様およびその他の標準は、上記のように外部から課すことができますが、内部の製造および品質仕様も課すことができます。これらは、食品医薬品だけでなく、加工機械品質プロセス、包装ロジスティクスコールドチェーン)などにも存在し、ISO14134およびISO15609に例示されています。[22] [23]

仕様の明示的なステートメントの逆は、仕様外の観測を処理するためのプロセスです。米国食品医薬品局は、まさにこの点に対処する拘束力のない勧告を発表しました。[24]

現在のところ、食品や食品に関する情報や規制の多くは、自動化された情報処理、保管、送信の方法や技術を適用することを困難にする形で残っています。

食品および食品に関する情報を処理、保存、および転送できるデータシステムは、効果的かつ効率的に動作するために、食品および食品に関するデータの表現に関する正式な仕様を必要とします。

特にデジタルコンピューティングシステムで使用するために必要かつ十分な明快さと精度を備えた食品および医薬品データの正式な仕様の開発が、一部の政府機関および標準化団体から浮上し始めています。米国食品医薬品局は、「構造化製品」の仕様を公開しています。製薬会社が医薬品ラベルの情報を電子的に提出するために使用を義務付けなければならない「製品ラベル」。[25]最近、ISOは、ISO 11238の発行を通じて、食品および医薬品の基準と規制物質に関するデータの正式な仕様の分野である程度の進歩を遂げました。 [26]

情報技術

仕様が必要

多くのコンテキスト、特にソフトウェアでは、相互運用性の問題など、互換性の欠如によるエラーを回避するための仕様が必要です。

たとえば、2つのアプリケーションがUnicodeデータを共有しているが、異なる正規形を使用したり、それらを誤って使用したり、互換性のない方法で、または相互運用性仕様の最小セットを共有しない場合、エラーやデータ損失が発生する可能性があります。たとえば、Mac OS Xには、分解された文字のみを優先または必要とする多くのコンポーネントがあります(したがって、UTF-8でエンコードされた分解のみのUnicodeは「UTF8-MAC」とも呼ばれます)。ある特定の例では、合成文字を処理するOS Xエラーと、sambaファイルおよびプリンター共有ソフトウェア(ファイル名をコピーするときに分解された文字を合成文字に置き換える)の組み合わせにより、混乱を招き、データを破壊する相互運用性の問題が発生しました。[27] [28]

アプリケーションは、入力コードポイントを保持し、それらをアプリケーションの内部使用に適した通常の形式のみに正規化することで、このようなエラーを回避できます。

このようなエラーは、バイナリ比較の前に両方の文字列を正規化するアルゴリズムを使用して回避することもできます。

ただし、さまざまなファイルシステムドライバ、オペレーティングシステム、ネットワークプロトコル、および数千のソフトウェアパッケージ間で相互運用可能であることが望まれるソフトウェア間の共通仕様の最小セットがないため、ファイル名エンコーディングの非互換性によるエラーが常に存在していました。

正式仕様

正式な仕様は、実装の開発に使用できるソフトウェアまたはハードウェアの数学的記述ですそれは、システムがそれをどのように行うべきかではなく、(必然的に)システムがをすべきかを説明します。このような仕様が与えられた場合、フォーマル検証手法を使用して、候補システムの設計がその仕様に関して正しいことを実証することができます。これには、実際に設計を実装するために大規模な投資が行われる前に、誤った候補システム設計を修正できるという利点があります。別のアプローチは、証明可能な正しい改良を使用することです仕様を設計に変換し、最終的には実際の実装に変換する手順。これは、構造によって正しいものです。

アーキテクチャ仕様

(ハードウェア、ソフトウェア、またはエンタープライズ)システム開発では、アーキテクチャ仕様は、そのシステムの構造動作、およびその他のビューを説明する一連のドキュメントです。

プログラム仕様

プログラム仕様は、コンピュータプログラムが実行することが期待されること定義です。非公式の場合は、開発者の観点からユーザーマニュアルと見なすことができ、公式場合は、数学またはプログラムの用語で定義された明確な意味を持ちます。実際には、多くの成功した仕様は、すでに十分に開発されたアプリケーションを理解して微調整するために作成されていますが、セーフティクリティカルな ソフトウェアシステムは、アプリケーション開発の前に慎重に指定されることがよくあります。仕様は、安定性を維持する必要がある外部インターフェイスにとって最も重要です。

機能仕様

ソフトウェア開発では機能仕様(また、機能仕様または仕様または機能仕様文書(FSD) )は、コンピュータープログラムまたはより大規模なソフトウェアシステムの動作を説明する一連の文書です。ドキュメントには通常、ソフトウェアシステムに提供できるさまざまな入力と、システムがそれらの入力にどのように応答するかが記載されています。

Webサービス仕様

Webサービスの仕様は、多くの場合、品質管理システムの傘下にあります[29]

ドキュメント仕様

これらのタイプのドキュメントは、特定のドキュメントの作成方法を定義します。これには、ドキュメントの命名、バージョン、レイアウト、参照、構造化、外観、言語、著作権、階層、形式などのシステムが含まれますが、これらに限定されません。[30] [31]非常に多くの場合、この種の仕様は指定されたテンプレートによって補完されます。[32] [33] [34]

も参照してください

参考文献

  1. ^ a b 規格の形式とスタイル、ASTMブルーブック (PDF)ASTMインターナショナル2012 2013年1月5日取得
  2. ^ GaryBlakeおよびRobertW。Bly The Elements of Technical Writing、pg。108.ニューヨークマクミラン出版社、1993。ISBN0020130856 
  3. ^ BS 7373-1:2001
  4. ^ BS 7373-2:2001
  5. ^ BS 7373-3:2005
  6. ^ スタウト、ピーター。「機器仕様書作成ガイド」(PDF)2019年4月28日にオリジナル(PDF)からアーカイブされました2009年6月15日取得
  7. ^ 「仕様書作成ガイド」(pdf)ロサンゼルス統一学区2010年11月8日取得
  8. ^ 「防衛およびプログラム-独自の仕様フォーマットおよびコンテンツ」(pdf)米国国防総省。2008年4月2日2010年9月16日取得
  9. ^ 国際標準化機構「01.080.01:一般的なグラフィックシンボル」2009年6月10日取得
  10. ^ 国際標準化機構「ISO10209」2009年6月10日取得
  11. ^ ab 国際標準化機構「ISO832:1994情報とドキュメント–書誌の説明と参照–書誌用語の略語の規則」2009年6月10日取得
  12. ^ ISO 690
  13. ^ 国際標準化機構「ISO12615:2004用語集の書誌参照とソース識別子」2009年6月10日取得
  14. ^ タイトル21CFRパート11
  15. ^ a bIEEE_ 「IEEEXploreのPDF仕様」(PDF)2009年3月27日取得
  16. ^ 建設仕様研究所
  17. ^ CSC-dcc.ca / Certification
  18. ^ 連邦調達規則、 52.236-21建設の仕様と図面、 2021年1月6日にアクセス
  19. ^ Food Standards Australia NewZealand「オーストラリアニュージーランド食品安全局コード」2008年4月5日にオリジナルからアーカイブされました2008年4月6日取得
  20. ^ 食品表示規制
  21. ^ ハザード分析と重要管理点
  22. ^ 国際標準化機構「ISO14134:2006光学および光学機器–天体望遠鏡の仕様」2009年3月27日取得
  23. ^ 国際標準化機構「ISO15609:2004金属材料の溶接条件の仕様と認定-溶接条件の仕様」2009年3月27日取得
  24. ^ 薬物評価および研究センター(2006年10月)。業界向けガイダンス:医薬品製造の仕様外(OOS)テスト結果の調査(PDF)食品医薬品局2009年5月20日取得
  25. ^ 米国食品医薬品局「構造化製品ラベルのリソース」食品医薬品局2011年8月29日取得
  26. ^ 国際標準化機構「ISO / DIS11238 –健康情報学–医薬品の識別–物質に関する規制された情報の一意の識別と交換のためのデータ要素と構造」2011年8月29日取得
  27. ^ Sourceforge.net
  28. ^ Forums.macosxhints.com
  29. ^ ステファノビッチ、ミラディン; マティエビッチ、ミラノ; エリッチ、ミラノ; Simic、Visnja; etal。(2009)。「品質システム文書に基づくWebサービスの設計と仕様の方法」。情報システムのフロンティア11(1):75–86。土井10.1007 / s10796-008-9143-yS2CID3194809_ 
  30. ^ 生物多様性情報基準。「TDWG標準ドキュメント仕様」2009年6月14日取得
  31. ^ 人間が使用する医薬品の登録に関する技術要件の調和に関する国際会議「ICHM2EWG-電子共通技術文書仕様」(PDF)2007年5月8日にオリジナル(PDF)からアーカイブされました2009年6月14日取得
  32. ^ デラニー、デクラン; スティーブンブラウン。「ソフトウェア工学における学生プロジェクトのドキュメントテンプレート」(PDF)2009年3月6日にオリジナル(PDF)からアーカイブされました2009年6月14日取得
  33. ^ 「レーザー安全標準操作手順」(PDF)2010年6月27日にオリジナル(PDF)からアーカイブされました2009年6月14日取得
  34. ^ トレド大学「BSL2封じ込めのためのサンプル標準操作手順要件」(PDF)2009年6月14日取得

さらに読む