업무 규칙·데이터 정의·수용 기준 상세화

핵심 요약

“정확한 고객 정보”, “빠른 보고서”처럼 평가 기준이 없는 표현은 설계자마다 다르게 해석한다. 상세화에서는 필요한 데이터의 업무 의미, 범위, 원천, 생성·갱신 시점, 계산·판정 규칙, 조건과 예외, 허용 품질과 수용 기준을 명시한다. 구현 기술을 미리 고정하지 않으면서도 결과를 시험할 수 있을 정도로 구체적이어야 한다.

학습 목표

• 상세 데이터 정의에 필요한 의미·범위·원천·시점·규칙을 설명한다.
• 업무 규칙을 조건·판정·행동·결과·예외 구조로 표현한다.
• 수용 기준과 구현 방법, 품질 목표와 측정 방법을 구분한다.
• 가정·제약·미결 사항을 숨기지 않고 책임·기한과 함께 관리한다.

1. 데이터 요구 상세화 항목

표준 단어·도메인·코드의 상세 수립 규칙은 Part 2에서 다룬다. 여기서는 요구를 모호하지 않게 정의할 정도의 데이터 의미와 제약을 기술한다.

2. 업무 규칙 표현

업무 규칙은 데이터의 생성·변경·파생·유효성·관계를 제약한다. 다음 요소를 사용하면 모호성을 줄일 수 있다.

[적용 조건] 어떤 상황·대상에
[판정 기준] 어떤 값·상태·기간을 기준으로
[의무/행동] 무엇을 해야 하거나 금지하는지
[결과] 어떤 상태·값이 되는지
[예외] 어떤 조건에서 다른 규칙이 적용되는지
[책임] 누가 확인·승인하는지

예: “주문 상태가 배송 전이고 결제 취소가 승인된 경우 주문을 ‘취소 완료’로 변경한다. 부분 출고가 있으면 자동 취소하지 않고 운영 승인 대상으로 전환한다.”

‘필요 시 처리한다’, ‘적절히 계산한다’는 판정 기준과 책임이 없어 검증하기 어렵다.

3. 수용 기준 설계

수용 기준은 구현 방식이 아니라 요구 결과를 관찰·측정하여 승인할 조건이다.

• 구체적 대상과 사전 조건이 있는가?
• 입력·사건과 기대 결과가 명확한가?
• 정상·경계·예외 사례를 포함하는가?
• 측정 단위와 허용 범위가 있는가?
• 요구의 모든 의무를 검증하며 불필요한 설계를 강제하지 않는가?

나쁜 기준: “빠르게 조회된다.”

개선 기준: “상담원 500명이 정상 부하에서 고객 식별자로 조회할 때, 정의된 데이터 범위가 승인된 성능 기준 내에 응답하고 권한 없는 민감 속성은 마스킹된다.”

구체 임계값은 업무·운영 근거로 확정해야 하며 근거 없는 숫자를 시험 공식처럼 고정하지 않는다.

4. 상세화 사례

원문: “우수 고객 매출을 매일 정확하게 보여준다.”

상세화 질문과 결과 예시

• 우수 고객: 평가월 직전 12개월 순매출과 등급 규칙에 따라 확정된 고객
• 매출: 승인 거래에서 취소·환불·세금을 어떻게 처리하는지 명시
• 기준 시점: 전 영업일 마감 기준
• 원천: 거래 원장과 고객 등급 기준선
• 갱신: 마감 완료 후 생성, 지연 시 상태 표시
• 사용자·목적: 영업 관리자의 지역별 실적 대응
• 예외: 등급 재산정 중인 고객, 늦게 도착한 취소 거래
• 수용 기준: 샘플 거래를 규칙대로 재계산해 결과와 일치하고 누락 상태가 표시됨

미정인 세금 처리와 늦은 거래 반영 시점은 임의로 채우지 않고 결정권자·기한과 함께 미결 사항으로 남긴다.

5. 비교와 구분

시험 판단 포인트

• 상세화는 데이터 의미·범위·원천·기준 시점·규칙·예외·수용 기준을 구체화한다.
• 업무 규칙은 조건·판정·행동·결과·예외와 책임을 판정 가능하게 표현한다.
• 수용 기준은 결과 충족 판단이며 특정 기술 구현을 불필요하게 강제하지 않는다.
• 가정과 미결 사항은 임의 확정하지 않고 근거·책임자·결정 기한을 기록한다.
• 정보 요구 명세서의 전체 구조와 승인 기준은 독립 신규 단원 후보로 분리한다.

자주 틀리는 부분

• “정확하게”, “신속하게”, “적절히” 같은 형용사만으로 요구를 완료하지 않는다.
• 현재 화면·테이블 구조를 요구 정의로 그대로 복사하지 않는다.
• 수용 기준을 “특정 제품을 사용한다” 같은 구현 방식으로 작성하지 않는다.
• 미결 규칙을 설계자가 임의 해석한 뒤 합의된 요구처럼 처리하지 않는다.