요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다.
국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “필수성(Necessary)”은 모든 요구사항이 시스템의 목표 달성에 반드시 필요한 요소만을 포함해야 한다는 원칙을 의미합니다.
이번 포스팅에서는 INCOSE GWR에서 언급하는 요구사항의 필수성이 무엇이고, 왜 중요한지, 그리고 이를 평가하는 방법에 대해 알아보도록 하겠습니다.
INCOSE 요구사항 작성 가이드 (Guide to Writing Requirements, GWR)
관련글 더 보기
소프트웨어 요구사항 모호성 & 일관성 해소: EARS (Easy Approach to Requirements Syntax)와 Glossary 활용
소프트웨어 공학: 니즈(Needs) vs. 요구사항(Requirements)
시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Requirements Specification, MBRS)
ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)
필수성(Necessary, C1)
요구사항이 “필수적(Necessary)“이라는 것은 해당 요구사항이 시스템의 목표 달성에 있어 필수적인지를 검토해야 한다는 의미입니다
니즈(Need) 문장 또는 요구사항(Requirement) 문장은 생명 주기 개념(lifecycle concept), 니즈(need), 원천(source), 또는 상위 요구사항(higher-level requirement)을 충족하는 데 필요한 기능, 특성, 제약 사항, 또는 품질 요소를 정의해야 합니다.
검토 중인 문장이 니즈 집합(Set of Needs) 또는 요구사항 집합(Set of Requirements)에 포함되지 않는다면, 시스템의 기능 또는 특성에 결함이 발생하며, 해당 결함은 기존의 다른 니즈 또는 요구사항을 구현하는 것으로는 해결될 수 없습니다.
모든 니즈 및 요구사항을 실현하는 데는 개발, 검토, 관리, 구현, 설계 검증(Design Verification), 설계 확인(Design Validation), 시스템 검증(System Verification), 시스템 확인(System Validation), 유지보수(Maintenance), 폐기(Disposal) 등의 자원, 노력, 비용이 필요합니다.
불필요한 니즈와 요구사항이 포함될 경우, 다음과 같은 부정적인 결과가 발생할 수 있습니다.
- 부가적인 비용과 불필요한 리스크 발생
- 설계 가능성을 부적절하게 제한하여 최적의 솔루션을 방해
- 불필요한 요구사항의 개발, 관리, 구현, 검증, 확인으로 인한 프로그램 비용 증가
- 과도한 요구사항으로 인해 시스템 성능이 저하되고, 실현 불가능한 솔루션으로 이어질 위험 증가
특히, 불필요한 요구사항이 포함될 경우, 전체 시스템의 성능이 저하될 수 있으며, 필수적인 니즈 및 요구사항을 충족하지 못하는 결과를 초래할 수 있습니다. 또한, 불필요한 요구사항이 포함될 경우, 요구사항 집합(Set of Requirements)의 실현 가능성(Feasibility, C12)이 저해될 수 있습니다.
다음과 같은 경우, 특정 니즈나 요구사항은 불필요한 것으로 간주될 수 있습니다.
- 해당 요구사항을 제거하더라도 시스템의 생명 주기 개념 또는 니즈가 여전히 충족될 수 있는 경우
- 해당 요구사항이 다른 요구사항을 통해 충족될 수 있는 경우
- 해당 요구사항이 원천(source), 니즈(need), 또는 상위 요구사항(higher-level requirement)과 연결되지 않은 경우
- 요구사항 작성자가 해당 요구사항의 유효한 근거(rationale)를 설명할 수 없는 경우
불필요한 요구사항을 방지하기 위해, 다음 사항을 고려해야 합니다.
불필요한 기능 추가 방지(Gold Plating)
필수적이지 않은 기능을 추가하면 개발 비용과 시간이 증가할 수 있습니다.
예: 시스템의 기본 기능과 관계없는 고급 그래픽 기능 추가
요구사항 범위 확장(Needs Creep, Requirements Creep) 방지
프로젝트가 진행됨에 따라 요구사항이 불필요하게 확장되는 것을 막아야 합니다.
예: 초기 요구사항에는 포함되지 않았던 새로운 기능이 점진적으로 추가되는 경우
“자체 생성된(Self-Derived) 요구사항”을 피해야 합니다.
모든 요구사항은 반드시 생명 주기 개념, 시스템 필요성, 미션, 목표, 위험 분석 등의 Source와 연결되어야 합니다.
요구사항이 Source와 연결되지 않으면, 그 필요성이 의심될 수 있습니다.
요구사항 우선순위 설정
모든 요구사항이 동일한 중요도를 가지는 것은 아닙니다. 그러므로 우선순위(Priority), 필수성(Essentiality), 구현 리스크(Risk of Implementation), 핵심 요구사항(Key Driving Requirement) 등의 속성을 사용하여 요구사항을 관리해야 합니다.
최소 기능 제품(MVP, Minimum Viable Product) 접근법 활용
일부 조직에서는 핵심 기능만 포함하는 MVP 방식을 활용하여, 불필요한 요구사항이 추가되는 것을 방지합니다. 이후 단계에서 추가 기능을 고려할 수 있도록 설계합니다.
필수성을 평가하는 방법
요구사항이 정말 필수적인지 평가하기 위해서는 다음과 같은 방법을 사용할 수 있습니다.
1. 시스템 목표와의 연관성 확인
요구사항이 시스템이 달성해야 할 목표와 직접적인 관련이 있는지를 검토해야 합니다.
• 질문 예시: 이 요구사항이 없으면 시스템의 주요 목표를 달성할 수 없는가?
• 검토 방법: 요구사항을 시스템의 최상위 목표와 연결하여 분석
2. 기능적, 비기능적 요구사항과의 관계 평가
요구사항이 특정 기능적 요구사항(Functional Requirement)이나 비기능적 요구사항(Non-Functional Requirement)과 직접적인 연관이 있는지 확인해야 합니다.
• 필수성이 높은 요구사항 예시:
• “시스템은 초당 1,000개의 데이터 요청을 처리할 수 있어야 한다.” (성능 관련 필수 요구사항)
• 필수성이 낮은 요구사항 예시:
• “UI 디자인은 푸른색 계열을 사용해야 한다.” (필수 요구사항이 아닐 가능성이 높음)
3. 요구사항의 비용 대비 가치 분석
요구사항을 충족하기 위해 필요한 개발 비용과 이를 통해 얻을 수 있는 가치를 비교하여 필수성을 판단합니다.
• 비용이 높지만 필수적인 요구사항 예시:
• “응급 의료 시스템의 응답 시간이 1초 이내여야 한다.” → 생명과 직결되므로 필수적
• 비용이 높고 필수성이 낮은 요구사항 예시:
• “사용자 인터페이스에 3D 애니메이션 효과를 추가해야 한다.” → 성능이나 기능에 직접적인 영향을 주지 않는다면 불필요할 수 있음
4. 중복된 요구사항 검토
요구사항 간에 유사하거나 중복되는 요소가 있는지 검토하고, 동일한 기능을 수행하는 두 개 이상의 요구사항이 존재하는 경우 이를 통합하거나 삭제해야 합니다.
5. 이해관계자의 필요 여부 검토
모든 요구사항은 이해관계자의 요구에서 비롯되지만, 이해관계자의 요구가 곧 시스템 요구사항으로 반영되어야 하는 것은 아닙니다. 따라서 이해관계자 요구사항이 실제 시스템 목표와 부합하는지 검토해야 합니다.
마치며...
요구사항의 필수성(Necessary)은 시스템이 목표를 달성하는 데 필요한 요구사항만 포함하고, 불필요한 요구사항을 배제하는 것을 의미합니다. 필수성이 확보되지 않은 요구사항은 개발 비용 증가, 유지보수 부담 증가, 성능 저하 등의 문제를 초래할 수 있으며, 결과적으로 프로젝트의 성공 가능성을 낮출 수 있습니다.
이를 방지하기 위해, 요구사항의 시스템 목표와의 연관성, 기능적 필요성, 비용 대비 가치, 중복성 여부, 이해관계자의 실제 필요성 등을 면밀히 검토하는 과정이 필요합니다.
궁극적으로, SOTIF, ISO/PAS 8800과 같은 안전성 표준을 준수하는 시스템 개발에서도 “필수적인 요구사항만을 명확하게 정의하고 관리하는 것”이 가장 효과적인 접근 방식이 될 것입니다. 요구사항이 불필요하게 많아지면 안전성 평가와 검증 과정도 복잡해지므로, 꼭 필요한 요구사항만을 포함하는 것이 중요합니다.
관련글 더 보기
소프트웨어 요구사항 모호성 & 일관성 해소: EARS (Easy Approach to Requirements Syntax)와 Glossary 활용
소프트웨어 공학: 니즈(Needs) vs. 요구사항(Requirements)
시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Requirements Specification, MBRS)
ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)
'System Engineering > INCOSE GWR' 카테고리의 다른 글
| INCOSE 요구사항 작성 가이드(GWR): Complete (C4) (0) | 2025.03.29 |
|---|---|
| INCOSE 요구사항 작성 가이드(GWR): Unambiguous (C3) (0) | 2025.03.27 |
| INCOSE 요구사항 작성 가이드(GWR): Appropriate (C2) (0) | 2025.03.11 |