규격서 개발

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


성능 및 개발 규격서는 획득자로 하여금 다음과 같은 업무를 수행하는 공식적인 메커니즘으로 사용된다.

· 시스템 또는 개체가 무슨 능력을 제공해야 하는지 요구하는 내용을 제시
· 그 능력이 얼마나 잘 수행되어야 하는지를 제시
· 시스템/개체가 수용해야 하는 외부 인터페이스를 식별
· 솔루션 세트에서 제약사항을 부과
· 시스템 개발자가 납품 및 수락 일치 여부를 미리 어떻게 할 것인지에 대한 판단 기준 설정

최상위 레벨에서 시스템 성능규격(SPS) 또는 목표기술서(SOO)는 사용자의 기술적인 대표로서 획득자와 시스템 개발자 상호간에 계약자의 기술적 합의를 설정한다. 이 글은 규격개발 실무를 소개하고 앞서 논의된 표준 지침을 더 많이 알아보는 데 있다.
규격서를 작성할 때, 대부분 엔지니어는 규격서 개발을 마치 이하의 사항을 시험해 보는 것처럼 접근하는 경향이 많다.

· 대상 시스템 식별
· 시스템 임무 정의
· 운용 모드와 상태 식별
· 시스템/개체가 수행해야 하는 기능
· 시스템 인터페이스 식별
· 중량 제한 사항
· 안전에 대한 특수 고려사항
· 시스템/개체가 설계되고 제작되는 방법에 관한 제약사항
· 교육훈련 사항

이 글에서는 규격서 개발을 위해 일반적으로 접근하는 방법을 알아보고 탐색해 본다. 또한, 규격 구조화의 기초를 제공하는 논리적 전략을 소개한다. 이러한 방법을 사용하면 조직에 가장 적합한 길을 모색할 수 있다.
또한, 규격서와 범주에 대한 생성 방법을 알아본 다음, 사용 가능한 규격서 생성 접근방법에 관한 사례를 알아보는 데 초점을 둔다. 더 나아가 규격개발을 위한 체크리스트와 규격 검토 단계로 마무리한다.

1. 얻고자 하는 내용

· 규격서 개발에서의 일반적인 접근방법은 무엇인가?
· 아키텍처 기반 규격서 개발 접근방법이란 무엇인가?
· 성능 기반 규격서 개발 접근방법이란 무엇인가?
· 특징 기반 규격서 개발 접근방법이란 무엇인가?
· 규격서 재사용 개발 접근방법이란 무엇인가?
· 규격서 개발에 대한 모델 기반 개발 접근방법은 무엇인가?
· 규격서 검토는 어떻게 수행하는가?

2. 주요 용어정의

· 아키텍처 기반 접근방법 : 구조분석 접근방법은 다음 사항을 포함한다. 1) 시스템 개념단계와 운용모드, 2) 시스템 능력과 성능 요구사항을 나타내는 구조로서 다중 레벨 논리적 아키텍처(예를 들면, 개체와 인터페이스)
성능 기반 접근방법 : 분석 시 시스템이나 개체를 박스로, 상태 기반의 입력, 출력, 거동능력과 반응 및 규격 요구· · 사항 개발에 대한 제약사항으로 나타내는 규격서 개발 접근방법
규격서 검토: 규격서의 완전성, 정확성, 확인 가능성, 검증 가능성, 생산성 및 리스크를 평가하기 위하여 이해관계자, 동료, 및 분야전문가(SME)에 의한 기술검토
· 재사용 기반 접근방법 : 신규 규격 작성 기준 사용 및 특정 애플리케이션으로 적용하기 위해 기존 규격서를 활용하는 접근방법으로 에러와 누락과 연관된 이 접근방법은 규격 작성자와 검토자의 경험 그리고 에러와 누락사항을 식별하고 수정하는 전문가에 절대적으로 의존한다.
· 특징 기반 접근방법 : 규격서 요구사항 개발을 위한 브레인스토밍 접근방법으로 이는 특징을 기반으로 한 현상에 힘입어 요구사항 계층구조에서의 누락사항과 검토자 경험에 많이 의존된다. 이는 누락사항을 발견하여 수정함에 적용된다.

‌규격서가 해야 할 사항을 이해

규격서란 소설가가 퓰리처상을 받기 위해 의도하는 것과는 다르다. 그러나 노벨상처럼 어긋난 토픽에 대한 지속성과 접근성을 가져오기 위해 통찰력을 요구하고 있다.
규격서 작성을 위한 길은 여러 가지가 있다. 일반적으로 가용한 규격서를 정교하게 하는 것보다 우리가 규격서에서 소통해야 할 내용이 무엇인지를 생각해 보자. 이를 통해 당신 조직에 가장 적합한 구조를 알아볼 수 있다.

1. 표준 템플릿

