시스템 규격서

민성기  시스템체계공학원장(ise@seinstitute.co.kr)


시스템이 어떤 요구능력을 얼마나 잘 수행할 것인가를 제시하는 공식적인 절차가 시스템 성능 규격서(SPS)이다. SPS는 사용자 계약 및 기술적 대표자로서의 획득자와 시스템 개발자 사이에 공식적인 기술 계약 요구사항을 설정해 준다.
대부분 사람은 규격서란 프로그램 초기에 시스템을 설계하기 위한 문서로 알고 있다. 이는 부분적으로는 맞다. 규격서란 시스템 개발 단계에서 의사결정의 기초 자료로 사용된다.

· 이는 의도하고 있는 운용요구를 충족시키는 물리적 시스템, 제품, 또는 서비스를 제공하기 위하여 사용자의 솔루션 영역을 능력(예를 들면, 기능과 성능) 텍스트와 그래픽으로 전환, 구속, 의사를 전달하기 위한 수단으로 사용된다. 
· 이는 최종 시스템 수락과 납품을 위해 미리 예고해 주기 위한 기술적 적합성을 평가하고 검증하는 기준을 설정하고 이에 대한 의사 결정하는 기준을 제공해 준다.

규격서 개발은 다중 레벨 시스템 분석 프로세스 지원을 요구하고 있다. 이러한 분석은 구속된 솔루션 영역의 능력을 시스템 전반을 구성하고 있는 하부시스템, 제품, 아셈부리로 분할된다.
이 글은 이와 같은 시스템, 제품, 또는 서비스에 요구되는 다중 레벨, 통합 구조의 규격서를 설정하는 규격서 실무를 소개한다. 우리는 다양한 유형의 규격서를 제시하는데, 무슨 내용을 담고 있는지, 상호간에 어떻게 연계되어 있는지를 소개한다. 여기에는 참조모델로 사용될 수 있는 일반적인 규격서 내용을 포함하고 있다.

1. 얻고자 하는 내용

· 규격서란 무엇인가
· 좋은 규격서란 무엇인가
· 초기 시스템 개념으로부터 시스템 성능 규격서(SPS)까지 규격서 진화과정을 설명해 보라
· 규격서 유형에는 어떠한 것이 있는가
· 이러한 각 규격서 형태는 시스템 개발자에게 어떻게 사용되는가
· 규격서 트리란 무엇인가
· 규격서 트리는 어떻게 구성되는가
· 대부분의 규격서 표준 포맷은 무엇인가

2. 주요 용어정의

