요구사항 정의서 작성법: 모호한 요청을 개발 가능한 문장으로 바꾸는 실무 예시

요구사항 정의서 작성법의 핵심은 “필요한 기능”을 많이 적는 게 아니라 누가, 어떤 조건에서, 무엇을 하면, 시스템이 어떻게 반응하고, 무엇으로 완료를 확인할지 한 문장에 담는 것이다. 초보 PM이라면 요구사항 ID, 유형, 설명, 우선순위, 수용 기준, 출처와 상태를 기본 열로 두고 기능·비기능·예외 조건을 함께 관리하면 된다. “빠르게”, “편리하게”, “적절히” 같은 말부터 검증 가능한 숫자와 행동으로 바꿔 보자!

요구사항 정의서란 무엇인가?

요구사항 정의서는 이해관계자의 필요를 설계·개발·테스트가 같은 뜻으로 읽을 수 있는 요구사항 목록으로 정리한 문서다. 단순한 아이디어 메모와 달리 각 요구사항에 식별자와 수용 기준을 붙여 변경과 검증까지 추적한다.

ISO/IEC/IEEE 29148:2018은 요구사항 공학을 시스템과 소프트웨어 생애주기 전반의 프로세스로 다루며, 잘 구성된 텍스트 요구사항과 요구사항의 추적·검증·확인을 설명한다. 여기서 검증은 요구사항이 잘 작성됐는지를, 확인은 이해관계자가 의도한 올바른 시스템을 정의했는지를 살피는 개념이다.

요구사항 정의서와 기능명세서는 어떻게 다를까?

두 문서는 프로젝트마다 이름과 범위가 조금씩 다르다. 실무에서는 다음처럼 역할을 나누면 덜 헷갈린다.

문서	주로 답하는 질문	상세 수준
요구사항 정의서	왜 필요하고 무엇을 충족해야 하는가?	사용자·업무 관점의 조건과 완료 기준
기능명세서	화면과 시스템이 구체적으로 어떻게 동작하는가?	입력값, 처리 규칙, UI 동작, 오류 문구
화면정의서	화면에 무엇이 보이고 어떻게 이동하는가?	화면 ID, 구성 요소, 이벤트, 화면 전환
테스트 시나리오	구현 결과가 요구를 충족했는가?	사전 조건, 절차, 기대 결과, 판정

작은 팀에서는 한 문서로 합쳐도 괜찮다. 다만 “왜 필요한가”와 “어떻게 동작하는가”, “어떻게 통과를 판단하는가”가 한 셀에 뒤섞이지 않게 구분하자.

기능 요구사항·비기능 요구사항·제약사항 구분

IBM의 요구사항 관리 안내는 요구사항을 비즈니스, 사용자·이해관계자, 시스템 관점으로 나누고 기능·비기능·도메인 요구사항으로도 분류한다. 초보 PM은 우선 아래 세 갈래로 시작하면 실무 누락을 줄이기 쉽다.

기능 요구사항

사용자나 시스템이 무엇을 할 수 있어야 하는지 적는다.

• 회원은 이메일과 비밀번호로 로그인할 수 있다.
• 관리자는 예약 상태를 승인·취소로 변경할 수 있다.
• 결제가 완료되면 주문번호가 포함된 알림을 발송한다.

비기능 요구사항

기능이 어느 수준으로 동작해야 하는지 적는다. 성능, 보안, 가용성, 접근성, 호환성, 사용성 등이 여기에 들어간다.

• 로그인 요청의 95%는 정상 부하에서 2초 이내 응답한다.
• 비밀번호는 평문으로 저장하지 않는다.
• Chrome, Safari 최신 두 개 주요 버전에서 핵심 예약 흐름을 지원한다.

제약사항과 업무 규칙

반드시 지켜야 할 기술·법·정책·운영 경계를 적는다.

