규격서 요구사항

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


규격서는 기술된 솔루션 영역 내에서 주어진 임무와 목표를 달성하기 위하여 시스템이 요구하고 있는 성능 수준과 기술 능력에 대한 동의를 나타낸 것이다. 따라서 규격서는 사용자가 조직의 임무와 목표를 달성할 수 있는 솔루션 영역을 미리 규약하고 특정 짓기 위한 문서이다.
이 장은 시스템, 제품, 또는 서비스에 대한 요구사항을 특정 짓기 위한 기본사항을 제공하고 있다. 우리는 운용, 능력, 비기능 사항, 인터페이스, 검증 및 확인 요구사항과 같은 다양한 이해관계자와 다양한 규격 요구사항의 형태와 영역을 알아본다. 우리는 또 운용 요구사항을 많이 다루면서 이를 정상, 비정상, 위기 및 재난과 같은 네 가지 운용 모델을 고려하여 알아본다.
솔루션 영역을 나타내는 규격서 요구사항은 계층 구조적이며 상호 연계되어 있다. 우리는 다양한 요구사항 형태 상호간의 계층구조 관계와 구조를 알아본다. 우리는 왜 특별한 방법으로 준비된 규격서가 놓치거나 잘 못된 것, 충돌되거나 중복된 요구사항에 따라 어떠한 문제가 발생될 수 있는지를 알아본다. 이러한 문제점들은 시스템 엔지니어가 이해하고 인식해야 할 위험 영역임을 알아야 한다.

1. 얻고자 하는 내용

· 요구사항이란 무엇인가?
· 소스 또는 원천 요구사항이란 무엇인가?
· 이해관계자 요구사항이란 무엇인가?
· 목표 요구사항이란 무엇인가?
· 한계 요구사항이란 무엇인가?
· 규격 요구사항 영역이란 무엇인가?
· 운용 요구사항이란 무엇인가?
· 능력 요구사항이란 무엇인가?
· 비기능적 요구사항이란 무엇인가?
· 인터페이스 요구사항이란 무엇인가?
· 검증 요구사항이란 무엇인가?
· 확인 요구사항이란 무엇인가?
· 요구사항 우선순위란 무엇인가?
· 네 가지 운용 요구사항 형태란 무엇인가?
· 요구사항의 네 가지 공통 문제점은 무엇인가?

2. 주요 용어정의
· 비기능(Nonfunctional) 요구사항 : 개체 외형, 중량, 크기와 같은 속성을 규정하는 정적이고 비거동적인 요구사항
목표(Objective) 요구사항 : 목표 가치란 사업관리자와의 계약 또는 달리 획득하고자 원하는 사용자 가치를 말한다. 목표 가치는 각 프로그램 요소에 대한 한계치 이상의 운용상의 목적이 있고, 치명적인 기간 및 비용 효과적인 증진을 의미한다. (참조 : DoD 획득 프로그램 준비지침. 출처 : DoD 5000.2R 초안1.2절 2001. 1. 1)
· 운용(Operational) 요구사항 : 제시된 시간표와 기술된 운용환경 내에서의 특정 임무목표와 산출물을 충족시키기 위한 통합 운용 세트를 말한다.
· 성능(Performance) 요구사항 : “특정 기능 속성으로 달성해야 할 성능과 본 능력으로 달성할 수 있는 조건을 식별하고 계량화하는 기준을 말한다.” (출처 : Kossiakoff & Sweet, 시스템엔지니어링, p.451)
· 한계(Threshold) 요구사항 : 사용자 판단 기준에 의해 최소한의 요구 충족을 할 수 있는 수락 기준을 말한다. 만일 한계 가치가 충족되지 않을 경우 프로그램의 성능은 심각한 상태가 될 수 있다. 예를 들면, 너무 비싸거나 필요시기에 공급할 수 없게 된다. (참조 : DoD 획득 프로그램 준비지침. 출처 : DoD 5000.2R 초안1.2절 2001. 1. 1)
· 요구사항 추출(Elicitation ) : 개인적인 인터뷰나 관찰을 통해 문제와 솔루션 영역에 대한 이해관계자 요구사항을 수집하고 식별하는 행위를 말한다.
· 요구사항 이해관계자(Stakeholder) : 시스템 능력과 성능 요구사항을 식별, 정의, 제시, 우선순위 제시, 검증 및 확인에 대한 이해관계를 가진 당사자를 말한다. 요구사항 이해관계자는 총순기에 걸친 시스템, 제품, 또는 서비스를 정의, 조달, 개발, 생산, 운용, 지원, 폐기 시 연관된 모든 책임부서를 포함한다.
· 요구사항 : “달성되어야 하고 운용되어야 할 환경에서 최종 품목의 임무수행 능력에 꼭 필요한 조건, 특성 또는 능력을 말한다.” (출처 : SD-15 성능규격지침, p.9)
· 검증(Verification) 요구사항 : 시스템, 제품이나 서비스 능력과 최소/최대 성능을 성공적으로 달성하고 있는지를 나타내는 방법과 조건 상태를 말한다.
· 확인(Validation) 요구사항 : 시스템, 제품, 또는 서비스가 사용자의 문서화된 운용요구를 충족하고 있는지를 확정하는 데 필요한 접근방법과 제시된 방법을 말한다.