· 세부 규격(Detail Specification) : 설계 요구사항을 나타내는 규격을 말한다. 예를 들면, 사용될 자재, 요구사항 달성방법, 품목조립 또는 제작방법을 들 수 있다. 성능과 세부 요구사항을 포함하고 있는 규격을 세부 규격으로 생각해도 좋다.
· 개발 규격(Development Specification) : 성능 규격, 인터페이스 및 기타 기술 요구사항을 나타내는 시스템 레벨 하위 품목에 적용되는 문서를 말한다. 이는 설계, 서비스에 필요한 엔지니어링과 평가를 위해 충분한 세항을 포함한다.
· 완화(Deviation) : 특정 소요량이나 특정 기간에 대한 규격, 도면 또는 기타 문서의 성능, 또는 설계 요구사항으로부터 발생된 차이, 한 품목 제작 이전에 주어진 문서화된 기준을 말한다. (출처 : DSMC, 국방획득 약어 및 용어 참조)
· 인터페이스 규격(Interface Specification) : 기계적인 요구특성과 시스템 요소 사이의 논리적 연결을 세부적으로 나타낸 인터페이스 요구사항으로 도출된 규격을 말한다. 여기에는 사용 포맷, 데이터 구조, 인터페이스로 나타난 전기 시그널을 포함하고 있다. (근거 : Kossiakoff and Sweet, 시스템엔지니어링, p. 449)   
· 성능 규격(Performance Specification) : 일치 여부 검증 기준에 대한 결과 요구사항으로 나타낸 요구 규격을 말한다. 그러나 요구결과 달성방법은 포함하지 않는다. 성능 규격은 품목에 대한 기능 요구사항과 운용환경 및 인터페이스와 상호운용 특성을 정의한다. (근거 : MIL-STD-961D, 3.29항, p.7)
소스 또는 근거 요구사항(Source or Originating Requirements) : 시스템, 제품 또는 서비스 획득 기초로 사용한 공적 요구사항으로 제시된 요구사항 세트를 말한다. 일반적으로 공식적인 사업제안서(RFP)에 포함된 목표기술서(SOO) 또는 시스템요구서(SRD)가 소스 또는 근거 요구사항으로 간주된다.
· 규격서(Specification) : 솔루션 영역에서의 품목, 자재, 프로세스 또는 서비스에 대한 필수 요구사항, 요구사항을 적용하는 데 필요한 데이터 및 공식적 수락 기준을 충족하기 위한 검증방법을 기술한 문서를 말한다.
· 규격서 트리(Specification Tree) : 고객 요구로부터 이를 충족하기 위해 기술된 시스템 솔루션 세트에 이르기까지 전환되는 품목개발, 제작 및 통합을 통제하는 데 필요한 모든 제반 규격서의 계층구조를 말한다. (출처 : MIL-STD-499B 초안)
· 테일러링(Tailoring) : 선정된 규격서, 표준서, 연관 문서에 대한 개별 요구사항(분야, 장 또는 절)으로 운용 필요성과 비용 간 적정 균형 달성 여부를 확인하기 위한 특정 시스템 및 장비 획득과 해당 요구사항의 수정을 위해 가장 적합한 범위를 제시하고 평가하는 프로세스를 말한다. (출처 : MIL-STD-961D, 3.40항 P.8)
· 면제(Waiver) : 생산 또는 검사요청 후, 주어진 요구사항과 다른 형상품목이나 기타 지정품목을 수용하기 위한 문서화된 절차이다. 그러나 승인된 방법에 의한 상태나 재보수 이후로 적합성을 판단해서는 안 된다. (출처 : DSMC, 국방획득 용어 및 약어집 참조)

규격서 정의

어떠한 형태의 요구사항을 개발하든지 다음 사항을 충분히 이해하는 것이 필요하다.
· 규격이란 무엇인가?
· 규격 작성 목적이 무엇인가?
· 규격은 특정 목적을 어떻게 설정토록 하는가?
이 장의 주요 용어 정의에서 제시된 규격서 정의를 분석해 보면 다음 세 가지로 요약할 수 있다. 이를 더 상세히 기술해 보자.
‘필수적인 품목, 자제, 프로세스, 또는 서비스에 대한 요구사항’을 해석하면, 규격이란 물리적으로 도출된 품목뿐만 아니라, 서비스와 다중 레벨 컴포넌트에 대하여 컴포넌트를 구성하고 있는 자재, 그리고 이러한 자재를 실 컴포넌트로 전환하는 데 필요한 절차적 프로세스에 대하여 작성된 문서이다.
‘요구사항 적용을 위해 필요한 데이터’를 해석하면, 시스템 개발은 기타 목표기술서(SOO), 설계 기준, 규격서, 표준서와 일치하고 요구된 항목을 충족함에 제약되어 있다.
‘공식적인 수락을 위해 특정 기준을 충족하기 위한 검증방법’을 해석하면, 규격이란 획득자와 시스템 개발자 간에 각 요구사항이 주어진 성능과 연관된 성능레벨을 만족하게 달성하는 물리적 체계/속성을 나타내기 위해 요구된 검증방법을 공식적으로 동의된 기술사항을 말한다.
하나의 요구사항 달성방법을 검증하는 일은 공식적으로 획득자 수락을 위해 점진적으로 기준을 충족해 나가도 좋다는 사실을 주목하라. 계약사항에서는 야전 설치 및 검토, 야전 배치 및 데모, 운용시험 및 평가(OT&E), 현저한 결함, 하자, 에러 사항 해결 등과 같은 기준을 요구하고 있다. 시스템 성능규격(SPS)이란 하나의 계약사항으로서 납품체계 수락과 후속 계약 종료의 일부분에 해당된다.
이제 규격에 대해 정의된 내용을 기초로 규격 작성 목적을 살펴보자.

