요구사항 명세서 템플릿과 실전 예시: 정부지원사업·외주개발 MVP 작성 기준
답부터 말하면, 요구사항 명세서는 ‘무엇을 만들지’보다 ‘어디까지 만들면 완료로 볼지’를 합의하는 문서입니다. 정부지원사업 선정 후 MVP를 외주개발하거나 내부 개발로 진행할 때 가장 많이 생기는 문제는 기능이 부족해서가 아니라, 기능의 경계가 문서로 정리되지 않아서입니다. 로그인, 관리자, 결제, 알림, AI 추천처럼 익숙한 단어일수록 사람마다 떠올리는 구현 수준이 다릅니다. 요구사항 명세서 템플릿은 이 차이를 기능 ID, 데이터 항목, 예외 상황, 권한, 우선순위, 검수 기준으로 바꿔 개발비 낭비와 분쟁 가능성을 줄이는 도구입니다.

정부지원사업의 사업계획서에는 보통 ‘시제품 개발’, ‘플랫폼 구축’, ‘관리자 페이지 제공’처럼 사업 목적 중심의 문장이 들어갑니다. 창업진흥원의 초기창업패키지 안내도 시제품 제작 등 사업화자금 지원 항목을 설명하지만, 실제 개발 계약 단계에서는 공고문과 협약 기준에 맞춰 구체적인 산출물과 검수 기준을 따로 정리해야 합니다. ([kised.or.kr](https://www.kised.or.kr/menu.es?mid=a10205020000)) 이 글은 공식 사업 지침을 대신하지 않습니다. 다만 사업계획서의 기능 목록을 외주개발 견적, 계약 범위, 중간 점검, 최종 검수에 연결하는 실무형 요구사항 명세서 작성 기준을 제공합니다.
1. 요구사항 명세서가 필요한 순간
초기 창업팀은 사업계획서 작성에는 익숙해도 개발 문서에는 익숙하지 않은 경우가 많습니다. 사업계획서는 심사자가 사업성과 시장성을 이해하도록 쓰는 문서이고, 요구사항 명세서는 개발자와 PM이 구현 범위와 완료 조건을 판단하도록 쓰는 문서입니다. 같은 ‘회원가입’이라도 이메일 가입만 할지, 소셜 로그인을 포함할지, 약관 동의 이력을 저장할지, 휴면 계정 정책이 필요한지, 관리자에서 회원 상태를 변경할 수 있는지에 따라 견적과 일정은 크게 달라집니다.
공공 SW 기준에서도 요구사항은 기능뿐 아니라 성능, 인터페이스, 데이터, 테스트, 보안, 품질, 제약, 프로젝트 관리, 프로젝트 지원 등으로 나뉩니다. 또 요구사항별 고유번호, 명칭, 상세설명, 산출정보, 관련 요구사항, 출처 같은 항목을 관리하도록 제시되어 있습니다. 스타트업 MVP가 이 구조를 모두 무겁게 따라야 한다는 뜻은 아니지만, 외주개발과 검수 기준을 잡을 때 참고할 만한 최소 골격입니다. ([law.go.kr](https://law.go.kr/flDownload.do?bylClsCd=200201&flNm=%5B%EB%B3%84%ED%91%9C+2%5D+%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EC%82%AC%EC%97%85+%EC%83%81%EC%84%B8+%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD+%EB%B6%84%EC%84%9D%C2%B7%EC%A0%81%EC%9A%A9%EA%B8%B0%EC%A4%80%28%EC%A0%9C11%EC%A1%B0+%EA%B4%80%EB%A0%A8%29&flSeq=128124887))
요구사항 명세서의 목표는 완벽한 문서가 아닙니다. 개발 착수 전 ‘포함되는 것’, ‘제외되는 것’, ‘검수할 수 있는 것’을 같은 표에서 확인하게 만드는 것입니다.
2. 요구사항 정의서·기능명세서·화면기획서의 차이
| 문서 | 주요 질문 | 초기 MVP에서의 역할 |
|---|---|---|
| 요구사항 정의서 | 왜 이 기능이 필요한가, 어떤 사용자 문제를 해결하는가 | 사업계획서와 제품 방향을 개발 범위로 좁히는 상위 문서 |
| 요구사항 명세서 | 각 요구사항은 어떤 조건에서 어떻게 동작하고, 무엇으로 검수하는가 | 견적·계약·검수의 기준이 되는 핵심 문서 |
| 기능명세서 | 각 기능의 화면, 버튼, 상태, 예외 처리는 어떻게 되는가 | P0 핵심 기능을 개발자가 구현 가능한 수준으로 상세화 |
| 화면기획서 | 사용자는 어떤 화면 흐름으로 기능을 사용하는가 | UI, 사용자 여정, 입력 폼, 관리자 화면을 시각적으로 합의 |
| 테스트 케이스 | 어떤 입력과 조건이면 통과 또는 실패인가 | 최종 검수 시 ‘완료’ 판단 근거 |
정부지원사업 후 MVP 개발에서는 이 모든 문서를 따로 두껍게 만들 필요는 없습니다. 하지만 요구사항 명세서 안에 화면 링크, 데이터 항목, 우선순위, 검수 기준을 함께 넣으면 작은 팀도 관리 가능한 형태로 운영할 수 있습니다.
3. MVP용 요구사항 명세서 템플릿
아래 템플릿은 엑셀, 구글 시트, 노션 데이터베이스, Jira 이슈 어느 형태로든 옮길 수 있습니다. 핵심은 ‘한 줄에 기능 하나’가 아니라 ‘한 줄에 검수 가능한 요구사항 하나’를 넣는 것입니다.
| 항목 | 작성 기준 | 예시 |
|---|---|---|
| 요구사항 ID | 분류 약어와 번호를 조합해 변경 추적이 가능하게 작성 | SFR-001, SER-002, TER-003 |
| 분류 | 기능, 성능, 데이터, 보안, 테스트, 관리자, 연동 등 | 기능 요구사항 |
| 사용자·권한 | 누가 이 기능을 사용하는지 명시 | 일반 회원, 기업 관리자, 슈퍼 관리자 |
| 요구사항명 | 중복 없는 짧은 이름으로 작성 | 기업 회원 가입 승인 |
| 목적 | 이 기능이 필요한 사업·운영 목적을 한 문장으로 작성 | 검증된 기업만 견적 요청을 등록하도록 한다 |
| 상세 동작 | 조건, 입력값, 처리 규칙, 완료 상태를 포함 | 사업자등록번호, 담당자명, 이메일을 입력하면 승인 대기 상태로 저장된다 |
| 데이터 항목 | 저장·조회·수정·삭제되는 필드와 필수 여부 | 회사명 필수, 사업자등록번호 필수, 첨부파일 선택 |
| 예외 상황 | 중복, 실패, 권한 없음, 외부 API 장애 등 | 이미 등록된 사업자번호면 가입 요청을 막고 안내 문구를 표시 |
| 관련 화면 | 와이어프레임, Figma, 관리자 화면 링크 | WF-03 회원가입, ADM-02 승인 관리 |
| 관련 요구사항 | 데이터, 보안, 알림, 관리자 기능과 연결 | DAR-001, SER-001, SFR-007 |
| 우선순위 | P0 필수, P1 중요, P2 후보, OUT 제외 | P0 |
| 검수 기준 | 테스트 가능한 문장으로 작성 | 승인 전 사용자는 로그인 후 서비스 메인에 접근할 수 없어야 한다 |
| 산출물 | 화면, API, 관리자 기능, 테스트 결과, 매뉴얼 등 | 회원가입 화면, 승인 API, 관리자 승인 목록, 테스트 결과표 |
| 제외 범위 | 이번 MVP에 포함하지 않는 내용을 명시 | 휴대폰 본인인증은 2차 개발 범위 |
| 출처·결정권자 | 사업계획서, 고객 인터뷰, 내부 회의, 승인자 | 사업계획서 3-2, 대표 승인 |

4. 사업계획서 기능 목록을 명세서로 바꾸는 순서
- 사업계획서의 기능 문장을 모두 추출합니다. 예를 들어 ‘AI 기반 추천 기능’, ‘관리자 페이지’, ‘알림 기능’처럼 넓은 표현을 그대로 모읍니다.
- 사용자 흐름으로 재배치합니다. 가입 전, 가입 후, 결제 전, 관리자 검토, 운영자 통계 확인처럼 실제 사용 순서로 배열합니다.
- 각 흐름을 요구사항 ID로 쪼갭니다. 하나의 문장에 화면, 데이터, 알림, 권한이 섞여 있으면 분리합니다.
- 우선순위를 붙입니다. 정부지원사업 결과보고에 반드시 필요한 핵심 시연 기능은 P0, 출시 후 개선해도 되는 기능은 P1 또는 P2로 나눕니다.
- 검수 기준을 먼저 씁니다. 구현 방식보다 ‘어떤 조건이면 완료인가’를 먼저 쓰면 견적 범위가 선명해집니다.
- 개발사와 리뷰하며 제외 범위를 확정합니다. 제외 범위는 나중에 분쟁을 막는 문장입니다. ‘이번 범위에는 포함하지 않음’이 명확해야 합니다.
특히 MVP 단계에서는 기능을 많이 넣는 것보다 ‘이번 지원사업 기간 안에 검수 가능한 기능’을 고르는 것이 중요합니다. 우선순위 판단이 어렵다면 MVP 기능 우선순위 매트릭스 설계에서 설명한 방식처럼 사용자 가치, 검증 필요성, 개발 난이도, 운영 부담을 함께 놓고 판단하는 편이 좋습니다.
5. 기능 요구사항 작성 공식
기능 요구사항은 다음 공식을 쓰면 과하게 기술적이지 않으면서도 개발자가 이해할 수 있는 수준으로 정리됩니다.
사용자는 특정 조건에서 특정 입력을 하면, 시스템은 어떤 데이터를 검증하고 어떤 상태로 저장하며, 성공·실패 결과를 어떻게 보여준다.
예시: 기업 회원 가입 승인
| 요구사항 ID | SFR-001 |
|---|---|
| 분류 | 기능 요구사항 |
| 요구사항명 | 기업 회원 가입 승인 |
| 사용자 | 기업 회원, 관리자 |
| 상세 내용 | 기업 회원은 회사명, 사업자등록번호, 담당자명, 이메일, 비밀번호를 입력해 가입을 요청한다. 가입 직후 상태는 승인 대기이며, 관리자가 승인하기 전까지 핵심 서비스 메뉴에 접근할 수 없다. 관리자는 가입 요청 목록에서 기업 정보를 확인하고 승인 또는 반려할 수 있다. |
| 예외 | 이미 등록된 이메일 또는 사업자등록번호는 중복 안내를 표시한다. 반려된 사용자는 반려 사유를 확인할 수 있다. |
| 검수 기준 | 승인 대기 계정으로 로그인하면 서비스 메인 접근이 차단되어야 한다. 관리자가 승인 처리한 뒤 같은 계정으로 로그인하면 서비스 메인에 접근되어야 한다. 반려 시 반려 사유가 사용자 화면에 표시되어야 한다. |
| 산출물 | 가입 화면, 로그인 후 접근 제어, 관리자 승인 화면, 가입 상태 DB 필드, 테스트 결과 |
| 우선순위 | P0 |
이 정도만 작성해도 ‘회원가입’이라는 한 단어보다 훨씬 정확한 견적을 받을 수 있습니다. 반대로 ‘회원가입 기능 구현’이라고만 쓰면 소셜 로그인, 이메일 인증, 약관 동의, 관리자 승인, 휴면 처리, 개인정보 파기 정책이 포함인지 제외인지 개발사마다 다르게 해석합니다.

6. 나쁜 요구사항과 좋은 요구사항 비교
| 기능 | 나쁜 요구사항 | 좋은 요구사항 | 비용 영향 |
|---|---|---|---|
| 로그인 | 로그인 기능 | 이메일과 비밀번호로 로그인한다. 비밀번호 5회 실패 시 10분간 잠금 처리한다. 관리자는 잠금 해제를 할 수 있다. | 보안 정책, 관리자 기능, 알림 여부에 따라 달라짐 |
| 관리자 | 관리자 페이지 제공 | 관리자는 회원 목록 검색, 상태 변경, 가입 승인, 반려 사유 입력, CSV 다운로드를 할 수 있다. | 관리자 기능은 화면 수와 권한 정책에 따라 별도 공수가 필요 |
| 알림 | 알림 발송 | 승인 완료 시 사용자 이메일로 알림을 보낸다. 카카오 알림톡과 SMS는 이번 범위에서 제외한다. | 채널별 외부 서비스 연동비와 발송 실패 처리가 달라짐 |
| 결제 | 결제 기능 | 신용카드 정기결제는 제외하고, MVP에서는 관리자 확인 후 수동 입금 상태만 관리한다. | PG 연동, 정산, 환불, 영수증, 보안 이슈가 범위를 크게 바꿈 |
| AI 추천 | AI가 자동 추천 | 사용자가 입력한 업종, 예산, 목표 고객 정보를 기반으로 사전 정의된 추천 규칙과 LLM 응답을 조합해 후보 3개를 제시한다. 추천 근거와 사용한 입력값을 함께 저장한다. | AI 기능은 데이터 구조, 프롬프트, 로그, 평가 방식까지 정해야 함 |
최근 공개된 공공 제안요청서 사례에서도 기능 요구사항 SFR, 성능 요구사항 PER, 인터페이스 요구사항 SIR, 데이터 요구사항 DAR처럼 요구사항 ID를 구분하고 각 항목을 세부 내용으로 나누어 관리하는 방식을 확인할 수 있습니다. ([g2b.go.kr](https://www.g2b.go.kr/pn/pnp/pnpe/UntyAtchFile/downloadFile.do?bidPbancNo=R26BK01512298&bidPbancOrd=000&fileSeq=2&fileType=&prcmBsneSeCd=01)) 스타트업 문서도 이 정도의 체계를 가볍게 차용하면 견적 비교가 쉬워집니다.
7. 비기능 요구사항을 빼면 생기는 문제
초기 팀이 가장 자주 놓치는 부분이 비기능 요구사항입니다. 기능은 보이지만 비기능은 보이지 않기 때문입니다. 그러나 성능, 보안, 백업, 로그, 브라우저 호환성, 관리자 권한, 개인정보 처리 방식은 개발 범위와 운영 리스크를 직접 바꿉니다.
| 분류 | 써야 할 질문 | MVP 작성 예시 |
|---|---|---|
| 성능 | 어느 화면에서 어느 정도 응답 속도가 필요한가 | 검색 결과는 일반적인 테스트 데이터 기준으로 사용자가 지연을 체감하지 않는 수준을 목표로 한다. 정확한 목표 수치는 개발사와 데이터 규모 합의 후 확정한다. |
| 보안 | 어떤 정보가 민감하고 누가 접근할 수 있는가 | 관리자만 회원 개인정보 상세를 조회할 수 있다. 일반 운영자는 이메일 일부를 마스킹해 본다. |
| 권한 | 사용자 유형별로 가능한 행동이 다른가 | 기업 관리자만 팀원을 초대할 수 있고, 일반 팀원은 조회만 가능하다. |
| 데이터 | 어떤 데이터를 저장하고 얼마나 보관하는가 | 견적 요청 이력은 관리자 화면에서 검색 가능해야 하며, 삭제 정책은 운영 정책 확정 후 반영한다. |
| 로그 | 나중에 장애와 분쟁을 추적할 수 있는가 | 관리자 승인, 반려, 상태 변경은 처리자, 처리일시, 변경 전후 값을 기록한다. |
| 백업 | 데이터 손실 시 복구 기준은 무엇인가 | MVP에서는 운영 DB 백업 주기와 복구 방식은 배포 환경 설계 단계에서 별도 합의한다. |
| 호환성 | 어떤 기기와 브라우저까지 보장할 것인가 | 관리자 화면은 데스크톱 웹 기준으로 우선 구현하고 모바일 최적화는 제외한다. |
| AI 품질 | AI 응답을 어떻게 검수하고 통제할 것인가 | AI 추천 결과에는 추천 근거를 표시하고, 운영자가 부적절한 결과를 신고·수정할 수 있는 로그를 남긴다. |
비기능 요구사항은 모든 숫자를 처음부터 확정하라는 뜻이 아닙니다. 오히려 모르는 항목은 ‘개발사와 협의 후 확정’이라고 표시하고, 그 항목이 비용과 일정에 영향을 주는 결정사항임을 드러내야 합니다.
8. 검수 기준은 어떻게 써야 하나
요구공학에서 검수 기준은 이해관계자가 산출물을 받아들일 수 있는 조건으로 설명됩니다. ([cpre.ireb.org](https://cpre.ireb.org/en/downloads-and-resources/glossary?utm_source=openai)) 실무적으로는 ‘대표가 봤을 때 마음에 드는가’가 아니라, 특정 입력과 조건에서 기대 결과가 재현되는가로 써야 합니다.
검수 기준 작성 패턴
- 조건: 승인 대기 상태의 기업 회원이 로그인한 경우
- 행동: 서비스 메인 URL에 접근하면
- 기대 결과: 승인 대기 안내 화면으로 이동하고 핵심 메뉴는 노출되지 않는다
- 실패 기준: 승인 전 사용자가 핵심 데이터 목록을 조회할 수 있으면 실패
- 증빙: 테스트 계정, 테스트 화면 캡처, 관리자 상태 변경 로그
검수 기준을 요구사항마다 1개 이상 넣으면 최종 검수 회의가 훨씬 짧아집니다. 특히 정부지원사업 결과보고나 중간 점검을 염두에 둔다면, 시연 가능한 사용자 시나리오와 관리자 시나리오를 함께 준비하는 것이 좋습니다. 다만 제출해야 할 산출물과 형식은 사업별 공고, 협약서, 주관기관 안내가 우선입니다.
9. 우선순위는 기능 중요도가 아니라 검수 위험도까지 봐야 한다
| 우선순위 | 의미 | 계약·견적 처리 |
|---|---|---|
| P0 | MVP 시연과 핵심 검증에 없으면 안 되는 기능 | 계약 범위에 포함하고 검수 기준을 상세히 작성 |
| P1 | 있으면 제품 완성도가 올라가지만 P0 이후 진행 가능한 기능 | 일정 여유 또는 추가 견적 조건으로 분리 |
| P2 | 출시 후 개선 또는 고객 반응 확인 후 개발할 기능 | 백로그로 관리하고 이번 견적에서는 제외 |
| OUT | 이번 정부지원사업 또는 MVP 범위에 포함하지 않는 기능 | 제외 범위에 명시해 추후 변경 요청으로 처리 |
우선순위를 정할 때는 기능의 멋짐보다 검수 리스크를 먼저 보아야 합니다. 예를 들어 AI 추천 기능이 사업계획서의 핵심 차별점이라면 추천 정확도 자체를 완벽하게 만들 수 없더라도, 입력값 저장, 추천 결과 표시, 추천 근거 기록, 운영자 피드백 로그는 P0가 될 수 있습니다. 반면 결제 자동화는 사업 검증에 당장 필요하지 않다면 수동 결제 확인으로 줄일 수 있습니다.
10. 외주개발 계약과 연결할 때 반드시 넣을 항목
요구사항 명세서는 계약서와 따로 놀면 안 됩니다. 계약서에는 전체 범위, 산출물, 검수 절차, 변경 요청, 소스코드 권리, 유지보수 범위를 넣고, 요구사항 명세서는 그 계약의 상세 별첨처럼 관리하는 방식이 안전합니다. 계약 조항을 함께 점검해야 한다면 외주개발 계약서 필수 조항 체크리스트를 같이 확인해 두는 것이 좋습니다.
- 범위 기준: 본 계약의 개발 범위는 요구사항 명세서 v1.0의 P0 항목으로 한다.
- 변경 기준: P0 항목의 추가·삭제·수정은 변경 요청서와 견적 재산정 대상이다.
- 검수 기준: 요구사항별 검수 기준 통과 여부와 주요 화면 시연을 기준으로 한다.
- 산출물: 소스코드, DB 스키마, 배포 환경 정보, 관리자 계정, API 문서, 운영 매뉴얼 등 제출 대상을 명시한다.
- 하자와 추가 개발 구분: 명세서에 있는 기능이 기준대로 동작하지 않으면 하자, 명세서에 없던 기능 추가는 변경 요청으로 본다.
공개 용역 제안요청서에서도 착수계, 수행계획서, 진도 보고서, 최종보고서, 원본 저장 매체와 코드 포함 자료 등 산출물을 구체적으로 열거하는 사례가 있습니다. ([g2b.go.kr](https://www.g2b.go.kr/pn/pnp/pnpe/UntyAtchFile/downloadFile.do?bidPbancNo=R26BK01391973&bidPbancOrd=002&fileSeq=3&fileType=&prcmBsneSeCd=03)) 스타트업 외주계약도 규모에 맞게 단순화하되, 최종 인수 시 무엇을 받아야 하는지는 반드시 문서화해야 합니다. 개발 완료 후 인수 기준은 외주개발 인수인계 체크리스트를 함께 보면 빠뜨리는 항목을 줄일 수 있습니다.

11. 계약 전·개발 착수 전·검수 전 체크리스트
계약 전
- 사업계획서의 기능 문장이 요구사항 ID로 분리되어 있는가
- P0, P1, P2, 제외 범위가 구분되어 있는가
- 관리자 기능이 별도 요구사항으로 작성되어 있는가
- 외부 API, 결제, 알림톡, 지도, AI API 등 유료·연동 항목이 표시되어 있는가
- 개발사가 견적에서 제외한 항목을 문서로 남겼는가
개발 착수 전
- 요구사항 명세서 버전과 승인자가 정해져 있는가
- 화면기획서 또는 와이어프레임과 요구사항 ID가 연결되어 있는가
- DB에 저장해야 하는 필수 데이터 항목이 정리되어 있는가
- 테스트 계정, 테스트 데이터, 검수 환경을 어떻게 만들지 합의했는가
- 변경 요청이 생겼을 때 승인권자와 비용 산정 절차가 있는가
검수 전
- P0 요구사항별 통과·실패 여부가 표로 정리되어 있는가
- 실패 항목의 재검수 일정과 담당자가 정해져 있는가
- 관리자 계정, 서버, 도메인, 배포 정보, 소스코드 접근 권한을 인수받았는가
- 운영 중 필요한 로그, 백업, 오류 대응 방법을 확인했는가
- 정부지원사업 결과보고에 사용할 화면 캡처, 시연 영상, 산출물 목록을 확보했는가
12. AgentMit가 요구사항 정리를 도울 수 있는 경우
요구사항 명세서는 대표가 혼자 쓰는 문서도, 개발사가 알아서 만들어 주는 문서도 아닙니다. 사업 목표, 운영 방식, 사용자 경험, 기술 구현, 검수 기준이 함께 들어가야 합니다. AgentMit는 AI 서비스 개발, SaaS MVP, 업무 자동화, 관리자 대시보드, 정부지원사업 MVP 개발처럼 범위와 검수 기준이 중요한 프로젝트에서 요구사항 정리와 우선순위 조정을 도울 수 있습니다.
예를 들어 사업계획서에 ‘AI 기반 업무 자동화’라고 적혀 있다면 실제로는 데이터 업로드, 권한 관리, 프롬프트 처리, 결과 검토, 관리자 수정, 사용량 로그, 오류 대응까지 나눠야 합니다. BizMit과 같은 업무 운영형 SaaS를 설계할 때도 기능 목록보다 운영 흐름과 관리자 기준을 먼저 정리해야 개발 후 현장에서 쓸 수 있습니다. 다만 AgentMit는 정부지원사업의 공식 대행기관이나 선정 보장 기관이 아닙니다. 역할은 선정 전후의 MVP 범위 설계, 개발 문서화, 구현 가능성 검토, 실제 서비스 개발을 실무적으로 돕는 것입니다.
13. 바로 복사해서 쓰는 간단 템플릿
| ID | 분류 | 요구사항명 | 사용자 | 상세 내용 | 예외 | 우선순위 | 검수 기준 | 산출물 | 제외 범위 |
|---|---|---|---|---|---|---|---|---|---|
| SFR-001 | 기능 | 회원 가입 | 일반 사용자 | 이메일, 비밀번호, 이름을 입력해 가입한다. 가입 후 기본 상태는 활성이다. | 중복 이메일이면 가입 불가 | P0 | 신규 이메일로 가입하면 로그인 가능해야 한다. 중복 이메일은 오류 안내가 표시되어야 한다. | 가입 화면, 회원 DB, 테스트 결과 | 소셜 로그인 제외 |
| ADM-001 | 관리자 | 회원 목록 관리 | 관리자 | 관리자는 회원 목록을 검색하고 상태를 변경할 수 있다. | 권한 없는 사용자는 관리자 URL 접근 불가 | P0 | 관리자 계정으로 회원 상태를 변경하면 사용자 로그인 가능 여부가 바뀌어야 한다. | 관리자 화면, 권한 체크 | CSV 다운로드는 P1 |
| SER-001 | 보안 | 개인정보 접근 제한 | 관리자 | 개인정보 상세는 관리자만 조회할 수 있다. | 일반 사용자는 타인의 개인정보 조회 불가 | P0 | 일반 사용자 계정으로 타인 정보 API를 호출하면 접근 거부되어야 한다. | 권한 정책, 테스트 결과 | 개인정보 파기 자동화는 별도 협의 |
| TER-001 | 테스트 | 핵심 시나리오 검수 | PM, 발주자 | 가입, 로그인, 핵심 기능 사용, 관리자 확인까지 하나의 시연 흐름으로 테스트한다. | 테스트 데이터 오류 시 재실행 | P0 | 준비된 테스트 계정으로 전체 흐름이 중단 없이 완료되어야 한다. | 검수표, 화면 캡처 | 부하 테스트 제외 |
이 표를 시작점으로 삼되, 결제·알림·AI·외부 API·관리자 권한이 들어가는 순간에는 반드시 요구사항을 더 쪼개야 합니다. 기능 하나가 아니라 비용과 검수 기준이 달라지는 단위로 나누는 것이 핵심입니다.
FAQ
Q1. 요구사항 명세서와 기능명세서는 다른 문서인가요?
실무에서는 혼용되지만 목적이 다릅니다. 요구사항 명세서는 기능, 비기능, 데이터, 권한, 검수 기준, 산출물까지 포함해 개발 범위와 계약 기준을 정하는 문서입니다. 기능명세서는 그중 기능 동작을 더 세부적으로 설명하는 하위 문서에 가깝습니다.
Q2. 정부지원사업 선정 후 요구사항 명세서를 꼭 제출해야 하나요?
모든 사업에서 동일하게 필수 제출물이라고 단정할 수는 없습니다. 공고문, 협약서, 전담기관 지침, 주관기관 안내가 우선입니다. 다만 외주개발 계약, 사업비 집행 설명, 중간·최종 검수 대응을 위해 요구사항 명세서를 준비하면 개발 범위와 산출물 기준을 훨씬 명확히 만들 수 있습니다.
Q3. 외주개발 견적을 받기 전 요구사항은 어느 수준까지 작성해야 하나요?
최소한 사용자 유형, 핵심 기능 목록, 관리자 기능, 데이터 항목, 외부 연동, 우선순위, 제외 범위, 검수 기준까지는 있어야 합니다. 화면 디자인이 없어도 되지만, 기능마다 입력값·처리 규칙·예외 상황이 없으면 개발사별 견적이 서로 다른 전제로 산정될 가능성이 큽니다.
Q4. MVP 요구사항도 처음부터 상세하게 써야 하나요?
모든 기능을 대형 프로젝트처럼 문서화할 필요는 없습니다. 대신 P0 핵심 기능은 검수 가능한 수준까지 상세히 쓰고, P1·P2 기능은 범위와 제외 조건을 분명히 적는 방식이 현실적입니다. MVP에서는 상세함보다 우선순위와 변경 기준의 명확성이 더 중요합니다.
Q5. 개발 중 요구사항이 바뀌면 어떻게 관리해야 하나요?
변경 요청서를 별도로 만들고 요구사항 ID, 변경 사유, 영향 기능, 일정·비용 영향, 승인자를 기록해야 합니다. 구두 요청이나 메신저 합의만으로 진행하면 검수 시 기준이 흔들립니다. 계약서에는 변경 범위와 추가 견적 절차를 함께 넣는 것이 좋습니다.
참고한 기준과 자료
- 국가법령정보센터, 소프트웨어사업 상세 요구사항 분석·적용기준: 요구사항 분류와 작성 항목 참고. ([law.go.kr](https://law.go.kr/flDownload.do?bylClsCd=200201&flNm=%5B%EB%B3%84%ED%91%9C+2%5D+%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EC%82%AC%EC%97%85+%EC%83%81%EC%84%B8+%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD+%EB%B6%84%EC%84%9D%C2%B7%EC%A0%81%EC%9A%A9%EA%B8%B0%EC%A4%80%28%EC%A0%9C11%EC%A1%B0+%EA%B4%80%EB%A0%A8%29&flSeq=128124887))
- 정보통신산업진흥원, 소프트웨어사업 요구사항 분석적용 가이드 공지: 공공 SW 요구사항 세분화 배경 참고. ([nipa.kr](https://www.nipa.kr/home/2-1/277))
- 나라장터 공개 제안요청서, AI기반 LCA데이터처리 시스템 구축: 요구사항 ID와 분류 사례 참고. ([g2b.go.kr](https://www.g2b.go.kr/pn/pnp/pnpe/UntyAtchFile/downloadFile.do?bidPbancNo=R26BK01512298&bidPbancOrd=000&fileSeq=2&fileType=&prcmBsneSeCd=01))
- 창업진흥원 초기창업패키지 사업안내: 정부지원사업 선정 후 시제품 제작 맥락 참고. ([kised.or.kr](https://www.kised.or.kr/menu.es?mid=a10205020000))
- IREB CPRE Glossary: 검수 기준 개념 참고. ([cpre.ireb.org](https://cpre.ireb.org/en/downloads-and-resources/glossary?utm_source=openai))

