요구사항 기술 방법(2) 

민성기  시스템체계공학원장(sungkmin0@gmail.com)


요구사항 개발지침

요구사항은 속성 범위로 특성지울 수 있다. 이 속성에는 법적, 기술, 비용, 우선순위 및 일정 특성을 포함하고 있다. 각 내용을 간단하게 살펴보자.

1) 각 요구사항 기술 : 요구사항은 대형 문서 내에서 그들의 고유성을 알아볼 수가 없는 경우가 발생한다. 이는 급하게 요구사항 사례를 찾고자 할 경우, 문제가 발생한다. 요구사항을 쉽게 위치하도록 하여 규격 사용자와 검토자로 하여금 쉽게 찾아볼 수 있도록 해야 한다. 각 요구사항에 대하여 “범퍼 이름”을 제시하도록 하라. 이는 규격 내용 도표 찾기와 식별하기 쉽게 하는 메커니즘을 제공해 준다.
2)‘Shall’ 조동사 사용 : 계약 요구사항의 일환으로 사용되는 요구사항은 법적 구속력과 ‘Shall’ 조동사로 표현함으로써 획득에 대한 충족을 요구할 수 있다. 엔지니어는 요구사항을 요구할 때 ‘will’,‘should’, ‘must’와 같은 여러 가지 조동사로 표현할 수가 있다. 이러한 조동사는 의도적인 표현으로 사용되나 의무 또는 요구활동으로 제시하진 못한다. 규격서에 큰 글씨로 ‘Shall’을 표시하는 것이 바람직하다.
[유의사항] ‘will’과 같은 조동사를 사용한 규격서는 보다 분명하지 않은 규격 요구사항임을 나타내는 증거가 많이 나타나고 있다. 일반적인 관점은 요구사항 기술의 ‘콘텍스트’에서 무엇이 중요한지를 나타내어야 한다. 예를 들어 그 시스템은 아래와 같은 활동을 수행할 것이라고 기술한다면, 당신은 규격서 작성 초기에 ‘will’이 ‘의무’ 이행범위를 어떻게 해석할 것인지를 표기해야 한다. 당신과 당신 조직에서 이를 어떻게 제시하더라도 이 규격을 사용하는 모든 사람이 일관되게 생각하도록 해야 한다. 따라서 가장 좋은 실무적 견해는 ‘shall’을 사용하는 것이다. 어느 경우든 법적해석이 필요한 경우 언제든지 당신의 법적 조언자의 의견을 물어 규격서를 작성하는 것이 바람직하다.
3) 다른 절, 규격 및 표준 참조 : 규격서의 연관된 절에서 가끔 문서 내부에 다른 절은 참조하도록 하고 있다. 전형적으로 ‘절 3.4.2.6을 참조’하라고 명시한다. 만약 당신이 이렇게 할 경우, 참조 절의 제목을 포함하여 제시하도록 하라. 왜냐하면, 규격서 구조가 자주 변경됨으로 제목이 추가되거나 삭제되기도 하기 때문이다. 이렇게 될 때 절의 번호가 다시 바뀌게 된다. 따라서 최초 ‘절 3.4.2.6을 참조’라는 번호가 바뀌어 아무런 연관이 없어지기 때문이다. 참조에 해당 절의 제목을 사용함으로써 검토자는 보다 쉽게 참조문서와 연관 절 사이에 문제를 인지할 수가 있다.
4) 외부 규격과 표준 참조 : 당신이 외부 규격과 표준을 참조로 할 경우, 문서번호와 제목을 삽입해야 한다. 일반적으로 제목과 문서 식별번호는 2.0절 참조문서란에 기술되어야 한다. 그러나 혼돈을 가져오는 유사 제목을 가진 문서의 예들이 많이 발생한다. 이렇게 되면 ‘XYZ 시스템 성능규격(SPS) (문서번호 123456)’과 같이 참조 표기해야 한다.
5) 운용 및 기술능력과 성능 특성 : 운용 및 기술 능력과 특성 요구사항은 요구 시스템 능력과 성능레벨을 외형적으로 기술해야 한다. 미 국방 획득관리센터(DSMC) 시험평가 관리지침에 다음과 같이 용어정의를 하고 있다.
· 요구 운용 특성 : ‘요구 임무 기능 수행과 지원될 주요 시스템 능력 지수로 나타낸 시스템 변수’로 규정하고 있다. (근거 : DSMC T&E 관리지침, 부록 B, 시험용어집, p.B-17)
· 요구 기술 특성 : ‘주요 엔지니어링 목표 달성지수로 선정된 시스템 변수, 이는 직접적인 계측이 아니어도 되지만, 요구 임무 기능 수행과 지원될 시스템 능력과 항상 연계되어야 한다.’(근거 : DSMC 시험평가 관리지침, 부록 B, DoD 시험용어집, p. B-17)
운용 및 기술 특성은 측정, 달성, 시험 및 검증 가능해야 한다는 사실을 기억하라.
6) 목록 근거 텍스트 요구사항 작성 회피 : 엔지니어는 요구규격 작성 시 전형적인 목록에 따라 작성하려고 한다. 그들은 주제 문장, 복합 및 항목을 가진 목록에 따라 요구사항을 작성한다. 이와 같이 요구사항을 작성하게 되면, 요구사항은 단일 시험 요구사항으로 고립되게 된다. 목록 근거 순차적 규격 작성은 1.0절의 목차를 그대로 수용한다.
문제는 시스템 개발자가 복합 요구사항을 3.x절에서 단일 요구사항으로 분리하거나 문장으로 꾸밀 때 너무 많은 시간을 소요하게 된다는 것이다. 당신 스스로 또는 시스템 개발자(계약자, 하부계약자 등)가 단일 요구사항 작성으로 시스템 규격을 생성하거나 우선시 하도록 하라. 이렇게 하면 상위 레벨에서의 우선순위 설정에 더 많은 시간을 보냄으로써 신뢰성, 이해성 및 검증성에 대한 일관된 포맷으로 시간을 전체적으로 절약하게 된다.
7) 복합 요구사항 작성 제거 : 복합 요구사항을 기술할 때, 요구사항 할당이 혼돈되거나 검증이 어려울 때가 있다. 왜냐하면, 다중 요구사항을 단일 요구사항처럼 기술하고 다른 체계로 할당될 때, 당신이 어떻게 기술된 요구사항의 일부분을 특정 목표 개체로 연결할 수 있는가 하는 문제가 발생한다. 시스템이 검증되어야 할 때, 요구사항의 일부분이 준비되지 않은 장비로 검증이 곤란할 경우, 어떻게 당신은 전체적인 요구사항을 검증할 수 있느냐 하는 문제이다. 오직 가능한 방법은 각 기술된 요구사항에 번호를 부여하는 길이다. 각 요구사항에 대한 검증이 시작될 때, 그 내용에 내장된 모든 요구사항에 대한 완전한 검증이 전반적인 내용 검증 충족이 요구된다.
8) ‘ALL’이라는 단어 제외 : 규격 작성자가 가끔 ‘ALL’이라는 단어를 자주 사용하게 된다. 규격서에는 ‘ALL’이라는 단어를 결코 사용할 수가 없다!
‘모든 XYZ 경우가 검증되어야 한다.....’는 법적 의미를 생각해 보자. ‘ALL’이라고 할 때 모든 우주의 범주가 얼마나 큰지를 상상해 보라. 따라서 ALL이란 실무적 환경에서는 제한된 영역의 하나를 나타낸다는 사실을 기억하라. 따라서 이는 모든 가상 시나리오나 개체 사례에 이르기까지 포함되지 않고 있다. 제한된 콘텍스트에서의 ALL은 ‘끝이 없음’으로 해석이 요구되는 영역이다. ALL을 사용하지 않기를 권장한다.
9) ‘Etc.’라는 용어나 약어 제외 : 등등이란 용어의 표기는 우리가 자주 사용하는 경우와 다르다. 대부분의 엔지니어는 일찍이 잘못한 경우에 대한 질책과 과학이나 자연적인 발생에 대하여 ‘흠잡기’하는 사람이 항상 있음을 경험해 왔다. 이리하여 엔지니어는 ‘etc’라는 용어를 사용함으로써 ‘모든 경우를 커버’한다는 의미로 사용해 왔다. 당신이 규격을 개발할 때, 당신의 의무는 솔루션 영역을 정하고 한정하는 것이다. 당신이 ‘최소한 그 시스템은 a, b, c 등으로 구성되어야만 한다’고 기술할 때, 획득자는 나중에 ‘우리는 d, e 및 f를 추가로 원한다’고 할 수 있다. 당신이 계약 시 etc를 사용했다면 우리는 d, e 및 f를 고려하지 않았다고 얘기해도 당신은 요구사항과 ‘etc’를 동의했고 이는 획득자가 원하는것은 무엇이든지 추가할 수 있다는 의미이다.
10)‘and/or’라는 용어 사용 회피 : 가끔 규격 작성자는 ‘and/or’라는 용어를 포함한 요구사항을 사용한다.
예를 들면 ‘그 시스템은 A, B, C and/or D능력으로 구성되어야만 한다.’라고 기술할 때, 엄밀하게 얘기하면, 그 시스템은 A, B, C 또는 D로 구성되어도 좋고 아니어도 된다. 만약 아니라면, 그 시스템이 무엇을 포함해야 하는지를 정확하게 제시해야 한다. 규격서란 시스템 수락 및 납품 시, 무슨 능력이 필요한지를 분명하게 말해야 한다는 사실을 기억하라!