1. 규격서 작성 목적

규격작성 목적은 이를 문서화하여 상호 의사전달을 수행함에 있다.
· 한 품목(시스템, 제품, 하부체계 등)의 요구된 필수 운용능력이 무엇인가?
· 그 능력을 어떻게 잘 달성할 수 있는가?
· 언제 그 능력을 수행해야 하는가?
· 누구에 의해 수행되는가?
· 어떠한 운용환경(예를 들면, 수용 가능한 입력사항과 환경조건에 대한 범주와 범위) 상태인가?
· 어떠한 수용 결과 또는 산출물(예를 들면, 거동, 제품, 부산물, 용역)을 기대하고 있는가?
· 기대하지 않고 있는 결과나 산출물은 무엇이며, 어떻게 하면 이를 줄이거나 배제할 수 있는가?

2. 규격서와 계약업무기술서(CSOWs)

사람들은 흔히 계약 업무기술서로부터 규격서를 도출함에 있어서 문제점을 지니고 있다. 이러한 근거로 활동, 업무, 규격서로 작성된 업무 산출물과 같은 전형적인 CSOW 언어를 볼 수 있다. 따라서 이러한 두 가지 문서 형태의 차이점은 무엇인가?
CSOW는 시스템 개발자, 하부계약자, 또는 벤더가 계약 조항과 조건(T&Cs)을 이행하기 위해 납품될 업무 산출물과 수행해야 할 업무 활동을 나타내는 획득자 계약문서를 말한다. 한편, 규격서란 납품 시스템, 제품 또는 서비스로 요구되는 능력, 특성 및 이와 연관된 성능레벨을 기술한 것이다.   

3. 요구사항과 규격서 요구사항

어떤 사람은 요구사항이라고 하고 어떤 사람은 규격서 요구사항이라고 한다. 그러면 그 차이는 무엇인가? 이는 그 상황에 따라 다르다. 전체적인 문서체계로서의 계약이란 규격서 요구사항 이외에 일정 요구사항, 일치 요구사항, 비용 요구사항을 포함한 요구사항을 말한다. 쉽게 말해 사람들은 규격서 요구사항이라고 부르는 대신 간단하게 ‘요구사항’이라고 부른다. 다중 레벨 규격서와 각 레벨에서의 규격서를 지닌 시스템에 대하여 일반적으로 사용되고 있는 ‘요구사항’이란 이는 참조 프레임에서의 규격서인지, 그 상황에 따라 달리 해석된다.
 
규격서의 필요성

