요구사항 정의서 작성법 2026: 양식·항목과 요구사항 명세서·기능명세서 차이

요구사항 정의서는 만들려는 서비스가 무엇을 해야 하는지를 문장 단위로 적어서 확정한 문서예요. 발주자가 개발사에 "이걸 만들어 주세요"라고 넘기는 기준이자, 개발이 끝난 뒤 "이대로 만들어졌나요"를 따지는 기준이기도 해요. 영어로는 Requirements Definition Document 또는 SRS(Software Requirements Specification)라고 부르고, 국내 현장에서는 요구사항 정의서와 요구사항 명세서를 섞어 씁니다.

이 글은 기획자나 개발자가 아니라 발주자, 그러니까 개발사에 돈을 지불하고 결과물을 받는 쪽을 위해 썼어요. 그래서 "요구사항을 분석하는 방법론"이 아니라 무엇을 요구 문장으로 적고, 개발사가 써 온 문서에서 무엇을 확인하는가를 다룹니다. 기능명세서와 화면설계서가 어떻게 다른지, 왜 "~할 수 있다"로 쓰는지, 우선순위는 어떻게 표기하는지, 그리고 이 문서가 왜 나중에 검수 기준으로 돌아오는지를 순서대로 정리했습니다.

요구사항 정의서는 무엇이고 누가 쓰나요?

요구사항 정의서는 서비스가 충족해야 할 조건을 한 줄씩 나열한 목록이에요. "회원은 이메일로 가입할 수 있다", "주문이 접수되면 판매자에게 알림이 발송된다" 같은 문장이 줄줄이 이어집니다. 각 문장에는 번호가 붙고, 우선순위가 붙고, 무엇을 보면 완료로 볼지가 붙습니다. 그림도 화면도 없이 문장만 있는 문서라고 생각하면 대체로 맞습니다.

누가 쓰느냐는 계약 형태에 따라 갈립니다. 원칙적으로는 발주자 쪽이 "무엇을"을 쓰고 개발사가 "어떻게"를 붙이지만, 실제로는 개발사가 초안을 작성하고 발주자가 검토·확정하는 형태도 자주 씁니다. 어느 쪽이 타이핑했든 최종 승인 주체는 발주자예요. 이 문서를 계약서가 범위의 근거로 참조하고 있다면, 여기 없는 기능은 추가 비용과 추가 일정 협의 대상이 됩니다. 실제 효력은 계약서의 범위·변경 조항이 이 문서를 어떻게 참조하는지에 따라 달라지니 두 문서를 함께 확인하세요.

그래서 발주자가 읽지 않고 넘어가면 나중에 "그건 요구사항에 없었습니다"라는 말의 근거가 이 문서가 됩니다. 반대로 발주자가 이 문서를 제대로 읽어두면, 같은 문장이 개발사에 대한 방패로도 작동합니다. 문서 자체는 중립적이고, 읽은 쪽이 유리해집니다.

요구사항 정의서와 기능명세서, 화면설계서는 무엇이 다른가요?

세 문서는 이름이 비슷해서 미팅에서 실제로 뒤섞입니다. 한 문장으로 가르면 이렇습니다. 요구사항 정의서는 무엇을 해야 하는가, 기능명세서는 그 기능이 어떤 규칙으로 동작하는가, 화면설계서는 그것이 어느 화면에서 어떻게 보이는가를 답합니다.

가르는 실전 기준은 "이 문장을 지웠을 때 사라지는 것이 무엇인가"입니다. 사업상의 요구가 사라지면 요구사항 정의서 항목이고, 동작 규칙이 사라지면 기능명세서 항목이고, 배치와 문구가 사라지면 화면설계서 항목입니다. 예를 들어 "회원은 비밀번호를 재설정할 수 있다"는 요구사항, "재설정 링크는 발급 후 일정 시간이 지나면 만료된다"는 기능명세, "메일 발송 완료 화면에 재발송 버튼을 둔다"는 화면설계입니다.

이 글이 다루는 범위는 표의 첫 칸입니다. 요구사항 문장, 우선순위, 완료 판정 기준이 여기 소속이에요. 기능 한 줄의 동작 규칙과 예외를 어떻게 적는지는 기능명세서 작성법: 양식·예시와 개발사에 넘기는 기준에서 다루고, 화면 목록과 배치를 어떻게 정리하는지는 화면설계서 작성법: 양식·예시와 와이어프레임의 차이에서 다룹니다.