요구사항 정의

규격서의 중심은 요구사항에 달려있다. 각 요구사항은 개발이나 보완을 통해 공급해야 할 시스템, 제품, 또는 서비스를 규정하고 구속하는 사항을 말한다. 요구사항 개발에 대한 일차적인 조건은 무슨 능력이 필요한지를 식별함에 있다. 따라서 그 요구사항을 어떻게 분류할 것인가를 이해해야 한다.

1. 요구사항 형태
사람들은 자주 요구사항이 특정 임무와 목적을 가지고 있다는 사실을 망각하고 일반적인 입장으로 생각하고 있다. 만일 당신이 규격서에 제시된 요구사항을 분석한다면, 그 요구사항은 여러 가지 영역으로 그룹화할 수 있음을 볼 수 있다. 이는 바로 요구사항 형태를 식별하고 때로 적용 시 복잡성을 줄여주는 역할을 하게 된다.

2. 요구사항 소스 또는 원천
획득자가 공식적으로 조달 시스템이나 개체를 나타내고 규정하는 요구문서를 제시할 때, 이와 같은 문서를 가리켜 소스 또는 원천 요구사항이라고 한다. 이러한 요구사항은 시스템 요구서(SRD) 및 목표 기술서(SOO)와 같은 하나 또는 여러 개의 문서로 나타낸 여러 요구사항 영역으로 제시된다. 
소스나 원천 요구사항을 적용하는 문제점 중 하나는 이는 상대적이라는 것이다. 누구와 상관되어 있는가? 획득자 관점에서 소스 또는 원천 요구사항은 사용자의 확인된 운용요구를 추적할 수 있어야 한다. 이러한 요구는 조달규격에서 비롯되는 의사결정 체인 문서를 통해 진화해 간다.
시스템 개발자 관점에서의 소스나 원천 요구사항은 사업제안 요청서(RFP), 시스템, 제품, 또는 서비스 획득을 위해 사용되는 SRD 또는 SOO와 같은 획득자 조달 규격서에 적용된다.

3. 이해관계자 요구사항
규격은 사용자 예산범위와 제약된 개발 일정 내에서의 FIT를 나타내는 필수적이고 우선적인 모든 이해관계자 요구사항을 제시한다.
1) 이해관계자 목표 관련 요구사항 : 일차적인 이해관계자 목표 요구사항은 다음 사항을 확인하는 것이다.

· 과업과 관계된 도메인의 모든 필수적인 요구사항이 시스템 성능규격서(SPS)에 식별, 분석, 문서화되어야 한다.
· 특정 요구사항은 다른 이해관계자 요구사항에 동일하게 주어지며 정확하고 간결하게 제시되어야 한다.
· 도메인/다분야 요구사항은 명백하고 분명하며, 이해하기 용이하고 무호성이 없으며, 시험 가능하고 측정 가능하며 검증할 수 있어야 한다.