일반적으로 우리는 규격서가 왜 필요한지에 대한 질문을 하게 된다. 만일 당신이 무엇이 필요한지를 사람들에게 말하지 않았다고 하면, 그들이 납품하는 품목에 대해 어떠한 불평도 할 수가 없다는 일반적인 상식을 먼저 생각해 보면 된다. 우리가 “무엇을 요청”했는지가 아니라 문서로 작성된 것을 납품한다고 말하고 있다. 다른 말로 하면, “문서로 작성되지 않으면, 결코 책임을 질 수가 없다”는 것과 같다.
어떠한 경우이든지 만일 기술적 분쟁이 발생되면, 법적인 해결을 할 수밖에 없다. 법적 조치를 하려면 다음과 같은 요소를 준비해야 한다.
· 계약, 회의록, 공식답변서, 대화록 등에 당신은 무엇을 기록하는가?
· 당신은 누구와 의논했는가?
· 어디서 그 말을 했는가?
· 언제 그와 같이 말했는가?
· 당신이 동의한 것을 어떻게 문서화 했는가?
이러한 마찰을 피하는 가장 좋은 길은 계약 이전에 명확히 하는 것이 바람직하다. 이는 획득자와 개발자 상호간에 상호 이해와 충족을 위해 기술적 동의를 하는 절차이다. 기술적 관점에서 이러한 절차의 문서가 체계 성능규격서(SPS)이다.
이러한 분쟁은 비단 획득자와 체계 개발자/용역 제공자-하위 계약자-벤더 인터페이스 상호간의 조직상의 문제만이 아니다. 사실상 동일한 쟁점 사항이 시스템 개발부서 내에서 시스템, 제품, 하부체계, 아셈부리, 하부 아셈부리 및 부품 계층레벨에서도 발생된다. 따라서 체계 성능규격서로부터 하위레벨로 요구사항을 분할 및 할당할 때에도 SE 설계팀에서 유사한 기술 동의절차를 밟아야 한다. 이를 통해 각 할당된 문제점 영역이 차 하위레벨 솔루션영역으로 규격서에 의해 분할된다.
따라서 왜 우리가 규격서가 필요한지를 잘 표현하려면 다음 사항을 유의토록 하라.
획득자, 사용자, 시스템 개발자 이해관계자 상호간에 보다 쉽고 간결하게 이해할 수 있도록 제시하라.
납품해야 할 제품에 대하여 꼭 필요한 형상과 특성을 표현하라.
최종 시스템, 제품 또는 서비스 수락 단계에서 잠재된 마찰을 줄이기 위하여 ‘오픈’ 또는 향후 제시와 같은 요소를 피하라.

규격서 작성요령

사람들은 가끔 좋은 규격서를 어떻게 하면 작성할 수 있는지 물어본다. 좋은 규격이란 상대적인 것이다. 한 사람에게 좋다고 하면 다른 사람에게는 나쁜 경우가 될 수 있다. 아마 더 좋은 질문은 ‘잘 정의된 규격서란 무엇인가 하는 것이 좋다는 의미이다.’
시스템 엔지니어들은 이러한 질문에 대하여 ‘함께 일하기가 편리하다’, ‘우리는 본 업무를 수행하면서 바른길을 통해 너무 많은 변경을 하지 않았다’, ‘획득자 수락단계에서 어떠한 문제도 발생되지 않았다’ 등으로 표현한다. 그러나 몇 가지 외적인 특성을 기준으로 잘 정의된 규격서 작성 모델을 제시하고 있다. 두 가지 관점에서 잘 작성된 규격서를 생각해 보도록 하자.

1. 일반적인 규격서 속성

잘 작성된 규격서란 이에 필요한 여러 일반적 속성을 다루어야 한다.
· 표준 원칙 : 잘 작성된 규격서는 산업 실무에서 인정되고 있는 표준 원칙에 따라야 한다. 모든 기술 성능 항목이 표현되어 있는지를 확인할 수 있도록 이해관계자 엔지니어링 토픽의 스펙트럼을 포함해야 한다. 이를 위해 이 장에서 좀 더 상세히 설명토록 하겠다.
· 소유 책임 : 잘 작성된 규격서는 납품 시스템, 제품, 또는 서비스의 규격 요구사항, 유지보수, 검증 및 최종 수락에 대한 책임을 지고 있는 부서나 개인을 분명하게 지정해 주어야 한다.
· 기준 통제와 유지 : 규격서는 그 내용에서 모든 이해관계자가 상호 동의할 수 있는 관리적 단계 또는 통제점에 대한 기준을 제시해야 한다.
· 참조 : 시스템 설계 및 개발 문서화 실무와 기술검토 실무를 참조한 규격서 검토, 승인, 배포에 대한 이벤트 중심의 통제점에 관한 더 많은 정보를 참조한다. 한 번 기준이 설정되고 나면, 규격서는 이해관계자 검토 절차(예를 들면, 형상통제)를 통해 업데이트되고 검증된다. 이는 이해관계자 요구사항의 현황을 반영해 주는 절차이다.
· 사용자 요구 추적 : 잘 작성된 규격서는 사용자의 기술된 솔루션 영역에 대한 추적이 가능해야 하며 조직임무와 목표에 대한 문제점 영역으로부터 도출된 운용 요구사항을 확인할 수 있어야 한다.
· 이해하기 쉽게 단순한 용어와 언어로 작성 : 잘 작성된 규격서는 이해하기 쉽고 잘 정의된 용어를 사용한 언어로 작성되어야 한다. 일반적으로 여러 연관된 사람들이 기술된 요구사항을 독립적으로 읽고 있으며, 기술성능 요구사항을 동일하게 이해하고 해석할 수 있어야 한다.
· 적용 가능성 : 잘 작성된 규격서는 획득자, 개발자 또는 용역 제공자로 하여금 수용 가능한 기술, 비용, 일정 및 지원으로 실제로 달성 가능한 기술, 숙련도, 프로세스, 도구 및 자원 범위 내에서 적용할 수 있어야 한다.