• 기존 사내 SSO를 인증 수단으로 사용한다.
• 예약 취소는 시작 24시간 전까지만 가능하다.
• 개인정보 보유 기간은 조직의 승인된 정책을 따른다.

“로그인 기능”만 적으면 세 갈래 중 기능 이름만 남는다. 권한, 실패 횟수, 응답 시간, 지원 환경, 개인정보 처리 같은 조건을 함께 질문해야 실제 개발 범위가 보인다.

개발 가능한 요구사항 한 줄의 구조

좋은 요구사항은 길기보다 구조가 분명하다. 아래 다섯 요소를 한 덩어리로 확인하자.

1. 주체: 누가 또는 어떤 시스템이 사용하는가?
2. 조건: 언제, 어떤 상태에서 실행되는가?
3. 행동: 사용자가 무엇을 하는가?
4. 시스템 반응: 시스템이 무엇을 처리하고 보여 주는가?
5. 수용 기준: 무엇을 관찰하면 완료라고 판정할 수 있는가?

IREB 요구사항 공학 용어집은 모호하지 않음을 서로 다른 사람이 다르게 이해할 수 없게 표현된 정도로, 검증 가능성을 구현된 시스템이 요구사항을 충족하는지 확인할 수 있는 정도로 설명한다. 결국 좋은 문장은 읽는 사람이 뜻을 추측하지 않아도 되고, 만든 뒤에는 맞는지 시험할 수 있어야 한다.

요구사항 정의서에 넣을 기본 항목 9가지

항목	작성 내용	실무 팁
요구사항 ID	FR-001, NFR-001처럼 고유한 값	문서 수정 후에도 ID는 함부로 바꾸지 않는다
유형	기능, 비기능, 제약, 데이터, 인터페이스	팀이 실제로 구분해 관리할 만큼만 나눈다
요구사항명	검색 가능한 짧은 이름	“회원 로그인 실패 제한”처럼 결과가 보이게 쓴다
상세 설명	주체·조건·행동·반응	한 항목에 여러 기능을 묶지 않는다
수용 기준	통과를 판정할 관찰 가능한 결과	정상·예외를 최소 한 개씩 적는다
우선순위	Must, Should, Could 등 합의한 체계	전부 최우선으로 두지 않는다
출처·요청자	인터뷰, 정책, VOC, 담당 부서	나중에 의도를 다시 확인할 사람을 남긴다
관련 항목	화면, API, 정책, 테스트 ID	요구→설계→테스트의 연결고리를 만든다
상태·버전	검토 중, 승인, 보류, 변경	승인자와 변경일을 함께 기록한다

Atlassian의 제품 요구사항 템플릿도 목적과 기능만 적는 데서 끝내지 않고 사용자 스토리, 중요도, 관련 이슈와 메모를 연결하도록 구성한다. 어떤 도구를 쓰든 한곳에서 최신 버전을 확인할 수 있게 만드는 것이 중요하다.

모호한 요청을 요구사항으로 바꾸는 5단계

1. 요청의 목적과 사용자를 먼저 묻는다

“관리자 검색이 필요해요”라고 들으면 바로 검색창을 그리지 말자. 누가, 어떤 업무 때문에, 무엇을 찾으려는지 확인한다.

• 사용자: 고객센터 상담원
• 상황: 고객이 전화로 주문 상태를 문의함
• 목적: 30초 안에 해당 주문과 배송 상태를 찾음

목적이 보이면 검색 대상과 우선순위가 달라진다. 주문번호만 필요한지, 고객 전화번호나 이름도 필요한지 판단할 근거가 생긴다.

2. 명사형 기능을 사용자 행동으로 바꾼다

나쁜 예

주문 검색 기능 제공

좋은 예

로그인한 상담원은 주문번호 전체를 입력해 주문 1건의 주문일, 결제 상태, 배송 상태를 조회할 수 있다.

“검색 기능”이라는 명사 대신 입력, 처리, 결과가 보이도록 쓴다. 한 요구사항에 조회·수정·다운로드를 모두 넣지 말고 각각 분리한다.