파생 요구사항 ‘시험수행’

많은 사람은 당신이 요구사항을 시험할 수 있다는 것을 알아내는 데 힘들어한다. 요구사항 시험수행은 코딩 표준과 그래픽 기준 같은 조직의 표준과 기준에 대하여 기술적 일치 여부 감사활동을 말한다. 모델링과 시뮬레이션은 요구사항 시험의 또 다른 방법을 제공해 주고 있다. 이러한 모델링과 시뮬레이션 수행은 요구사항 적합성, 성능 할당, 잠재적 마찰 및 검증의 어려움을 미리 알려준다.
또한, 요구사항 시험은 이미 주어진 기준에 따라 각 요구사항에 대한 검사와 평가를 포함하고 있다.

1. 요구사항 확인 기준
검사 또는 평가로 요구사항 확인 시험을 수행할 때, 요구사항에 대한 적합성과 충족성을 결정하기 위해 여러 가지 기준을 사용한다. <표 1>은 이러한 주요 기준에 대한 예들을 제공해 주고 있다.



<표 1>에 나타난 판단 기준은 일반적으로 타당하게 제시되어 있다. 당신은 이와같은 기준을 어떻게 수백 개 이상의 요구사항에 적용할 것인지를 생각해 보아야 한다.
첫째, 시스템 엔지니어는 이러한 기준을 마음속 깊이 새기고 있어야 한다. 경험적으로 당신은 규격 요구사항을 시험하기 위하여 재빨리 익혀야 한다.
둘째, 대형 규격서일 경우, 시스템 엔지니어 그룹 차원에서 시험과 분석활동을 수행해야 한다. 나아가 결과에 대한 유의수준 레벨과 지속성을 가지고 요구사항 작성 및 검토를 적절한 방법으로 수행할 수 있도록 모든 시스템 엔지니어들을 훈련해야 한다.