규격서 형태

시스템 엔지니어가 시스템, 제품, 또는 서비스 개발에 요구되는 품목, 자재, 프로세스를 기술할 때 이를 어떻게 달성할 수 있는가? 이러한 업무연관 제품은 다음 사항을 초점에 두고 계층 구조적 규격에 따라 작성된다.
· 다중 레벨 시스템 품목에 대한 요구사항을 정의
· 이러한 품목 개발을 지원하기 위한 자재와 프로세스에 대한 규격서를 지원
· 계층 구조적 규격서는 규격서 트리 형태로 문서화 된다. 규격서 트리 내에서 계층 구조를 이해하기 위하여 구조상에 나타난 규격서 트리를 먼저 설정할 필요가 있다. 규격서를 분류해 보면 다음과 같다.
· 일반 또는 성능 규격
· 세부 또는 품목 개발 규격
· 설계 또는 제작 규격
· 자재 규격
· 프로세스 규격
· 조달 규격
· 재고 품목 규격
· 설비 인터페이스 규격
그림 1에서 이러한 일차 규격 형태를 볼 수 있다.



규격서의 품목 개발로 연계

이상 다양한 규격서 형태를 연결하기 위해 그림 2와 같은 사례를 생각해 보자.



시스템 성능규격(SPS)으로 문서화된 시스템 요구사항은 하나 또는 더 많은 품목에 대하여 제품, 하부체계, 아셈부리와 같이 하나 또는 보다 많은 레벨로 분할되고 할당된다. 이러한 품목 요구사항은 각각 개발 또는 조달 규격으로 연결된다. 이는 ‘규정된 형상’으로 문서화된다.
다중 레벨과 회귀적 설계 활동이 고도로 반복적으로 진화됨에 따라 시스템 엔지니어는 개발될 물리적 부품의 특성과 속성을 반영하기 위하여 하나 또는 그 이상의 설계 또는 제작 규격을 개발한다. 설계 시, 하나 또는 그 이상의 프로세스 규격과 자재 규격이 품목의 조달, 제작, 코딩, 아셈부리, 검사, 시험을 위해 개발된다. 설정된 규격의 수집 세트는 그 품목을 어떻게 개발하거나 조달할 것인지에 대한 방법을 문서화한 ‘설계된’ 개발형상을 나타낸다.
각 품목이나 형상품목(CI)에 대하여 생성된 규격 세트는 내부나 외부 하부계약자 또는 벤더에 사용될 설비처럼 개발을 위한 기초로 사용된다. 형상품목이 시스템 검증을 포함한 시스템 통합, 시험 및 평가(SITE) 단계를 종료할 때, ‘검증된’ 형상은 제품 기준으로 문서화되고 CI의 제품규격으로 제시된다.

규격서 트리

