SI 산출물은 왜 따로 노는가 — 요구사항부터 테스트까지 ‘연결’로 설계하는 방법

📌 서론

SI 프로젝트에서 흔히 보는 풍경입니다.

• 요구사항분석서 있음
• 기능명세서 있음
• 설계서 있음
• 테스트명세서 있음

그런데 결과는?

“요구사항이 제대로 반영 안 됐습니다”

문제가 뭘까요?

산출물이 없는 게 아니라, 연결이 없다

---

📌 1. 산출물 중심 전체 구조

핵심은 이겁니다.

[REQ] 요구사항
↓
[FUNC] 기능정의
↓
[DESIGN] 설계
↓
[EST] 공수산정
↓
[TEST] 테스트

 

👉 이건 단순 흐름이 아니라

ID 기반으로 연결되는 구조여야 합니다

---

📌 2. 요구사항 → 기능정의 연결

✔️ 구조

REQ-001: 회원가입
↓
FUNC-001: 회원 생성 API
FUNC-002: 이메일 인증

 

---

✔️ 핵심

• 요구사항 1개 → 기능 N개
• 반드시 ID로 연결

---

❌ 실패

• 요구사항 문서 따로
• 기능명세 따로

👉 연결 불가

---

✔️ 기준

기능은 요구사항을 “구현 가능한 단위”로 쪼갠 것

---

📌 3. 기능정의 → 설계 연결

✔️ 구조

FUNC-001: 회원 생성 API
↓
DESIGN:
- Controller: UserController
- Service: UserService
- DB: users 테이블

 

---

✔️ 핵심

• 기능 1개 → 설계 요소 매핑
• 코드 구조까지 이어져야 함

---

❌ 실패

• 설계서가 추상적 (박스 다이어그램만 있음)

---

✔️ 기준

설계는 “이 기능을 어디에 구현할 것인가”다

---

📌 4. 기능정의 → 공수산정 연결

✔️ 구조

FUNC-001: 회원 생성 API → 2MD
FUNC-002: 이메일 인증 → 1MD

 

---

✔️ 핵심

• 기능 단위로 산정
• 합산 = 프로젝트 공수

❌ 실패

“회원가입 3일”

 

👉 근거 없음

---

✔️ 기준

공수는 기능 단위로 쪼개야 정확해진다

---

📌 5. 요구사항 → 테스트 연결 (핵심)

✔️ 구조

REQ-001: 회원가입
↓
TC-001: 정상 가입
TC-002: 이메일 중복
TC-003: 비밀번호 정책 실패

 

---

✔️ 핵심

• 요구사항 1개 → 테스트 케이스 N개
• “검증 가능성 확보”

---

❌ 실패

• 테스트는 있는데 요구사항과 무관

---

✔️ 기준

테스트는 요구사항의 검증 도구다

---

📌 6. 전체 Traceability 구조

이게 완성 형태입니다.

 

REQ-001 (회원가입)
↓
FUNC-001 (회원 생성 API)
↓
DESIGN (UserController, UserService, users 테이블)
↓
EST (2MD)
↓
TC-001 ~ TC-003

 

---

👉 핵심

하나의 요구사항이
코드 → 공수 → 테스트까지 이어져야 한다

---

📌 7. 실무에서 터지는 문제

❌ 연결 안 된 상태

요구사항 ≠ 기능 ≠ 설계 ≠ 테스트

 

---

결과

• 누락 기능 발생
• 테스트 누락
• 일정 틀림
• 책임 추적 불가

---

---

📌 8. 해결 방법 (실무 적용)

✔️ ID 규칙 만들기

REQ-xxx
FUNC-xxx
TC-xxx

 

---

✔️ 매핑 테이블 관리

REQFUNCTEST

REQ-001	FUNC-001	TC-001
	FUNC-002	TC-002

---

✔️ 도구 활용

• Jira (Issue link)
• Notion DB
• Excel (현실적으로 많이 씀)

---

📌 9. 핵심 요약

단계연결 대상

요구사항	기능
기능	설계 + 공수
요구사항	테스트

 

 

📌 결론

SI 프로젝트의 품질은 코드가 아니라
산출물의 연결 구조에서 결정됩니다

---

📌 마무리 한 줄

좋은 문서는 잘 쓴 문서가 아니라

다음 단계와 연결된 문서다