세 문서를 한 파일에 합치는 경우도 있는데, 합치면 변경의 무게를 구분하지 못하게 됩니다. 버튼 위치를 옮기는 일과 기능 하나를 통째로 추가하는 일이 같은 문서의 같은 줄에서 벌어지면, 어느 쪽이 추가 비용 대상인지 판단할 근거가 사라집니다.

세 문서는 어떤 순서로 만들어지나요?

흔히 쓰는 순서는 기획 정리, 제안요청서(RFP), 요구사항 정의서, 기능명세서, 화면설계서, 개발, 검수입니다. 앞 단계가 뒤 단계의 입력이 되기 때문에, 앞이 흔들리면 뒤가 통째로 다시 만들어집니다. 요구사항 한 줄이 바뀌면 기능명세 여러 항목과 화면 여러 장이 함께 움직입니다.

현실에서는 이 순서가 깔끔하게 지켜지지 않고 상당 부분 병렬로 진행됩니다. 그래도 요구사항 정의서만은 견적 이전에 한 번 굳혀두는 편이 낫습니다. 견적을 뜯어보면 결국 무엇을 몇 개 만드는가로 환원되기 때문에, 목록이 없으면 총액의 근거를 되짚을 수 없습니다. 발주 문서를 처음부터 준비한다면 RFP 뜻과 작성법 완전 가이드가 앞 단계를 다룹니다.

기획 자체가 정리되지 않은 상태라면 요구사항 문장을 쓰는 일이 먼저가 아니에요. 핵심 사용자와 핵심 행동이 정해져야 요구사항 문장이 나옵니다. 그 앞 단계는 IT 프로젝트 기획 완전 가이드에 정리돼 있습니다.

요구사항 정의서 양식에는 어떤 항목이 들어가나요?

양식은 크게 문서 머리와 본체로 나뉩니다. 문서 머리에는 프로젝트 개요, 적용 범위, 용어 정의, 개정 이력이 들어갑니다. 본체는 요구사항 목록 하나로, 여기가 문서의 전부라고 봐도 됩니다. 양식 파일 자체는 어디서 받아도 모양이 비슷합니다. 차이를 만드는 건 목록 한 줄에 어떤 칸이 있는지예요.

칸이 부족한 양식은 나중에 분쟁의 재료가 됩니다. 특히 "완료 판정 기준"과 "우선순위"가 빠진 양식이 자주 돌아다니는데, 이 두 칸이 없으면 검수와 범위 조정을 할 수 없습니다. 아래 표는 요구사항 한 줄이 갖춰야 하는 칸과, 그 칸이 비었을 때 실제로 벌어지는 일을 정리한 것입니다.

우선순위 칸과 상태 칸이 겹쳐 보일 수 있는데 역할이 다릅니다. 우선순위 Won't는 "이번 범위에서는 하지 않기로 합의했다"는 뜻이라 다음 단계에서 다시 올라올 수 있는 항목이고, 상태 취소는 "이 요구 자체를 접었다"는 뜻입니다. 둘 다 줄을 지우지 않고 남겨둡니다.

칸 이름만 보면 감이 안 잡히니, 채워진 줄을 그대로 옮겨 적을 수 있게 예시를 붙입니다. 아래 세 줄은 이 글 본문에서 쓴 문장을 그대로 넣은 것입니다.

칸이 열 개라고 해서 부담스러워할 필요는 없습니다. 표 형태로 한 줄에 한 요구사항을 담으면 항목이 많아도 문서가 두꺼워지지 않아요. 오히려 서술형 문단으로 길게 쓴 요구사항 정의서가 읽히지 않고, 읽히지 않은 문서는 검수에서 쓰이지 않습니다.

기능 요구사항과 비기능 요구사항은 어떻게 나누나요?

기능 요구사항은 사용자가 할 수 있게 되는 행동이고, 비기능 요구사항은 그 행동이 어떤 조건에서 이뤄져야 하는지입니다. "장바구니에 상품을 담을 수 있다"는 기능, "장바구니 화면은 모바일 브라우저에서도 동일하게 동작한다"는 비기능이에요. 판별 질문은 하나입니다. 이 문장을 지웠을 때 사라지는 것이 사용자의 행동인지, 그 행동의 품질인지 보면 됩니다.

