요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다.
국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “적절성(Appropriate)”은 소프트웨어 개발과 시스템 설계에서 요구사항이 적절한 수준에서 정의되어야 한다는 원칙을 의미합니다.
이번 포스팅에서는 INCOSE 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)
INCOSE 요구사항 작성 가이드 (Guide to Writing Requirements, GWR)
적절성(Appropriate,C2)
니즈(Need) 문장 또는 요구사항(Requirement) 문장은 해당 엔터티(Entity) 의 수준(추상화 수준, 조직 수준, 시스템 아키텍처 수준)에 적절한 의도와 세부 수준을 가져야 합니다.
니즈는 일반적으로 요구사항보다 더 높은 수준의 추상적 표현으로 작성됩니다.
아래 그림 에서 보는 바와 같이, 수준(Level) 은 조직 내의 계층 또는 시스템 아키텍처 내의 계층(시스템, 서브시스템, 시스템 요소 등)을 의미할 수도 있습니다. 니즈와 요구사항은 조직이나 시스템 아키텍처의 어떤 수준에서든 정의될 수 있지만, 일반적으로 니즈 또는 요구사항은 해당하는 엔터티의 수준에서 표현되어야 하며, 해당 수준에서 검증(Verification) 또는 확인(Validation)이 가능해야 합니다.
잘못된 수준에서 정의된 요구사항이 초래할 수 있는 문제점은 다음과 같습니다.
하위 수준 엔터티의 요구사항이 상위 수준 엔터티의 요구사항 세트에 포함된 경우
설계 세부 사항이 설계 입력(Design Input)으로 정의될 때, 해당 요구사항이 “왜 (Why)” 필요한지 또는 상위 요구사항(Parent Requirement)이 무엇인지 명확하지 않은 경우가 많습니다. 이 경우, 실제 상위 수준 엔터티의 요구사항이 명시되지 않을 수도 있으며, 하위 수준 엔터티로 적절히 할당되지 않을 가능성이 큽니다. 따라서, 해당 요구사항은 적절한 수준의 엔터티 요구사항 세트로 이동해야 하며, 상위 수준 엔터티의 요구사항 세트에 누락된 상위 요구사항을 추가해야 합니다.
상위 수준 엔터티의 요구사항이 잘못된 방식으로 하위 수준 엔터티의 요구사항 세트에 포함된 경우
해당 요구사항이 적절하게 다른 엔터티로 할당(Allocation)되지 않았을 가능성이 큽니다. 이로 인해 일부 하위 수준 엔터티에 필요한 자식 요구사항(Child Requirements)이 누락될 수 있습니다.
잘못된 수준에서 정의된 니즈 또는 요구사항은 다음과 같은 결과를 초래할 수 있습니다.
- 정확하지 않음 (C8 - Correct)
- 검증 또는 확인이 불가능함 (C7 - Verifiable/Validatable)
적절한 요구사항 작성 및 검토 방법
요구사항 문장의 주어(Subject)는 해당 수준의 엔터티(Entity)여야 합니다.
요구사항은 반드시 해당 엔터티의 수준에서 정의되어야 합니다. 예를 들어, 시스템 수준의 요구사항이 하위 시스템을 직접 참조해서는 안 됩니다.
설계 입력 요구사항(Design Input Requirements)과 설계 출력 요구사항(Design Output Requirements)을 혼동하지 말아야 합니다.
- 설계 입력 요구사항(Design Input Requirements): 특정 설계 방법을 강요하지 않도록 설계 독립적인 방식(Implementation Independent) 으로 정의해야 하며, 불필요한 제약을 방지하기 위해 특정 구현 방법을 강제하지 않습니다.
- 설계 출력 요구사항(Design Output Requirements): 실제 구현을 담당하는 개발자 및 제조업체를 위해 필요한 상세한 기술적 명세를 포함합니다.
요구사항이 특정 구현을 강제하는 경우, 반드시 그 이유(Rationale)를 포함해야 합니다.
특정 구현이 필수적인 경우, 그 이유를 명확하게 정의해야 합니다. 예: 규제 요건, 기술적 제약, 비용 절감 등의 이유로 특정 구현이 필요할 수 있음.
요구사항의 적절한 표현을 위해 다음과 같은 사항을 확인해야 합니다.
- 무엇을 검증하려 하는가?
- 이 요구사항이 필요한 이유는 무엇인가?
마치며...
GWR에서 요구사항의 적절성(C2 - Appropriate)은 소프트웨어 개발과 시스템 설계에서 필수적인 요소입니다. 요구사항이 적절한 수준에서 정의되지 않으면, 시스템의 검증 및 확인이 어려워지고 개발 과정에서 혼선이 발생할 가능성이 큽니다.
적절한 요구사항이란, 해당하는 엔터티의 수준(시스템, 하위 시스템, 구성 요소)에 맞게 구체적이면서도 검증 가능해야 하며, 과도한 제약 없이 시스템 설계의 유연성을 보장해야 합니다. 요구사항이 너무 추상적이거나, 반대로 지나치게 상세한 구현 방식까지 포함하고 있다면, 이는 요구사항의 적절성을 해치는 요소가 될 수 있습니다.
요구사항의 수준을 올바르게 설정하는 것은 설계의 유연성을 유지하면서도, 프로젝트의 목표와 사용자 니즈를 충족하는 핵심 과정입니다. 이를 위해,
- 요구사항이 해당 수준의 엔터티를 정확하게 지칭하는지,
- 설계 입력 요구사항(Design Input)이 특정한 구현 방법(How) 대신 목적(What)을 정의하는지,
- 하위 요구사항이 상위 요구사항과 적절하게 연결(Traceability)되어 있는지 철저히 검토해야 합니다.
결과적으로, 요구사항의 적절성을 유지하면 시스템 개발 과정에서 혼선을 줄이고, 검증 가능하고 실현 가능한 요구사항을 정의할 수 있습니다. 이는 프로젝트의 성공 가능성을 높이고, 비용과 시간을 절감하는 데 중요한 역할을 합니다. 따라서, 모든 요구사항은 작성 및 검토 단계에서 적절성을 반드시 확인하여, 명확하고 일관된 요구사항 집합을 구축해야 합니다.
관련글 더 보기
소프트웨어 요구사항 모호성 & 일관성 해소: 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): Necessary (C1) (0) | 2025.03.08 |