2) 이해관계자 요구사항 추출과 문서화 : 이해관계자 요구사항이 계약 인터페이스상의 양자에게 관계됨으로 사용자, 획득자, 시스템 개발자와 같은 조직부서는 이해관계자 요구사항 식별과 연관된다. 따라서 이는 어떻게 추출되는가?
획득자는 계약이 이루어지기 전에 모든 사용자 운용 이해관계자의 일치된 의견으로 설정할 수 있어야 한다. 특히, 시스템 생산, 배치, 운용 및 지원, 그리고 폐기 단계에서의 시스템 결과와 성능에 대한 요소를 제시해야 한다.
시스템 개발자 역시 계약 단계에서 시스템 개발과 생산에 대한 내부적 이해관계자 요구사항을 분명하게 하는데 계약 관련 이해관계자 성능과 재정관계를 제시한다. 따라서 시스템 개발자 이해관계자 요구사항은 계약협상 기간 중에서와 마찬가지로 사업제안 시 SPS를 제시하기 전에 이루어져야 한다.
계약 당시 이행해야 할 사항이 무엇인지를 완전하게 이해하고 사인해야 함을 잊지 말기 바란다.

요구사항 규격 영역

요구사항은 우리가 의도하는 사용방법과 목적을 가장 잘 나타내기 위하여 여러 형태의 영역으로 구성할 수 있다. 전형적인 영역은 다음과 같다. 1) 운용 요구사항, 2) 능력 및 성능 요구사항, 3) 비기능 요구사항, 4) 인터페이스 요구사항, 5) 설계 및 제작 요구사항, 6) 검증 요구사항, 7) 확인 요구사항을 들 수 있다. 이러한 요구사항 형태를 좀 더 상세히 알아보자.

1. 운용 요구사항
운용 요구사항은 시스템 임무 목적과 거동 상호관계와 연관된 상위 레벨 요구사항으로 구성되어 있으며, 그리고 이는 주어진 운용환경과 조건상태 내에서 형성된다. 일반적으로 이를 수행하기 위한 기대 속성은 무엇인가?

2. 능력 요구사항
능력 요구사항은 각 시스템 개체나 품목이 결과물, 제품, 부산물, 또는 서비스를 산출하는 데 필요한 기능/논리 및 성능 활동으로 솔루션 영역을 구속하고 제시한다. 전통적으로 이러한 요구사항은 기능 요구사항으로 나타나 수행되어야 할 기능에 초점을 두고 있다. 그러나 능력 요구사항은 얼마나 잘 그 기능이 수행되어야 할 것인지를 나타내는 기능적/논리적 사항과 성능수준으로 나타난다.

3. 비기능 요구사항
비기능 요구사항은 물리적 시스템 또는 개체의 속성과 특성과 연관되어 있다. 비기능 요구사항은 행동을 나타내지는 않으나 특정 운용 결과물이나 효과에 영향을 줄 수 있는 사항이다. 예를 들면, 비기능적인 밝은 황색 페인트가 안전을 향상시켜 주는가?

4. 인터페이스 요구사항
인터페이스 요구사항은 자체 물리적 영역을 넘어선 외부 시스템과 직접 또는 간접적인 연결성이나 논리적 관계를 구속하고 제시하는 사항으로 구성되어 있다.

5. 검증 요구사항
검증 요구사항은 능력, 성능, 파라미터, 또는 비기능 요구사항과 일치하는 시스템이나 개체인지를 평가하기 위하여 사용될 요구사항 내용과 방법으로 구성되어 있다. 검증 요구사항은 전형적으로 검사, 분석, 데모, 시험과 같은 검증 방법으로 나타낸다.

6. 확인 요구사항
확인 요구사항은 의도하는 사용자의 운용요구를 충족하는 올바른 시스템이 제작되었는지를 분명하게 시현하기 위하여 무엇을 수행해야 하는지를 기술한 임무 중심의 유스 케이스 시나리오 요소로 구성되어 있다. 확인 요구사항은 전형적으로 사용자 또는 사용자를 대표하는 독립적인 시험기구(ITA)에 의해 준비된 운용 시험 및 평가(OT&E)계획에 의해 문서화된다. 유스 케이스는 시스템을 활용할 사용자의 활동을 나타내기 때문에 유스 케이스 문서가 상대적인 역할을 해준다. 일반적으로 확인은 치명적인 운용 및 기술적 쟁점(COIs/CTIs)사항이 해결되고 최소화되었는지를 보여주어야 한다.

요구사항 우선순위

요구사항을 추출할 때, 각 이해관계자는 그들의 조직 임무를 성취하기 위해 요구사항 중요도에 따라 가치를 부여하게 된다. 이러한 가치를 우선순위라고 한다. 시스템 개발 현상은 모든 요구사항이 적용하고 이를 공급하기 위하여 비용이 지급되어야 한다. 주어진 제한된 자원과 이해관계자 가치로 솔루션 영역을 구속하는 것은 가용자원으로 원하는 요구사항 비용을 감수해야 한다. 그 결과로 요구사항은 적용을 위한 우선순위가 주어져야 한다.