3. 업무 규칙과 예외를 붙인다

정상 흐름만 적으면 개발 중 질문이 쏟아진다.

• 존재하지 않는 주문번호면 “일치하는 주문이 없습니다”를 표시한다.
• 상담원은 자신이 속한 브랜드의 주문만 조회할 수 있다.
• 주문번호 앞뒤 공백은 제거하지만 일부 일치는 허용하지 않는다.
• 개인정보 항목은 권한에 따라 마스킹한다.

모든 예외를 처음부터 완벽히 찾을 필요는 없다. 빈번한 실패, 권한, 데이터 없음, 중복, 한도 초과부터 확인하자.

4. 수용 기준을 Given-When-Then으로 쓴다

수용 기준은 개발자에게 지시하는 문장이 아니라 팀이 결과를 함께 판정하는 약속이다.

Given 조회 권한이 있는 상담원이 로그인했고 주문 A20260923-001이 존재할 때
When 주문번호 전체를 입력하고 검색을 누르면
Then 주문일, 결제 상태, 배송 상태가 한 건 표시되고 고객 전화번호 뒤 네 자리는 마스킹된다.

예외 기준도 이어 쓴다.

Given 조회 권한이 있는 상담원이 로그인했을 때
When 존재하지 않는 주문번호를 검색하면
Then 결과 목록 대신 “일치하는 주문이 없습니다”가 표시된다.

5. 이해관계자와 테스트 가능성을 함께 검토한다

요청자에게는 “이 기능이 실제 문제를 해결하는가?”를, 개발자에게는 “구현 범위와 전제가 충분한가?”를, QA에게는 “통과 여부를 재현할 수 있는가?”를 묻는다. 세 질문 중 하나라도 답하기 어렵다면 아직 빈칸이 남은 것이다.

좋은 예와 나쁜 예 비교

모호한 문장	개발 가능한 문장
페이지가 빨리 떠야 한다	정상 부하에서 상품 상세 요청의 95%는 2초 이내 응답한다
관리자가 회원을 관리한다	관리자 권한 사용자는 이메일로 회원을 조회하고 활성·정지 상태를 변경할 수 있다
오류를 친절하게 안내한다	필수값이 비어 있으면 해당 입력란 아래에 누락된 항목명을 포함한 오류 문구를 표시한다
모바일에서도 잘 보여야 한다	360px 이상 화면에서 가로 스크롤 없이 예약 신청의 핵심 흐름을 완료할 수 있다
보안을 강화한다	로그인 실패가 5회 연속 발생하면 계정을 10분간 잠그고 사용자에게 해제 시각을 안내한다

숫자가 들어갔다고 무조건 좋은 요구사항은 아니다. 근거 없는 “0.1초 이내”는 비용만 높일 수 있다. 현재 성능, 사용자 기대, 계약 조건, 기술 검토를 바탕으로 측정값을 합의하자.

바로 복사해 쓰는 요구사항 정의서 빈칸 템플릿

# [프로젝트명] 요구사항 정의서

## 1. 문서 정보
- 목적:
- 범위:
- 작성자 / 승인자:
- 버전 / 기준일:

## 2. 사용자와 업무 배경
- 주요 사용자:
- 해결할 문제:
- 성공 기준:
- 제외 범위:

## 3. 요구사항 목록
| ID | 유형 | 요구사항명 | 상세 설명 | 우선순위 | 출처 | 상태 |
|---|---|---|---|---|---|---|
| FR-001 | 기능 |  |  | Must |  | 검토 중 |

## 4. 수용 기준
| 요구사항 ID | 사전 조건 | 실행 | 기대 결과 | 예외 결과 |
|---|---|---|---|---|
| FR-001 |  |  |  |  |

## 5. 비기능·제약사항
| ID | 구분 | 측정 조건 | 목표값·규칙 | 검증 방법 |
|---|---|---|---|---|
| NFR-001 | 성능 |  |  |  |

