QA 시선으로 본 요구사항 정의서의 구조와 놓치기 쉬운 맹점
요구사항 정의서, 다들 작성해보셨죠? 프로젝트의 시작점인 이 문서가 잘못되면, 개발 과정은 물론 QA 단계에서도 혼란이 생기기 마련이에요. 제가 품질 전문가로서 현장에서 겪은 실제 사례를 토대로, 요구사항 정의서가 갖춰야 할 구조와 그 안에 숨어 있는 맹점을 풀어보려 해요. 잘 짜인 요구사항 정의서 하나가 수천만 원짜리 손실을 막기도 하니까요. 함께 한번 파헤쳐볼까요?
목차
요구사항 정의서의 일반적인 구조
요구사항 정의서는 보통 개요, 시스템 개요, 기능 요구사항, 비기능 요구사항, 인터페이스 요구사항, 제약사항 등의 항목으로 구성됩니다. 각 항목은 프로젝트의 성공을 위한 기본적인 틀을 형성하죠. 하지만 이 틀이 있다는 이유만으로 문서가 완전하다고 말하긴 어렵습니다. 구조를 갖췄다는 것은 시작일 뿐이고, 중요한 건 그 안의 ‘내용’과 ‘정확도’입니다.
QA가 보는 주요 검토 항목
품질 보증(QA)의 입장에서 요구사항 정의서를 검토할 때, 단순히 기능 유무만 보는 게 아닙니다. 각 기능이 테스트 가능하게 정의되어 있는지, 애매한 표현은 없는지, 상호 충돌하는 요구사항이 있는지를 중점적으로 살펴봅니다.
| 검토 항목 | 설명 | QA 관점 주의점 |
|---|---|---|
| 기능 정의 | 시스템이 수행해야 하는 기능 명시 | 테스트 가능성 확보 |
| 비기능 요건 | 성능, 보안, 가용성 등 | 정량적 수치 필요 |
| 용어 정의 | 전문 용어 및 약어 정리 | 해석 오류 방지 |
놓치기 쉬운 맹점들
요구사항 정의서를 보면 겉보기엔 완벽해 보이지만, 실제론 아래 같은 맹점들이 숨어있는 경우가 많아요. 이런 부분을 QA는 민감하게 짚고 넘어가야 해요.
- ‘사용자는 쉽게 로그인할 수 있어야 한다’ 같은 모호한 표현
- 조건 누락: “데이터 백업”만 있고, “백업 주기”는 없음
- 상호 모순: 페이지에서 “자동저장”과 “사용자 수동저장”이 동시에 명시됨
“Ambiguity in requirements leads to the majority of software defects.”
— *IEEE Software Engineering Journal*, 2021
이 인용이 의미하는 바는 명확해요. 요구사항의 모호함이야말로 가장 많은 버그의 근원이라는 거죠. 그러니, 애매하다는 느낌이 들면 무조건 다시 짚고 명확하게 문서화해야 해요.
초기 QA 참여의 중요성
요구사항 정의 단계에서 QA가 초기부터 참여한다는 건 단순히 ‘문서 리뷰’를 넘어서요. 테스트 시나리오 설계에 필요한 조건을 미리 파악하고, 누락 가능성이 있는 기능을 사전에 발견하는 것이 핵심이에요. 저는 예전에 QA가 설계 단계부터 참석한 프로젝트에서 실제로 20% 이상 버그 발생률이 줄어든 경험이 있었어요. 개발과 QA가 따로 노는 시대는 끝났습니다.
실제 사례로 보는 실패와 교훈
한 금융 프로젝트에서, 로그인 후 자동 로그아웃 기능이 명확히 정의되지 않았어요. 실제로 QA 단계에서야 이 문제가 드러났고, 전체 사용자 시나리오를 수정해야 했죠. 결과적으로 릴리스는 3주 연기됐고, SI업체는 패널티까지 물어야 했어요. 이 사건은 ‘요구사항에 대한 단 하나의 해석’이 얼마나 중요한지를 보여줍니다.
| 항목 | 문제점 | 결과 |
|---|---|---|
| 자동 로그아웃 | 요구사항 누락 | 테스트 단계에서 문제 발생 |
| 로그인 유지 시간 | 서술 불명확 | 시스템 오작동 |
| 시나리오 수정 | QA 단계에서 역추적 필요 | 릴리스 지연 |
QA 관점의 요구사항 점검 체크리스트
요구사항을 검토할 때 이 리스트만 있으면 일단 절반은 성공이에요. 단순히 읽는 것을 넘어, 이 항목들을 기준 삼아 문서를 비판적으로 바라봐야 합니다.
- 각 요구사항은 테스트 가능한가?
- 모든 기능 요구사항이 정량적 수치를 포함하는가?
- 이중 해석 가능성이 있는 표현은 없는가?
- 기능 간 상호작용이 문서화되어 있는가?
- 제약사항은 명확하게 기재되어 있는가?
요구사항 정의서에서 가장 중요한 요소는 ‘명확성’입니다. 누구도 오해하지 않도록 구체적이고 측정 가능하게 작성해야 하죠.
기능이 ‘동작한다’가 아니라 ‘5초 이내에 결과를 출력한다’처럼 구체적이고 명확해야 QA가 테스트할 수 있습니다.
가능하면 요구사항 정의 초기부터 참여해야 합니다. 그래야 누락이나 충돌 요소를 조기에 발견할 수 있어요.
초기 참여를 통해 QA는 테스트 설계에 필요한 조건을 문서에 반영시키고, 사전 예방적 품질 확보가 가능합니다.
모호한 표현은 이해되는 대로 테스트하면 큰 오류를 유발할 수 있으므로, 반드시 작성자에게 확인 요청을 해야 합니다.
‘빠르게 처리’같은 표현은 해석 차이가 크기 때문에, 수치 기준이나 조건을 다시 명확히 받아 문서화해야 합니다.
성능 수치나 장애 복구 시간 같은 항목은 자주 누락됩니다. 비기능 요구사항도 정량적으로 서술돼야 합니다.
단순히 ‘빠르게’가 아니라 ‘2초 이내’, ‘30분 이내 복구’처럼 수치 기준이 있어야 운영상의 품질을 보장할 수 있어요.
네, 변경 요구사항의 영향 분석은 QA의 핵심 업무 중 하나예요. 테스트 케이스에 어떤 영향이 가는지를 꼭 분석해야 하죠.
변경사항이 테스트 대상 범위를 바꾸기 때문에, QA는 영향 분석을 통해 누락 테스트를 방지해야 합니다.
요구사항 정의서는 단순한 기획 문서가 아닙니다. QA 입장에서 보면, 모든 테스트와 품질 관리의 출발점이 되는 중요한 기준이죠. 작은 표현 하나가 수천 개의 테스트 케이스에 영향을 미칠 수 있고, 그로 인해 프로젝트 전체의 품질이 좌우될 수도 있어요. 요구사항을 작성하거나 검토할 때, 이 글에서 다룬 체크리스트와 사례들을 떠올리며 조금 더 비판적인 눈으로 접근해보세요. 그것이 진짜 품질을 만드는 첫걸음입니다.
요구사항정의서, QA, 품질보증, 소프트웨어테스트, 기능요구사항, 비기능요구사항, 테스트전략, SI프로젝트, 소프트웨어개발, 품질관리