시스템 요구 사항 정의 프로세스는 이해관계자가 원하는 기능을 기술적이고 개발자 중심의 관점으로 변환하여 시스템이 이러한 기능을 어떻게 달성할 수 있는지 설명합니다. 시스템 요구 사항은 SoI(System of Interest, 개발 대상 시스템)이 이해관계자의 요구를 충족하기 위해 반드시 충족해야 할 사항을 설명하며, 잘 구성된 텍스트 진술과 지원 모델 또는 다이어그램의 적절한 조합으로 표현됩니다.
시스템 요구 사항은 시스템 엔지니어링에서 다음과 같은 중요한 역할을 합니다:
- 시스템 아키텍처 및 설계 활동의 기초를 형성합니다.
- 시스템 통합 및 검증 활동의 기초를 형성합니다.
- 프로젝트 전반에서 상호작용하는 여러 프로젝트 팀 구성원 간의 의사소통 수단을 제공합니다.
시스템 요구 사항 정의 프로세스의 출력물은 시스템 설계 정의, 시스템 아키텍처 정의, 시스템 검증을 포함한 여러 기술적 프로세스의 입력으로 사용됩니다.
시스템 요구사항 vs. 소프트웨어 요구사항 차이점
| 구분 | 시스템 요구사항 | 소프트웨어 요구사항 |
| 범위 | 시스템 요구 사항은 전체 시스템을 대상으로 하며, 하드웨어와 소프트웨어 모두를 포함하는 요구 사항을 다룹니다. | 반면, 소프트웨어 요구 사항은 소프트웨어 구성 요소에 국한된 요구 사항입니다. |
| 구체성 | 시스템 요구 사항은 상위 수준의 요구 사항으로, 시스템이 무엇을 해야 하는지에 초점을 맞춥니다. | 소프트웨어 요구 사항은 시스템에서 정의된 요구사항 중 소프트웨어로는 무엇을 구현되어야 하는지에 대한 세부적인 내용을 정의합니다. |
| 연관성 | 시스템 요구 사항에서 정의된 기능 중 일부는 소프트웨어로 구현되어야 할 수도 있고, 일부는 하드웨어로 구현될 수도 있습니다. | 소프트웨어 요구 사항은 시스템 요구 사항 중 소프트웨어와 관련된 부분을 구체화하는 역할을 합니다. |
1. 원칙과 개념 (Principles and Concepts)
시스템 요구 사항 정의는 시스템 개념 정의 활동의 결과물을 사용하여 시스템이 무엇을 해야 하는지, 즉 개발 대상 시스템이 통합된 요구 사항을 실현하기 위해 수행해야 할 작업을 다룹니다. 그림 1에서 보듯, 이러한 시스템 요구사항 정의 결과는 시스템 아키텍처 정의, 시스템 설계 정의, 그리고 시스템 검증 프로세스의 입력으로 제공됩니다.
요구 사항을 정의하는 것은 단순한 글쓰기 작업이 아니라, 엔지니어링 작업입니다. 각 요구 사항은 개발 대상 시스템이 수행해야 할 작업이나 시스템이 가져야 할 품질을 결정하는 엔지니어링 판단을 의미합니다. 이러한 요구 사항은 필요를 충족하기 위해 시스템이 무엇을 해야 하는지 결정하는 세부 요구 사항 분석 과정을 통해 도출됩니다. 이 과정에서는 모델, 시뮬레이션, 프로토타입의 개발 및 사용이 포함될 수 있습니다.
요구 사항에 기술된 문장은 “지정된 제약 조건 내에서 허용 가능한 위험과 함께 일부 기능을 수행하거나 일부 품질을 보유하도록 하는 합의된 의무로 하나 이상의 요구 사항 또는 상위 요구 사항을 공식적으로 변환한" 결과입니다. (INCOSE NRM 2022). 여기서 ‘품질’이라는 용어는 고유한 특징이나 두드러진 속성을 의미합니다.
여러 종류의 요구 사항이 있지만, 여기서는 시스템 아키텍처 및 시스템 설계 정의 프로세스의 입력으로 사용되는 요구 사항을 설명합니다. 이러한 요구 사항은 설계 입력 요구 사항이라고도 하며, 통합 시스템이 하위 시스템 및 시스템 요소로 분해됨에 따라 반복적이고 재귀적으로 정의됩니다(개발 대상 시스템은 시스템 아키텍처의 어느 수준에서든 존재할 수 있습니다).
2. 시스템 요구사항 생성 프로세스 (Process for Generating System Requirements)
2.1 요구 사항으로의 니즈 변환
시스템 요구 사항 정의 활동은 통합된 니즈(Needs) 집합을 개발 대상 시스템에 대한 요구 사항으로 변환하는 것에서 시작됩니다. 이러한 요구 사항은 개발 대상 시스템이 시스템 아키텍처 내에서 존재하는 수준에 적합해야 하며, 개발 대상 시스템이 요구 사항을 충족하기 위해 무엇을 해야 하는지를 정의합니다. 여기서 중요한 점은 개발 대상 시스템에 대한 물리적 실체화을 위한 구현 요구 사항은 제외합니다.
니즈(Needs)란?
이해 관계자가 개발 대상 시스템에 대해 외부에서 기대하는 것, 즉 블랙박스 관점에서 시스템이 무엇을 해야 하는지에 대한 기대를 정의한 것입니다.
예: 사용자는 커피 메이커가 사용자가 선택한 온도에 도달하면 물을 더 이상 가열하지 않기를 원합니다.
니즈의 출처는 이해관계자의 니즈 정의에서 기인합니다. 이해관계자 니즈 정의에는 이해관계자의 기대와 요구 사항, 동인과 제약 조건, 위험 분석, 생애 주기 개념 분석 및 성숙화 활동이 포함됩니다. 이러한 니즈는 시스템 요구 사항 정의 프로세스의 입력으로 처리되며, 개발 대상 시스템에 대한 설계 입력 요구 사항 세트로 이어집니다.
요구사항(Requirement)이란?
개발 대상 시스템이 이해관계자의 니즈를 충족하기 위해 내부에서 해야 할 일을 정의하는 기술적이고 개발자 중심의 관점에서 작성됩니다.
예: 커피 메이커는 선택된 브루 온도에 도달하면 가열 기능을 멈추어야 한다.
요구 사항을 작성하는 과정은 단순히 필요 진술의 주체를 사용자에거 개발자 관점으로 바꾸는 것이 아니라, 시스템이 요구를 충족하기 위해 해야 할 작업을 분석하는 것입니다. 이를 결정하기 위해 다양한 분석 및 도구가 사용됩니다:
- 기능 분석 (Functional Analysis)
- 인터페이스 분석 (Interface Analysis)
- 데이터 흐름 다이어그램 (Data Flow Diagram)
- 성능 분석 (Performance Analysis)
- 니즈 변환 매트릭스 (Needs to Transformation Matrix)
기능 및 성능에 대한 요구 사항 분석은 모델 기반 시스템 엔지니어링(MBSE) 애플리케이션을 지원하는 시스템 모델을 사용하여 수행할 수 있습니다. 주요 모델 뷰에는 활동 다이어그램, 시퀀스 다이어그램, 상태 기계 다이어그램, 구조 다이어그램(계층 및 인터페이스용)이 포함됩니다. 기능 분석의 예시는 그림 2에 나타나 있습니다.
정확한 변환을 보장하고 추적 가능성을 유지하기 위해 이해관계자와의 긴밀하고 빈번한 협력이 필요합니다. 이로 인해 시스템 실체화의 기초가 될 수 있는 측정 가능한 특성을 전달하는 시스템 요구 사항 세트가 생성됩니다. 하나의 니즈에 대한 진술의 세부 분석은 해당 니즈를 충족하기 위해 시스템이 수행해야 할 여러 요구 사항으로 이어질 수 있으며, 측정 가능한 성능 기준의 정의를 포함할 수 있습니다 (INCOSE NRM 2022).
2.2 속성의 사용
속성은 요구사항 개체와 관련된 추가 정보로, 요구사항 개체의 정의와 관리를 돕는 데 사용됩니다. 잘 선택된 속성은 적절하게 정의되고 추적될 때, 시스템 생애 주기 동안 요구 사항을 올바르게 해석하고 관리하는 데 도움을 줄 수 있습니다. 고려할 수 있는 몇 가지 유용한 속성은 다음과 같습니다:
- 근거(Rationale),
- 출처 또는 상위 요소와의 추적성(Trace to source or parent),
- 시스템 검증 성공 기준(System verification success criteria),
- 소유자(Owner),
- 카테고리(Category),
- 상태(Status),
- 중요도(Criticality),
- 우선순위(Priority).
근거 속성을 사용하면 요구 사항이 왜 필요한지, 가정된 사항, 수치의 출처, 관련 설계 연구 결과 또는 기타 관련된 지원 정보 등을 전달하는 데 도움을 줍니다. 이는 추가적인 요구 사항 분석 및 분해를 지원하며, 요구 사항 값의 출처를 식별하는 데 도움이 됩니다.
시스템 검증 성공 기준을 정의하는 것은 요구 사항이 잘 구성되었고, 검증 가능하며, 프로젝트의 검증 프로그램 계획에 도움을 주는지 확인하는 데 도움이 됩니다 (INCOSE NRM 2022).
2.3 요구 사항 분류
요구 사항을 체계적으로 정리하는 것은 유용하며, 유사한 유형의 요구 사항을 하나의 집합 내에서 그룹화할 수 있습니다. 조직마다 분류 방식은 다를 수 있지만, 요구 사항 집합이 완전하려면 다음 각 카테고리 주제를 모두 다루어야 합니다.
- 기능적 요구 사항: 시스템이 수행해야 하는 기능을 정의.
- 성능 요구 사항: 시스템이 어느 정도의 성능을 보여야 하는지 설명.
- 인터페이스 요구 사항: 시스템이 다른 시스템과 어떻게 상호작용하는지 규정.
- 안전 요구 사항: 시스템이 어떻게 안전하게 작동해야 하는지에 대한 기준.
- 보안 요구 사항: 시스템이 어떻게 보안을 유지해야 하는지 규정.
- 규정 준수 요구 사항: 표준, 법적 요구 사항에 대한 준수.
- 운영 요구 사항: 시스템이 예상 운영 환경에서 어떻게 사용될 것인지 정의.
- 유지보수 요구 사항: 시스템이 어떻게 유지 관리되고 업데이트될지 설명.
이러한 요구 사항을 카테고리화하면 명확한 요구 사항 관리를 가능하게 하며, 각 영역의 요구 사항이 모두 포함되었는지 확인하는 데 도움이 됩니다.
| 분류 | 설명 |
| 기능/성능 | 개발 대상 시스템이 의도된 사용 목적에 맞춰 수행해야 할 주요 기능과 관련된 성능을 정의합니다. 기능은 이해관계자들이 SoI가 갖추기를 기대하는 기능과 특징을 다루며, 성능은 해당 기능이 얼마나 잘, 얼마나 많이, 얼마나 빠르게 작동해야 하는지에 대한 속성을 설명합니다. 많은 주요 기능은 개발 대상 시스템과 외부 시스템 간의 상호작용(인터페이스)을 포함합니다. 이 카테고리에는 모든 중요한 및 높은 우선순위의 요구 사항이 포함됩니다. |
| 적합성/운영성 | 개발 대상 시스템 기본 기능을 수행하기 위해 필요한 부가적 또는 지원 기능, 외부 시스템과의 상호작용을 다룹니다. 여기에는 시스템이 인터페이스를 통해 다른 시스템과 연결하고 상호작용하며, 매크로 시스템의 일부분으로 통합되어 운영될 수 있는 능력이 포함됩니다. 적합성에는 인간-시스템 상호작용 및 인터페이스뿐만 아니라 유도된 환경과 자연 환경(운영, 운송, 저장, 유지보수 조건)이 포함됩니다. 예를 들어, 안전성, 보안, 전원, 냉각, 운송 및 취급, 저장, 유지보수, 폐기와 관련된 요구 사항이 해당됩니다. |
| 형태 | 개발 대상 시스템의 물리적 특성을 정의합니다. 이는 시스템을 고유하게 구별하는 모양, 크기, 치수, 질량, 무게 및 기타 관찰 가능한 매개변수를 포함합니다. 소프트웨어의 경우, 형태는 프로그래밍 언어, 코드 라인 수, 메모리 요구 사항 등을 다룰 수 있습니다. |
| 품질 | 사용 적합성 또는 “품질”을 정의합니다. 예를 들어, 신뢰성, 시험 가능성, 운영성, 가용성, 유지보수성, 지원성, 개발 가능성, 상호운용성 등 다양한 “~ility” 속성을 포함할 수 있습니다. |
| 준수성 | 설계 및 개발 표준 및 규정을 준수하는지를 다룹니다. |
다음은 시스템 요구사항 작성 예입니다.
| 요구사항 ID | 요구사항 제목 | 요구사항 | 근거(Rationale) | 분류 |
| R1 | 가변 온도 설정 | 커피 메이커는 사용자가 선택할 수 있는 두 가지 커피 추출 온도를 제공해야 합니다: 미지근함: 96°C +/- 2°C, 뜨거움: 100°C+/- 2°C. | 선택 가능한 온도에 대한 포커스 그룹 입력을 기반으로, 값은 소비자 조사 및 안전 규정을 바탕으로 한 분석 결과입니다. | 기능/성능 |
| R2 | 용기가 없을 경우 추출 금지 | 커피 용기가 추출 위치에 완전히 삽입되지 않은 경우, 커피 메이커는 추출 기능을 금지해야 합니다. | 비정상 사용 사례와 관련된 보호 조치입니다. | 기능/성능 |
| R3 | 운영 수명 | 커피 메이커는 3년 이상의 운영 수명을 가져야 합니다. | 분석에 따르면 3년 동안 1,000시간의 예상 운영 서비스가 보장되며, 이는 가전 제품이 보증 기간 동안 지속될 수 있음을 보장합니다. | 품질 |
| R4 | 사용자 입력 | 커피 메이커는 사용자의 입력을 다음으로 제한해야 합니다: 전원 켜기, 추출 온도, 추출 크기, 추출 시작. | 사용자 입력은 포커스 그룹에서 최소한의 입력 세트로 평가되어, 커피 메이커의 전체 생애 주기 개념을 달성할 수 있도록 구성되었습니다. | 적합성/운영 |
2.4 계층 내에서의 요구 사항
요구 사항 정의는 아키텍처 정의 프로세스와 동시에 수행되는 반복적이고 재귀적인 과정입니다. 시스템 계층 구조가 결정되면, 시스템 수준의 요구 사항과 계층 구조 하위 요소에서 이를 지원하는 요구 사항을 나타내는 요구 사항 트리를 수립할 수 있습니다. 그림 3은 시스템 요구 사항에서 하위 수준 요구 사항으로의 흐름을 예시하고, 그림 4는 요구 사항 트리의 예시를 보여줍니다.
할당(Allocation)은 물리적 아키텍처의 한 수준에서 요구 사항이 다음 하위 수준의 엔터티에 할당되는 과정입니다. 이러한 엔터티는 할당된 요구 사항의 구현에서 역할을 수행합니다. 이 과정은 프로젝트 팀이 아키텍처의 다음 수준에 있는 각 하위 시스템이나 시스템 요소가 할당된 요구 사항의 구현에서 어떤 “역할”을 하는지 결정하는 분석을 포함합니다. 하위 수준에서 생성된 요구 사항은 할당된 상위 요구 사항의 하위 요구 사항(child requirements)으로 간주됩니다.
할당과 관련된 중요한 개념 중 하나는 예산 책정(budgeting)입니다. 예산은 시스템 수준에서 정의된 매개변수의 총 값을 나타냅니다. 시스템 요구 사항 값은 하위 요소들이 그들의 기여를 통해 시스템 수준의 총 값을 달성할 수 있도록 분해될 수 있습니다. 예산 책정된 양은 상호 의존성을 가지며, 하나의 값이 변경되면 다른 값도 변경해야 합니다. 예산 책정 값에는 질량(무게), 전력 사용량, 대역폭, 시간, 품질 속성이 포함될 수 있습니다.
3. 시스템 요구사항을 거버닝하는 원칙
3.1 인터페이스 및 상호작용 다루기
아키텍처의 각 부분에 대해, 외부 인터페이스 다이어그램은 SoI(관심 시스템)과 외부 시스템 간의 상호작용을 다룰 수 있는 기능을 제공합니다(그림 5 참조).
인터페이스 요구 사항이라는 용어는 다른 시스템과의 인터페이스 경계를 넘는 상호작용과 관련된 기능적 요구 사항의 특정 형태 또는 템플릿을 나타냅니다. 인터페이스 요구 사항을 작성하는 과정은 세 가지 단계로 이루어집니다(INCOSE NRM 2022):
- 인터페이스 경계와 해당 경계를 넘는 상호작용을 식별합니다.
- 인터페이스 경계를 넘는 상호작용을 정의합니다(경계를 넘는 특성과 관련 매체를 정의).
- 인터페이스 요구 사항을 작성합니다.
인터페이스 요구 사항 예시: 시스템은 ICD 123, 표 X에 정의된 대로 지상 시스템에 원격 측정 데이터를 전송해야 한다.
3.2 모델 형식의 요구사항
요구 사항은 문서, 데이터베이스, 또는 모델의 형태로 기록하고 관리할 수 있습니다:
- 모델은 기능, 해당 기능에 대한 입력, 입력의 출처, 출력, 그리고 출력의 고객(목적지/사용자)에 관한 완전성을 다룰 수 있는 기능을 제공합니다.
- 모델은 복잡한 시스템과 프로세스를 더 쉽게 이해할 수 있게 하여 의사소통을 촉진합니다(“그림 한 장이 천 마디 말보다 낫다”는 속담처럼).
- 모델은 요구 사항과 시스템 데이터셋의 다른 측면(입력, 요구 사항, 아키텍처, 테스트 케이스 등) 간의 상호 의존성을 포착할 수 있게 합니다.
- 모델은 정량적 분석과 시뮬레이션 실행을 가능하게 합니다.
모델 기반 시스템 엔지니어링(MBSE)에서는 요구 사항의 모델 형식을 다이어그램(그림 6)이나 모델링 도구 내의 표(그림 7)로 표현할 수 있으며, 이때 잘 구성된 텍스트 진술을 요구 사항 모델 요소의 일부로 사용합니다. 요구 사항 관리에 대한 추가 가이드는 텍스트와 모델 요구 사항과 관련된 도구 사용법을 참조하십시오.
3.3 Unknown 다루기
초기에 요구 사항 세트를 생성할 때, 추후 분석이 필요해 실제 값을 결정해야 하는 매개변수들이 존재할 수 있습니다. 이를 처리하는 일반적인 방법 중 하나는 요구 사항 진술에 플레이스홀더를 사용하여 해당 요구 사항이 초안 상태임을 표시하고, 완전한 요구 사항으로 간주되기 전 추가 작업이 필요함을 나타내는 것입니다. 값이 알려지지 않은 경우, 일반적으로 “추후 결정(To Be Determined, TBD)” 표시를 사용해 실제 값 대신 요구 사항 진술에 표기합니다. 값이 결정되었지만 확신이 낮은 경우(예: 타당성 평가가 이루어지지 않음), 이를 반영하는 방법으로 값 옆에 “추후 해결(To Be Resolved, TBR)” 표시를 사용할 수 있습니다. TBD와 TBR을 합쳐 “TBX”라고 통칭합니다.
TBX를 추적하면 요구 사항이 생애 주기 동안 얼마나 성숙했는지 알 수 있으며, 이는 통합된 요구 사항 세트와 설계 입력 요구 사항 세트의 완료 및 성숙도를 평가하는 귀중한 지표가 됩니다.
TBX는 프로젝트 팀이 설계 솔루션을 확립하기 전까지 해결하지 않으면 위험을 초래할 수 있습니다. TBX 관리는 요구 사항 세트에서 TBX를 식별하고, 문제 해결을 위한 작업을 정의하며, 해당 작업의 소유자를 지정한 다음, 체계적으로 반복하며 작업을 완료해 요구 사항에서 이러한 플레이스홀더를 제거하는 과정을 의미합니다.
3.4 추적성
추적성은 설계 입력 요구 사항을 관리하는 강력한 방법으로, 특히 특정 수준 내의 하위 시스템 및 시스템 요소 간뿐만 아니라 생애 주기 전반에 걸쳐 요구 사항을 관리하는 데 매우 유용합니다. 추적성은 요구 사항이 그들의 필요에 맞게 작성되었는지, 그리고 올바르고 완전한지 확인하는 데 도움을 줍니다. 또한, 추적성은 요구 사항이 아키텍처의 하위 수준 시스템 요소에 어떻게 할당되는지 식별하는 데도 도움이 됩니다. 생애 주기 동안 요구 사항이나 다른 데이터 유형의 변경이 미치는 영향을 평가할 수 있어, 그 변화가 유익한지 또는 비용이 많이 드는지에 대한 통찰력을 제공합니다.
프로젝트 초기에 추적 관계 모델을 정의하면 개발 대상 시스템 개발 과정에서 어떤 관계가 설정되고 추적성을 통해 관리될 것인지 이해할 수 있습니다.
3.5 요구사항 검증 계획
프로젝트가 시스템 검증을 어떻게 수행할 것인지에 대한 조기 계획을 수립하는 것은 매우 중요합니다. 요구 사항이 생성될 때 시스템 검증 성공 기준, 전략, 방법을 정의하면, 요구 사항 진술이 적절하게 표현되고, 프로젝트 계획 범위 내에서 검증 가능하다는 특성을 갖추었음을 확인할 수 있습니다. 이러한 정보는 요구 사항에 정의된 속성에 포함시켜 관리할 수 있습니다.
3.6 요구 사항 평가
요구 사항은 잘 구성되었는지, 그리고 변환된 필요 사항의 의도를 충족하는지 평가해야 합니다. 요구 사항 평가와 관련된 개념은 “요구 사항 검증”과 “요구 사항 확인”이라는 용어로 설명되며, 이는 시스템 검증 및 시스템 확인과는 다른 개념입니다.
- 요구 사항 검증 활동은 다음 질문에 답합니다: 요구 사항이 잘 구성되었는가? 즉, 개별 요구 사항과 요구 사항 집합이 조직의 잘 구성된 요구 사항 기준에 정의된 특성을 가지고 규칙을 따르고 있는가?
- 요구 사항 확인 활동은 다음 질문에 답합니다: 우리가 적절한 요구 사항을 가지고 있는가? 즉, 요구 사항이 그들이 변환된 필요 사항, 상위 요구 사항, 기타 출처의 의도를 명확하게 전달하고 있는가? 이는 아키텍처 정의, 설계 정의, 제조/코딩 팀이 이해할 수 있는 언어로 되어 있는가? 확인은 요구 사항이 정확하고 달성 가능한지 여부를 다룹니다.
여러 가지 방법을 사용하여 요구 사항을 검증하고 확인할 수 있습니다. 예를 들어, 표준 동료 검토 기법, 요구 사항 특성과 통합된 필요 세트를 기준으로 한 각 요구 사항의 비교 등이 있습니다. 텍스트 형식으로 전달된 요구 사항의 경우, 잘 구성된 요구 사항을 작성하기 위한 가이드라인이 존재하며, 여기에는 요구 사항 진술의 구문, 표현 방식(배제, 개념 표현 등), 특성(구체적, 측정 가능, 달성 가능, 실행 가능, 테스트 가능 등)에 대한 권장 사항이 포함됩니다(INCOSE GtWR 2023).
'System Engineering > SEBoK (System Eng. Body of Knowledge)' 카테고리의 다른 글
| SEBoK: 시스템 분석 (System Analysis) (2) | 2024.10.22 |
|---|---|
| SEBoK: 물리 아키텍처 (Physical Architecture) (2) | 2024.10.21 |
| SEBoK: 논리 아키텍처 (Logical Architecture) (1) | 2024.10.20 |
| SEBoK: 기능 아키텍처 (Functional Architecture) (0) | 2024.10.19 |
| SEBoK: 시스템 아키텍처 설계 (System Architecture) - 정의, 설계, 모델링, 개요 (1) | 2024.10.19 |