사양(기술표준)

Specification (technical standard)
「사양」은 여기서 리다이렉트 됩니다.다른 용도는 규격(동음이의)을 참조하십시오.

사양은 종종 재료, 디자인, 제품 또는 [1]서비스에 의해 충족되어야 하는 문서화된 요구 사항을 말합니다.사양은 기술 표준의 한 종류인 경우가 많습니다.

기술 사양 또는 엔지니어링 사양(스펙)에는 다양한 유형이 있으며, 이 용어는 기술 컨텍스트에 따라 다르게 사용됩니다.이들은 종종 특정 문서 및/또는 문서 내의 특정 정보를 참조합니다.명세서는 '명시적 또는 상세하게 기술한다' 또는 '구체적으로 기술한다'로 폭넓게 정의된다.

요건사양이란 주어진 재료, 설계, 제품, 서비스 [1]등에 의해 충족되어야 하는 문서화된 요건 또는 문서화된 요건 세트이다.많은 분야에서 엔지니어링 설계 및 제품 개발 프로세스의 공통적인 초기 부분입니다.

기능사양서는 요건사양의 일종으로 기능블록도를 [citation needed]나타낼 수 있다.

설계사양 또는 제품사양은 설계솔루션 또는 최종제작솔루션 중 하나를 참조하여 요건사양 솔루션의 특징을 기술합니다.제조/생산을 안내하기 위해 자주 사용됩니다.데이터 시트(또는 사양 시트)와 관련하여 규격이라는 용어를 사용하는 경우가 있는데, 이는 혼동될 수 있습니다.데이터 시트는 제품 또는 제품의 기술적 특성을 기술하며, 사람들이 제품을 선택하거나 사용하는 데 도움을 주기 위해 제조업체에서 발행하는 경우가 많습니다.데이터 시트는 제작 방법을 알려주는 기술 사양이 아닙니다.

"인 서비스" 또는 "유지관리" 사양은 마모 및 유지관리(구성 변경)의 영향을 포함하여 수년간 작동한 후 시스템 또는 물체의 상태를 지정합니다.

사양은 공공부문과 민간부문 모두에서 다양한 종류의 조직에 의해 개발될 수 있는 기술표준의 일종입니다.예를 들면, 법인, 컨소시엄(소규모 법인 그룹), 무역 협회(산업 전체의 기업 그룹), 국가 정부(각종 공공기관, 규제 기관, 국가 연구소 포함), 전문 협회(사회), 목적별 표준 등이 있다.ISO와 같은 조직 또는 벤더 중립이 개발한 일반 요구사항.어떤 조직이 다른 조직의 표준을 참조(참조, 호출, 인용)하는 것은 일반적입니다.자발적 기준은 정부 또는 사업 계약에 의해 채택될 경우 의무화될 수 있습니다.

사용하다

엔지니어링, 제조 및 비즈니스에서는 재료, 제품 또는 서비스의 공급업체, 구매자 및 사용자가 모든 [2]요구사항을 이해하고 동의하는 것이 중요합니다.

명세서는 계약서나 조달서류에 의해 자주 참조되는 표준 또는 (단수에서 자주 사용되기는 하지만) 일련의 요건에 대해 합의된 표준을 참조할 수 있다.어느 경우든 특정 요건에 대해 필요한 상세 정보를 제공합니다.

규격 표준은 정부 기관, 표준 기관(SAE, AWS, NIST, ASTM, ISO / IEC, CEN / CEN / CENELEC, DoD 등), 무역 협회, 기업 등에 의해 제공될 수 있다.사양에는 다음 영국 표준이 적용됩니다.

  • BS 7373-1:2001 규격 작성 지침
  • BS 7373-2:2001 제품 사양.제품 사양의 기준을 식별하고 제품 적합성을 선언하는 방법
  • BS 7373-3:2005, 제품 사양.서비스 오퍼링을 특정하기 위한 기준 식별