발주자가 놓치기 쉬운 쪽은 비기능입니다. 기능은 눈에 보이니까 빠지면 바로 알아채는데, 비기능은 출시 직후나 사용자가 늘어난 뒤에야 문제로 드러납니다. 그리고 비기능은 뒤늦게 추가하면 구조를 손대야 해서 비용이 크게 붙습니다. 그래서 비기능 항목은 기능 목록을 다 쓴 뒤 별도 절로 한 번 훑는 습관을 만드는 게 좋습니다.

비기능 요구사항에 숫자를 넣을 때는 측정 조건을 함께 적어야 의미가 생깁니다. "3초 안에 응답한다"만 쓰면 어떤 회선에서, 몇 명이 붙었을 때, 어느 화면 기준인지가 빠져 있어 판정이 불가능합니다. 숫자를 정하기 어렵다면 개발사에 "이 화면의 목표치를 제안해 주세요"라고 요청하고, 그 제안을 문서에 받아 적으면 됩니다. 이 표의 항목 가운데 보안 점검·취약점 대응, 백업·복구·재해대응, 글로벌·다국어 출시 세 가지는 계약 조항 수준으로 따로 정리한 글이 있어서, 한 줄로 적기 어렵다면 그쪽을 보고 문장을 가져오면 됩니다.

요구사항은 왜 "~할 수 있다" 형식으로 쓰나요?

이 형식을 쓰는 이유는 문체 취향이 아니라 참과 거짓을 판정하기 위해서예요. "회원 정보를 관리한다"는 문장은 개발이 끝난 뒤 됐는지 안 됐는지 판정할 수 없습니다. "관리자는 회원의 이메일을 수정할 수 있다"는 문장은 화면에 들어가서 해보면 바로 판정됩니다. 검수 가능한 문장만 계약 문서로 쓸모가 있습니다.

문장 구조는 주어(누가) + 조건(언제) + 행동(무엇을 할 수 있다)로 잡습니다. 주어를 빼면 권한 설계가 통째로 빠지고, 조건을 빼면 예외 상황이 개발사 재량으로 넘어갑니다. "비밀번호를 변경할 수 있다"와 "로그인한 회원은 현재 비밀번호를 입력한 뒤 비밀번호를 변경할 수 있다"는 만들어지는 결과물이 다릅니다.

또 하나 지킬 규칙은 한 문장에 요구 하나예요. "상품을 등록하고 수정하고 삭제할 수 있다"처럼 세 개를 묶으면, 셋 중 둘만 됐을 때 그 줄을 완료로 볼지 미완으로 볼지 애매해집니다. 견적도 세 줄로 나눠야 정확해지고, 우선순위도 셋이 서로 다를 수 있습니다. 줄이 늘어나는 걸 두려워하지 말고 쪼개는 편이 낫습니다.

부정형과 모호어도 피합니다. "느리지 않아야 한다", "직관적이어야 한다", "필요시 알림을 보낸다" 같은 문장은 판정 기준이 없어서 검수에서 그대로 분쟁이 됩니다. "필요시"는 특히 위험한데, 필요를 누가 판단하는지가 적혀 있지 않기 때문이에요.

우선순위는 Must·Should·Could로 어떻게 표기하나요?

우선순위 표기는 MoSCoW라고 부르는 방식을 자주 씁니다. Must(반드시), Should(있어야 하지만 없어도 출시 가능), Could(여유가 되면), Won't(이번에는 하지 않음) 네 등급이에요. 이 표기가 중요한 이유는 예산이나 일정이 줄었을 때 무엇을 뺄지를 미리 합의해 두는 장치이기 때문입니다. 요구사항 목록에서 등급을 정해두면 기능명세서와 견적서는 그 등급을 옮겨 적기만 하면 됩니다.