일반적인 문서작성방법처럼 모든 계약 프로그램에 대한 규격서의 표준화 지침, 테일러링, 그리고 적용하는 순서를 생각해 보자. 만일 이 중에 하나라도 없다면, 당신 조직에서 하나의 미디어를 설정해 보라. 만약 적용하고 있는 대부분의 규격서를 분석한다면, 다음 두 가지를 생각해 보자.
① 전문적인 경험을 많이 갖지 못한 사람들은 다른 조직에서 사용하고 있는 규격서를 참조하게 된다. 그런데 목차와 순서가 서로 다르고 체계화되지 않았는데도 조직에서 그 순서가 마음에 든다면, 실무자와 독자인 이해관계자에게는 불필요한 경우가 많다.
② 규격서 목차를 생성할 때 실무자에게 맞지 않는 학문적 관점에서 만들기가 쉽다. 당신은 1레벨 요구사항을 4레벨, 5레벨 또는 6레벨에서 나타나는 여러 레벨에서의 논리적 구조로 규격을 제시할 수가 있다. “그 시스템은 다음과 같은 능력을 수행해야 한다”와 같은 상위레벨 요구사항이 하위레벨 3.X.X.X.X에 나타난다고 생각해 보라. 대형 복합 시스템의 경우, 통상 4레벨에서 8레벨까지 세부적으로 나타나기 때문에 5레벨 요구사항이 첫 번째 요구사항에 나타나게 된다면 이를 참조하기 곤란할 뿐만 아니라 실용적이지 못하다. 경험적으로 주요 요구사항이 최소 3레벨에서 나타나는 것이 바람직하다.

2. 규격서 목차

규격서가 무엇을 나타내어야 하는지 알기 위해서 다음과 같은 구조적 지침을 생각해 보자. 이를 당신에게 적합하도록 재구성해도 좋다.

1.0 개요
2.0 참고문헌
3.0 요구사항
3.1 운용성능특성
3.1.1 시스템(레벨 1 시스템) 개체 정의
3.1.2 시스템 임무
3.1.3 운용단계
3.1.4 신뢰성
3.1.5 유지보수성
3.1.6 가용성
3.1.n (기타 연관사항)
3.2 시스템/개체 능력(레벨 1)
3.2.1 시스템 능력 아키텍처
3.2.2 단계 기반 능력 적용 매트릭스
3.2.3  3.2.n 항 (개별 능력)
3.3 시스템 인터페이스
3.3.1 외부 인터페이스(레벨 1)
3.3.2 내부 인터페이스(레벨 2)
3.4 설계 및 제작 제약사항
3.5 인력 및 교육훈련
3.6 운용 및 지원(O&S)
3.7 운송 가능성
3.8 기술문서
3.9 요구사항 우선순위 및 중요도
4.0 품질조항
4.1 검증 책임
4.2 검증방법
4.3 품질 적합성 검사
4.4 품질시험
5.0 포장
6.0 요구사항 추적
7.0 주기
7.1 용어 및 약어
7.2 정의
7.3 가정

[지침 #1] 일반적인 법칙으로 대부분 조직은 어떠한 형식이든 위와 같은 목차 구조를 지닌다. 이러한 관점을 넘어 규격서 개발은 조직이나 개발자가 선호하는 접근방법에 달려있다.

우리는 이제 조직과 개인이 규격서를 어떻게 개발하고 있는지를 알아보자.

‌규격서 개발 접근방법

규격서를 개발하면서 조직과 시스템 엔지니어는 여러 가지 접근방법을 사용하고 있다. 전형적인 접근방법은 이하와 같다.

· 특징 기반 접근방법
· 재사용 기반 접근방법
· 성능 기반 접근방법
· 모델 기반 접근방법

대부분 비공식적으로 시작되는 특징기반 접근방법을 먼저 알아보자.

1. 특징 기반 접근방법

특징 기반 규격서는 필수적으로 브레인스토밍을 통해 요구사항 목록을 정리한 것이다. 일반적으로 규격서 개발에 공식적 훈련이 부족한 사람들은 특징 기반 접근방법을 사용한다.
이러한 방법으로 작성된 규격서는 가끔 원하는 사항 중심으로 나열된다. 특징 기반 규격서가 표준 규격 목차를 사용한다 할지라도 이는 누락, 충돌 또는 중복된 요구사항이 많아 체계화가 되지 않는다.
1) 특징 기반 접근방법의 이점
특징 기반 접근방법은 개발자로 하여금 최소의 노력으로 요구사항 입력사항을 빨리 도출하고 수집할 수 있다. 규격서 개발자는 잠재 적용과 요구사항 영향을 분석하고 이해하는데에 매우 적은 시간을 투자한다. 시간이 제약되어 있거나 신규 시스템이 기존 시스템에서 수정을 매우 적게 하게 될 경우, 이 방법이 최소한 수락 가능한 방법이다. 모든 시스템은 다르고 케이스에 따라 서로 다르게 평가된다. 일정과 예산 제약을 충족하기 위하여 일반적인 과정을 생략하기 쉽다는 사실을 기억하도록 하라.
2) 특징 기반 접근방법의 단점
특정 기반 접근방법의 단점은 계층 구조적인 요구사항을 대충 작성함으로써 다음과 같은 결과를 초래한다.

· 산문체로 작성된 복합 요구사항
· 다른 요구사항과 충돌
· 다중의 중복 발생
· 재해석이 필요한 모호하고 애매한 요구사항 문장