설계/제품 사양은 제품이 모든 맥락에서 정확하거나 유용한 것을 반드시 입증하는 것은 아닙니다.품목이 사양에 적합한지 확인되거나 사양 번호가 찍힐 수 있습니다.이것만으로 해당 품목이 검증되지 않은 다른 용도에 적합함을 나타내는 것은 아닙니다.아이템(엔지니어, 노동조합 등)을 사용하거나 아이템(건물코드, 정부, 산업 등)을 지정하는 사람은 사용 가능한 사양의 선택을 검토하고 올바른 사양을 지정하며 컴플라이언스를 적용하고 아이템을 올바르게 사용할 책임이 있습니다.적합성 검증이 필요합니다.

지침 및 내용

경우에 따라서는,[6][7][8] 적절한 사양의 기입과 포맷에 도움이 되는 가이드나 표준 조작 순서를 이용할 수 있습니다.사양에는 다음이 포함됩니다.

  • 명세서의 제목, 번호, 식별자 등
  • 최종 개정 및 개정 지정일
  • 문서의 저작권, 소유권 및[9] 출처를 나타내는 로고 또는 상표
  • 문서가 긴 경우 목차(TOC)
  • 사양, 업데이트 및 편차에 대한 질문을 담당하는 개인, 사무실 또는 기관.
  • 규격의 중요성, 범위 또는 중요성 및 용도.
  • 명세서의[10][11] 의미를 명확히 하기 위한 용어, 정의 및 약어
  • 지정된 모든 특성을 측정하는 테스트 방법
  • 재료요건: 물리, 기계, 전기, 화학 등목표와 허용 범위.
  • 퍼포먼스 테스트 요건을 포함한 수용 테스트.목표와 허용 범위.
  • 도면, 사진 또는 기술 일러스트
  • 세공
  • 인증이 필요합니다.
  • 안전상의 고려사항 및 요건
  • 보안에 관한 고려사항 및 요건(해당하는 경우: 정부기관 또는 군사기관, 정보기술회사 등에 제공되는 제품 및 서비스 등)
  • 환경에 관한 고려사항 및 요건
  • 품질관리요건, 합격샘플링, 검사, 합격기준, 또는 품질관리시스템이 가동되고 있는 경우에는 사양의 범위에 포함되는 제품/서비스 제공에 관련된 비즈니스 프로세스를 규제하기 위해 규정된 품질보증요건.
  • 명세서의 실시를 담당하는 개인, 사무소 또는 기관(명세서에 기재된 요건에 대한 적합성을 검증하기 위한 감사의 준비 및 실행을 포함할 수 있음)
  • 완료 및 배송 조건(종종 표준화된 ICOTERMS를 참조).
  • 거부, 재검사, 재가열, 시정조치에 대한 규정
  • 문서의[11][12][13] 트레이서빌리티와 명료성을 실현하기 위해 필요한 내용 중 지시사항과 인용문헌
  • 필요한 [14]경우 승인 서명. 경우에 따라 특정 절차가 승인/매수 이벤트에 적용됩니다.
  • 내부 회람이[15] 필요한 경우 기록 변경 시 기록 작성, 개정 및 완료 시간 순으로 요약
  • 부록 및 부록: 세부사항 확장, 설명 추가 또는 옵션 [15]제공.

시공사양서

북미지역 건설사양서

북미 사양은 건축 및 인프라 프로젝트 건설에 수반되는 계약 문서의 일부를 형성합니다.사양은 코드 인용과 공개된 표준을 사용하여 건축 자재의 품질과 성능을 기술하고 도면 또는 건축 정보 모델(BIM)은 자재의 양과 위치를 기술합니다.이름과 번호에 대한 안내 마스터 문서는 MasterFormat의 최신 버전입니다.이 문서는 2개의 전문 조직이 공동으로 후원하는 합의 문서입니다.건설사양 캐나다 및 건설사양연구소는 미국에 근거지를 두고 있으며 2년마다 갱신된다.