## 6. 추적과 변경 이력
| 변경일 | 요구사항 ID | 변경 전 | 변경 후 | 사유 | 승인자 |
|---|---|---|---|---|---|

요구사항 정의서 검토 체크리스트

• 요구사항마다 중복되지 않는 ID가 있다.
• 한 요구사항에는 하나의 핵심 행동이나 품질 조건이 담겨 있다.
• 주체, 조건, 행동, 시스템 반응이 읽힌다.
• “빠르게”, “쉽게”, “적절히”를 측정 가능한 표현으로 바꿨다.
• 기능 요구사항뿐 아니라 성능·보안·접근성·호환성도 확인했다.
• 권한, 데이터 없음, 실패, 중복 같은 예외가 있다.
• 수용 기준을 다른 담당자가 그대로 재현할 수 있다.
• 출처와 요청자가 있어 의도를 다시 확인할 수 있다.
• 요구사항과 화면·API·테스트 항목을 연결할 수 있다.
• 우선순위, 상태, 변경일, 승인자가 최신으로 유지된다.
• 서로 충돌하거나 같은 뜻을 중복한 요구사항이 없다.
• 현재 일정과 예산 안에서 실현 가능한지 기술 검토를 받았다.

요구사항 정의서 작성법 FAQ

요구사항은 누가 작성하나요?

PM이나 기획자가 초안을 관리하는 경우가 많지만 혼자 확정하면 안 된다. 현업과 사용자는 문제와 업무 규칙을, 개발자는 기술적 전제와 실현 가능성을, QA는 검증 가능성을 확인한다. 문서 담당자는 의견을 모아 한 버전으로 정리하고 승인 이력을 남기는 역할에 가깝다.

요구사항은 얼마나 자세히 써야 하나요?

설계 방법까지 미리 고정하지 않으면서도 개발과 테스트가 같은 결과를 예상할 정도가 적당하다. 사용자 가치와 시스템이 충족할 조건을 적고, 데이터 구조나 컴포넌트 같은 구현 방식은 꼭 필요한 제약이 아닐 경우 설계 단계에 맡기자.

애자일이면 요구사항 정의서가 필요 없나요?

형식은 가벼워질 수 있지만 요구 자체가 사라지지는 않는다. 백로그의 사용자 스토리와 수용 기준, 비기능 요구사항, 결정 로그를 연결해 최신 기준을 찾을 수 있다면 문서 이름이 무엇인지는 덜 중요하다. IBM도 애자일 환경의 요구사항에 사용자 스토리와 에픽이 포함될 수 있다고 설명한다.

변경된 요구사항은 원래 문장을 고치기만 하면 되나요?

최신 문장은 고치되 변경 전후와 사유, 영향, 승인자를 함께 남기자. 일정·비용·화면·API·테스트에 미치는 영향을 확인하고 연결된 항목의 상태도 갱신해야 한다. 그래야 회의 때마다 “최종본이 어느 파일이죠?”를 반복하지 않는다.

요구사항 정의서 작성법 핵심 정리

요구사항 정의서 작성법은 모호한 요청을 두껍게 포장하는 일이 아니다. 주체와 조건, 행동, 시스템 반응, 수용 기준을 연결해 모두가 같은 결과를 예상하게 만드는 일이다. 기능·비기능·제약사항을 나누고, 각 요구사항에 ID와 출처·우선순위·상태를 붙이자. 마지막으로 요청자·개발자·QA가 함께 읽어 뜻, 실현 가능성, 테스트 가능성을 확인하면 개발 중 되묻기와 재작업을 꽤 줄일 수 있다~

참고한 최신 출처

• ISO: ISO/IEC/IEEE 29148:2018 Requirements engineering
• IREB: CPRE Requirements Engineering Glossary
• IBM: What is requirements management?
• Atlassian: Product requirements template
• Atlassian: What is a product requirements document?