이는 요구사항 규격 품질을 저하시키고 누락, 충돌 또는 중복된 요구사항과 같은 결함을 나타내게 된다.

2. 재사용 기반 접근방법

재사용 기반 접근방법은 기존 규격에서 간단하게 도출하거나 여러 규격을 짜깁기해서 통합하는 방법을 말한다. 이러한 방법에서의 기본 가정은 기존 규격이 하나의 참조 모델로 사용된다는 점이다. 이는 잠재적으로 큰 문제점을 가지고 있다. 시작점에서 사용하고자 하는 소스 규격의 품질이 나쁜 상태를 생각해 보라.
재사용 기법은 시간과 돈을 벌고 있다는 전제로 사용되고 있다. 개발자는 보다 더 많은 돈과 시간이 필요한 모델 기반 접근방법과 비교해 볼 때, 간과되고 부정확한 요구사항에 따른 규격서 결함으로 제품설계 수정이 더 많아져 결과적으로 실패의 원인이 된다.
규격서 재사용은 나름대로 좋다는 제품라인에서도 발생된다. 당신은 이를 조직에서 잘 정리된 알려진 개체로부터 작업하게 된다. 그러나 규격서 재사용은 관련이 없는 제품 도메인과 조직을 넘어 엄청난 리스크를 가져오게 된다.