텍스트 문서와 도면 사이에 불일치가 있는 경우, 「사양서」가 도면을 우선한다고 생각하는 경향이 있지만, 오너와 청부업자 사이의 계약에는 실제 의도가 명시되어야 한다.표준 AIA(American Institute of Architects)와 EJCDC(Engineering Joint Contract Documents Committee)는 도면과 사양이 상호 보완적이며 완전한 시설에 필요한 정보를 제공한다고 명시하고 있습니다.해군시설사령부(NAVFAC)와 같은 많은 공공기관은 사양이 도면보다 우선한다고 밝히고 있다.이는 분쟁 시 배심원(또는 중재자)이 도면보다 단어를 해석하기 쉽다는 생각에 기초한다.

건설 시방서의 표준 일람은 50개의 부문, 즉 건설과 관련된 작업 유형 및 작업 결과의 광범위한 범주로 분류된다.중분류는 섹션으로 세분되며, 각 섹션은 건설 작업의 특정 재료 유형(콘크리트) 또는 작업 생산물(강철 문)을 다룬다.특정 재료는 작업 결과에 따라 여러 위치에서 피복할 수 있다. 스테인리스강(예를 들어 중분류 07)은 플래싱에 사용되는 시트재로서, 금속은 중분류 05에 포함되는 난간 등의 완제품의 일부이거나 건물 하드웨어의 구성품이 될 수 있다.08. 당초의 사양 부문 리스트는, 시공의 시간 순서에 근거해 외부에서 내부로 작업하고 있었습니다.이 논리는, 새로운 재료나 시스템이 건설 공정에 침투하고 있기 때문에, 아직 어느 정도 추종되고 있습니다.

각 섹션은 "일반", "제품" 및 "실행"의 세 부분으로 구분됩니다.MasterFormat 및 단면[16] 형식 시스템은 주거, 상업, 토목 및 산업 건축에 성공적으로 적용될 수 있습니다.많은 건축가는 대부분의 주택용 프로젝트에는 다소 방대한 상업적인 사양 스타일이 너무 길기 때문에 자체 사양의 약어를 작성하거나 ArCHspec(주택용 프로젝트용으로 특별히 작성)을 사용합니다.마스터 사양 시스템은 Arcom, Visispec, BSD 및 Spect와 같은 여러 벤더가 제공합니다.이러한 시스템은 미국 전역의 언어를 표준화하기 위해 작성되었으며, 일반적으로 구독 기반입니다.

사양은 "성능 기반"으로, 지정자는 완성된 작업에 의해 달성되어야 하는 성능을 기술하는 텍스트로 제한하거나, 지정자가 품목에 적용되는 조립 표준 등의 특정 기준을 기술하는 "규범적" 또는 지정자가 특정 제품을 나타내는 "독자적" 중 하나입니다.벤더, 심지어 각 작업범위에서 허용되는 계약자까지 포함시킬 수 있습니다.또한 사양은 특정 제품 목록과 함께 "닫힘"되거나 청부업자에 의한 대체가 가능하도록 "열림"될 수 있습니다.대부분의 건축사양서는 퍼포먼스 베이스와 독자 사양의 조합으로 허용 가능한 제조원 및 제품에 이름을 붙이는 동시에 충족해야 할 특정 표준 및 설계 기준을 명시하고 있습니다.

북미 사양은 일반적으로 작업에 대한 광범위한 설명으로 제한되지만, 유럽 사양과 토목공사는 재료 명세서 같은 건식 벽 면적(평방 미터)을 포함한 실제 작업량을 포함할 수 있습니다.이러한 유형의 사양은 사양 작성자와 수량 조사원이 공동으로 작업한 것입니다.이러한 접근 방식은 북미에서는 이례적으로 각 입찰자가 도면과 사양에 따라 수량 조사를 실시합니다.유럽 대륙의 많은 국가에서는 미국에서 "사양서"로 기술될 수 있는 컨텐츠가 건축 법규 또는 시 법규에 포함되어 있습니다.미국의 민간 및 인프라 작업에는 수행해야 할 작업의 수량 내역이 포함되는 경우가 많습니다.

