요구공학 with CPRE

요구공학 완전 정복 준비하기: 왜, 누구에게, 어떻게?

이직 후 업무를 위한 적응 및 새로운 지식 학습(성능, 프로세스, 서비스 일부 운영 등등..) 등 잡다하게 하다보니 반년전쯤 책장에 소중히 모셔둔 요구공학책과 소홀해진 자신을 반성하며 CPRE로 한줄이라도 채우기 위해 블로그를 다시 시작합니다 :) 

1. 요구공학이란 무엇인가?

요구공학(Requirements Engineering)은 소프트웨어 개발의 초기 단계에서 요구사항을 정의, 분석, 문서화, 검증 및 관리하는 학문이자 실무 영역입니다. 시스템이 무엇을 해야 하는지에 대한 이해를 바탕으로 사용자, 이해관계자, 개발자 간의 공통된 언어를 형성합니다.

요구공학의 주된 활동에는 다음이 포함됩니다:

• 요구사항 도출 
• 요구사항 분석 (Analysis)
• 요구사항 명세화 (Specification)
• 요구사항 검증 및 확인 (Validation & Verification)
• 요구사항 관리 (Requirements Management

---

2. QA가 요구공학을 공부해야 하는 이유

2.1 품질 보증의 시작은 명확한 요구로부터

QA는 단순히 테스트만 수행하는 직무가 아닙니다. 결함 없는 시스템을 보장하려면 테스트 이전에 시스템의 요구사항이 명확해야 합니다. 요구가 명확하지 않으면, 테스트 케이스 또한 애매모호해지고, 이는 시스템 품질의 저하로 직결됩니다.

2.2 금융 시스템의 복잡성과 민감성

발담고 있는 금융 도메인 시스템은 다음과 같은 특징을 가집니다:

• 높은 규제 준수 요구 : 금융위/금감원/금보원에서 명시하는 규제 요건은 금융권 전반에 반드시 적용되는 케이스도 있으나, 해석의 차이가 있는 가이드라인도 있습니다. 이러한 해석의 오류(차)로 인해 불명확한 요건이 나오고 추후 컴플라이언스에서 달라진다면 최종적으로 고객에게 전달하기까지 시간 및 비용은 증가할 수 있습니다
• 실시간 처리 및 고가용성 시스템 : 제공하는 서비스가 돈과 관련되기 때문에 극단적으로 0.0x 초 단위의 처리를 요하는 경우도 있습니다. 가용성은 전체 사용자 및 동시 사용자에 따라 달라지며 HA를 위한 인프라적 요건을 명확히 정의하여 이해관계자를 이해시키는 것이 어렵습니다
• 복잡한 사용자 시나리오 (고객, 내부직원, 자동화된 외부 시스템 등) : 비즈니스 로직 및 시나리오의 단계가 일반적인 서비스 시스템보다 복잡하며 불특정/특정 사용자 집군에 따라 다른 기능으로 인해 복잡성과 민감도가 비교적 높습니다
• 회계, 리스크, 보안 등 다수 도메인의 협업 필요

이러한 특성은 요구사항의 충돌, 누락, 과잉 등을 유발할 수 있습니다. QA는 요구공학을 통해 이러한 위험요소를 조기에 파악하고, 보다 효과적인 테스트 전략을 설계할 수 있습니다.

2.3 테스트 이전 단계에서의 품질 기여

요구공학 지식을 보유한 QA는 다음과 같은 방식으로 프로젝트에 기여할 수 있습니다:

• 요구사항 리뷰에 참여하여 결함 조기 발견
• 테스트 가능성 분석 (Testability) 수행
• Behavior Driven Development(BDD)나 Acceptance Criteria 정의에 참여

---

3. 요구공학 학습이 필요한 대상

요구공학은 단순히 분석가만을 위한 영역이 아닙니다. 아래와 같은 실무자들이 반드시 학습해야 합니다:

QA 엔지니어	테스트 설계의 정확성, 테스트 커버리지 확보를 위해
비즈니스 애널리스트(BA)	사용자 요구를 체계적으로 수집하고 전달하기 위해
PM/PO	프로젝트 범위 및 스코프 조율, 우선순위 결정 시 필수
개발자	명확한 기능 이해 및 구현 일관성 확보를 위해
디자이너	사용자 니즈와 시스템 요구를 효과적으로 매핑하기 위해

 

---

4. 요구공학의 핵심 원칙

요구공학에는 다음과 같은 원칙들이 존재합니다. 실무에 바로 적용 가능한 내용이므로 QA 입장에서도 적극적으로 익히는 것이 중요합니다.

 

요구공학의 9가지 기본 원칙 

1. 가치 지향: 요구사항은 목적을 위한 수단이며, 비용 대비 이익을 고려.
2. 이해관계자 중심: 다양한 이해관계자의 요구사항을 수렴하고 조율.
3. 공통 이해: 문서화된 명시적/암묵적 공감대 형성이 필수.
4. 정황 인식: 시스템은 정황과의 상호작용 속에서만 의미를 갖는다.
5. 문제-요구사항-솔루션: 문제 해결을 위한 요구사항 도출과 솔루션은 서로 연관됨.
6. 밸리데이션(유효성 검증): 검증되지 않은 요구사항은 쓸모없음.
7. 진화: 요구사항은 변경을 전제로 계획해야 함.
8. 혁신: 단순한 충족을 넘어 사용자 감동을 목표로.
9. 체계성과 규율: 상황에 맞는 유연한 접근이 필요하지만, 구조화된 실천이 요구됨.

 

4.1 명확성 (Clarity)

• 요구사항은 누구나 이해할 수 있도록 간결하고 모호하지 않아야 함

4.2 일관성 (Consistency)

• 서로 충돌하지 않는 요구들로 구성되어야 하며, 내부 논리적 오류가 없어야 함

4.3 추적 가능성 (Traceability)

• 각 요구사항은 테스트, 설계, 개발, 배포까지 추적 가능해야 함

4.4 완전성 (Completeness)

• 누락된 요구사항이 없고, 관련 규칙 및 예외까지 명시되어 있어야 함

4.5 검증 가능성 (Verifiability)

• 요구는 테스트 가능한 방식으로 표현되어야 함 ("빠르다" 대신 "응답시간 3초 이내")

---

5. 요구공학 관련 자격증 및 학습 경로

요구공학에 특화된 자격증을 취득하면 실무 능력과 이론적 기반을 모두 강화할 수 있습니다.

5.1 국제 자격증

• IREB CPRE (Certified Professional for Requirements Engineering)
  • 국제적으로 가장 권위 있는 요구공학 자격증
  • Foundation → Advanced → Expert 레벨로 구성
• BCS Business Analysis Certifications
  • BCS Foundation Certificate in Requirements Engineering 포함
• ISTQB CTFL – Agile Tester Extension
  • 요구 기반 테스트 관점에서 활용 가능

6. QA 실무에서 요구공학 적용 방법

6.1 요구사항 기반 테스트 설계

• 각 요구사항마다 테스트 케이스 매핑
• 요구사항 ID 기준으로 결함 추적 (Defect Traceability Matrix)

6.2 요구사항 리뷰 & 정제

• 초기 설계서/BRS 단계에서 QA가 요구 검토 참여
• ‘이 요구가 테스트 가능한가?’, ‘누락된 시나리오는 없는가?’를 중심으로 피드백

6.3 자동화 테스트와 요구 연결

• 자동화 스크립트와 요구사항 ID를 연동하여 커버리지 추적
• 예: JIRA → Zephyr → Selenium 연동

6.4 요구사항 변경 관리

• Change Request가 빈번
• QA가 요구사항 변경 이력과 기존 테스트 영향도 분석

6.5 애자일 요구공학 적용

• 사용자 스토리 기반 테스트 설계
• Acceptance Criteria를 기준으로 QA 자동화 시나리오 작성

7. 실무 사례 소개

📌 사례 1: 은행권 계좌개설 서비스 QA

• 신규 모바일 계좌개설 기능 도입
• 초기 BRD에서 ‘사진 업로드 기능’ 누락 → QA 요구공학 리뷰에서 발견
• 테스트 전에 누락 요구 반영 → 개발 재작업 최소화 → 프로젝트 지연 방지

📌 사례 2: 요구사항 추적 매트릭스 도입

• 기존에는 요구와 테스트 간 매핑 없음
• 요구-ID 기반 테스트 설계 및 결함 관리 도입
• 금융감독원 감사 시, 체계적 요구 대응 문서로 우수 사례 평가

8. 맺으며

요구공학은 개발자나 BA만의 영역이 아닙니다. QA가 요구공학에 대한 이해를 갖추면 테스트의 전략성과 효과가 비약적으로 향상됩니다. 특히 금융권처럼 복잡성과 규제 준수 요구가 높은 환경에서는 요구공학 역량이 곧 리스크를 줄이고 품질을 높이는 가장 효과적인 무기가 됩니다.