요구사항 정리에서 절반이 결정됩니다
개발이 끝난 뒤 “생각했던 것과 다르다”는 말이 나오는 이유는 대개 두 가지입니다. 완료의 기준을 정하지 않았거나, 사용 상황을 공유하지 않았기 때문입니다. 요구사항은 기능 목록이 아니라 “누가, 어떤 상황에서, 무엇을 할 수 있어야 하는가”의 기록이어야 합니다.
기능 목록은 만들 것을 적은 문서이고, 요구사항은 끝났다고 말할 수 있는 조건을 적은 문서입니다.
1. 요구사항 정리 단계
이 단계에서 합의할 것
이 시스템을 매일 사용할 사람은 누구인가 (역할별로 구분)
지금은 그 업무를 어떻게 처리하고 있는가
반드시 되어야 하는 기능과 있으면 좋은 기능의 구분
다루는 데이터의 종류와 민감도, 접근 권한 범위
기존에 쓰는 시스템 중 연동이 필요한 것
사용 환경 (사내망 전용, 모바일 사용 여부, 동시 사용자 수)
2. 설계 단계
이 단계에서 합의할 것
화면 목록과 각 화면에서 할 수 있는 일
권한 체계 — 누가 무엇을 보고 수정할 수 있는가
데이터 구조와 보관 기간
예외 상황의 처리 방식 (입력 오류, 중복, 삭제 요청)
화면 시안의 확정 시점과 수정 가능 횟수
3. 구현 단계
이 단계에서 합의할 것
중간 확인 주기와 확인 방법 (주 1회 데모 등)
요구사항이 바뀔 때의 처리 절차와 일정·비용 영향
개발 환경과 운영 환경의 분리 여부
연동 대상 시스템의 담당자와 응답 소요 시간
4. 검수 단계
이 단계에서 합의할 것
검수 항목과 합격 기준 (요구사항 한 줄마다 확인 방법)
검수 기간과 수정 요청 가능 범위
실제 데이터로 검증할 것인지, 테스트 데이터로 할 것인지
성능 기준 (처리 시간, 동시 접속)
5. 인수인계 단계
이 단계에서 합의할 것
소스 코드와 계정의 소유권, 전달 방식
운영 매뉴얼과 관리자 교육 범위
장애 발생 시 연락 방법과 대응 시간
유지보수 범위·기간·비용, 추가 개발의 산정 방식
자주 빠지는 항목
- 계정과 권한 — 외부 서비스 계정을 누구 이름으로 만들지 정하지 않아 이관 때 문제가 됩니다.
- 데이터 이관 — 기존 엑셀·시스템의 데이터를 옮기는 작업이 범위에 없으면 오픈이 미뤄집니다.
- 운영 비용 — 서버, 외부 API, 도메인 비용의 부담 주체를 정해 둡니다.
- 종료 조건 — 프로젝트가 언제 끝나는지 적혀 있지 않으면 끝나지 않습니다.
견적을 받기 전에 한 장으로 정리합니다
해결할 문제, 사용자, 필수 기능, 연동 대상, 완료 조건, 희망 일정. 이 여섯 줄만 정리되어 있어도 받게 되는 견적의 정확도가 크게 달라집니다. 정리가 어렵다면 그 자체가 아직 범위가 정해지지 않았다는 신호이므로, 요구사항 정리부터 별도 단계로 진행하는 편이 안전합니다.