사양서는 보통 건축가의 사무소에서 발행하지만, 사양서 작성 자체는 건축가와 다양한 엔지니어 또는 전문 사양서 작성자가 담당합니다.사양서의 작성은, 「Certified Construction Specifier(CCS)」등의 전문 자격증을 건설사양연구소에서, 등록사양서 작성자(RSW)[17]가 캐나다 건설사양서를 통해서 입수할 수 있는, 구별되는 전문 업종이 많은 경우입니다.사양 작성자는 설계사, 엔지니어 또는 건설 관리 회사의 직원 또는 하청업체입니다.사양서 작성자는 건설업자가 제안서를 작성하기 위한 견적에 자사 제품을 포함시킬 수 있도록 향후 건설 프로젝트에 제품을 명기하려는 건축 자재 제조업체와 자주 만난다.

2015년 2월 주거건축 개선을 목적으로 하는 미국 건축전문협회 ArCH(Architects Creating Homes)에서 ArCHSPEC이 라이브로 가동되었습니다.ArCHSpec은 SFR(Single Family Residential) 아키텍처 프로젝트를 설계하면서 라이센스 있는 건축가가 사용하도록 특별히 제작되었습니다.보다 상업적인 CSI(50 이상의 사업부 사양)와 달리 ArCHSpec은 보다 알기 쉬운 16개의 기존 사업부 및 Division 0(Scope & Bid Forms) 및 Division 17(저전압)을 사용합니다.지금까지 많은 건축가가 주거용 설계의 사양을 제공하지 않았기 때문에 ArCHSpec이 탄생한 이유 중 하나로, 보다 콤팩트한 주거용 사양으로 업계의 공백을 메우기 위해서입니다.주거용에 적합한 보다 짧은 양식 사양 문서도 Arcom을 통해 입수할 수 있으며, 2004년부터 미국과 캐나다에서 채택된 50개 중분류 형식을 따른다.16개의 분할 형식은 더 이상 표준으로 간주되지 않으며 CSI 또는 CSC, 서브스크립션 마스터 사양 서비스, 데이터 저장소, 제품 리드 시스템 및 대부분의 정부 기관에서 지원되지 않습니다.

연방정부와 그 기관의 조달을 관리하는 미국 연방취득규정은 도면과 [18]규격의 사본을 건설현장에서 사용할 수 있도록 유지해야 한다고 규정하고 있다.

이집트의 건축사양서

이집트의 사양서는 계약서류의 일부를 구성합니다.HBRC(Housing and Building National Research Center)는 건축 사양 및 법규 개발을 담당합니다.HBRC는 토공, 회반죽 등의 건축 활동을 다룬 15권 이상의 책을 출판했습니다.

영국의 건축사양서

영국에서의 사양은 건물 건설에 수반되는 계약서류의 일부입니다.건축사, 건축기술자, 구조기술자, 조경설계사, 건축서비스기술자 등의 건축전문가가 준비한다.이것들은 이전의 프로젝트 사양, 사내 문서 또는 NBS(National Building Specification)와 같은 마스터 사양에서 작성됩니다.National Building Specification은 RIBA(Royal Institute of British Architects)가 상업 그룹인 RIBA Enterprise(RIBAe)를 통해 소유하고 있습니다.NBS 마스터 사양은 광범위하고 포괄적이며 지정자가 프로젝트의 요구에 맞게 콘텐츠를 맞춤화하고 최신 상태로 유지할 수 있는 소프트웨어 기능을 사용하여 제공됩니다.

영국의 프로젝트 사양 유형은 규범적인 것과 성과적인 것의 두 가지 주요 범주로 분류됩니다.규범적 규격은 필요한 것에 대한 일반적 또는 독점적 설명을 사용하여 요구사항을 정의하는 반면, 성능 규격은 구성요소의 특성보다는 결과에 초점을 맞춘다.