요구사항 최소화

시스템 엔지니어는 하나의 시스템에 대한 요구사항이 몇 개가 필요한 지에 대하여 궁금해 한다. 여기에는 특정 지침이나 법칙이 없다. 다만 훈련되고 경험된 정도에 의해 이를 알아본다. 경험에 의하면, 규격서의 품질은 요구사항 수량에 의해 나타나지 않는다는 것이다.
놀라지 말고 생각해 보라. 각 요구사항 계층에서 낮은 비용으로 일정준수 및 리스크를 달성하기 위한 시스템 개발자의 융통성과 옵션을 제한하는 제약사항, 복잡도, 비용 및 일정을 추가하고 있다는 사실을 기억하라.
그러면 얼마나 많은 요구사항이 이상적으로 필요한가? 가정적으로 하나의 요구사항이지만 하나의 요구규격은 제한된 유틸리티를 가지고 있다. 더구나 적절하게 준비된 규격서는 최소 요구사항 수량으로 하지만 주어진 운용능력과 성능 요구를 충족시키기 위하여 검증되고 확인될 수 있는 시스템을 사용자/획득자가 획득할 수 있어야 한다.
어떻게 이러한 조건을 달성할 수 있는 이상적인 규격을 만들 것인가? 그 답은 성능 규격에 달려있다. 성능 규격은 시스템 엔지니어로 하여금 입력과 출력을 가진 박스처럼 한 시스템을 정의한 것이다. 이는 의도적으로 주어진 운용환경에서의 시나리오와 상태에 대한 시스템 거동을 제한하는 범주를 제시하는 것이다. 이를 위해 성능측정(MOP)을 지원하는 효과도 측정(MOE)과 적합도 측정(MOS)을 사용하게 된다. 시스템 특성을 ‘성능 허용한계’로 제시하되 어떻게 시스템이 설계되어야 하는지를 제시해서는 안 된다.