Won't 등급을 문서에 남기는 것도 의미가 있습니다. 논의는 됐지만 이번 범위에 넣지 않기로 한 항목을 적어두면, 몇 달 뒤 "그건 당연히 포함인 줄 알았다"는 대화가 줄어듭니다. 빠진 것을 적는 칸이 있는 문서가 안전합니다. 아래 표는 각 등급을 문서에 어떤 형태로 남기는지를 기준으로 정리한 것입니다.

실무에서 반복적으로 관찰되는 실패는 모든 항목에 Must를 붙이는 것이에요. 전부 Must면 우선순위가 없는 것과 같고, 일정이 밀렸을 때 개발사가 임의로 뺀 항목이 나중에 문제가 됩니다. 스스로 정하기 어렵다면 Must의 개수를 먼저 정해놓고 그 안에 들어갈 항목을 고르는 방식이 편합니다. 어떤 기능을 어느 등급으로 보낼지 판정하는 질문은 MVP 범위 확정 절차와 경계 기능 판단에 정리돼 있으니 그쪽에 맡기고, 이 글은 정해진 등급을 문서에 어떻게 표기하는지만 다룹니다.

요구사항 ID는 왜 붙이고 어떻게 매기나요?

ID가 견적서·변경 요청·검수 결과를 서로 연결하는 열쇠라는 설명과 번호 체계를 정하는 방법은 기능명세서 작성법: 양식·예시와 개발사에 넘기는 기준에서 다룹니다. 여기서는 요구사항 목록에서만 지켜야 하는 규칙 두 가지를 적습니다.

첫째, 한 번 부여한 번호는 재사용하지 않습니다. REQ-PAY-014를 취소한 뒤 새 요구에 같은 번호를 다시 붙이면, 몇 달 전 회의록과 견적서가 가리키는 대상이 조용히 바뀝니다. 번호는 늘어나기만 하고 줄어들지 않는다고 생각하면 됩니다.

둘째, 요구사항이 취소되면 줄을 삭제하지 말고 상태 칸을 취소로 바꿔 남겨둡니다. 삭제해 버리면 몇 달 뒤 "그 항목이 왜 사라졌는지" 확인할 방법이 없어지고, 같은 논의를 처음부터 반복하게 됩니다.

이 두 규칙이 있어야 다음 절의 기준선 대비 추가라는 말이 성립합니다. 번호가 고정돼 있고 취소된 줄이 남아 있어야, 착수 시점 목록과 지금 목록을 나란히 놓고 무엇이 늘었는지 셀 수 있기 때문이에요. 번호를 돌려 쓰거나 줄을 지우는 문서에서는 이 비교가 불가능합니다.

요구사항 정의서가 왜 나중에 검수 기준이 되나요?

검수는 결국 합의한 문장과 만들어진 화면을 한 줄씩 대조하는 작업이에요. 이 대조가 성립하려면 요구사항 줄마다 완료 판정 기준이 적혀 있어야 합니다. "동작한다"는 판정 기준이 아니에요. "취소된 주문은 목록에서 취소 상태로 표시되고, 구매자에게 알림이 발송된다"처럼 확인할 대상을 적어야 판정이 됩니다. 이 칸이 비어 있으면 검수 회의가 "됐다"와 "안 됐다"의 대화로 흐릅니다.

완료 판정 기준을 적을 때 기준은 하나입니다. 그 문장을 읽은 제3자가 같은 결론에 도달할 수 있는가예요. 화면을 열어 무엇을 누르고 무엇이 보이면 되는지가 문장 안에 있으면 됩니다. 발주자가 이 칸을 직접 채워야 하는 이유도 여기 있어요. 무엇을 보면 만족하는지는 사업 쪽 판단이라 개발사가 대신 정할 수 없습니다.

잔금 지급 조건도 여기에 걸립니다. 계약서가 "검수 완료 후 잔금 지급"으로 돼 있다면, 검수 완료를 무엇으로 판정하는지가 계약서에 적혀 있는지 먼저 확인하세요. 요구사항 정의서 항목의 통과 여부로 지정해 두면 판정 기준이 문서에 남습니다. 그래서 요구사항 문장이 애매하면 돈이 애매해집니다. 검수 절차와 사인오프 설계는 IT 외주 개발 산출물 검수·사인오프 가이드에서, 출시 전 테스트 범위는 IT 외주 개발 QA 가이드에서 이어서 볼 수 있습니다.