사양은 빌딩 정보 모델링의 필수 요소이며 비기하학적 요구 사항을 포함합니다.

식품 및 의약품 사양

의약품은 보통 다양한 약국에서 테스트하고 인증할 수 있습니다.현행 의약품 규격은 다음과 같습니다.

만약 어떤 제약제품이 위의 표준에서 다루어지지 않는다면, 그것은 다른 나라로부터의 추가 약품 공급원, 산업 사양 또는 다음과 같은 표준화된 조제법으로부터 평가될 수 있다.

식품 제조업에서도 유사한 접근방식이 채택되고 있으며, 그 중 Codex Alimentarius가 가장 높은 기준을 차지하고 있으며, 지역 [19]및 국가 기준이 그 뒤를 잇고 있습니다.

ISO에 의한 식품 및 의약품 규격의 적용 범위는 지역 또는 국가 [20][21]헌법의 엄격한 제한 때문에 현재 덜 생산적이고 아직 시급한 의제로 상정되지 않았다.

사양 및 기타 표준은 위에서 설명한 바와 같이 외부에서 부과될 수 있지만 내부 제조 및 품질 사양도 부과할 수 있습니다.식품이나 의약품뿐만 아니라 가공기계, 품질공정, 포장, 물류(콜드체인) 등에도 존재하며 ISO 14134 및 ISO 15609에 [22][23]의해 예시된다.

명세서의 반대는 규격에 맞지 않는 관측치를 처리하는 과정입니다.미국 식품의약국은 이 점을 [24]다루는 구속력 없는 권고안을 발표했다.

현재 식품 및 식품에 관한 정보 및 규제의 대부분은 자동화된 정보처리, 저장 및 전송 방법 및 기술을 적용하기 어려운 형태로 남아 있다.

식품 및 식품에 대한 정보를 처리, 저장 및 전송할 수 있는 데이터 시스템은 효과적이고 효율적으로 운영하기 위해 식품 및 식품에 대한 데이터 표현에 대한 공식적인 규격이 필요하다.

특히 디지털 컴퓨팅 시스템에서 사용하기 위해 필요하고 충분한 명확성과 정확성을 갖춘 식품 및 의약품 데이터의 공식 사양 개발이 일부 정부 기관 및 표준 조직으로부터 나타나기 시작했다: 미국 식품의약국은 "구조화된 제품"의 사양을 발표했다.의약품 [25]제조사가 의무적으로 의약품 라벨의 정보를 전자적으로 제출하기 위해 사용해야 하는 "bel"입니다.최근 ISO는 ISO 11238의 [26]발표를 통해 식품 및 의약품 표준 및 규제 물질에 대한 데이터에 대한 공식 사양 분야에서 어느 정도 진전을 이루었다.

정보기술

사양 요구

많은 컨텍스트, 특히 소프트웨어에서는 호환성 결여로 인한 오류를 피하기 위해 예를 들어 상호운용성 문제 등이 필요합니다.

예를 들어, 두 응용 프로그램이 Unicode 데이터를 공유하지만 서로 다른 일반 형식을 사용하거나, 호환되지 않는 방식으로 또는 최소 상호 운용성 사양 세트를 공유하지 않으면 오류 및 데이터 손실이 발생할 수 있습니다.예를 들어, Mac OS X에는 분해된 문자만을 선호하거나 필요로 하는 많은 구성 요소가 있습니다(따라서 UTF-8로 인코딩된 분해된 유니코드만 "UTF8-MAC"라고도 합니다).예를 들어 구성 문자를 처리하는 OS X 오류와 Samba 파일 및 프린터 공유 소프트웨어(파일 이름을 복사할 때 분해된 문자를 구성 문자로 대체함)의 조합으로 인해 상호 운용성이 [27][28]혼란스럽고 데이터가 파괴되는 문제가 발생했습니다.

