시스템 기능 정의 시 주의사항
- Part 1
URS 한 줄이 밸리데이션을 무너뜨린다
“시스템은 알람 기능을 제공해야 한다.”
이 문장 하나로 밸리데이션을 말아먹은 QA들이 몇이나 될까?
문제는 이 문장이 너무 익숙해서 아무도 이상하다고 생각하지 않는다는 거다.
하지만 실사를 나온 감사인은, 이 한 줄에서 수십 개의 질문을 뽑아낸다.
“어떤 조건에서 알람이 발생하나요?”
“알람은 어디에 표시되며, 누가 해제할 수 있죠?”
“발생·해제 로그는 자동으로 저장되나요?”
“Audit Trail은 연결되어 있습니까?”
당신이 쉽게 쓴 한 줄이,
감사인의 머릿속에서는 기능 정의 → 설계 명세 → 테스트 항목 → 기록 유지 → 감사 대응으로
풀 세트를 자동 생성하고 있는 셈이다.
“이건 그냥 기능 설명인데요?”
아니, 그게 문제다.
URS는 단순한 ‘기능 설명서’가 아니다.
GMP Annex 11, GAMP5, PIC/S 등 모든 규제 문서는
기능 요구사항은 검증 가능하고, 품질 통제를 보여주는 형태로 작성되어야 한다고 명시하고 있다.
단순히 기능이 ‘있어야 한다’는 건,
그저 “그런 거 있었으면 좋겠다” 수준의 이야기일 뿐이다.
‘익숙함’이 함정이다.
알람, 백업, 보고서 출력 같은 기능들은
너무 자주 봐서 누구나 당연하게 느낀다.
그러니 더 위험하다.
예를 들어,
“시스템은 데이터 백업 기능을 제공해야 한다”
이렇게 쓰면 너무 당연하고 깔끔해 보인다.
하지만 진짜 시험 항목으로 연결할 수 있을까?
백업은 언제 발생하나?
자동인가 수동인가?
저장 경로는 고정인가?
권한자는 누구인가?
주기는 설정 가능한가?
백업 실패 시 알람은?
로그 기록은 자동으로 되는가?
이 모든 걸 OQ 테스트에서 증명해야 한다.
그런데 URS에 아무것도 안 써뒀다면?
실사 때 물어볼 사람이 없다는 건 착각이다.
그때 당신이 QA고, 당신의 사인에 책임이 있다.
문장 하나가 시스템 신뢰도를 만든다.
GAMP5에서는 이렇게 말한다.
“System Functions shall be specified in a testable way.”
시스템 기능은 반드시 시험 가능한 방식으로 정의되어야 한다.
그 한 줄을 쉽게 쓰지 마라.
그 한 줄이 시스템 전체의 신뢰도를 만들고,
당신의 이름 옆 사인의 무게를 결정한다.
다음 편에선
“~할 수 있어야 한다”는 기능 정의의 유령 문장이
어떻게 실사에서 꼬리를 물고 추궁당하는지 보여줄 거다.