[주기 #1] 재사용 기반 접근방법은 일반적으로 별도의 규격개발 훈련을 받지 않았다고 할지라도 새로운 엔지니어는 표준 절차로 받아들인다. 관리자는 한 엔지니어가 규격서를 개발하기를 원한다. 회의 일정이 잡히면 엔지니어는 기존 규격을 보유하고 있는 사람을 접촉한 다음 단순하게 업무 필요성을 충족시키려고 한다. 건설적으로 보자면 이 방법은 엔지니어가 적절한 방법을 모른 채 그냥 일시적으로 모면하는 길을 가게 된다는 것이다. 어떤 엔지니어는 일생동안 보다 적합한 방법을 알지 못한 채 지내고 있다. 불행하게도 대부분의 조직과 관리자가 이를 종용하고 있다는 사실이다. 지식이 부족할수록 적절한 교육훈련 제공에 실패를 가져오게 된다.

재사용 접근방법을 사용함에 있어서 리스크는 소스에 있거나 ‘모델’ 접근방법이 전혀 다른 시스템, 시스템 적용 또는 임무에 대하여 시도하려는 것과 비교된다. 모든 접근방법에서의 공통점은 상위 레벨에서의 목차와 순서이다. 그 결과로 규격서는 다음 두 가지 문제점을 지니고 있다.

① 부적합하거나 생략된 외부 규격서와 표준서 참조
② 적용되지 않는 요구사항 유지

그 요구사항의 목차가 동일하다 할지라도 신규 시스템의 적용을 위해 필요한 성능 레벨과 능력을 누락 또는 과도, 부족으로 제시하게 된다.

[지침 #2] 다음 성능 기준 및 모델 기준 접근방법이 규격서 개발에 더 좋은 방법을 제공해 준다. 우리는 나아가 모델 기준 접근방법이 시스템/개체 아키텍처에 관한 지식을 가정함으로써 아키텍처로 이를 제시하는 모델 기준 접근방법을 적용하게 된다.

3. 성능 기반 접근방법

성능기반 접근방법은 성능 영역 조건과 전환 항목으로 시스템/개체 능력 요구사항을 제시한다. 시스템/개체는 자동적으로 그림 1에서와 같이 입력과 출력을 가진 하나의 박스로 설명된다.



· 규격서 항목 3.0 요구사항에서 이하와 같은 시스템/개체를 식별한다.
· 사용자 레벨 0/계층 0 시스템 또는 외부 인터페이스와의 관계
· 시스템 임무, 단계, 모드/유스 케이스
· 수용 및 수용불가 입력사항
· 입력사항을 성능 기반 산출물로 전환하는 데 필요한 능력
· 수용 및 수용불가 출력사항-거동, 제품, 부산물, 용역
· 설계 및 제작 제약사항

성능규격서는 특별히 불확실한 시스템일수록 다양한 사업에 대한 규격서 개발로 접근하는 가장 중요한 문서이다. 설계 특성 요구사항을 피하기 위해 획득자는 시스템 개발자에게 계약 비용, 일정, 및 리스크 제약사항 범위 내에서 적절한 아키텍처 솔루션을 생성하기 위한 융통성을 제공해 준다. 획득자의 의도에 따라 성능 기준 규격서는 광범위한 시스템 개발자/하청 계약자의 구조분석과 선호 시스템 아키텍처를 선정하기 위한 요구사항 도출을 요구한다.
입증되지 않은 불확실한 시스템 대부분의 획득자는 요구사항이 잘 알려지지 않은 다중 획득 단계 전략의 초기 단계로서 성능 기반 규격서 접근방법을 선호하게 된다. 이 전략은 시스템 요구사항을 성숙해 가기 위해서 일련의 나선형식 개발방법을 적용한다. 다음과 같은 예제를 생각해 보자.

[예제 #1] 잘 알지 못하는 새로운 시스템을 개발하고자 하는 획득자가 있다고 하자. 고심 끝에 그 획득자는 다중 단계 획득전략을 모색해 보기로 했다. 획득전략의 1단계는 시험, 자료수집, 및 성능자료 분석을 위한 초기 시제개발, 시스템 아키텍처 선정 및 다음 2단계 시제 또는 시스템을 위한 산출물로서의 일련의 요구사항을 생성하기 위하여 성능 기반 규격으로 계약하는 절차이다. 최종 시스템 개발에 따른 리스크를 줄여나가는 나선형식 개발절차가 있다.

1단계 요구사항과 시스템 아키텍처가 하나 또는 둘 이상의 계약을 통해 성숙해감에 따라 이제 획득자는 다음 토픽으로서 모델 기반 구조분석 접근방법으로 넘어간다.

4. 모델 기반 구조분석 접근방법

모델 기반 접근방법은 그림 2에서와 같이 잘 정의된 시스템/개체 모델 기반 아키텍처 프레임 구조 내에 있는 요소들의 성능과 능력의 범주, 규격을 제시함에 초점을 두고 있다.
이 방법은 모델 기반 아키텍처 프레임 구조로 불리기도 한다. 시스템 레벨은 ‘박스’로 표현된다. 그러나 이 시스템은 상관된 개체 또는 능력 아키텍처로 분할된다. 각 시스템의 아키텍처 개체인 하부체계 또는 능력은 이하의 두 가지 방법으로 표현될 수 있다.

① 성능 기반 접근방법을 사용하는 성능 기반 개체
② 개체나 능력의 하위레벨 아키텍처로 분할

이 방법의 예제를 살펴보자.

[예제 #2] 자동차에 대한 시스템 성능규격을 개발한다고 하자. 3.1항은 성능 기반 접근방법으로 조립된 운용성능과 특성을 제시한다. 다음, 규격개발자가 아키텍처 요소에 근거한 능력을 3.2항에 나타낸다.

3.2 능력
3.2.1 자동차 프레임
3.2.2 보디
3.2.3 추진장치
3.2.4 연료장치
3.2.5 전기장치
3.2.6 냉각장치
3.2.7 조향장치
3.2.8 오락장치
3.2.9 저장장치 등

1) 모델기반 분석 접근방법 적용
규격개발팀이나 개발자는 그림 2에 나타난 하부체계 A에서 D까지로 구성된 시스템에 대한 분석적 아키텍처를 생성한다. 하부체계 A는 능력 A1에서 A4까지로 분할되고, 하부체계 B는 능력 B1과 B2로 구성된다. 그 팀은 다음과 같은 체계 상호간의 관계를 표현하는 아키텍처 모델을 형성한다.
 
· 시스템과 1부터 5까지 외부체계
· A부터 D까지 하부체계
· 각 하부체계 내에서 능력 A1-A4, B1-B2 등

[주기 #2] ‘아키텍처 모델’이라는 용어사용을 주목하라. 규격개발팀은 필수 요소로서 비공식 또는 공식적으로 통제되고 있는 시스템의 모델을 생성한다.
분석에 근거하여 규격개발자는 이하와 같이 규격서 3.2항 능력을 나타낸다.

3.2 시스템 능력
3.2.1 능력 A
3.2.1.1 능력 A1
3.2.1.2 능력 A2
3.2.1.3 능력 A3
3.2.1.4 능력 A4
3.2.2 능력 B
3.2.2.1 능력 B1
3.2.2.2 능력 B2
3.2.3 능력 C
3.2.3.1 능력 C1
3.2.3.2 능력 C2
3.2.3.3 능력 C3
3.2.4 능력 D
3.2.4.1 능력 D1
3.2.4.2 능력 D2
3.2.4.3 능력 D3
3.2.4.4 능력 D4

이 모델은 모든 시스템/개체 유스 케이스와 시나리오에 대한 사례를 수용하는 능력 형상을 나타낸다. 이는 어떠한 유스 케이스 또는 시나리오에 대하여 분석하는 성능 기반 산출물을 나타내기 위한 각 능력에 대한 입력사항으로부터 ‘스레드’를 추적할 수 있다.
이 모델을 사용하여 규격개발자는 시스템 규격서에 포함된 텍스트를 제공하기 위해 무슨 능력을 요구하고 있는지를 제시할 수 있다. 분석적 목적으로 규격서 특정 형상 솔루션을 편집하지 않고 적절한 그래픽 모델 요소에 규격 참조사항을 삽입해도 좋다. 각 능력은 산출물 기반 성능 요구사항에 대한 기반을 나타내는 다중 레벨 하위 능력으로 분할된다.
형상품목(CI)과 같은 시스템 개발자 부서 내에서 적용하기 위해 개발된 규격서일 경우, 문서에 그림 2를 포함해도 좋다.



그러나 하나 또는 둘 이상의 하부체계를 외부 벤더로부터 획득하려고 하면, 특정 솔루션을 편집하여 사용하는 것이 바람직하다.
향후, 만일 벤더가 그래픽에서 주요 능력을 간과할 경우, 누락된 능력을 보완하기 위하여 계약서를 수정하고 이에 따른 추가비용을 지급해야 한다. 여기서 벤더는 초기 추정에서 이를 간과함에 따라 다른 능력 비용을 회복할 기회를 가지도록 해야 한다. 부가적으로 만일 벤더가 그래픽으로 제시된 시스템을 개발하여 당신의 요구사항을 충족하지 못한다면, 벤더는 “우리는 당신이 개발하기로 계약된 시스템을 만들었다”고 주장할 것이다. 최소한 아키텍처 그래픽, 특별히 시스템/개체 아키텍처 그래픽처럼 그래픽을 규격서에 삽입할 때는 이를 조심해야 한다.
규격개발을 지원하기 위해 그림 2와 같이 분석적 아키텍처를 생성함에 따라 당신은 특정 솔루션을 반드시 제시하지 않아도 당신이 원하는 능력을 표현하는 수단으로 보완하는 것이 바람직하다. 만일 당신이 그 분석을 잘 수행하고 이를 능력 기반 요구사항으로 제시한다면, 통찰력을 가진 입찰자는 그 시스템의 그래픽을 ‘역설계’할 수 있어야 한다. 그 차이점은 ‘시스템 개발자에게 어떻게 그 시스템을 설계할 것인지를 제시하지 않고 있다’는 점이다.
2) 모델 기반 분석 접근방법 적용
모델 기반 규격서는 기체, 추진 장치, 및 조종실처럼 잘 알려진 아키텍처로 된 기존 시스템을 적용할 때 적합하다. 그러나 규격서 개발자가 일차적인 아키텍처 컴포넌트를 제시할 때, 두 개의 기존 컴포넌트를 하나로 복합하는 것처럼 새로운 기술과 방법을 적용해야 하는 신규 및 창의적인 아키텍처에 대한 잠재적인 영향은 제한된다. 
부가적으로 하부체계 요구사항은 하부체계 인터페이스 설계를 무의식적으로 제한하는 리스크를 지니고 있다. 그 결과로 비용과 일정 영향이 발생하게 된다. 단순하게 보면 아키텍처 컴포넌트 능력을 성능 기반 개체로 말할 수 있다. 다음 예제를 생각해 보자.

[예제 #3] 일반적으로 민항기 기장은 조종사, 부조종사, 항법장치로 구성되어 있다. 그리고 기존 패러다임으로서 대부분 항공기는 세 사람이 조종하고 있다. 그러나 기술의 발달로 항법장치를 사용해 항해사를 줄임으로써 운용비용을 절감할 수 있게 되었다. 이와 같이 항법 기능을 조종사와 부조종사에게 수행토록 하는 새로운 패러다임을 구상함으로써 기장이 두 기능을 함께 수행할 수 있게 항법 시스템을 설계하도록 했다.

위의 예제처럼 세 사람의 조종사가 요구되는 모델 기반 규격과, 단순히 세 가지 기능 역할을 식별하고 시스템 개발자로 하여금 이를 물리적으로 적용할 수 있도록 하는 성능 기반 규격을 상호 비교하게 된다.

[지침 #4] 여기서 우리는 규격서 개발 시, 보다 편리한 일반적인 접근방법 소개하도록 한다. 다음 토픽은 규격서 생성 방법을 알아보기로 한다.

규격서 개발 패러다임

대부분 사람은 규격서 개발자가 작가가 혼자서 작품을 쓰는 것처럼 규격서를 쓴다고 생각한다. 그들은 그 어떠한 분석기법이나 문서에 포함된 성능 레벨과 능력 도출방법을 사용하지 않는다. 바로 이것이 계약단계에서 계약자와 시스템 개발자 상호간에 “잘 못 시작하는 것을 피하라”는 이유를 설명해 주는 패러다임이다.
규격개발은 의사결정 사유를 문서화토록 요구하는 다중레벨, 시스템 분석, 개념 설계에 대한 노력을 말한다. 어느 조직과 시스템 엔지니어는 “우리는 이와 같이 노력한다. 만일 어느 사람이 장차 숫자를 제시해야 할 사항을 TBD로 남겨 놓고 규격서를 작성한다고 하면, 우리는 엔빌롭 분석을 하거나 실험실에서 시뮬레이션한 다음 그 숫자를 제시하여 문제를 해결했다”고 말한다. 이것은 우리가 찾고자 하는 정답이 아니다.
우리가 생각해야 할 점은 우리가 규격을 개발할 때, 무슨 아키텍처와 거동분석을 수행했느냐와 능력 기반 요구사항에 관한 의사결정 근거 기준이 무엇이었는지를 알아야 한다. 따라서 다음과 같은 내용을 어떻게 했는지를 알아야 한다.

· 누락, 잘못된 위치, 충돌, 또는 중복된 규격 요구사항을 회피
· 하위 레벨 규격으로 요구사항 할당 지원

이에 대한 답은 그림 3에 나타난 SE 프로세스 모델을 적용함에 있다.



이러한 프로세스를 알아보도록 하자.

1. SE 프로세스 모델

· 일반적으로 시스템 엔지니어링 및 통합팀(SEIT)이 다음과 같이 적용한다.
· 시스템 레벨 SE 프로세스 모델을 적용하고 SPS를 분석한다.
· SE 프로세스 모델의 운용, 거동 및 물리적 도메인 솔루션을 생성한다.

도메인 솔루션을 생성하는 동안에 SEIT는 제품 레벨 개발규격으로 할당하는 요구사항을 지원할 데이터를 획득하기 위해 의사결정지원을 요청한다. 이와 같은 반복적인 사이클로 그림 3에서와 같이 개발 또는 통합 제품팀(IPTs)이 SE 프로세스 모델을 적용하여 하위 레벨까지 진행된다.
이제 각 레벨에서 SE 프로세스 모델이 규격서 개발로 연계되는지를 살펴보도록 하자.

2. SE 프로세스 모델 규격서 개발 적용

우리는 앞서 논의되었던 모델 기반 접근방법을 적용할 수 있다. 그림 4는 그림 2에서 제시된 시스템의 규격개발 전략 적용방법을 보여주고 있다.



어떠한 규격일지라도 SEIT, IPT 및 기타 연관팀은 목표기술서(SOOs), 시스템 요구서(SRD), SPS, 개발규격과 같은 다중 레벨 사용자 요구사항을 분석한다. 문제점 및 솔루션 영역, 유스 케이스, 시나리오, 유사한 사항을 포함한 분석을 통하여 연관팀은 시스템/개체 I/O 모델 능력(2)을 식별한다. 주어진 능력에서 아키텍처 대안을 형성하고 미리 준비된 선정 기준에 따라 가장 적합한 아키텍처(4)를 선정한다. 
여기서 해당되는 팀은 이하의 질문에 답해야만 한다. 선정된 아키텍처가 어떻게 상위 레벨 소스 요구사항이나 규격 능력과 연관되어 있는가? 그들은 아키텍처 요소를 도출된 능력과 연결 또는 할당한 간단한 매트릭스(7)를 생성하여 이를 해결토록 한다. 이러한 할당에 근거하여 요구사항이 하위 레벨 규격으로 분할된다. 할당되거나 분할된 요구사항은 사용자가 요구하는 사항을 어떻게 잘 수행할 것인가를 상위 레벨 전환이라는 사실을 기억해야 한다.
모델 기반 규격서 개발이 다중 레벨 관점에서 어떻게 이루어지고 있는지를 보기 위해 다시 한 번 모델 기반 접근방법으로 돌아가 보자. 그 예로써 그림 2의 하부체계를 사용하여 하위 레벨 규격이 어떻게 개발될 수 있는지를 알아보자. 이는 그림 5에서 그래픽 사례로 볼 수 있다.



· SEIT는 SPS를 분석하고, 다중 레벨 능력에 대한 I/O모델을 생성하기 위해 SE 프로세스 모델을 적용하며, 하나의 시스템 아키텍처를 선정한다. 그리고 그 능력을 아키텍처 요소에 할당하며, 할당된 요구사항을 제품 A3 개발규격에 분할한다.
· 제품 A3 IPT는 요구사항 할당을 분석하고, 다중 레벨 능력에 대한 I/O 모델을 생성하기 위해 SE 프로세스 모델을 적용하며, 제품 A3 아키텍처를 선정한다. 그리고 그 능력을 아키텍처 요소로 할당한 다음, 할당된 요구사항을 하부체계 A33 개발 규격으로 분할한다.

만약 시스템 개발 모델로 낙차식 모델을 적용할 경우, 위 단계는 상위 레벨 규격서에서 출발하여 순서적으로 수행된다. 이와 연관된 설계는 다음 레벨로 진입하기 이전에 완료되어야 한다. 이를 위해 빈번한 반복이 되어야 하기 때문에 규격서 개발은 다중 레벨 활동으로 수행된다.

3. 실제 환경

앞에서 논의한 바와 같이 규격서 개발은 고도로 빈번하게 반복적인 다중 레벨 프로세스이다. 인력 자산을 고도로 효과적이고 효율적으로 사용할 수 있도록 상위 레벨에서의 요구사항 할당이 하위 레벨 규격개발 활동을 시작하기 전에 성숙한 레벨로 도달해야 한다. 따라서 다중 레벨에서 규격개발 시 이러한 상태를 벗어날 수가 있다는 점을 유의해야 한다.
어떠한 경우든지 동시적 규격개발이 상위 레벨에서 무엇을 요구하고 있는지를 이해함으로써 하위 레벨 주요 운용 및 기술 쟁점사항(COIs/CTIs)을 해결해 나가도록 노력해야 한다. 당신은 왜 그런지 그 이유를 항상 물어보아야 한다.
시스템 분해 및 규격서 개발을 위한 단계에서 각 요구사항에 대하여 이하의 요구사항을 확인토록 한다.

· 사용자 우선순위
· 적용 시 이에 따른 비용
· 위험 레벨
· 적용 시 이에 따른 시기와 일정

따라서 당신은 내부적으로 ‘이러한 능력을 적용 시 타당성을 알아보고 결정한 다음, 이에 대한 피드백을 제공’하는 활동을 통해 다중 레벨 규격을 개발할 필요가 있다. 상위 레벨 규격이 보다 추상적인 반면에 하위 레벨 규격은 어느 품목을 어느 벤더에 실제로 개발하여 획득할 것인지를 나타낸다. 당신은 시간이 지남에 따라 상위 레벨 규격이 더욱 분명해져 간다는 사실을 알게 된다. 당신은 이러한 이유로 왜 다중 레벨 규격 개발이 하향식, 상향식, 좌우, 우좌 프로세스로 진행되어야 하는지를 이해하게 된다.

· 어느 레벨에서의 요구사항도 차상위 레벨로 추적 가능해야 하며 결과적으로 획득자의 SOO 또는 SRD와 같은 소스 또는 본래의 조달 요구사항으로 추적되어야 한다.
· 규격서 요구사항은 주어진 비용과 일정 예산 범위 내에서 수용 가능한 리스크로 실제적으로 달성되어야 한다.

규격서 순서 목차 생성

우리가 규격서를 개발할 때, 사용자가 운용대상 시스템/개체를 어떻게 원하는지를 나타낼 문서 서식을 사용하게 된다. 따라서 규격서 목차 3.0은 운용특성을 나타내는 3.1항으로 구성된다. 성능 기반 규격서인 경우, 시스템 능력에 관한 3.2항을 생략하고 3.2항으로 시스템 인터페이스를 사용해도 좋다. 규격서 3.1항 특성 개발 프로세스는 그림 6과 같다.



그림 6은 그림 2에서 식별된 운용 개체 관계가 운용 능력을 어떻게 다중 레벨 능력 기반 요구사항 내용으로 구성하고 작성되는지를 보여주고 있다. 대부분 시스템은 이전 시스템을 고려하여 개발되기 때문에 위에서 언급한 대로 3.1항을 적용하고 시스템 개체 능력 3.2항에 특정 아키텍처 요소 요구사항을 나타낸다. 이는 획득자로 하여금 특정 아키텍처 능력과 연관된 요구사항을 나타내도록 하고 있다. 규격 개발자는 그림 2와 같은 아키텍처 분석을 생성한다. 아키텍처를 기반으로 계층구조 3.2항으로 구성하며 아키텍처 능력을 그림 7과 같은 요구사항으로 제시하게 된다.



1. 소결론
규격개발 접근방법은 아직 완전히 입증된 과정이 아니다. 이러한 접근방법은 요구사항을 식별하고 문서화하는 분석가들에게 현재까지 잘 사용될 수 있는 절차에 불과하다. 그러나 모델 기반 구조분석 접근방법은 모든 운용 단계와 모드 기간 중 시스템 능력 요구사항을 보다 더 잘 나타내고 있는 형상 기반 방법으로서 보다 우월한 접근방법이다.
 
규격서 개발 체크리스트

시스템/개체 규격서는 개발자에게 수많은 도전을 제공해 주고 있다. 규격서 개발에 따른 여러 가지 교훈을 통해 여기서 몇 가지 고려해야 할 요소를 제시하도록 한다.

· 규격서 요구사항으로 CSOW 활동 언급을 피하라.
· 사용자 문제점과 솔루션 영역을 잘 이해하여야 한다.
· 사용자와 함께 운용 요구사항을 확인하라.
· 이해관계자와 친밀한 용어를 사용하는 요구사항을 제시하라. 하위 레벨 규격서에서는 개발자와 친밀한 용어를 사용토록 하라.
· 올바른 솔루션 영역과 시스템을 설정하라.
· 솔루션 영역과 운용환경을 적합하게 제시하라.
· 시스템 위협과 우선순위를 식별하라.
· 하나의 시스템 설계 솔루션을 그대로 사용하는 것을 피하라.
· 어떻게(How) 해야 하는지보다 무엇을(What) 해야 하는지에 대한 요구사항을 제시하라.
· 목표 기반 목적 요구사항으로부터 한계 요구사항을 제시하라.
· 외부 참조 요구사항을 외적으로 식별하여 제시하라.
· 최소 비용으로 할 수 있는 최소 검증방법을 선정하라.
· 불완전한 요구사항 작성을 피하라.
· 해석상 불분명한 주관적인 요구사항을 피하라.
· 중복, 충돌 및 누락된 요구사항을 피하라.
· 불필요한 정교성과 정확성을 요구하는 요구사항을 피하라.
· 요구사항의 일치성과 완전성을 규격 내 또는 범위를 넓혀서 적용하라.
· 기법, 기술, 지원, 비용 및 일정상 위험의 균형을 도모    하라.
· 규격 개발 및 소유권에 대한 권한을 명기하라.
· 검증방법을 식별하여 범주화하라.
· 요구사항 추적성을 설정하고 유지하라.
· 의미 부여와 연관된 주요 항목, 주기 및 가정 사항을 정의하여 제공하라.
· 적용과 비용 목적에 대한 요구사항 우선순위를 제시하라.
· 만일 제시된 요구사항이 분명하고 텍스트 기반 요구사항과 마찰이 없다면 시스템 블록 도표(SBDs)를 포함하라.
· 이해관계자 요구사항을 도출하고 이에 대한 코멘트를 검토하라.

규격서 검토

규격서가 성숙단계로 진행하려면, 이해관계자와 규격서 검토를 수행하라. 이러한 검토를 수행하는데 여러 가지 방법이 있다.

1. 요구사항 한 줄 한 줄 세밀하게 검토

일부 개인과 조직은 많은 시간을 들여 요구사항에 대한 한 줄 한 줄 검토하는 방법을 사용한다.

2. 검토자 코멘트-쟁점사항 접근방법

또 다른 검토방법으로서 요구문서를 이메일로 배포한 다음 변경해야 할 사항을 밑줄 긋고 이에 대한 코멘트를 요구하는 방법이다. 그리고 해당 코멘트 사항을 검토한 후 정당성을 알아본다. 이해관계자의 확인이 필요한 경우 이를 협의하도록 한다.
수집된 검토 코멘트 사항을 근거로 주요 쟁점사항을 식별하고 이해관계자 검토를 수행한다. 이러한 검토 행위는 주요 쟁점사항을 해결함에 그 목적이 있다.
검토 결과에 따라 기준 정리와 결과 승인 또는 차후 검토 문서를 업데이트하라. 이러한 접근방법은 한 줄 한 줄 검토하는 방법의 이해관계자와 함께 ‘만족’과 ‘동의’를 위해 소모하는 시간을 줄여준다.

3. 검토기록

어느 접근방법이 가장 적합할지 모르지만, 여하튼 참가 이해관계자 명단, 변경내용, 의사결정 및 조치사항 등을 포함한 회의결과를 문서화해야 한다.

4. 규격 기준

규격서 형태 기준을 언제 제시해야 하는지를 당신은 확인해야 한다. 첫째, 특정 요구사항에 대한 당신의 계약당사자와 항상 의논해야 한다. 일반적으로 규격서는 표 1에서와 같이 기준화한 다음, 제출해야 한다.



지침

요약해서 앞서 논의한 모든 내용은 규격서 개발 실무에 관한 여러 가지 지침 설정 기준을 제시하고 있다.

[지침 #1] 누구든지 규격서 개요를 작성할 수 있다. 그러나 규격서 개발은 알려진 분석에 의해 지원되는 지식을 요구하고 있다.

[지침 #2] 모든 규격서는 그 자체에 대한 개발, 적용 및 유지에 적합한 책임자 임명을 요구하고 있다.

[지침 #3] 모든 규격서는 아래 두 가지 요구사항 관점을 지니고 있다.
① 시스템/개체가 무엇을(WHAT) 수행해야 하며, 얼마나 잘(HOW WELL) 수행해야 하는지
② 요구사항 일치성을 검증할 수 있는 품질규정 조항 삽입

[지침 #4] 획득자와 사용자에게 친숙한 시스템 규격서 용어를 사용하라. 하위 레벨 규격서에는 개발자와 친숙한 용어를 사용한다.

[지침 #5] 요구사항 문장이 일치성을 달성하기에 적합한 의무조항으로 표현되어 있어야 한다. 목표는 의무 사항으로 표현한다. 

‌요약

우리가 논의한 규격서 개발 실무에서 시스템 규격과 연관된 주요 도전사항, 쟁점사항 및 방법을 식별했다. 최종적으로 개념 부분에서 규격서를 준비하는 기본 방법을 알아보았다.
이 방법은 사용자가 어떠한 시스템을 요구하고 있는지에 기초한 규격서 개발에 대한 운용 접근방법을 제공하고 있다. 이러한 시스템 솔루션으로 시스템 성능 규격서(SPS) 요구사항을 개발하는 데 초점을 두고 있다.

1. 일반적 예제

1) 개요에서 우리가 이해해야 할 질문에 대하여 한 번 생각해 보아라.
2) 앞에서 제시한 시스템 목록을 참조하라. 앞서 제시된 시스템을 개발하거나 전혀 새로운 시스템을 선정할 때, 이 장에서 언급된 사항을 참조토록 하라. 그리고 다음 사항을 식별해 보라.

당신은 시스템 성능규격(SPS) 3.0이 어떻게 제시하고 있다고 믿는지 설명해 보라.
시스템의 한 컴포넌트를 선택하라. 그리고 해당 컴포넌트 개발 규격에 대한 3.0항을 설명해 보라.

2. 조직 중심 예제

1) 당신 조직의 수행된 여러 가지 계약 프로그램을 살펴보라. 그리고 기술책임자, 프로젝트/수석 엔지니어, 또는 SE 책임자와 상의하여 다음 질문사항에 답해 보라.

· 해당 계약서에 어느 형태의 규격서가 요구되어 있는지
· 형태 기반, 재사용, 또는 구조분석 등 각 규격서는 어떻게 개발되었는가.
· 인터뷰 결과를 토대로 그 규격을 새롭게 준비한다고 하면, 당신은 무엇을 적용하여 준비할 것인지

2) 당신 조직의 지휘계통을 살펴보라. 규격서 개발과 접근방법에 관하여 무슨 지침이나 방법을 제공하고 있는가.