발주자가 직접 쓸 수 있는 범위는 어디까지인가요?

어떤 항목을 발주자가 정하고 어떤 항목을 개발사에 맡기는지, 항목별 역할 분담 표는 기능명세서 작성법: 양식·예시와 개발사에 넘기는 기준에 정리돼 있습니다. 요구사항 정의서에서 유독 경계가 애매한 자리는 하나예요. 비기능 요구사항의 숫자입니다.

목표치를 정하는 건 사업 판단이지만, 그 숫자가 현실적인지는 기술 판단입니다. 발주자가 숫자를 먼저 박으면 두 가지가 벌어집니다. 근거 없이 높게 잡으면 견적이 부풀고, 낮게 잡으면 나중에 문제가 생겨도 계약상 근거가 없습니다. 그래서 이 칸은 발주자가 상황을 적고 개발사가 숫자를 제안하게 나누는 편이 낫습니다.

"행사 당일에는 평소보다 접속이 몰릴 것으로 본다", "회원 데이터에는 연락처와 결제 이력이 들어간다"까지가 발주자 몫이고, 거기에 맞는 구성과 목표치를 제안하는 것이 개발사 몫입니다. 제안받은 숫자는 그대로 요구사항 줄의 완료 판정 기준 칸에 옮겨 적으면 됩니다. 그러면 그 숫자는 개발사가 스스로 제시한 기준이 되고, 검수에서 다투기 어려워집니다.

요구사항 정의서를 쓸 때 자주 어긋나는 표현은 무엇인가요?

같은 내용을 적어도 문장 형태에 따라 개발되는 결과가 달라집니다. 요구사항 목록에서 반복적으로 눈에 띄는 유형은 이런 것들이에요. 범위를 무한히 열어두는 접미사, 주어가 빠진 문장, 한 줄에 요구가 여러 개 들어간 문장, 전제 조건이 빠져 순서가 꼬이는 문장, 측정 조건이 없는 비기능 숫자, 그리고 출처가 없어 나중에 취소 판단을 못 하는 요구입니다. 특히 "등", "기타", "필요시", "포함하여"는 뒤에 무엇이 오는지 정해지지 않은 상태로 계약에 들어갑니다.

아래 표는 그 유형을 어떻게 고쳐 쓰는지 정리한 것입니다. 고친 문장의 공통점은 누가, 언제, 무엇을 하면, 무엇이 보이는가가 한 줄에 다 들어 있다는 점입니다.

개발사에서 받은 요구사항 정의서는 무엇을 확인하나요?

개발사가 초안을 써 오는 경우, 발주자가 할 일은 새로 쓰는 게 아니라 빠진 것을 찾는 일입니다. 처음부터 끝까지 읽되, 다음 순서로 훑으면 놓치는 것이 줄어듭니다.

1. 사용자 유형이 전부 있는지 봅니다. 일반 사용자만 있고 관리자와 운영자가 없는 문서가 자주 나옵니다.
2. 각 요구사항에 우선순위와 완료 판정 기준 칸이 채워져 있는지 봅니다. 빈 칸은 그대로 분쟁 예약입니다.
3. 비기능 절이 따로 있는지 봅니다. 기능 항목에 비해 비기능이 몇 줄뿐이면 뒤에서 비용이 붙을 수 있습니다.
4. 우리가 구두로 말한 요구가 문장으로 들어갔는지 대조합니다. 미팅 메모와 문서를 나란히 놓고 봅니다.
5. 제외 항목이 명시돼 있는지 봅니다. 하지 않는 것을 적지 않은 문서는 나중에 양쪽 해석이 갈립니다.
6. 요구사항 번호와 견적서 항목이 연결되는지 확인합니다. 연결되지 않으면 무엇에 얼마를 내는지 알 수 없습니다.

여섯 번째 항목이 특히 중요합니다. 요구사항 목록과 견적서를 행 단위로 나란히 놓고 보면, 견적서에만 있는 항목과 요구사항에만 있는 항목이 드러납니다. 둘 다 위험 신호예요. 견적서를 읽는 기준은 IT 외주 개발 견적서 분석 가이드에 항목별로 정리돼 있습니다.

요구사항이 바뀌면 문서는 어떻게 관리하나요?

