시스템 기능 정의 시 주의사항 - Part 4
이 문장 하나로 실사에서 살아남는다
“시스템은 백업 기능을 제공해야 한다.”
이 문장, URS에서 수도 없이 본다.
그리고 실사장에서 이렇게 물어본다.
“백업은 주기적으로 자동 저장되나요?”
“누가 백업 주기를 설정하나요?”
“백업 로그는 Audit Trail로 남나요?”
“백업 데이터는 변경이 불가능한 저장소에 있나요?”
...당신의 URS 문장이 이 질문에 대답할 수 없다면,
그 문장은 기능 정의가 아니다. 그냥 구색 맞춘 문장일 뿐이다.
좋은 기능 정의 문장은 이렇게 생겼다.
“시스템은 실시간 데이터를 매 5분 주기로 자동 백업하고,
백업 파일은 변경 불가능한 외부 스토리지에 저장되어야 하며,
백업 주기는 시스템 관리자만 설정 가능해야 한다.
백업 내역은 자동으로 Audit Trail에 기록되어야 한다.”
이 문장이 왜 중요한가?
OQ에서 검증할 수 있는 모든 기준점을 문장 안에 담고 있기 때문이다.
– 주기적 자동 백업: 테스트 가능
– 외부 스토리지 저장 여부: 테스트 가능
– 관리자 권한 설정 여부: 테스트 가능
– Audit Trail 기록 여부: 테스트 가능
GAMP5가 말하는 “검증 가능한 요구사항”이 바로 이런 문장이다.
기능 정의는 결국 ‘테스트 시나리오의 씨앗’이다.
많은 QA들이 “OQ 문서 작성을 따로 배워야 하나요?”라고 묻는다.
아니다.
좋은 URS 문장이 있으면, OQ 문서는 자동으로 열린다.
지금 위 문장 하나로,
– OQ 테스트 케이스 3~4개가 도출된다.
– Audit Trail 설정 확인도 가능하다.
– 백업 경로 설정까지 검증할 수 있다.
좋은 URS 문장 하나 = IOQ 문서의 뼈대
이쯤에서 실무 감성 한 방
당신이 시간에 쫓겨
“백업 기능 제공”이라고만 써놓고 사인했다면,
그 문장은 실사장에서 “이 사람은 이 시스템의 백업 방식을 이해하지 못했다”는 증거가 된다.
그리고 그 순간,
문서 전체의 신뢰도가 무너진다.
기술 스펙은 누구나 쓴다.
검증 가능한 문장을 쓰는 사람이 실사장을 통과한다.
마지막 5편에서는
외부 시스템과 연동되는 기능을 어떻게 정의해야 하는지,
즉 “경계를 명확히 해야 실사장에서 살아남는다”는 주제를 다룬다.
특히 EMS, BMS 같은 통신 기반 연동 기능을
구체적이고 검증 가능하게 쓰는 법.
실무자라면 반드시 필요한 내용이다.
이번 시리즈의 피날레.
다음 편에서 끝장을 보자.