1. 한계와 목표 요구사항
요구사항 우선순위를 도출하여 나타내는 방법으로는 산계와 목표 요구사항을 설정하는 길이다.

· 한계(Threshold) 요구사항 : 한계 요구사항은 최소의 수용 가능한 능력과 성능수준을 말한다.
· 목표(Objective) 요구사항 : 획득자가 시스템 개발자에게 원하는 목표를 요구하는 것으로서 한계 요구사항을 넘어서는 수치를 설정하는 것을 말한다.

[예제 1] 사용자는 상위레벨 목표를 달성하기 위하여 주어진 법위 내에서 최소의 수용 가능한 성능 즉, 한계 요구사항 수준을 요구한다. 상위 레벨 목표 요구사항 달성은 기술 성숙도와 그 기술을 일관되고 신뢰성 있게 생산할 수 있는 벤더 능력에 달려있다.

한계와 목표 요구사항은 운용요구서(ORD)와 시험평가 종합계획서(TEMP)와 일치되어야 한다. 만일 당신이 한계와 목표 요구사항을 제시할 때, 표면적으로 다음과 같이 제시하여야 한다.

· 옵션 1 : XYZ 능력(한계) 및 XYZ 능력(목표)과 같이 괄호를 사용하여 각 한계와 목표 요구사항을 외형적으로 나타낸다.
· 옵션 2 : 달리 규정하지 않으면, 모든 요구사항은 ‘한계 요구사항’임을 규격서 맨 앞부분에 제시토록 한다. 나중에 목표 요구사항이 제시될 때, ABC 능력(목표)이라고 작성된 라벨을 제시하면 된다.

어느 경우에도 규격서 어느 부분에서라도 한계 또는 목표 요구사항이라고 정의해 두어야 한다. 세 번째 옵션은 한계와 목표 요구사항에 대한 요약 매트릭스를 포함하는 방법이다. 매트릭스 접근방법은 작성된 요구사항 문서 외부에 나타내는 것이다. 이 방법은 본문과 매트릭스 간에 왔다갔다하면서 독자로 하여금 혼돈할 가능성이 있다. 따라서 적절한 위치에 (한계 또는 목표) 표시를 한 라벨을 붙여 단순하게 사용하는 것이 바람직하다.

운용 요구사항 형태

규격 작성자가 요구사항을 추출하고 개발할 때, 사람들은 정상적이고 성공적으로 작동하는 이상적인 시스템을 겨냥하게 된다. 이상적으로 생각할 수 있겠지만, 실제적인 시스템, 제품 및 서비스에서는 제한된 신뢰성과 수명주기를 가지고 있다. 따라서 항상 기능적으로 정상가동이 되지 않을 수 있다. 그 결과로 규격서는 운용환경 시나리오와 조건 상태에 따른 단계와 모드를 나타내는 유스 케이스 요구사항을 제시해야 한다.

1. 운용 요구사항 단계
시스템, 제품, 서비스는 운용단계에서 그 임무를 수행한다. 따라서 시스템 엔지니어는 각 단계에서 이해관계자 기대사항을 나타내는 요구사항이 적절하게 표현되었는지를 확인해야 한다. 최소한 여기에는 임무전 단계, 임무단계, 임무 후 단계 운용상태를 포함해야 한다.

2. 운용모드 요구사항
각 운용단계는 임무단계에서 운용목적을 달성하기 위하여 특정 요구능력을 나타내는 최소한 하나 또는 둘 이상의 운용 모드를 포함하고 있다. 만일 당신이 대부분의 임무 시스템 운용을 분석하고 추적한다면, 다음 네 가지 운용환경 시나리오와 상태를 준비해야 한다. (1) 정상, (2) 비정상, (3) 위기, (4) 천재지변 상태이다. 이러한 각 상태를 보다 구체적으로 살펴보자.

1) 정상운용
정상운용은 특정 성능 한계와 자원 내에서 시스템 운용능력과 성능을 나타내는 임무 시스템 활동과 업무로 구성된다.

