ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 요구사항 정의서와 기능 명세서 차이, 실무 구분 기준
    프로젝트 유형별 플레이북 2026. 7. 18. 04:20

    요구사항 정의서와 기능 명세서는 다른 문서다. 앞의 것은 발주자가 "무엇이 필요한가"를 적는 문서이고 뒤의 것은 개발자가 "그래서 시스템이 정확히 어떻게 동작하는가"를 적는 문서다. 외주 프로젝트에서 두 문서를 섞어 쓰면 견적 단계와 검수 단계가 함께 흔들린다. 이 글은 두 문서의 역할 경계, 발주 단계별로 누가 어떤 문서를 책임지는지, 그리고 발주자가 요구사항 정의서에서 멈춰도 되는 지점을 정리한다.


    두 문서의 역할 경계


    요구사항 정의서의 주어는 사용자다. "회원이 이메일로 가입할 수 있어야 한다"처럼 무엇이 가능해야 하는지를 적는다. 기능 명세서의 주어는 시스템이다. 같은 요구가 "가입 화면은 이메일 형식을 검증하고, 중복이면 안내 문구를 띄운다"처럼 동작 단위로 쪼개진다.

    그래서 작성 주체가 다르다. 요구사항 정의서는 발주자가 초안을 쥐고 업체와 다듬는 문서이고 기능 명세서는 업체가 요구사항을 받아 기술 언어로 번역한 문서다. 실무에서 진행하다 보면 발주자가 기능 명세서까지 쓰려다 어색한 기술 용어를 섞어 오해가 생기는 경우가 있는데, 그럴 필요가 없다. 발주자의 몫은 요구를 빠짐없이 적는 데까지다.


    발주 단계별 문서 대응표


    • 상담·견적 단계 - 요구사항 정의서. 발주자가 초안 작성, 업체가 질문으로 보완한다. 견적의 근거가 된다.
    • 계약 직후 - 기능 명세서. 업체가 요구사항을 화면·동작 단위로 확정한다. 발주자는 검토·승인만 한다.
    • 개발 중 - 변경 요청서. 요구가 바뀌면 두 문서 어디에 영향이 가는지 업체가 명시한다.
    • 검수 단계 - 두 문서 모두. 요구사항 정의서로 "빠진 것"을, 기능 명세서로 "다르게 동작하는 것"을 가른다.

    이 대응이 무너지는 전형이 있다. 견적은 요구사항 정의서 없이 말로 받고 검수는 기능 명세서 없이 감으로 하는 경우다. 그러면 견적 근거도 검수 기준도 없어서 분쟁이 나면 기댈 문서가 없다.


    발주자가 멈춰도 되는 지점


    요구사항 정의서에서 화면 목록, 기능 목록, 저장할 데이터, 예외 상황까지 적었다면 발주자의 준비는 충분하다. 데이터베이스 설계나 화면 상세 규격은 기능 명세서의 영역이고 업체가 쓰는 것이 맞다.

    대신 기능 명세서를 받으면 반드시 읽어야 한다. 요구사항 한 줄이 명세서에서 여러 동작으로 갈라지는데, 그 갈라진 결과가 의도와 맞는지 확인할 사람은 발주자뿐이다. 진행하다 보면 "명세서는 어려워서 안 읽었다"는 발주자가 있는데, 검수 때 기준으로 쓰이는 문서를 안 읽고 승인하면 그 기준에 그대로 묶인다.

    승인 전에 확인할 최소 루틴은 이렇다.

    • 요구사항 정의서의 기능 목록과 명세서의 화면·동작이 하나씩 짝이 맞는지 센다.
    • 예외 상황(취소·오입력·마감)이 명세서에서 어떤 동작으로 처리되는지 확인한다.
    • 명세서에 없는 요구가 발견되면 개발 시작 전에 문서를 고쳐 달라고 요청한다.

    요구사항 정의서 자체를 어떻게 쓰는지는 원문에서 7개 항목 템플릿으로 정리했다.


    Q&A


    Q. 요구사항 정의서 없이 기능 명세서만 받으면 안 되나?
    A. 위험하다. 명세서는 요구사항을 번역한 문서라, 원본 요구가 문서로 없으면 번역이 맞는지 대조할 기준이 없다. 견적 비교도 요구사항 정의서 단위로 해야 같은 범위가 된다.

    Q. 두 문서를 하나로 합쳐 쓰면 안 되나?
    A. 작은 프로젝트라면 한 문서에 두 층위를 나눠 적기도 한다. 다만 "사용자가 원하는 것"과 "시스템이 하는 것"을 같은 문장에 섞지 않는 것이 조건이다. 섞이는 순간 검수 기준이 흐려진다.

    원문: https://nova-lab.dev/r/t/requirements-doc-basics


    자주 묻는 질문


    Q. 요구사항 정의서는 몇 장 정도 써야 하나요?

    분량보다 항목이 중요하다.

    단순 소개형은 한두 장, 예약·회원 기능형은 서너 장이면 충분한 경우가 많다.

    화면·기능·데이터·예외가 빠짐없이 담겼는지가 기준이다.

     

    Q. 개발 용어를 몰라도 쓸 수 있나요?

    쓸 수 있다.

    일상 언어로 동작을 문장으로 적으면 업체가 기술 용어로 번역해 준다.

    모르는 용어를 억지로 쓰면 오히려 오해가 생긴다.

     

    Q. 업체가 알아서 정리해 주지 않나요?

    좋은 업체는 상담으로 요구를 끌어내 주지만 그 시간도 비용에 들어간다.

    초안이 있으면 상담이 확인 중심으로 바뀌어 견적이 빨라지고 정확해진다.

    글 · 노바랩 NovaLab · https://nova-lab.dev

Designed by Tistory.