URS의 목적과 책임 - Part 1
URS는 단지 요구서가 아니다
시스템을 도입하면,
제일 먼저 등장하는 문서가 있다.
URS – 사용자 요구사항 명세서.
처음엔 그냥 체크리스트처럼 보인다.
“이런 기능이 필요하다.”
“이런 조건이 있었으면 좋겠다.”
그런데 진짜 문제는,
그 기능을 나중에 ‘입증할 수 있는가’다.
많은 URS는
기능을 나열한 목록에 불과하다.
하지만 그 문장은
나중에 OQ 항목이 되고,
감사장에서 근거가 되며,
그 기능이 규제 요건에 부합하는지를 판단하는 기준이 된다.
검토자 입장에서 보면,
URS는 단지 “기능이 있어야 한다”는 말이 아니다.
“이 기능은 규제를 충족할 수 있는가?”
“시험 가능하고, 기록에 남을 수 있는가?”
이게 URS 문장을 바라보는 기준이다.
반대로 작성자는
자신이 필요로 하는 기능을 기술적으로 적는다.
하지만 그 문장이
검증 가능하지 않으면, 아무 의미 없다.
“접근 권한이 있어야 한다”는 말은
당연한 말처럼 들리지만,
그게 몇 단계로 나뉘고,
누가 설정하고, 로그는 남고, 변경은 통제되는지
아무것도 드러나지 않으면,
그건 검증할 수 없는 기능이 된다.
URS는 기술 사양이 아니라
밸리데이션 전략의 시작점이다.
작성자와 검토자의 언어가
하나의 문서 안에서 충돌하지 않고,
서로 연결되어야 한다.
기능은 기대가 아니라,
증명의 단서로 서술되어야 한다.
그리고 바로 다음 단계에서
그 문장이 신뢰받을 수 있는 구조인지가 드러난다.
누구나 쓰는 기능 설명과,
검토자가 멈추지 않고 넘어갈 수 있는 문장 사이엔
분명한 차이가 있다.
그 차이는...
URS의 목적과 책임 - Part 2
“신뢰받는 URS 문장의 구조”에서 이어가도록 하겠다.