요구사항의 다중 레벨 분할과 할당은 규격서 트리 형태의 수직적 구조의 시스템 속성을 논리적으로 연결하는 계층 구조적 형식으로 나타낸다. 그림 3의 오른편이 규격서 트리의 한 사례를 보여주고 있다.



1. 규격서 트리 관리와 통제

규격서 트리는 전형적으로 프로그램 기술 이사나 시스템엔지니어링 및 통합팀(SEIT)에 의해 관리되고 통제된다. SEIT는 현 규격서 기준의 변경을 관리하기 위하여 형상통제위원회(CCB)를 통해 통제한다.

2. 규격서 트리의 CWBS 및 시스템 아키텍처와의 연계

사람들은 규격서 트리가 시스템 아키텍처 및 계약 업무분해구조(CWBS)와 무관하게 독자적으로 만들어진다고 생각하고 있다. 이는 심각한 문제이다. 규격서 트리와 CWBS는 일차적으로 시스템 아키텍처 구조를 반영함으로써 자연적으로 연결된다. 이러한 관점에서 그림 3의 그래프를 참조토록 하라.

규격서 포함 내용

대부분 엔지니어를 위한 학습절차는 규격서 내용에서 시작된다. 그러나 대부분 엔지니어는 규격서 내용이 어디에서 비롯되었는지를 이해하지 못하고 있다. 이러한 문제를 해결하기 위하여 규격서에 포함된 세부 내용과 규격서에 무엇을 담고 있는지를 알아보자. 규격서에 대한 형식, 양식, 기능을 보여주는 주요 요소와 시스템 속성을 그래프로 살펴보자. 그림 4에서 이러한 목적을 볼 수 있다.
시스템이나 실체에 관한 내용은 일반적으로 속성으로 사용된다는 사실을 기억하라. 정의에 의하면, 분야, 제품, 하부체계, 아셈부리, HWCI, CSCI가 시스템에 속한다. 따라서 여기서 논의되는 것은 모든 레벨에 적용된다.

1. 대상시스템(SOI)

규격서를 작성해야 할 시스템 속성은 그림 4에 나타나 있다.



시스템을 분석할 경우, 시스템 실체나 품목을 특성 짓는 여러 주요 속성이 있음을 알 수 있다. 이러한 속성을 살펴보면 다음과 같다. 1) 운용 특성, 2) 물리적 특성, 3) 모드 및 상태, 4) 인터페이스, 5) 성장 능력, 6) 제품 및 서비스, 7) 부산물, 8) 특성, 9) 품질 요소, 10) 문서화이다. 여기서 시도하고자 하는 내용은 실체에 대한 거동과 물리적 특성이다.
우리가 이러한 속성의 세트를 어떻게 수집하느냐는 질문이 생겨난다. 그 답은 이러한 속성을 제약하고 영향을 주는 다양한 외부 요소에 달려있다. 이러한 외부 요소를 살펴보자.

1. 시스템 요구사항을 도출하는 외부 요소