애플리케이션은 입력 코드 포인트를 보존하고, 내부 사용을 위해서 애플리케이션이 선호하는 일반 형식으로만 정규화함으로써 이러한 오류를 방지할 수 있습니다.

이러한 에러는 바이너리 비교 전에 양쪽 스트링을 정규화하는 알고리즘에서도 회피할 수 있습니다.

그러나 다양한 파일 시스템 드라이버, 운영 체제, 네트워크 프로토콜 및 수천 개의 소프트웨어 패키지 간에 상호 운용이 가능한 소프트웨어 간에 공통 사양이 최소한 부족하기 때문에 파일 이름 인코딩 비호환성으로 인한 오류는 항상 존재했습니다.

형식 사양

주요 기사:형식 사양

정식 사양은 구현 개발에 사용할 수 있는 소프트웨어 또는 하드웨어의 수학적인 설명입니다.시스템의 동작에 대해 설명합니다(필요에 따라서는), 시스템의 동작에 대해서는 설명하지 않습니다.이러한 사양에 따라 후보 시스템 설계가 해당 사양에 대해 올바르다는 것을 증명하기 위해 공식 검증 기법을 사용할 수 있다.이는 잘못된 후보 시스템 설계를 실제 구현에 큰 투자를 하기 전에 수정할 수 있다는 장점이 있습니다.대안적 접근법은 입증 가능한 정확한 개선 단계를 사용하여 사양을 설계로 변환하고 궁극적으로는 실제 구현으로 변환하는 것입니다.

아키텍처 사양

(하드웨어, 소프트웨어 또는 엔터프라이즈) 시스템 개발에서 아키텍처 사양은 해당 시스템의 구조, 동작 및 더 많은 뷰를 설명하는 문서 세트입니다.

프로그램 사양

프로그램 사양은 컴퓨터 프로그램이 무엇을 할 것으로 예상되는지에 대한 정의입니다.개발자의 관점에서 사용자 매뉴얼로 간주할 수 있는 비공식적인 방법일 수도 있고, 수학적인 방법이나 프로그래밍적인 용어로 정의된 명확한 의미를 갖는 형식일 수도 있습니다.실제로 많은 성공적인 사양은 이미 잘 개발된 애플리케이션을 이해하고 미세 조정하기 위해 작성되지만, 안전성에 중요한 소프트웨어 시스템은 애플리케이션 개발 전에 주의 깊게 지정되는 경우가 많습니다.사양은 안정성을 유지할 필요가 있는 외부 인터페이스에 가장 중요합니다.

기능사양서

주요 기사:기능사양서

소프트웨어 개발에서 기능사양서(기능사양서, 사양서 또는 기능사양서(FSD))는 컴퓨터 프로그램 또는 더 큰 소프트웨어 시스템의 동작을 설명하는 문서 세트입니다.일반적으로 이 문서에서는 소프트웨어 시스템에 제공할 수 있는 다양한 입력과 시스템이 이러한 입력에 어떻게 반응하는지에 대해 설명합니다.

웹 서비스 사양

상세 정보:웹 서비스 사양 목록

웹 서비스 사양은 종종 품질 관리 시스템의 [29]산하에 있습니다.

문서 사양

