문서는 여기서 먼저 갈리기 시작합니다
요구사항 정의서 작성법을 찾는 분들은 보통 문서 양식부터 열어봅니다. 그런데 처음 막히는 지점은 양식이 아니라 어디까지 써야 하는지 쪽인 경우가 많아요.
기능명을 많이 적는다고 문서가 좋아지진 않습니다. 요구사항 정의서는 팀이 같은 장면을 떠올리게 만드는 약속에 가까워요. 사용자가 왜 이 기능을 필요로 하는지, 어디까지 만들지, 끝났다고 보는 기준은 뭔지를 먼저 맞춰야 합니다.
처음이라면 이렇게 보면 편합니다. 요구사항은 무엇을 만들지보다 어떤 문제가 사라져야 하는지에서 시작해요. 이 순서를 놓치면 회의에서는 괜찮아 보여도 개발, 디자인, QA 단계에서 말이 계속 바뀝니다.
잠깐 정리하면, 요구사항 정의서 작성법의 첫 기준은 이겁니다.
- 사용자가 겪는 문제를 한 문장으로 적기
- 이번 범위에 넣을 것과 뺄 것을 나누기
- 기능이 끝났다고 볼 기준을 쓰기
- 예외 상황을 짧게라도 남기기
- 다음 문서로 넘길 내용을 구분하기
요구사항을 기능으로 더 잘게 나누는 단계가 필요하면 기능정의서 작성방법을 이어서 보면 흐름이 훨씬 덜 꼬입니다. 요구사항과 기능정의서를 한 문서에 다 넣으려 하면 문서가 금방 무거워지거든요.
문제와 범위는 여기서 먼저 자릅니다
요구사항 정의서 작성법에서 가장 먼저 볼 건 문제 정의입니다. “로그인 기능 개선”처럼 쓰면 넓습니다. “휴면 계정 사용자가 다시 로그인할 때 안내가 부족하다”처럼 쓰면 훨씬 선명해집니다.
문제가 선명해지면 범위도 잘립니다. 이번에 할 일, 다음에 할 일, 아예 안 할 일이 보이기 시작해요. 여기서 범위를 자르지 않으면 요구사항이 회의할 때마다 자랍니다.
처음 문서에는 아래 3가지를 먼저 적어두면 편합니다.
| 구분 | 적을 내용 | 조심할 점 |
|---|---|---|
| 문제 | 사용자가 막히는 상황 | 기능명으로만 쓰지 않기 |
| 범위 | 이번 배포에 넣을 것 | 욕심내서 다 넣지 않기 |
| 제외 | 이번엔 안 할 것 | 나중에 말 바뀌지 않게 남기기 |
요구사항 정의서 작성법을 어렵게 만드는 건 문서 분량이 아닙니다. 짧아도 범위가 흐리면 위험해요. 반대로 길어도 판단 기준이 있으면 팀원이 읽고 움직일 수 있어요.
사용자 흐름은 화면보다 먼저 씁니다
화면부터 그리면 빨라 보입니다. 버튼, 입력창, 목록을 그려두면 뭔가 만들어지는 느낌도 나고요. 근데 요구사항이 흐린 상태에서 화면을 먼저 잡으면 나중에 고칠 게 많아져요.
요구사항 정의서 작성법에서는 화면보다 사용자 흐름을 먼저 봅니다. 사용자가 어디서 들어오고, 무엇을 선택하고, 어떤 결과를 기대하는지부터 적어야 합니다.
예를 들어 “비밀번호 재설정”이라면 이런 식입니다.
- 로그인 화면에서 비밀번호 찾기 선택
- 가입한 이메일이나 휴대폰 입력
- 인증 통과 후 새 비밀번호 생성
- 실패 시 보여줄 안내 정리
- 일정 횟수 이상 실패할 때 제한 조건 확인
이 흐름이 잡히면 화면은 자연스럽게 따라옵니다. 구글 스프레드시트 WBS로 일정까지 이어갈 때도 이 흐름이 먼저 있어야 작업을 작게 나눌 수 있어요.
요구사항 정의서 작성법은 완료 기준을 먼저 봅니다
초보자가 자주 빼먹는 게 완료 기준입니다. “알림을 보낸다”라고만 쓰면 부족해요. 언제, 누구에게, 어떤 조건에서, 실패하면 어떻게 할지까지 있어야 합니다.
완료 기준은 개발자만을 위한 문장이 아닙니다. 디자이너는 화면 상태를 보고, QA는 테스트 기준을 잡고, 운영자는 고객 문의에 답할 준비를 하거든요. 그래서 “끝났다”의 의미를 문서에서 맞춰야 합니다.
처음에는 거창하게 쓰지 않아도 됩니다.
- 성공했을 때 사용자가 보는 결과
- 실패했을 때 보여줄 안내
- 저장되거나 바뀌는 데이터
- 권한이 없을 때 막는 방식
- QA에서 확인할 최소 조건
요구사항 정의서 작성법을 실무에서 쓰려면 이 기준이 꼭 필요합니다. 여기서 빠진 조건은 대부분 QA나 배포 직전에 다시 돌아와요. 그때 고치면 비용이 더 커집니다.
예외 상황을 놓치면 여기서 다시 돌아옵니다
처음 문서를 쓸 때 예외 상황까지 다 적으려면 숨이 막힙니다. 그래도 아예 비워두면 더 위험해요. 사용자는 늘 우리가 생각한 대로 움직이지 않거든요.
요구사항 정의서 작성법에서 예외는 “모든 경우의 수”가 아니라 “팀이 헷갈릴 만한 순간”부터 적으면 됩니다. 로그인이 풀렸을 때, 권한이 없을 때, 중복 요청이 들어왔을 때, 저장에 실패했을 때 같은 장면입니다.
예외를 따로 길게 쓰기 어렵다면 요구사항 아래에 한 줄만 붙여도 됩니다.
- 실패하면 기존 입력값 유지
- 권한이 없으면 목록 진입 차단
- 중복 신청은 기존 신청 내역으로 안내
- 서버 오류는 다시 시도 안내로 처리
이 정도만 있어도 대화가 줄어듭니다. 이후 검수 단계로 넘어가면 서비스 기획자 QA 체크리스트처럼 실제 확인 항목으로 바꿔보면 좋아요.
처음 쓰는 사람은 이 순서부터 보면 덜 흔들립니다
요구사항 정의서 작성법은 양식을 잘 꾸미는 일이 아닙니다. 처음에는 문서가 조금 투박해도 괜찮아요. 대신 읽는 사람이 그래서 뭘 만들고, 어디까지 하고, 무엇을 확인하면 되는지를 바로 알 수 있어야 합니다.
실무에서는 이 순서가 편합니다.
- 사용자 문제를 한 문장으로 적습니다.
- 이번 범위와 제외 범위를 나눕니다.
- 사용자 흐름을 먼저 적습니다.
- 성공과 실패 기준을 붙입니다.
- 예외 상황을 짧게 남깁니다.
- 기능정의서, WBS, QA 문서로 넘길 내용을 분리합니다.
요구사항 정의서 작성법을 처음부터 완벽하게 잡으려 하면 오히려 손이 멈춥니다. 문서를 한 번에 끝내려 하지 말고, 회의에서 바뀐 조건을 반영하면서 좁혀가는 쪽이 현실적입니다.
자주 나오는 질문, 여기서 많이 갈립니다
양식보다 먼저 볼 기준
양식은 있으면 좋지만, 양식이 핵심은 아닙니다. 같은 회사 안에서도 서비스 성격에 따라 필요한 항목이 달라질 수 있어요. 신규 기능인지, 운영 개선인지, 관리자 화면인지에 따라 문제 정의와 완료 기준이 다르게 잡힙니다.
처음에는 문제, 범위, 사용자 흐름, 완료 기준, 예외 상황만 있어도 됩니다. 나중에 팀에서 자주 묻는 질문이 생기면 그 항목을 양식에 추가하면 됩니다. 양식을 먼저 완성하려고 하면 실제 프로젝트와 맞지 않는 칸만 늘어날 수 있어요.
요구사항정의서와 기능정의서 나누는 기준
요구사항정의서는 왜 필요한지와 어디까지 할지에 가깝습니다. 기능정의서는 그 요구를 화면과 동작으로 어떻게 만들지에 더 가깝고요. 둘이 붙어 있지만 역할은 다릅니다.
예를 들어 요구사항에는 “사용자가 비밀번호를 잊어도 계정을 복구할 수 있어야 한다”라고 적을 수 있습니다. 기능정의서에는 입력값, 인증 방식, 실패 메시지, 제한 조건처럼 더 구체적인 동작이 들어갑니다.
신입 기획자가 제일 조심할 부분
가장 조심할 건 기능명만 적고 끝내는 겁니다. “알림 기능”, “검색 기능”, “관리자 기능”처럼 쓰면 읽는 사람마다 다르게 이해해요. 이러면 회의가 끝나도 결정된 게 별로 없습니다.
기능명 옆에는 사용 상황과 완료 기준을 붙이는 게 좋습니다. 누가, 어떤 조건에서, 어떤 결과를 봐야 하는지만 적어도 문서가 훨씬 실무적으로 바뀝니다. 처음에는 예쁘게 쓰는 것보다 오해를 줄이는 쪽이 더 중요합니다.
오늘 바로 고칠 부분
요구사항 정의서 작성법은 결국 팀이 같은 말을 하게 만드는 작업입니다. 문서를 잘 쓰는 사람처럼 보이려고 어려운 단어를 넣을 필요는 없습니다. 오히려 쉬운 말로 범위를 자르고, 끝난 기준을 남기는 게 더 도움이 됩니다.
이미 작성한 문서가 있다면 기능명만 적힌 줄을 먼저 보세요. 그 옆에 사용자 문제, 완료 기준, 예외 상황을 한 줄씩 붙이면 문서가 바로 달라집니다. 댓글이나 메모로 막힌 문장을 남겨두면 다음 리프레시 때 실제 예시로 더 쉽게 풀어보겠습니다.