시스템 요구사항을 규약하는 절차는 실체의 솔루션을 제약하고 구속하는 외부 요소에 의해 도출된다.
· 운용요구(2) : 시스템 실체의 목적은 사용자 운용요구를 충족함에 있다. 따라서 규격서는 사용자 운용요구에 의해 도출되거나 추적 가능한 능력 요구사항과 성능레벨을 제시해야 한다. 
· 규격서, 표준서, 법적 제약사항(3) : 시스템 실체 설계는 시스템 인터페이스, 일솜씨, 자재를 포함한 기존의 규격서, 표준서, 법적 제약사항에 엄격하게 일치하도록 해야 한다.
· 주기 및 가정 사항(4) : 요구사항은 문장과 그래프로 나타나기 때문에 콘텍스트상에서 명백해야 한다. 요구사항을 잘 모르는 경우에 가정 사항을 제시한다. 부가적인 그래프 협약이 보다 명확하게 나타낼 수 있다. 따라서 규격서는 정의, 콘텍스트, 사용정보, 용어, 협약을 제시하기 위해 주기와 가정 사항을 포함해야 한다.
· 검증방법(5) : 시스템 실체의 주요 속성을 나타내는 요구사항은 시스템 설계자가 이해하기 쉬운 언어와 용어를 사용해야 한다. 문제는 물리적 실체가 요구사항과 어떻게 일치하는가를 어떻게 검증하고 확인하느냐 하는 것이다. 이러한 딜레마를 해결하기 위해 규격서는 실체 검증과 확인을 위한 요구사항을 구체화하는 부분을 포함하고 있다. (사용자 옵션)
· 시스템 엔지니어링 실무(6) : 성공적인 시스템 개발은 교훈과 엔지니어링 연습으로부터 도출된 실무가 위험을 최소화하기 위하여 일관되게 적용되어야 한다. 따라서 규격서는 납품대상 제품이 시스템 요구사항을 달성하기 위해 시스템 엔지니어링 실무를 포함해야 한다.
· 설계와 생산 제약사항(7) : 규격서는 무엇을 어떻게 시스템/실체로 잘 수행할 수 있느냐는 그 이상의 내용을 제시해야 한다. 시스템에 부과된 제약사항, 시스템 운용 및 능력에 연관된 개발 의사결정을 제시해야 한다. 이를 가리켜 설계와 생산 제약사항이라고 한다. 일반적으로 설계와 생산 제약사항은 크기, 중량, 색상, 질량 특성, 유지보수, 안전 한계, 인간 요소, 일 솜씨를 포함하고 있다.
· 보관, 포장, 운반(8) : 시스템을 납품할 때, 운용임무 지원이 가능하며 온전하게 능력을 구현할 수 있도록 주의가 요구된다. 보관, 포장, 운반 요구사항은 납품될 시스템/실체가 준비되고 포장되고 운송되는 방법을 제시함에 있다.
· 지원 시스템 요소 요구사항(9) : 임무시스템은 임무수행 전, 수행, 수행 후 유지 가능토록 요구하고 있다. 이는 치명적인 단계적 이벤트와 분야에서 지원시험장비(STE)를 사용해야 한다. 이는 기존의 설비와 지원 장비 사용을 요구하고 있다. 여기에는 일반 지원장비(CSE), 특정 지원장비(PSE) 또는 이러한 품목을 개발해야 할 필요성을 포함한다. 따라서 규격서는 지원시스템 요소 요구사항을 포함한다.
· 인력요소 요구사항(10) : 전형적으로 대부분 시스템은 ‘수동식’ 운용과 임무 수행 이전 및 이후에 시스템을 통제하기 위해 인력요소를 요구하고 있다. 부가적으로 사람-기계 절충을 통해 시스템 성능을 최적화한다. 이는 무슨 사항은 사람이, 무슨 사항은 기계가 가장 적합한지를 도출함으로써 가능하다. 따라서 규격서는 사람-시스템 통합을 성공적으로 수행하기 위하여 인력요소에 부과된 훈련과 교육 요구사항을 식별해야 한다.
· 운용환경조건(11) : 모든 실체는 성공적인 임무를 수행하기 위한 성능 수행레벨에서 기술된 운용환경에서의 임무를 수행할 수 있어야 한다. 따라서 규격서는 실체의 능력과 성능레벨을 도출하고 구속하는 운용환경조건을 정의해야 한다.
· 설계 성능기준(12) : 시스템 실체는 물리적 시스템 인터페이스와 성능을 시뮬레이션할 때, 성능 범위 내에서 운용하도록 요구된다. 이러한 일이 발생할 때, 규격서는 설계 기준으로 나타난 외부 성능 요구사항을 기술한다. 이러한 경우, 시스템 시뮬레이션 또는 시스템 인터페이스에 관한 설계기준 목록(DCL)을 참조문서로 작성된다.



일반적인 규격서 구조 형태

