SI 개발 발주 전 요구사항 정의서에 반드시 들어갈 7가지

SI 개발 견적을 받을 때 기능 목록만 전달하면 업체마다 해석과 금액이 크게 달라집니다. 같은 '관리자 페이지'도 누가 어떤 데이터를 보고, 무엇을 승인하며, 오류가 났을 때 어떻게 복구하는지에 따라 개발 범위가 달라지기 때문입니다. 발주 전에 아래 일곱 가지를 정리하면 제안 비교와 검수가 훨씬 명확해집니다.

1. 사용자와 역할

사용자를 직급이 아니라 시스템 안에서 하는 일로 구분합니다. 신청자, 승인자, 처리 담당자, 통계 조회자, 시스템 관리자처럼 역할별로 볼 수 있는 정보와 실행할 수 있는 작업을 적습니다. 한 사람이 여러 역할을 가질 수 있는지도 함께 정해야 합니다.

2. 시작부터 종료까지의 업무 흐름

화면 목록보다 먼저 업무가 시작되는 조건과 끝나는 조건을 적습니다. 예를 들어 신청 등록, 담당자 배정, 검토, 보완 요청, 승인, 결과 통보 순서와 각 단계에서 다음 단계로 넘어가는 기준을 정리합니다. 예외 상황과 되돌림도 정상 흐름만큼 중요합니다.

3. 입력 데이터와 기준정보

각 화면에서 입력하는 항목, 필수 여부, 형식, 기본값, 수정 가능 시점을 정합니다. 고객사, 부서, 품목, 상태 코드처럼 여러 기능에서 함께 쓰는 기준정보는 누가 관리하는지까지 포함해야 합니다. 기존 엑셀이나 DB를 옮겨야 한다면 데이터 양과 품질도 확인합니다.

4. 외부 시스템 연동

ERP, 그룹웨어, 이메일, 문자, 결제, 지도, 공공 API 등 연결 대상과 교환할 데이터를 구분합니다. 실시간 연동인지 배치 연동인지, 상대 시스템이 제공하는 API 문서와 테스트 계정이 있는지 확인합니다. 연동 실패 시 재처리 방법도 요구사항에 포함합니다.

5. 권한과 보안

로그인 방식, 비밀번호 정책, 접근 가능한 네트워크, 개인정보 마스킹, 다운로드 권한, 작업 이력 보관 기간을 정합니다. '관리자만 가능'이라는 문장보다 어떤 관리자 역할이 어떤 데이터에 어떤 행동을 할 수 있는지 표로 만드는 편이 안전합니다.

6. 검수 기준

기능이 존재한다는 것과 업무에 사용할 수 있다는 것은 다릅니다. 주요 시나리오별 입력값, 예상 결과, 오류 메시지, 처리 시간, 지원 브라우저와 모바일 범위를 검수 조건으로 정합니다. 발주사와 개발사가 같은 테스트 시나리오를 사용해야 완료 판단이 흔들리지 않습니다.

7. 배포 이후 운영

운영 서버, 도메인, 백업, 장애 알림, 관리자 교육, 하자보수와 유지관리 범위를 미리 정합니다. 소스코드와 계정의 소유 주체, 배포 권한, 운영 문서 인계 기준도 계약 전에 확인해야 합니다.

요구사항은 화면이 아니라 판단 기준입니다

좋은 요구사항 정의서는 모든 화면을 미리 그린 문서가 아닙니다. 무엇을 만들고 무엇을 만들지 않을지, 어떤 결과가 나오면 완료인지 합의할 수 있는 문서입니다. AMARANS SI 개발·시스템 개발 서비스는 기존 시스템과 업무를 확인한 뒤 요구사항, 연계 구조, 화면과 권한을 프로토타입으로 검증하고 개발 범위를 정합니다.