요구사항은 프로젝트 중에 바뀝니다. 바뀌는 것 자체는 문제가 아니고, 바뀐 기록이 남지 않는 것이 문제예요. 그래서 계약과 견적의 근거가 된 버전을 따로 표시해 둡니다. 흔히 기준선이라고 부르는데, 이 버전이 있어야 "무엇 대비 추가인가"를 말할 수 있습니다. 기준선 없이 최신 파일만 굴리면, 추가 요구가 원래 있던 것처럼 섞여 들어가고 개발사도 발주자도 근거를 잃습니다.

기준선은 요구사항 정의서 쪽에서 잡습니다. 계약서가 범위의 근거로 참조하는 문서가 이쪽이라서, 기능명세서나 화면설계서가 여러 번 개정되더라도 "무엇을 만들기로 했는가"의 기준점은 이 목록 한 벌이에요. 방법은 단순합니다. 착수 시점 파일을 별도 이름으로 저장해 양쪽이 같은 사본을 갖고, 이후 변경은 원본을 덧칠하지 말고 문서 머리의 개정 이력에 한 줄씩 쌓습니다.

개정 이력 표는 칸 구성이 전부입니다. 아래 여섯 칸이면 나중에 되짚을 수 있습니다.

변경이 견적이나 일정에 영향을 주는 순간에는 문서 수정만으로 끝내지 말고 변경 요청서(CR) 작성 가이드의 절차를 함께 밟습니다. 요구사항 문서는 현재 무엇을 만들기로 했는지를 보여주고, 변경 요청서는 왜 그렇게 바뀌었고 대가가 무엇인지를 보여줍니다. 둘은 역할이 달라서 한쪽으로 대체되지 않습니다.

AI 기능이 들어간 요구사항은 어떻게 적나요?

챗봇이나 문서 요약처럼 AI가 답을 만들어내는 기능은 같은 입력에도 결과가 달라질 수 있습니다. 그래서 요구사항 목록에서 손봐야 하는 칸은 하나예요. 완료 판정 기준입니다. "질문에 정확하게 답변한다"는 판정할 수 없으니, 그 자리에 답의 정확성 대신 동작의 경계를 적습니다. 어떤 범위의 질문에 답하고 어떤 범위를 거절하는지, 답을 만들지 못했을 때 화면에 무엇이 보이는지처럼 참과 거짓으로 확인되는 문장이면 됩니다.

이 판정 기준을 무엇으로 잡을지, 그리고 AI 기능이 견적과 계약에서 어떻게 다뤄지는지는 IT 외주 개발 AI·LLM 기능 발주 완전 가이드에 발주 체크리스트로 정리돼 있습니다. 챗봇처럼 AI 자체가 제품의 중심인 경우에는 요구사항 문서의 성격 자체가 달라지는데, 그 경우의 발주 기준은 AI 챗봇·대화형 AI 개발 업체 추천에서 다룹니다.

요구사항 목록 초안을 미팅 전에 어디까지 채워 가면 되나요?

완성된 요구사항 정의서를 혼자 만들 필요는 없습니다. 다음 미팅에서 개발사와 함께 채울 뼈대 한 장이면 충분해요. 뼈대가 있으면 미팅이 "무엇을 만들까요"에서 "이 줄이 맞습니까"로 바뀝니다.

1. 사용자 유형 목록. 서비스에 등장하는 역할을 전부 적습니다.
2. 유형별로 할 수 있어야 하는 행동을 "~는 ~할 수 있다" 문장으로 적습니다.
3. 각 줄에 Must / Should / Could / Won't 중 하나를 붙입니다.
4. 이번 범위에서 하지 않기로 한 것을 제외 항목으로 따로 적습니다.
5. 비기능 여덟 가지 항목을 훑고 해당되는 것만 한 줄씩 적습니다.
6. 각 Must 항목 옆에 "무엇을 보면 됐다고 할지"를 한 문장으로 적습니다.

여섯 줄짜리 준비물이지만, 이걸 들고 가면 견적 논의의 성격이 달라집니다. 총액 하나를 받아 드는 대신 줄 단위로 가격이 붙은 목록을 받게 되고, 예산이 맞지 않을 때 무엇을 뺄지 스스로 고를 수 있게 됩니다. 요구사항 정의서를 쓰는 진짜 이유는 문서를 갖추기 위해서가 아니라, 프로젝트에서 판단할 권한을 발주자 쪽에 남겨두기 위해서입니다.