2) 비정상 운용
비정상 운용은 기능 또는 물리적 능력 상태를 식별, 원인규명, 분리, 수정활동에 초점을 둔 시스템 운용과 업무로 구성된다. 이러한 상태는 정상 임무 능력 범주 밖에 있는 성능 수준을 나타내지만 사람, 재산, 또는 환경의 안전에 치명적인 영향을 가져오진 않는 상태를 말한다.

3) 위기 운용
위기 운용은 건강, 안전, 재정, 인적, 조직, 재산, 환경에 대한 보안 리스크를 가져오는 잠재력을 가진 물리적 능력 상태, 위협, 안전사고를 제거하고 보완함에 초점을 둔 시스템 운용 및 업무로 구성된다.

4) 천재지변 운용
천재지변 운용은 건강, 안전, 재정, 사람, 조직, 재산, 주위환경에 나쁜 영향을 주는 주요 시스템 고장에 따라 발생하는 운용 또는 업무로 구성된다.

3. 운용 상태 영역 상호관계
시스템 운용조건에 대한 요구사항은 유스 케이스 또는 상태 구속과 범주뿐만 아니라 그 상태로 이전하기 위한 전이 상태와 모드도 포함된다. 이러한 상태를 잘 이해하기 위해 그림 1을 참조하라.
그림 1에서와같이 시스템은 정상 상태로 운용된다. 이를 위한 시스템 엔지니어의 노력은 신뢰성, 가용성, 유지보수성, 정상 작동을 유지하기 위한 예방과 수정 정비에 필요한 수리 부속품 요구사항을 도출해야 한다.



만일 하나의 상태 또는 이벤트가 임무수행 전, 수행 중 또는 수행 후에 나타난다면, 그 시스템은 (1)에서 비정상 상태로 전이해 간다. 정상 상태에서 (3)을 통해 위기 상태로 전이될 수도 있다. 실제 그림 1은 위기 상태로 이전하기 전에 비정상 상태가 선행하게 되어있다.
비정상 상태 기간 중, 시스템 또는 운용자가 회복 상태, 수정 또는 제거를 통해 정상적인 상태(2)로 전환토록 노력해야 한다. 비정상 작동 시, 위기상태나 이벤트가 위기 모드 작동 (3)이 발생되어도 된다. 시스템과 위기 이후 건강 상태에 따라 그 시스템은 비정상 상태(4)로 되돌아갈 수 있다.
만일 위기 작동이 실패한다면, 그 시스템은 천재지변 이벤트를 가져오게 된다. 이는 천재지변 모드 작동(6)을 가리킨다.

4. 운용상태 영역과 시스템 요구사항 관계
시스템과 그의 임무 적용에 따라 시스템 성능규격서(SPS)가 사람, 재산, 환경 안전을 도모하는 상태를 나타내기 위하여 능력과 성능 요구사항을 제시해야 한다. 이러한 SPS에서 정상, 비정상, 위기, 천재지변 운용을 제시하고 있는가. 일반적으로 그렇지 않다. 대신에 이러한 상태 유형의 요구사항은 SPS를 통해 배포된다. 그러나 좋은 사례로써 획득자와 시스템 개발자는 SPS 요구사항을 잘 고려하여 포함된 상태로 연결하기 위한 여러 유형의 문서를 유지한다.

5. 운용상태 영역 요구사항 정의 실패
운용환경에 대한 물리적 상태를 시스템 불가능 조건으로 과장하는 경우가 많이 발생하고 있다. 왜냐하면, 이러한 조건과 시나리오 요구사항이 무시, 과장 또는 잘 발생되지 않는 경우로 가정하기 때문이다.

6. 운용상태 요구사항을 시스템 요소로 할당
당신이 SPS를 작성할 때, 시스템은 정상, 비정상, 위기, 또는 천재지변 상태를 예상 범위 내에서 수용해야 한다는 사실을 주목하라. 여기서 ‘시스템’은 운용 단어임을 주목하라. 따라서 시스템은 모든 시스템 요소를 나타내고 있음을 잊지 마라. 궁극적으로 장비라고 말할 때, 시스템 엔지니어는 몇 가지 상태 요구사항을 안전 요구사항을 충족시키고 개발비용을 줄이는 절차 데이터, 인력, 임무자원, 지원 시스템으로 책임과 권한을 할당한다.

‌요구사항 계층 구조

