INCOSE 요구사항 작성 가이드(GWR): Complete (C4)

요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다.

 

국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “완전성(Complete)”은 소프트웨어 개발과 시스템 설계에서 요구사항이 갖추어야 할 사항을 모두 정의되어야 한다는 원칙을 의미합니다.

 

이번 포스팅에서는 INCOSE GWR에서 언급하는 요구사항의 완전성(Complete)이 무엇이고, 왜 중요한지, 그리고 모호하지 않은 요구사항을 작성하기 위해서는 무엇을 고려해야 하는지에 대해 알아보도록 하겠습니다.

INCOSE 요구사항 작성 가이드 (Guide to Writing Requirements, GWR)

반응형

완전성(Complete)

요구사항의 완전성(Completeness)이란, 요구사항 또는 필요사항이 그 자체만으로 필요한 능력, 특성, 제약, 조건, 또는 품질 요소를 충분히 설명하고 있는 상태를 의미합니다. 즉, 어떤 외부 문서나 추가 설명 없이도 무엇을 해야 하는지, 얼마나 잘 해야 하는지, 어떤 조건에서 수행되어야 하는지가 모두 명확히 드러나야 합니다.

 

필요사항의 경우에는 시스템 생애주기 개념이나 그에 상응하는 출처에 따라 시스템이 수행해야 할 내용을 충분히 담고 있어야 하며, 요구사항은 해당 필요사항이나 상위 요구에서 파생된 목적을 달성하기 위한 내용을 완전하게 포함해야 합니다.

 

왜 요구사항의 완전성이 중요한가

1. 계약적 효력의 기반이 됩니다

요구사항은 개발자와 고객, 또는 공급자 간의 공식적인 약속입니다. 이 약속이 불완전하면 책임 소재가 불분명해지고, 해석의 차이로 인해 계약 분쟁이나 납품 실패로 이어질 수 있습니다. 완전한 요구사항은 그런 위험을 예방할 수 있는 기초가 됩니다.

 

2. 검증 가능성과 연결됩니다

불완전한 요구사항은 해당 시스템이 검증 가능(Verifiable)하거나 유효성 확인 가능(Validatable)하지 않게 만듭니다. “무엇을”, “얼마나 잘”, “어떤 조건에서” 수행하는지를 알 수 없다면, 그 요구사항이 충족되었는지를 확인할 방법이 없습니다.

 

3. 설계와 구현의 기준이 됩니다

요구사항은 시스템 설계와 구현의 출발점입니다. 불완전한 요구사항은 설계자와 개발자가 임의로 해석하거나 가정을 해야 하므로, 일관성 없는 결과물이 나올 수 있으며, 이는 품질 저하 및 재작업의 원인이 됩니다.

 

 

 

추가 팁

① 요구사항은 스스로 완결된 문장이어야 합니다

요구사항은 문서의 제목이나 다른 요구사항에 의존하지 않고, 그 자체로 독립적으로 의미가 완전해야 합니다. 예를 들어 “위 기능은 항목 3.2에 따름”과 같은 표현은 완전하지 않습니다.
[참고사항]

소프트웨어 요구사항 모호성 & 일관성 해소: EARS (Easy Approach to Requirements Syntax)와 Glossary 활용

소프트웨어 요구사항 모호성 & 일관성 해소: EARS (Easy Approach to Requirements Syntax)와 Glossary 활용

 

② 다른 문서에 대한 참조는 구체적으로 명시해야 합니다

인터페이스 문서(ICD)나 데이터 딕셔너리와 같은 외부 자료를 참조할 경우, 단순히 문서 이름만 언급하는 것이 아니라 해당 문서의 정확한 섹션 번호까지 포함해야 완전하다고 볼 수 있습니다.

 

③ TBD/TBS/TBR 표현은 제외해야 합니다

요구사항에 ‘To Be Defined’, ‘To Be Specified’, ‘To Be Resolved’ 같은 미완성 표현이 포함되어 있다면, 해당 요구는 완전하지 않습니다. 이런 표현은 분석 단계에서만 임시로 사용하고, 최종 요구사항 세트에는 반드시 제거되어야 합니다.

 

④ 요구사항 간 상호참조는 피해야 합니다

요구사항은 문서 내 순서나 위치에 의존하지 않아야 하며, 다른 요구사항을 전제로 하지 않아야 합니다. 데이터베이스나 요구사항 관리 시스템에서는 개별 항목이 독립적으로 검토되고 추적되기 때문에, 상호참조는 오히려 혼란을 야기할 수 있습니다.

 

Completeness 확인을 위한 체크리스트

체크항목	확인 질문	확인 기준
기능 명확성	무엇을 해야 하는가?	시스템의 동작이나 행위가 명확히 기술되어 있는가?
성능 기준	얼마나 잘 해야 하는가?	수치화 가능한 성능 지표 (속도, 시간, 거리 등)가 포함되어 있는가?
조건 기술	어떤 조건에서 수행되는가?	상태, 모드, 환경, 트리거 등 조건이 포함되어 있는가?
문장 독립성	문맥 없이도 의미가 통하는가?	다른 요구사항이나 문서의 제목 없이도 해석 가능한가?
정의된 용어 사용	용어가 프로젝트 용어집 또는 데이터 사전에 정의되어 있는가?	중의적이지 않고 일관된 의미로 사용되는가?
외부 문서 참조	문서 참조 시 구체적인 섹션이나 조항이 명시 되어 있는가?	"ICD 3.4절에 따라" 같은 명확한 참조가 있는가?
미완성 표현 없음	TBD, TBS, TBR 같은 표현이 제어되었는가?	최종 문서에는 반드시 포함되지 않아야 함

 

---

마치며...

요구사항의 완전성은 말 그대로, 그 문장 하나만 봐도 “무엇을, 어느 정도로, 어떤 상황에서” 해야 하는지를 알 수 있어야 한다는 뜻입니다. 얼핏 보면 당연해 보이지만, 실제로 요구사항을 작성하다 보면 빠뜨리기 쉬운 요소들이 꽤 많습니다. 작은 표현 하나가 빠졌을 뿐인데, 개발자는 다른 방향으로 해석하고, 검증팀은 확인 방법을 찾지 못하는 상황이 생길 수 있습니다.

 

그래서 요구사항을 작성할 때는 ‘이 문장만 보고도 누가 봐도 같은 방식으로 이해할 수 있을까?’, ‘이걸 바로 설계나 구현으로 옮길 수 있을까?’ 하는 질문을 계속 던져보는 게 중요합니다. 또, 이미 작성된 요구사항이라도 패턴을 적용해 보거나 체크리스트를 활용해서 빠진 부분은 없는지 점검하는 것도 좋은 방법입니다.

 

완전한 요구사항은 프로젝트 전체의 소통을 원활하게 하고, 개발과 검증의 기준을 분명하게 해 줍니다. 말하자면, 좋은 설계도나 내비게이션 같은 역할을 하는 셈입니다. 처음엔 조금 어렵고 시간이 걸릴 수 있지만, 익숙해지면 훨씬 더 효율적인 개발이 가능해집니다.

 

요구사항은 단순한 문장이 아니라, 시스템의 시작이자 약속이기 때문에, 조금 더 신중하게, 꼼꼼하게 써 내려가는 습관이 결국 더 나은 결과로 이어질 것입니다.