SI 프로젝트 산출물의 본질 — 요구사항부터 테스트까지, 제대로 만드는 기준

SI 프로젝트는 결국 문서로 시작해서 문서로 끝납니다.

• 요구사항분석
• 설계서
• 기능명세서
• 공수산정서
• 테스트명세서

문제는 대부분 이렇게 됩니다.

“문서는 있는데, 시스템은 이상하다”

이유는 단순합니다.

산출물은 있는데, 연결이 없다

---

📌 1. 전체 흐름 (산출물 체계)

먼저 구조부터 정리합니다.

요구사항 → 기능정의 → 설계 → 공수산정 → 테스트

 

👉 이건 순서가 아니라 의존 관계입니다.

---

📌 2. 요구사항분석서 (Requirement)

✔️ 목적

• “무엇을 만들 것인가” 정의

---

✔️ 핵심 산출물

• 기능 요구사항 (Functional)
• 비기능 요구사항 (성능, 보안 등)
• 유스케이스 / 시나리오

---

✔️ 좋은 기준

• 모호한 표현 없음
• 검증 가능 (Testable)
• 사용자 기준

---

❌ 실패 사례

“사용자가 편리하게 사용할 수 있어야 한다”

 

👉 테스트 불가능

---

✔️ 한 줄

요구사항은 “개발용 문서”가 아니라
검증 기준이다

---

📌 3. 기능정의서 (Feature / Functional Spec)

✔️ 목적

• 요구사항을 시스템 기능으로 변환

---

✔️ 핵심 산출물

• 기능 리스트
• API 정의
• 입력 / 출력
• 상태 변화

---

✔️ 예시

[기능] 주문 생성

입력:
- userId
- productId

출력:
- orderId

상태:
- CREATED → PAID → SHIPPED

 

---

❌ 실패 사례

• 요구사항 복붙
• 기능 경계 없음

---

✔️ 한 줄

기능정의는 “개발 가능한 단위”로 쪼개는 작업이다

 

📌 4. 설계서 (Design)

✔️ 목적

• 기능을 구조로 변환

---

✔️ 핵심 산출물

• 아키텍처 다이어그램
• DB 모델 (ERD)
• 클래스 / 패키지 구조
• 인터페이스 설계

---

✔️ 좋은 설계 기준

• 책임 분리 (SRP)
• 결합도 최소화
• 변경 가능성 고려

---

❌ 실패 사례

• DB부터 설계
• 화면 기준 설계

---

✔️ 한 줄

설계는 “코드의 미래 비용”을 결정한다

---

📌 5. 공수산정서 (Estimation)

✔️ 목적

• 일정 / 비용 결정

---

✔️ 핵심 산출물

• 기능별 공수
• 리스크 버퍼
• 의존성

---

✔️ 좋은 기준

• 기능 단위 기반
• 과거 데이터 활용
• 불확실성 반영

---

❌ 실패 사례

“이거 하루면 됩니다”

 

👉 근거 없음

---

✔️ 한 줄

공수는 예측이 아니라
리스크 관리다

 

---

📌 6. 테스트명세서 (Test Spec)

✔️ 목적

• “정상 동작 검증”

---

✔️ 핵심 산출물

• 테스트 케이스
• 입력 / 기대 결과
• 성공 기준

---

✔️ 예시

[TC-001] 주문 생성 성공

입력:
- userId=1
- productId=10

기대:
- orderId 생성
- 상태 CREATED

 

---

❌ 실패 사례

• 테스트 없음
• Happy path만 있음

---

✔️ 한 줄

테스트는 문서가 아니라
품질 보증 시스템이다

 

---

📌 7. 가장 중요한 문제: 연결 안 됨

실제 SI에서 제일 많이 터지는 문제

---

❌ 단절 구조

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

 

---

✔️ 정상 구조

요구사항 → 기능 → 설계 → 테스트
(Traceability)

 

---

👉 예

• 요구사항 ID → 기능 ID → 테스트 케이스 연결

---

✔️ 핵심

모든 산출물은 연결되어야 한다

---

📌 8. 실무 기준 핵심 요약

단계핵심

요구사항	테스트 가능해야 한다
기능정의	개발 가능한 단위
설계	변경 비용 최소화
공수산정	리스크 포함
테스트	요구사항 검증

---

📌 결론

SI 프로젝트는 문서가 많아서 실패하는 게 아닙니다.

문서가 연결되지 않아서 실패합니다

---

📌 마무리 한 줄

좋은 산출물은 많아서가 아니라

서로 연결되어 있어서 가치가 있다