벤더가 써준 URS
어디까지 믿어도 될까?
요즘은 프로젝트 초기에 벤더가 미리 URS 초안을 작성해주는 경우가 많습니다.
겉보기엔 깔끔하게 포맷도 갖춰져 있고, 마치 바로 검토 후 서명만 하면 될 것처럼 보이죠.
그런데… 이게 진짜 사용자 요구사항일까요?
사실 대부분의 벤더 URS 초안은 ‘기술사양 목록’에 가깝습니다.
“이 기능은 있어요, 저 기능도 됩니다”
– 마치 쇼핑몰 설명처럼 말이죠.
이런 문서에 곧장 싸인하면,
나중에 실사에서 이런 말 듣습니다:
“이 기능은 누가 왜 요구한 거죠?”
“테스트 항목으로 만들 수 있나요?”
“이 설정은 규제 요건 중 어디에 해당하죠?”
벤더는 기술을 설명했을 뿐이고,
감사인은 규제 기준을 물어봅니다.
그리고 그 중간에서 책임지는 건… 바로 QA입니다.
사례: 벤더 문장을 QA가 다시 쓴다면?
벤더 초안 문장
“시스템은 로그인 기능을 제공해야 한다.”
한 줄 요약: 로그인이 된다.
이걸 QA 시선으로 보면, 너무 많은 게 빠져있습니다.
누가 로그인 가능한가?
로그인 실패 시 시스템 반응은?
로그는 어디에 남는가?
권한은 어떻게 설정되는가?
QA가 다시 쓰면?
“시스템은 사용자 계정별 권한 그룹을 기반으로 접근 권한을 제한하고, 모든 로그인 시도(성공/실패)는 변경 불가능한 로그로 기록되어야 하며, 실패 횟수 5회 초과 시 해당 계정은 자동 잠금 처리되고, 잠금 해제는 관리자 계정으로만 가능해야 한다.”
이 문장 하나로,
OQ 테스트 항목이 생기고,
감사 대응 논리가 생기고,
규제 기준 연결 고리가 생깁니다.
벤더 URS 초안, 이럴 땐 주의하라
모호한 단어 “시스템은 백업 기능을 제공한다” → 언제, 어디에, 어떻게, 누가 설정?
기술 중심 표현 “HTML5 기반의 UI 제공” → 기술은 중요하지 않습니다. 사용자와 데이터의 통제 기준이 빠졌습니다.
책임 주체 없음 “설정은 변경 가능해야 한다” → 누가 변경하죠? 어떤 조건에서? 변경 내역은?
기억해야 할 문장
벤더는 “이게 됩니다”를 말하고,
감사인은 “왜 필요했고, 어떻게 입증합니까?”를 묻습니다.
URS는 ‘무엇이 되는지’가 아니라
‘무엇을 입증할 수 있는지’를 서술하는 문서입니다.
마무리
URS는 벤더가 써주는 게 아닙니다.
시스템을 실제 사용하는 사람, 그 품질을 책임지는 사람이
마지막으로 책임지고 완성시켜야 하는 문서입니다.
벤더가 준 초안은 초안일 뿐,
진짜 URS는 QA가 만든다는 자세가 필요합니다.
다음 편 예고: 이 시스템, 왜 신뢰할 수 있는가
– 데이터 무결성과 감사 대응의 핵심 ‘Audit Trail’ 파헤치기