자주 묻는 질문

요구사항 정의서와 기능명세서는 무엇이 다른가요?

요구사항 정의서는 서비스가 무엇을 해야 하는지를 문장 단위로 적은 문서이고, 기능명세서는 그 기능이 어떤 입력과 조건에서 어떻게 동작하는지를 규칙으로 적은 문서예요. 요구사항 정의서는 견적과 계약 이전에 확정하고, 기능명세서는 계약 직후 착수 단계에서 만듭니다. 가르는 기준은 그 문장을 지웠을 때 사업상의 요구가 사라지는가, 동작 규칙이 사라지는가입니다.

요구사항 정의서 양식에는 어떤 항목이 반드시 들어가야 하나요?

요구사항 ID, 요구사항 문장, 기능과 비기능 구분, 사용자 유형, 우선순위, 전제 조건, 완료 판정 기준, 관련 화면, 출처, 상태 칸이 한 줄에 들어가야 합니다. 이 가운데 우선순위와 완료 판정 기준이 빠진 양식이 자주 돌아다니는데, 두 칸이 없으면 예산이 줄었을 때 뺄 항목을 고를 수 없고 검수에서도 판정이 안 됩니다. 양식 파일 자체는 어디서 받아도 모양이 비슷하니, 파일을 구하는 것보다 이 칸들이 있는지를 보세요.

요구사항을 "~할 수 있다" 형식으로 쓰는 이유는 무엇인가요?

개발이 끝난 뒤 참과 거짓을 판정하기 위해서예요. "회원 정보를 관리한다"는 됐는지 안 됐는지 확인할 수 없지만, "관리자는 회원의 이메일을 수정할 수 있다"는 화면에서 해보면 바로 판정됩니다. 문장은 주어와 조건과 행동을 갖추고, 한 문장에 요구를 하나만 담습니다.

기능 요구사항과 비기능 요구사항은 어떤 기준으로 구분하나요?

기능 요구사항은 사용자가 할 수 있게 되는 행동이고, 비기능 요구사항은 그 행동이 어떤 조건에서 이뤄져야 하는지입니다. 문장을 지웠을 때 사라지는 것이 행동이면 기능, 그 행동의 품질이면 비기능이에요. 응답 속도, 동시 사용자, 보안과 인증, 지원 환경, 개인정보와 법규, 백업과 복구, 로그와 통계, 다국어와 통화가 대표적인 비기능 항목입니다.

요구사항 우선순위 Must, Should, Could는 어떻게 표기하나요?

Must는 없으면 출시 자체가 불가능한 항목, Should는 중요하지만 출시를 막지 않는 항목, Could는 여유 공수가 남을 때만 착수하는 항목이에요. 이번 범위에서 하지 않기로 합의한 항목은 Won't로 적되 줄을 지우지 않고 제외 항목 목록에 함께 표기합니다. 모든 항목에 Must를 붙이면 우선순위가 없는 것과 같아서, Must의 개수를 먼저 정해놓고 그 안에 들어갈 항목을 고르는 방식이 편합니다.

요구사항 정의서는 개발이 끝난 뒤 검수에 어떻게 쓰이나요?

검수는 합의한 요구사항 문장과 만들어진 화면을 한 줄씩 대조하는 작업이라, 각 줄에 완료 판정 기준이 적혀 있어야 합니다. "동작한다"는 판정 기준이 될 수 없고, "취소된 주문은 목록에서 취소 상태로 표시되고 구매자에게 알림이 발송된다"처럼 확인할 대상을 적어야 판정이 됩니다. 계약서가 "검수 완료 후 잔금 지급"으로 돼 있다면, 검수 완료를 무엇으로 판정하는지가 계약서에 적혀 있는지 먼저 확인하세요. 요구사항 정의서 항목의 통과 여부로 지정해 두면 판정 기준이 문서에 남습니다.

함께 읽으면 좋은 글

• 기능명세서 양식과 한 행에 넣을 항목
• 화면설계서와 와이어프레임의 차이
• 서비스 기획서에 미리 정해둘 항목