시스템 기능 정의 시 주의사항 - Part 3
사양서 Ctrl+C 했다가 실사장에서 Ctrl+Alt+Del
“시스템은 HTML5 기반의 웹 인터페이스를 제공한다.”
이 문장, 많이 봤을 거다.
이런 문장들은 흔히 URS에 붙어 있고, 보통은 무난하게 넘긴다.
하지만 실사장에서 이 문장이 문제 되면?
다음 질문이 날아온다.
“그래서 이 HTML5 인터페이스에서 사용자 권한 설정은 어떻게 작동하죠?”
“그 화면에서 변경된 로그는 어떻게 관리되나요?”
“해당 기능은 어떤 업무 목적을 위해 쓰이는 거죠?”
...이 질문들에 한 번이라도 문서에서 답할 수 있어야 한다.
벤더 사양서, 그거 QA가 쓴 문서 아니다.
벤더 문서는 제품의 기술 사양을 나열할 뿐이다.
그 사양이 당신 회사의 품질 정책과 어떻게 연결되는지,
데이터 무결성과 어떤 관련이 있는지는
당연히 포함되어 있지 않다.
그걸 재정의해서 품질 기반 요구사항으로 바꾸는 게 QA의 역할이다.
그걸 안 하면?
“그건 그냥 매뉴얼이지, URS가 아닙니다.”
벤더 문서 의존 → 테스트 누락 → 실사 탈락
예를 들어 이런 문장을 보자.
“시스템은 다양한 사용자 역할을 제공하며,
각 역할은 기능 접근 권한을 설정할 수 있다.”
이 문장, 듣기엔 좋아 보인다.
하지만 실제로는 아무 기능도 정의하지 않은 문장이다.
어떤 역할이 있는지?
기능 접근은 어떤 단위로 설정되는지?
권한 변경은 누가, 언제, 어떻게?
로그 기록은 남는지?
이 모든 게 빠져 있다.
그러니 테스트도 작성 못 하고,
결국 OQ에서 검증이 안 되는 문장이 된다.
기능 요구는 “규제기관이 기대하는 방식”으로 써야 한다.
EU GMP Annex 11, GAMP5, HMA/EMA DI 가이드라인이 공통적으로 말하는 건 이거다.
“기능 정의는 기술적 사양이 아니라 품질 통제를 전제로 구성되어야 한다.”
벤더 문서를 그대로 쓰면
그 시스템이 어떤 방식으로 품질에 기여하는지 설명할 수 없다.
그리고 그 순간,
그 기능은 CSV 대상에서 제외되거나, 실사장에서 의심을 받는다.
실무 감성 한 방 추가하자.
신공장 프로젝트 초기,
시간에 쫓기면서 URS를 급하게 작성하다 보면
벤더 사양서를 그냥 긁어붙이는 순간이 온다.
그 순간 QA는 실질적으로 검증 책임을 벤더에게 넘긴 셈이 된다.
하지만 실사장은 절대 벤더에게 책임을 묻지 않는다.
항상 문서에 사인한 QA에게 책임을 묻는다.
벤더 문서 복붙은 기술자의 일이다.
품질 문서를 만드는 사람은,
기술을 어떻게 품질 정책과 데이터 무결성 위에 얹을지 고민해야 한다.
기능 정의는 기술 사양의 요약이 아니다.
당신의 품질 전략의 설계도다.
다음 편은,
실제 사례로 보는 기능 정의의 '좋은 예'와 '나쁜 예'를 다룬다.
특히 “백업 기능” 같은 흔한 항목을 가지고
어떻게 URS 문장이 OQ 시나리오로 연결되는지 구체적으로 살펴볼 거다.
지금까지 내용을 현실에 적용하고 싶은 사람이라면 절대 놓치면 안 된다.