시스템 성능규격서(SPS) 요구사항은 일반적으로 상위레벨, 임무중심의 요구사항 문서이다. 3단계 상위레벨 문서는 보다 높은 상위레벨 요구사항 내용을 더욱 분명하게 하고 구속하며 규격으로 제시하는 하위레벨 요구사항으로 계속해서 더 세분화해 간다. 사실상, 요구사항 계층 구조가 형성되어 간다.
반면에 많은 사람은 요구사항이란 임의적인 생각 또는 희망 사항 목록으로 제시되지 않는다고 믿고 있다. 이러한 생각에 대한 분명한 사실은 규격서가 작성된다는 것으로 이해할 수 있다. 우리는 이 사항을 규격서 개발 실무에서 다루기로 한다. 대신에 규격서는 계층 구조적인 연결방식으로 구성되고 체계화된다. 이리하여 그 구조는 요구사항을 하나 또는 둘 이상의 소스 또는 원류 요구사항으로 추적할 수 있도록 참조 절차를 제공한다.
우리는 그림 2와 같이 이러한 요구사항 계층 구조를 그래프로 나타낼 수 있다.



각각의 요구사항이 보다 높은 상위레벨 요구사항으로 추적할 수 있도록 연결사항을 보여주는 상호관계를 번호로 나타내고 있다.

[예제 2] 모 능력 요구사항, R1은 세 가지 형제 관계 능력 요구사항, R11, R12, R13으로 나뉜다. 이러한 번호를 부여하는 방식은 각 레벨의 오른쪽에서부터 번호를 부여하고 “__1”과 같은 순서로 시작한다. 이리하여 숫자 순으로 각 요구사항에 대하여 번호를 부여하는 “족보”를 형성할 수 있다. 요구사항 족보, R31223은 R3-R31-R312-R4122- R31223으로 연계된다.

위에서 나타난 계층은 모든 요구사항이 적합하게 더 높은 상위레벨 요구사항으로 연계되어 있음을 보여주는 가장 이상적인 경우이다. 논의를 위해 요구사항 연결성을 보여주기 위해 이러한 도표를 사용한다는 사실을 생각하기 바란다. 요구사항은 시스템과 임무 레벨에서의 효과도 측정(MOE), 적합성 측정(MOS), 성과 측정(MOP)으로부터 도출되고 이를 추적할 수 있어야 한다.
MOE, MOS, MOP에 대한 보다 상세한 사항은 운용 효용성, 적합성, 효과도 실무를 참조하기 바란다.
시스템 임무는 그림 2에서의 최상위 레벨 요구사항을 나타낸다. 임무는 R1, R2, R3 세 가지 상위레벨 능력 요구사항으로 구속되고 범주를 제시하여 기술한다. R12, R32, R33과 같이 단독 요구사항일 경우, 그 연결 체인이 끝이 난다. 때로 “테(leaf)”로 불리는 요구사항으로 사용된다.
이와 같이 이론적인 능력 요구사항 계층구조에 대한 기본적인 이해로부터 우리는 규격서 요구사항과 연관된 공통적인 문제점을 알아내는 데 매우 유익하게 사용할 수 있다.

규격서 요구사항의 공통적인 문제점

종종 규격서는 수많은 에러, 결점, 결함을 가지고 무의식적으로 불완전하게 제시되고 있다. 이러한 상태를 알아보기 위해 규격서에 공통적으로 나타나는 일련의 불완전한 상태를 사례로 살펴보자.
일찍이 우리는 많은 사람이 규격서를 표준화된 구조로 나타난 생각이나 희망 사항 목록으로 제시하고 있다고 앞에서 예기했다. 이러한 형태의 요구사항은 비공식에서 공식적인 의견수렴 절차를 따라 진화해 간다. 이러한 과정에서 제시된 요구사항은 검토용으로 발간된다. 이러한 검토 기간에 해당 구조에 자신이 원하는 항목을 추가하기 위해 많은 검토자와의 로비가 시작된다.
요구사항은 추가 예산이 반영되지 않으면, 규격서에 이를 추가할 수 없다. 각 요구사항은 이를 수용하기 위한 하드웨어 또는 소프트웨어에 대한 비용이 필요하다는 사실을 유념해야 한다. SPS 레벨에서 요구사항 변경은 계약 수정사항으로 반영되어야 한다. 시스템 개발자 조직에서 추가 요구사항이 발생되면 이와 연동한 비용 및 일정 수정활동이 동시에 이루어져야 한다.
만일 당신이 규격서 산출물을 분석한다면, 최소한 다음 네 가지 문제 형태를 전형적으로 살펴보아야 한다.

