요구사항 정의서 작성법, 처음 맡았다면 이렇게
요구사항 정의서 작성법, 처음 맡았다면 이렇게
IT 프로젝트에서 요구사항 정의서를 처음 작성하라는 요청을 받으면 어디서부터 시작해야 할지 막막합니다. 양식을 열어도 무엇을 어느 수준까지 작성해야 하는지 판단하기 어렵기 때문입니다.
특히 고객이 원하는 기능을 그대로 옮겨 적는 것과 개발자가 구현할 수 있는 요구사항으로 정리하는 것은 서로 다른 작업입니다.
제가 요구사항 문서를 검토할 때 중요하게 보는 기준은 개발자와 테스트 담당자가 같은 의미로 이해할 수 있는가입니다. 항목이 많고 표가 깔끔해도 해석이 달라진다면 추가 확인이 필요합니다.
이번 글에서는 요구사항 정의서의 기본 개념부터 작성 순서, 쇼핑몰 회원가입 기능을 활용한 예시, 검토 체크리스트까지 정리하겠습니다.
1. 요구사항 정의서란?
요구사항 정의서는 시스템이나 서비스가 충족해야 할 조건과 기능을 이해관계자가 확인할 수 있도록 정리한 문서입니다.
단순히 고객이 요청한 내용을 기록하는 문서가 아닙니다. 무엇을 구현해야 하고, 어떤 조건을 만족해야 하며, 완료 여부를 어떻게 판단할지 정리하는 기준 문서입니다.
왜 요구사항 정의서가 필요할까요?
예를 들어 쇼핑몰 담당자가 다음과 같이 요청했다고 가정하겠습니다.
이 문장만으로는 개발을 시작하기 어렵습니다. 이메일 가입인지, 소셜 로그인인지, 어떤 정보를 입력받아야 하는지 알 수 없기 때문입니다.
기획자는 추가 질문을 통해 기능의 범위와 조건을 구체화해야 합니다.
- 이메일로 가입할 수 있어야 하나요?
- 휴대전화 인증이 필요한가요?
- 필수 입력 항목은 무엇인가요?
- 중복 가입을 어떻게 판단하나요?
- 가입 완료 후 어떤 화면으로 이동하나요?
이 질문에 대한 답변을 정리하면 구현 가능한 요구사항으로 발전시킬 수 있습니다.
요구사항 정의서와 기능 명세서의 차이
| 구분 | 요구사항 정의서 | 기능 명세서 |
|---|---|---|
| 목적 | 무엇이 필요한지 정의 | 기능이 어떻게 동작할지 구체화 |
| 중심 내용 | 업무 목적, 조건, 요구사항 | 동작 규칙, 입력값, 처리 결과 |
| 예시 | 이메일 중복 가입 방지 | 중복 확인 시 처리 결과와 오류 표시 |
다만 프로젝트에 따라 두 문서를 통합하거나 작성 범위를 다르게 정할 수 있습니다. 문서 이름보다 중요한 것은 내용의 중복과 누락을 방지하는 것입니다.
2. 요구사항 정의서의 필수 작성 항목
요구사항 정의서 양식은 회사와 프로젝트마다 다릅니다. 그러나 최소한 요구사항을 식별하고, 내용을 이해하고, 검토할 수 있는 정보는 포함하는 것이 좋습니다.
| 항목 | 설명 |
|---|---|
| 요구사항 ID | 각 요구사항을 구분하는 고유 번호 |
| 요구사항명 | 요구사항을 간결하게 표현한 이름 |
| 분류 | 기능, 비기능, 정책 등 |
| 상세 내용 | 시스템이 충족해야 하는 조건 |
| 우선순위 | 구현 중요도 및 일정 협의 기준 |
| 요구 출처 | 요청 부서, 담당자 또는 근거 문서 |
| 검수 기준 | 완료 여부를 확인하는 조건 |
| 상태 | 검토 중, 승인, 보류 등의 진행 상태 |
기능 요구사항과 비기능 요구사항
기능 요구사항은 시스템이 수행해야 하는 동작을 정의합니다.
사용자는 이메일과 비밀번호를 입력하여 회원가입을 신청할 수 있어야 합니다.
비기능 요구사항은 성능, 보안, 접근성, 가용성처럼 시스템이 만족해야 하는 품질이나 제약 조건을 정의합니다.
시스템은 승인된 보안 정책에 따라 사용자 비밀번호를 안전하게 저장해야 합니다.
두 유형을 구분하면 기능 구현 외에 놓치기 쉬운 품질 조건도 함께 관리할 수 있습니다.
3. 요구사항 정의서 작성 순서 5단계
1단계. 이해관계자 요구사항 수집
고객 인터뷰, 회의록, 기존 업무 문서, 운영 중인 시스템 등을 통해 요구사항을 수집합니다.
이 단계에서는 바로 해결 방법을 확정하기보다 요청 배경과 해결하려는 문제를 확인합니다.
2단계. 요구사항 분류 및 중복 제거
수집한 내용을 기능, 비기능, 운영 정책 등으로 구분합니다. 비슷한 요청은 병합하고, 서로 충돌하는 내용은 별도로 표시합니다.
예를 들어 회원가입, 회원정보 수정, 비밀번호 변경은 회원 관리 영역으로 묶을 수 있습니다.
3단계. 요구사항 상세화
요청 내용을 시스템의 동작과 조건으로 구체화합니다.
회원가입을 편리하게 한다.
수정 후사용자는 이메일과 비밀번호를 입력하여 회원가입을 신청할 수 있어야 합니다.
이때 가입 절차, 필수 동의 항목, 인증 정책처럼 추가 결정이 필요한 내용은 미확정 사항으로 분리해 관리합니다.
4단계. 우선순위와 검수 기준 정리
모든 요구사항을 동일한 중요도로 처리할 수는 없습니다. 서비스 출시 범위와 업무 중요도 등을 기준으로 우선순위를 결정합니다.
또한 요구사항마다 테스트 가능한 검수 기준을 작성합니다.
이메일 중복 가입을 방지해야 합니다.
검수 기준이미 가입된 이메일로 신규 회원가입을 시도하면 가입을 완료하지 않고 중복 안내 메시지를 표시합니다.
5단계. 이해관계자 검토 및 확정
작성한 문서는 고객, 개발자, 디자이너, 테스트 담당자 등 관련 이해관계자와 검토합니다.
검토 시에는 누락된 기능, 모호한 표현, 구현 범위와 정책 충돌 여부를 확인합니다.
승인되지 않은 정책을 확정된 요구사항처럼 작성하지 않는 것이 중요합니다. 미결정 항목은 담당자와 결정 기한을 함께 관리하는 편이 좋습니다.
4. 실무 예시: 쇼핑몰 회원가입 요구사항 정의서
이번에는 가상의 쇼핑몰 프로젝트를 기준으로
요구사항 정의서를 작성해 보겠습니다.
예시 프로젝트의 범위는 다음과 같습니다.
- 서비스: 온라인 쇼핑몰
- 대상 기능: 이메일 회원가입
- 사용자: 신규 회원
- 목표: 회원가입 신청 및 완료 처리
요구사항 정의서 샘플
아래 표는 실습을 위해 작성한 예시이며, 실제 프로젝트에서는 인증 및 개인정보 처리 정책 등을 추가로 확정해야 합니다.
| ID | 요구사항명 | 상세 내용 | 우선순위 | 검수 기준 |
|---|---|---|---|---|
| REQ-001 | 이메일 가입 | 사용자는 이메일과 비밀번호를 입력하여 회원가입을 신청할 수 있어야 합니다. | 높음 | 유효한 입력값과 필수 동의 조건을 충족하면 가입을 신청할 수 있습니다. |
| REQ-002 | 이메일 중복 확인 | 이미 등록된 이메일을 사용한 신규 가입을 방지해야 합니다. | 높음 | 기존 이메일로 가입을 시도하면 가입이 완료되지 않고 안내 메시지가 표시됩니다. |
| REQ-003 | 비밀번호 검증 | 비밀번호는 승인된 비밀번호 정책을 만족해야 합니다. | 높음 | 정책에 맞지 않는 값을 입력하면 가입 진행을 차단하고 오류를 표시합니다. |
| REQ-004 | 가입 완료 안내 | 회원가입 성공 시 완료 안내를 표시해야 합니다. | 중간 | 가입 성공 처리 후 지정된 완료 화면을 표시합니다. |
표의 우선순위와 처리 방식은 가상 프로젝트의 예시이며 실제 정책을 의미하지 않습니다.
REQ-002를 상세 요구사항으로 확장하기
위 표를 바탕으로 하나의 요구사항을 더 구체적으로 작성해 보겠습니다.
| 요구사항 ID | REQ-002 |
|---|---|
| 요구사항명 | 이메일 중복 가입 방지 |
| 분류 | 기능 요구사항 |
| 상세 내용 | 시스템은 기존 회원 계정에 사용된 이메일로 신규 가입이 완료되지 않도록 처리해야 합니다. |
| 우선순위 | 높음 |
| 검수 기준 | 기존 이메일로 회원가입을 시도하면 가입을 완료하지 않고 안내 메시지를 표시합니다. |
| 확인 필요 | 탈퇴 계정의 이메일 재사용 정책, 이메일 대소문자 처리, 개인정보 노출 방지 문구 |
| 상태 | 검토 중 |
여기서 중요한 것은 단순히 중복 여부를 확인하는 기능만 기술하지 않았다는 점입니다.
탈퇴한 회원의 이메일을 재사용할 수 있는지, 오류 메시지는 어떻게 안내할지 등 추가로 결정해야 할 정책도 드러납니다.
이메일 가입 여부를 안내하는 문구는 계정 존재 여부가 불필요하게 노출되지 않도록 보안 및 개인정보 처리 정책과 함께 검토해야 합니다.
5. 요구사항 정의서 작성 완료 체크리스트
문서를 작성한 후에는 다음 항목을 확인해 보세요.
- □ 요구사항마다 고유 ID가 있는가?
- □ 요구사항의 목적과 범위가 명확한가?
- □ 이해관계자 간 해석이 달라질 표현이 없는가?
- □ 구현 여부를 테스트할 수 있는가?
- □ 필수 정책과 예외 조건을 확인했는가?
- □ 우선순위가 합의되었는가?
- □ 미결정 사항과 담당자가 표시되어 있는가?
- □ 변경 이력을 관리할 수 있는가?
체크리스트에서 확인되지 않은 항목은 반드시 잘못 작성되었다는 의미는 아닙니다. 추가 협의가 필요한 부분을 발견했다는 의미로 활용하면 됩니다.
6. 실무 팁: 요구사항 정의서 품질을 높이는 3가지 방법
팁 1. 하나의 요구사항에는 검증 가능한 내용을 담습니다.
서로 다른 검증 조건은 가능한 한 분리해서 관리하세요.
예를 들어 회원가입과 비밀번호 찾기를 하나의 요구사항으로 묶으면 개발과 테스트 진행 상태를 구분하기 어려워집니다.
기능이나 검증 조건이 독립적이라면 요구사항도 분리하는 편이 좋습니다.
팁 2. 모호한 표현을 구체적인 조건으로 바꿉니다.
빠르게, 쉽게, 안전하게 같은 표현에는 판단 기준이 필요합니다.
"빠르게 조회되어야 한다"라고 작성했다면 측정 대상, 데이터 규모, 응답 시간 목표 등을 별도로 정의해야 합니다.
이러한 기준이 없으면 구현 후 완료 여부를 판단하기 어렵습니다.
팁 3. 요구사항 ID로 설계와 테스트를 연결합니다.
요구사항과 후속 산출물 사이의 연결 관계를 유지하세요.
REQ-002가 회원가입 화면의 특정 입력 동작과 테스트 케이스에 연결되도록 관리하면 변경 사항의 영향을 추적하기 쉽습니다.
다만 모든 연결 관계를 수작업으로 유지하면 관리 부담이 커질 수 있습니다. 프로젝트 규모에 따라 엑셀이나 이슈 관리 도구를 선택하는 것이 좋습니다.
7. 자주 묻는 질문(FAQ)
Q1. 요구사항 정의서와 기능 명세서는 어떻게 다른가요?
요구사항 정의서는 시스템이 충족해야 할 업무 요구와 조건을 정리합니다. 기능 명세서는 기능의 상세 동작을 구체화하는 데 초점을 둡니다. 다만 실제 프로젝트에서는 두 문서의 역할을 통합하기도 합니다.
Q2. 요구사항 정의서는 반드시 엑셀로 작성해야 하나요?
반드시 엑셀일 필요는 없습니다. 스프레드시트, 노션, Jira, 요구사항 관리 도구 등을 사용할 수 있습니다. 중요한 것은 요구사항 ID, 상태, 변경 이력, 검토 결과를 일관되게 관리하는 것입니다.
Q3. 요구사항이 변경되면 어떻게 관리하나요?
변경 사유와 요청자, 영향 범위를 기록하고 관련 이해관계자의 검토를 거쳐 변경 내용을 반영하는 것이 좋습니다. 필요하다면 기존 요구사항과 테스트 항목의 연결 관계도 함께 업데이트합니다.
8. 마무리: 좋은 요구사항 정의서는 무엇이 다를까?
요구사항 정의서는 분량보다 명확성과 검증 가능성이 중요합니다.
- 요구사항은 개발자가 구현할 수 있도록 구체적으로 작성합니다.
- 검수 기준과 미결정 정책을 함께 관리합니다.
- 요구사항 ID를 활용해 설계와 테스트를 연결합니다.
처음부터 완벽한 문서를 만들려고 하기보다 작은 기능 하나를 선정하여 요구사항을 작성하고 검토하는 연습부터 시작해 보세요.
이번 글에서 사용한 쇼핑몰 회원가입 기능을 기준으로 요구사항 ID와 검수 기준을 직접 작성해 보는 것도 좋은 방법입니다.