[참조] 성능 측정(MOP), 효과도 측정(MOE) 및 적합도 측정(MOS)을 보다 상세하게 보려면 다음 장에서 운용 유틸리티 및 효과도 실무를 참조하기 바란다.

한 시스템을 ‘성능 허용한계’ 레벨에서 다룰 때, 한 가지 문제점이 있다. 만약 당신이 너무 많은 융통성을 가진 방법으로 성능 규격을 제시할 경우, 그 결과는 획득자가 수용하기 어렵게 된다는 점이다. 이는 시스템 개발자로 하여금 무슨 시스템 능력과 얼마나 잘 수행해야 하는지에 대한 도전이나 해석에 어려움을 주게 된다. 이는 결과적으로 획득자 또는 시스템 개발자/하부계약자로서의 해야 할 역할에 따라 좋을 수도 나쁠 수도 있다.
모든 능력이 특별히 제약된 예산에 의해 사용자에게 동일한 중요도로 여겨지지 않기 때문에 사용자 우선순위 목록은 시스템 개발자의 우선순위 목록과 다를 수가 있다.

[주기] 시스템 개발자는 기술, 비용 및 일정에 대한 리스크의 최소화를 생각하는 반면, 사용자는 능력과 성능의 최적화에 관심 있어 한다는 사실을 유념하라. 시스템 개발자는 계약형태에 따라 이윤을 최적화하면서 기술, 비용 및 일정 리스크를 최소화하는 데 관심이 있다. 양자가 윈-윈 정책으로 최적 솔루션을 기꺼이 이해하지 않을 경우, 우선순위 관점에서 충돌이 일어날 수 있으며 조직이 와해되는 경우가 발생하기도 한다.

우리는 어떻게 이러한 딜레마를 풀어갈 수 있는가? 획득자는 우선순위와 마찬가지로 주요 능력, 성능 레벨을 보다 명확하게 식별하기 위하여 부가적인 요구사항을 제시해야 한다. 이를 위해 몇 가지 도전해야 할 사항이 있다. 어느 레벨까지 획득자가 요구사항을 제시할 것인가? 궁극적으로 획득자는 예산 요소에 따라 과도 및 과소 제시가 가능하다. 또한 획득자가 계약업무기술 시, ‘의사결정 통제 또는 승인’에 대한 다른 옵션을 제시할 수가 있다. 
따라서 최적 요구사항 수량이란 무엇을 의미하는가? 간단치 않지만, 철학적으로 다음 최적 시스템 요구사항 개념 토픽에서 이를 살펴보도록 하자.

1. 최적 시스템 요구사항 개념
알려진 데이터에 의한 이상적인 규격 요구사항 수량을 그래프로 표현할 수 있다. 그림 1를 살펴보자.