· 문제 1 : 능력 요구사항 누락
· 문제 2 : 능력 요구사항 위치 조정
· 문제 3 : 규격 요구사항 충돌
· 문제 4 : 요구사항 중복

그림 2는 에러, 결함 및 결점을 나타내는 이러한 상태를 제시해 주고 있다. 이러한 네 가지 상태는 몇 가지 공통 문제점 요구사항 분석으로 가능하고 시스템 엔지니어는 이러한 활동을 수행하게 된다. 나아가 다음 두 가지 경우를 더 고려해 볼 수 있다.

· 시스템 엔지니어, 규격서 요구사항 분석가, 및 이해관계자를 당신이 최종 적용 여부를 계약적으로 이행하기 전에 분석, 준비, 검토하는 방법을 공식적으로 훈련시키는 것이 왜 중요한가를 생각하라.
· 규격서 검토를 왜 이해관계자와 함께해야 하는지 그 이유를 생각하라. 사람들이 가끔 규격서를 처음부터 끝까지 또는 일부분을 읽어볼 때, 문법이나 사용한 텍스트에 따라 다르게 해석하는 경우가 발생된다는 사실을 유의하라.

지침

요약해서 이 장에서 논의된 사항은 규격서 요구사항 실무에 도움을 주는 여러 가지 지침을 설정해 준다.

[지침 1] 모든 규격서는 다음 네 가지 시스템 상태를 나타내는 형태를 보여주고 있다.
1. 정상작동
2. 외부 시스템 고장
3. 불량 작동
4. 내부 시스템 고장

요약

규격서 요구사항에 대한 논의는 규격서 문서에 포함된 요구사항 형태에 대한 개요를 제공해 주고 있다. 나중에, 이는 내부 형상품목(CI) 또는 외부 벤더로부터 제공되는 비개발 품목(NDI) 조달에 대한 요구사항 결정에 기초가 된다.

1. 일반적 예제

1) 개요에서 우리가 이해해야 할 질문사항에 대하여 다시 한 번 생각해 보아라.
2) 앞 장에서 논의했던 일반적인 시스템 또는 신규 시스템에 대하여 이 장에서 제시한 내용을 적용해 보아라. 네 가지 운용상태(정상, 비정상, 위기, 천재지변)에 대하여 선정된 시스템을 식별하고 기술해 보라.

2. 조직 중심 예제

1) 당신 조직 내에서의 여러 가지 계약 프로그램을 알아보라. 각 프로그램에 대하여 시스템성능규격서(SPS)를 분석 후, 다음 질문사항을 답해 보라.

· 운용 요구사항 다섯 가지를 식별해 보라.
· 능력 요구사항 다섯 가지를 식별해 보라.
· 비기능 요구사항 다섯 가지를 식별해 보라.
· 검증 요구사항 다섯 가지를 식별해 보라.
· 설계 및 제작 제약사항 다섯 가지를 식별해 보라.
· 한계 및 목표 요구사항이 식별되어 있는가.

2) 프로그램의 기술 관리자와 시스템 엔지니어와 협의하여 시스템 성능규격서 요구사항이 어떻게 이해관계자로부터 수집되고 도출되었는지를 알아보라. 그리고 그 결과를 문서화하라.

3) 프로그램 참여자들이 다음 사항에 대하여 얻은 교훈이 무엇인지를 제시하고 이를 어떻게 해결하였는지를 제시하라.

· 누락된 요구사항
· 위치가 잘 못된 요구사항
· 충돌된 요구사항
· 중복된 요구사항
· 비기능적인 요구사항
· 검증 요구사항

4) 규격서 결점과 결함을 추적하기 위하여 사용된 측정방법은 무엇인가.

5) 분석계약 프로그램에 사용된 규격서를 선정하고 이 장에서 제시된 개념을 사용하여 해당 규격서에 결점과 결함을 식별하고 규격서 개발자의 도움을 받아 향상 대책을 제시해 보라.

6) 계약된 규격서를 분석하고 의사결정을 위해 선행적으로 검토해야 할 요구사항을 식별해 보라.

7) 계약 프로그램에 대하여 SPS 이해관계자가 제시된 요구사항을 인지하고 있는지를 알아보라. 그리고 해당 이해관계자와 함께 요구사항 추정을 통한 우선순위를 제시해 보라.