요구사항을 만들때, 과도하게 큰 요구사항이랑 과도하게 작은 요구사항을 레벨링 하려면 어떤 방법을 써야 할까?

 

요구사항을 정의하다 보면 너무 크거나 추상적인 요구사항(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 수준으로 중요도/우선순위로 정리
트레이서빌리티 매트릭스	상위 ↔ 하위 요구사항 간 추적 가능하게 매핑해서 빠진 거나 과한 거 정리

---