요구사항을 정의하다 보면 너무 크거나 추상적인 요구사항(epic)도 생기고, 반대로 너무 작고 세부적인 요구사항(micro task 수준)도 생깁니다. 이런 경우엔 요구사항의 크기(granularity)를 적절히 조절해서 계층적으로 정리하는 레벨링 작업이 필요합니다.
아래는 과도하게 큰 요구사항과 과도하게 작은 요구사항을 레벨링하는 방법을 정리한 거예요.
✅ 1. 과도하게 큰 요구사항 → 분할하기 (Decomposition)
문제
- 너무 포괄적이고 모호해서 개발하거나 테스트하기 어려움
- 흔히 Epic(에픽) 또는 상위 요구사항이라고도 함
해결 방법
- 하위 요구사항으로 분해(Split) 하여 구체화하고 관리 가능하게 만들기
- 보통 User Story나 Use Case, 기능 요구사항 등으로 분할
예시
markdown복사편집[과도하게 큰 요구사항]
- "고객이 웹사이트에서 상품을 검색, 구매, 결제할 수 있어야 한다."
[분해 후]
1. 고객은 상품을 검색할 수 있어야 한다.
2. 고객은 장바구니에 상품을 담을 수 있어야 한다.
3. 고객은 결제 정보를 입력할 수 있어야 한다.
4. 고객은 주문을 완료하고 확인할 수 있어야 한다.
✅ 2. 과도하게 작은 요구사항 → 통합하기 (Aggregation)
문제
- 너무 세세해서 요구사항 문서가 복잡해지고, 관리 비용이 커짐
- 구현 단계의 할 일(Task)에 가까운 수준
해결 방법
- 유사하거나 관련 있는 요구사항들을 그룹화해서 상위 수준 요구사항으로 통합
예시
diff복사편집[과도하게 작은 요구사항들]
- "결제 버튼은 초록색이어야 한다."
- "결제 완료 후 ‘주문이 완료되었습니다’ 메시지를 보여줘야 한다."
- "결제 완료 페이지에서 주문 번호를 보여줘야 한다."
[통합 후]
- 사용자가 결제를 완료하면 확인 메시지와 주문 번호를 포함한 완료 페이지가 표시되어야 한다.
🔧 도구적 접근: 요구사항 레벨링을 위한 기법
| 기법 | 설명 |
|---|---|
| 유스케이스 모델링 | 큰 요구사항을 액터-시스템 간 상호작용으로 나누기 |
| Story Mapping | 사용자 여정 흐름에 따라 요구사항을 구조화 |
| INVEST 기법 | 좋은 User Story 기준: Independent, Negotiable, Valuable, Estimable, Small, Testable |
| MoSCoW 분석 | Must, Should, Could, Won’t 수준으로 중요도/우선순위로 정리 |
| 트레이서빌리티 매트릭스 | 상위 ↔ 하위 요구사항 간 추적 가능하게 매핑해서 빠진 거나 과한 거 정리 |