그림 1은 세 가지 곡선 그래픽 프로파일로 구성되어 있다. 각 그래픽 프로파일 아래로 구분된 영역을 Zone이라 부르자. X와 Y축이 만나는 점에서 상부 계층 레벨에서 식별된 법적 요구사항은 논리적으로 최적 레벨까지 시스템 정의에 대한 적합성이 증가한다. 우리는 이 논리적인 점을 가리켜 곡선의 기울기에 대한 변곡점이라고 한다.
이 변곡점에서 최적 요구사항 수량이라고 볼 수 있다. 가설적으로 요구사항 수량은 원하는 능력과 성능 레벨로 나타낸 시스템을 규정하면서 기술적으로 필요 충분한 양으로 볼 수 있다. 이 레벨에서 요구사항이 사용자가 의도하는 운용요구에 충분하게 제약되는 최소 수량의 요구사항이 될 수 있다.
변곡점을 넘어가면 요구사항 제약사항이 증가하는 Zone이 된다. 곡선의 기울기가 증가함에 따라 요구사항 수량이 증가하지만, 규격 적합성과 유틸리티 측면에서 과도한 규격에 따른 비용이 증가한다. 각 추가 요구사항은 SE 설계 옵션을 제한하고 기술, 비용, 일정, 기법 및 지원 리스크가 높아진다.
요구사항 수량이 오른쪽으로 갈수록 많아짐에 따라 Zone 3으로 넘어간다. Zone 3은 요구사항이 매우 경직되는 영역이다. 이리하여 SE 설계 옵션을 제약하고 시스템의 타당성을 급격히 제한하게 된다. 일반적으로 이러한 사실이 발생한다면, 사업제안 초기 단계에서 문제가 발생한다. 경직된 기술, 비용, 일정 및 지원비용에 대한 리스크를 줄이기 위해 획득자는 요구사항 일부를 삭제하게 된다. 
여기에서 기술된 문제점은 획득자에게만 나타나는 것이 아니다. 동일한 문제점이 시스템 개발자에게도 나타나며 이는 시스템 레벨뿐만 아니라 하위 레벨 다중 규격 레벨에서 발생된다. 모든 레벨에서의 모든 요구사항이 일정과 리스크 적용을 넘어 검증비용과 적용비용을 가지고 있다. 이는 시스템/제품 수명주기의 시스템 개발단계에서의 설계 프로세스, 컴포넌트 획득 및 개발 프로세스 및 시스템 통합, 시험 및 평가(SITE) 프로세스에 영향을 준다.
이러한 개념은 최적 규격 요구사항 수량이란 무엇인지에 대한 답을 가져다준다는 것인가? 아니다. 그러나 몇 가지 가설적 조건(변곡점, 전환점)을 마음속에 심어준다. 최저선이란 규격서 작성은 일정의 제약조건 속에서 단순히 ‘임의 사고’로 작성하는 것보다 더 많은 생각을 낳게 한다. 당신은 당신이 무엇을 요구하고 있는지 그리고 시스템 개발자에게 잠재적인 요소는 어떤 게 있는지 생각할 수 있다.

[주기] 일반적으로 기업은 측정과 이를 다른 경우와 비교하는데 많은 시간을 보낸다. 상대적으로 개략 추정(ROM)을 하는 동안 ‘최종 게임’은 획득자, 시스템 개발자 및 하부계약자가 적극적인 경험을 통해 무엇을 가져올 것인지에 대한 상호 이해와 동의하는 과정을 놓쳐서는 안 된다. 모든 시스템이 다르고 각각의 장점에 의해 평가되어야 한다. 만일 시스템 상호간 비교를 한다면, 두 가지 시스템은 형태, 조립 및 기능 측면에서 비교되어야 한다.

2. 소결론
앞서 논의된 사실은 다음 주요 관점을 밝히는데 주안을 두고 있다. 요구사항을 규정할 때, 그 내용을 적절하게 커버하기 위해 양적 측면에서 최적 요구사항 수량을 알려고 노력해 왔다는 점이다. 그러나 비용, 리스크 및 개발기간 증가를 피하고 동일한 품질 설계 옵션에 대한 유동성을 감소시키기 위한 수량에 초점을 두어야 한다.