앞서 우리는 규격서 작성을 위해 표준 구조 형태를 마련할 필요가 있음을 제시한 바 있다. 표준 규격 형태는 전형적으로 다음 일곱 가지 분야로 나누어진다.
· 서문
· 제1장 개요
· 제2장 참조문서
· 제3장 요구사항
· 제4장 관련 규정
· 제5장 포장, 취급, 저장 및 수송
· 제6장 요구사항 추적
· 제7장 주기
이는 다음 규격서 개발 실무에서 좀 더 상세히 다루어진다. 항상 그래 왔듯이 성능규격 포맷 지침, 즉 계약자료 요구목록(CDRL)에 대하여 협의할 필요가 있다. 만일 지침이 없을 경우, 프로그램 기술책임자 또는 조직부서의 계약담당관과 상의해 보라.

규격서 개발방법-진화적 순서

규격서 개발과 순서를 보다 잘 이해하기 위하여 그림 5의 시스템 개발 프로세스 업무흐름 구조를 사용할 필요가 있다.
만일 우리가 시스템 개발 프로세스를 시간에 따라 일반화한다면, 그림 6과 같이 전반적인 규격서 구조가 어떻게 계약 성사 후, 시스템 검증시험(SVT)을 거쳐 진화해 가는지를 볼 수 있다.

지침 원칙

요약해서 우리는 규격서 접근방법에 관한 지침 원칙을 설정하는 기초를 논의해 왔다.
[원칙 1] 규격서란 시스템/실체가 무엇을 수행하기 위한 것인지 그리고 어떻게 잘 수행할 것인지를 제시한 것이다. CSOW는 시스템 개발자가 수행해야 할 업무와 납품해야 할 업무연관 제품을 보여주고 있다. 각 문서의 범주를 잘 이해하고 적용토록 하라.

요약

앞서 규격서 실무를 논의하면서 우리는 시스템 규격서를 생성함에 있어서 주요 도전사항, 쟁점사항, 및 방법을 살펴보았다. 기본개념의 마지막 부분에서 일반적인 규격서의 구조를 제시했다.
기본적인 규격서 이해에서 다음 시스템 요구사항의 이해로 넘어가기 전에 규격서로 문서화된 요구사항 형태를 살펴볼 수 있었다.
 
1. 일반적 예제

1) 개요에서 우리가 이해해야 할 질문사항에 대하여 다시 한 번 생각해 보아라.
2) 앞 장에서 논의했던 일반적인 시스템 또는 신규 시스템에 대하여 이 장에서 제시한 내용을 적용해 보아라. 만일 당신이 충분한 자원을 가진 획득자의 컨설턴트라고 한다면, 1)계약자료 요구목록(CDRL)으로 제시된 품목에 대하여 어떠한 형태의 규격서를 추천할 것인가? 그리고 이를 선택한 의사결정의 근거를 제시해 보라. 2)시스템 성능규격(SPS)에서의 획득자 시스템엔지니어링 산출물 관점에서의 간략한 규격서 토픽을 제시해 보라.

2. 조직 중심 예제

1) 당신 조직 내에서의 개발 규격에 대한 지침을 알아 보라.
· 계약 프로그램에 대하여 규격서와 관련하여 어떠한 지침을 요구하고 있는가?
· 규격서 개발 및 승인 시기에 무엇을 해야 하는지를 알아보라.
2) 당신 조직 내에서 수행하는 계약 프로그램을 하나 선정해 보라.
· 계약자료 요구목록(CDRL)으로 제시해야 할 규격서는 무엇인가?
· 체계 개발단계에서 프로그램 규격서 CDRL 산출물로서 무엇을 납품해야 하는가?
· 해당 프로그램은 규격서 트리를 가지고 있는가?
· 규격서 트리 구조를 다중 레벨 시스템 아키텍처와 비교해 보라. 잘 일치되고 있는가? 차이점은 무엇인가? 차이점에 대한 프로그램상에서 논리를 제시해 보라.
· 불필요하게 보이는 규격서는 어떠한 것이 있는가?
· 계약에서 요구되지 않은 프로그램 규격서로는 어떠한 것이 있는가?