이러한 유형의 문서는 문서 명명, 버전, 레이아웃, 참조, 구조, 외관, 언어, 저작권, 계층 또는 형식 [30][31]등의 시스템을 포함하지만 이에 한정되지 않는 특정 문서를 작성하는 방법을 정의합니다.대부분의 경우 이러한 사양은 지정된 [32][33][34]템플릿으로 보완됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Form and Style of Standards, ASTM Blue Book (PDF). ASTM International. 2012. Retrieved 5 January 2013.
  2. ^ 게리 블레이크와 로버트 W. 블라이, 기술문헌의 요소, 108페이지.뉴욕: 맥밀런 출판사, 1993.ISBN 0020130856
  3. ^ BS 7373-1:2001
  4. ^ BS 7373-2:2001
  5. ^ BS 7373-3: 2005
  6. ^ Stout, Peter. "Equipment Specification Writing Guide" (PDF). Archived from the original (PDF) on 28 April 2019. Retrieved 15 June 2009.
  7. ^ "A Guide to Writing Specifications" (pdf). Los Angeles Unified School District. Retrieved 8 November 2010.
  8. ^ "Defense and Program-Unique Specifications Format and Content" (pdf). US Department of Defense. 2 April 2008. Retrieved 16 September 2010.
  9. ^ International Organization for Standardization. "01.080.01: Graphical symbols in general". Retrieved 10 June 2009.
  10. ^ International Organization for Standardization. "ISO 10209". Retrieved 10 June 2009.
  11. ^ a b International Organization for Standardization. "ISO 832:1994 Information and documentation – Bibliographic description and references – Rules for the abbreviation of bibliographic terms". Retrieved 10 June 2009.
  12. ^ ISO 690
  13. ^ International Organization for Standardization. "ISO 12615:2004 Bibliographic references and source identifiers for terminology work". Retrieved 10 June 2009.
  14. ^ 제목 21 CFR Part 11
  15. ^ a b IEEE. "PDF Specification for IEEE Xplore" (PDF). Retrieved 27 March 2009.
  16. ^ 건축사양연구소
  17. ^ CSC-dcc.ca/Certification
  18. ^ Federal Acquisition Regulation, 52.236-21 건설 관련 사양 및 도면, 2021년 1월 6일 액세스
  19. ^ Food Standards Australia New Zealand. "Australia New Zealand Food Standards Code". Archived from the original on 5 April 2008. Retrieved 6 April 2008.
  20. ^ 식품표시규정
  21. ^ 위험 분석 및 중요 제어 지점
  22. ^ International Organization for Standardization. "ISO 14134:2006 Optics and optical instruments – Specifications for astronomical telescopes". Retrieved 27 March 2009.
  23. ^ International Organization for Standardization. "ISO 15609:2004 Specification and qualification of welding procedures for metallic materials -- Welding procedure specification". Retrieved 27 March 2009.
  24. ^ Center for Drug Evaluation and Research (October 2006). Guidance for Industry:Investigating Out-of-Specification (OOS) Test Results for Pharmaceutical Production (PDF). Food and Drug Administration. Retrieved 20 May 2009.
  25. ^ United States Food and Drug Administration. "Structured Product Labeling Resources". Food and Drug Administration. Retrieved 29 August 2011.
  26. ^ International Organization for Standardization. "ISO/DIS 11238 – Health Informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated information on substances". Retrieved 29 August 2011.
  27. ^ 소스 포지그물
  28. ^ Forums.macosxhints.com
  29. ^ Stefanovic, Miladin; Matijević, Milan; Erić, Milan; Simic, Visnja; et al. (2009). "Method of design and specification of web services based on quality system documentation". Information Systems Frontiers. 11 (1): 75–86. doi:10.1007/s10796-008-9143-y. S2CID 3194809.
  30. ^ Biodiversity Information Standards. "TDWG Standards Documentation Specification". Retrieved 14 June 2009.
  31. ^ International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use. "ICH M2 EWG - Electronic Common Technical Document Specification" (PDF). Archived from the original (PDF) on 8 May 2007. Retrieved 14 June 2009.
  32. ^ Delaney, Declan; Stephen Brown. "Document Templates for Student Projects in Software Engineering" (PDF). Archived from the original (PDF) on 6 March 2009. Retrieved 14 June 2009.
  33. ^ "Laser Safety Standard Operating Procedure" (PDF). Archived from the original (PDF) on 27 June 2010. Retrieved 14 June 2009.
  34. ^ The University of Toledo. "Sample Standard Operating Procedure Requirements for BSL2 Containment" (PDF). Retrieved 14 June 2009.

추가 정보