‌원칙

요약해서 앞서 우리는 요구사항 작성실무를 위한 지침을 설정하는 기본을 제공해 왔다.

[원칙 #1] 모든 시스템 요구사항은 시스템 내에서 유일해야 하며, 목적이 단일하고, 다른 요구사항과 일치하며 충돌이 없어야 한다.
[원칙 #2] 모든 요구사항은 명료하게 이해되어야 하며, 실제적이고 달성 가능하며 일관되고 시험, 측정 및 검증할 수 있어야 한다.
[원칙 #3] 모든 요구사항은 적용하고 유지하는 오너가 있어야 한다.
[원칙 #4] 다음과 같은 사항이 충족되지 않을 경우, 이는 요구사항이 아니다.
· RVM을 통해 소스 또는 원 요구사항에 대한 추적
· 요구사항 확인 기준 충족
· 하나 또는 그 이상의 검증방법
· 이해관계자 동의에 의한 수락
· 적용 승인
[원칙 #5] 모든 요구사항은
· 사용자로 하여금 우선순위와 가치를 부여한다.
· 설계 솔루션 옵션을 제약한다.
· 리스크가 증가한다.
· 적용과 유지를 위한 비용을 지니고 있다.

요약

· 주요 속성을 기술하고 좋은 요구사항을 특성으로 제시했다.
· 요구사항 작성 준비를 위해 요구사항 내용과 문법을 동시적으로 개발함에 있어서 공통적인 문제를 피하기 위한 · 세 가지 단계적 접근방법을 기본적으로 제시했다.
· 좋은 요구사항을 개발하면서 추천 목록을 제시했다.
· 특정기준을 충족하는 단일 요구사항 기술에 초점을 두고 제시했다.
· 요구사항 검증 매트릭스(RVM) 개발방법을 제시했다.
· 요구사항이 공식적인 요구사항으로 인식되는 시기에 대하여 논의했다.
· 요구사항 검증방법을 선택하기 위한 프로세스를 기술했다.

1. 일반적 예제
1) 개요에서 우리가 이해해야 할 질문에 대하여 한 번 생각해 보아라.
2) 앞에서 제시한 시스템 목록을 참조하라. 앞서 제시된 시스템을 개발하거나 전혀 새로운 시스템을 선정할 때, 이 장에서 언급된 사항을 참조하도록 하라.
(a) 시스템에 의해 식별된 능력 기반 네 가지에서 여섯 가지 유스 케이스를 기준으로 하여 각 능력에 대한 요구사항을 기술해 보라.
(b) 각 능력 요구사항에 대하여 상위 레벨 능력을 달성하기 위하여 완료되어야 할 다음 하위 레벨 요구사항을 도출해 보아라.
(c) 요구사항 검증 매트릭스(RVM)를 만들어 보라. 각 요구사항의 일치 여부를 입증하는 검증방법을 식별해 보라.
(d) 두 가지 요구사항을 준비하라. 참고로 <표 1>을 사용하여 각 요구사항에 대한 표를 만들고 각 요구사항이 어떻게 그 기준을 충족하고 있는지 별도란을 만들어 설명해 보라.

2. 조직 중심 예제
1) 당신 조직에서 개발된 하나 또는 계약 요구사항을 선택하라. 그리고 이 장에서 제시된 기준을 사용하여 시험해 보라.
2) 요구사항 작성에 대한 당신 조직의 지침 또는 규정에 대한 지휘체계를 살펴보라. 발견된 점을 문서로 제출하라.
3) 당신 조직의 계약 프로그램을 선택하라.
(a) 규격 요구사항을 검토하기 위하여 무슨 규격 검토방법을 사용하고 있는가?
(b) 요구사항 개발 지침이나 기준에서 규격서 개발자에게 어떠한 지침을 적용하고 있는가?