Intro

DAsP에서 다루는 데이터 요건 분석은 데이터를 수집하고, 조사하고, 분석하고, 검증함으로써 데이터의 일관성과 추적 가능성을 확보하는 것을 목표로 한다. 이 단계를 제대로 거쳐야 이후의 개념 데이터 모델, 논리 데이터 모델, 물리 데이터 모델 역시 흔들리지 않는다. 반대로 이 단계가 부실하면 설계와 개발, 테스트, 운영 전반에서 끝없는 수정이 반복된다.

---

1장. 정보 요구사항 개요

1.1 정보 요구사항?

정보 요구사항은 사용자가 업무를 수행하는 과정에서 필요로 하는 정보와 기능, 그리고 이를 시스템에 반영하기 위해 요청하는 내용을 의미한다. 향후 시스템이 어떤 데이터를 저장하고, 어떤 규칙으로 처리하며, 어떤 방식으로 제공해야 하는지를 결정하는 과정이다.

예를 들어 영업 부서가 “고객별 월간 매출 현황을 보고 싶다”라고 요청했다고 하자. 이 문장은 겉보기에는 단순한 보고서 요구처럼 보이지만, 데이터 관점에서는 이미 여러 요소가 내포되어 있다.

• 고객이라는 관리 대상이 존재
• 매출이라는 사실 데이터를 구조적으로 관리
• 월 단위 집계를 위한 시간 기준 요구
• 확실한 고객과 매출 사이의 관계
• 조회 권한과 성능 요건 고려

즉 하나의 요구사항 안에는 이미 업무 개념, 데이터 구조, 처리 규칙, 통제 기준이 함께 들어 있다. 따라서 데이터 요건 분석은 그 안에 숨어 있는 의미를 데이터 관점에서 해석하는 과정이다.

1.2 정보 요구사항의 역할

정보 요구사항은 프로젝트와 시스템 개선 과정에서 다음과 같은 역할을 수행한다.

1. 개발 범위 정의
   무엇을 구현해야 하고, 무엇은 범위 밖인지 구분하는 기준이 된다.

2. 데이터 설계의 근거
   어떤 엔터티가 필요한지, 어떤 속성이 필요한지, 데이터 간 관계는 어떻게 정의해야 하는지를 도출할 수 있다.

3. 사용자와 개발자 사이의 기준점
   사용자는 자신이 원하는 것이 반영되었는지 판단하고, 개발자는 무엇을 구현해야 하는지 판단한다.

4. 검증과 테스트의 기준
   요구사항이 명확해야 테스트 케이스도 명확해진다.

5. 변경 관리의 기준
   향후 추가 요구나 변경 요청이 발생했을 때 어떤 항목이 바뀌었는지 추적할 수 있다.

1.3 정보 요구사항의 유형

정보 요구사항은 여러 기준으로 분류할 수 있지만, 데이터 요건 분석 관점에서는 보통 다음과 같이 구분된다.

1. 기능적 요구사항
   가장 일반적인 요구사항으로 시스템이 무엇을 해야 하는가에 대한 요구
   ex) 고객 등록, 주문 생성, 매출 조회, 정산 처리 등

2. 비기능적 요구사항
   시스템이 어느 수준으로 동작해야 하는가에 대한 요구
   ex) 성능, 보안, 가용성, 확장성, 백업, 접근통제 등

3. 데이터 요구사항
   어떤 데이터를 수집하고 저장하고 활용해야 하는가에 대한 요구
   ex) 고객 식별값, 거래일시, 상태코드, 이력 보관 여부, 보존 기간 등

4. 인터페이스 요구사항
   다른 시스템과 어떤 방식으로 연계해야 하는가에 대한 요구
   ex) 외부 기관 연계, 배치 파일 교환, API 호출, 메시지 기반 송수신 등

실제로는 이 유형들이 깔끔하게 분리되어 나타나지 않고 섞여 있는 경우가 대다수다. 예를 들어 “외부 시스템에서 회원 정보를 받아 실시간 반영하고, 오류 시 재처리하며, 개인정보는 암호화해야 한다”는 문장에는 기능, 인터페이스, 데이터, 보안 요구가 모두 함께 들어 있다. 따라서 요구사항을 수집한 후에는 이를 적절히 분해하고 정리하는 작업을 거쳐야한다.

1.4 정보 요구사항 생명주기

정보 요구사항은 한 번 수집하고 끝나는 정적인 대상이 아니다. 일반적으로 다음과 같은 생명주기를 가진다.

• 요구사항 수집
• 요구사항 정리 및 분석
• 요구사항 상세화
• 요구사항 검증
• 요구사항 확정 및 변경 관리

이 흐름은 소프트웨어 생명주기와도 밀접하게 연결된다. 요구사항이 애매하면 설계가 흔들리고, 설계가 흔들리면 개발이 흔들리며, 개발이 흔들리면 테스트 비용과 운영 리스크가 크게 증가한다. 그래서 요구사항 단계는 뒤 단계보다 비용은 적게 들 수 있지만, 프로젝트 전체에 미치는 영향력은 오히려 훨씬 크다.

---

2장. 정보 요구사항 조사

2.1 정보 요구사항 조사의 목적

정보 요구사항 조사 단계는 실제 현업과 시스템 환경 속에서 필요한 요구를 수집하고 드러내는 과정이다. 개요 단계가 “무엇을 어떤 관점에서 볼 것인가”를 정하는 준비였다면, 조사 단계는 “실제로 어떤 요구가 존재하는가”를 찾는 단계다.

이 단계가 중요한 이유는, 사용자의 요구가 처음부터 명확하게 정리되어 있지 않은 경우가 대부분이기 때문이다. 사용자는 자신이 불편한 점은 말할 수 있어도, 그것을 데이터 구조나 시스템 기능 수준으로 체계화해서 표현하지는 못하는 경우가 많다. 따라서 요구 사항에 암묵적으로 포함된 내용을 분석하는 과정이 필수다.

2.2 조사 대상

정보 요구사항 조사의 대상은 단순히 사용자 인터뷰만을 의미하지 않는다. 실제로는 다양한 출처가 함께 고려되어야 한다.

• 현업 사용자 인터뷰
• 중간 관리자 및 의사결정자 인터뷰
• 기존 시스템 화면과 메뉴 구조
• 업무 매뉴얼, 보고서, 전표, 입력 양식
• 데이터 사전, 테이블 정의서, ERD
• 외부 연계 문서와 인터페이스 명세
• 장애 이력, 개선 요청 이력
• 현행 프로그램 및 배치 흐름

현실에선 사용자가 직접 말해 주는 요구사항보다 문서와 시스템 분석을 통해 더 중요한 단서를 발견하는 경우가 많다. 왜냐하면 사용자는 현재 시스템에 익숙해져 있어서 불편함을 당연하게 받아들이는 경우가 있기 때문이다. 반면 화면 구조, 입력 양식, 보고서 체계, 코드 정의 등을 살펴보면 중복 입력이나 용어 불일치, 책임 주체 모호성 같은 문제가 더 잘 드러난다.

2.3 정보 요구사항 수집 기법

2.3.1 관련 문서 조사

가장 기본적이면서도 중요한 방법이다.
업무 매뉴얼, 보고서, 규정집, 시스템 설계서, 인터페이스 문서, 화면 정의서, 코드 체계 등을 검토하여 현재 업무와 데이터 구조를 파악한다.

문서 조사의 장점은 공식 기준과 실제 관행을 동시에 확인할 수 있다는 점이다. 예를 들어 시스템에서는 “회원상태”라는 용어를 쓰고 있는데 보고서에서는 “고객등급”이라는 용어를 쓴다면, 두 용어가 같은 개념인지 다른 개념인지 확인이 필요하다. 이러한 차이는 나중에 데이터 표준화와 모델링에서 매우 중요한 이슈가 된다.

또한 문서 조사 단계에서는 수집한 자료를 무작정 쌓아두는 것이 아니라, 분석 목적에 맞게 구조화해야 한다. 예를 들어 업무 문서, 시스템 문서, 데이터 문서, 외부 연계 문서를 분리해 관리하면 이후 분석 효율이 높아진다.

2.3.2 사용자 면담

사용자 면담은 현업 실무자와 직접 대화하면서 요구를 끌어내는 방식이다. 이때 중요한 것은 “무엇이 필요하십니까?”라고 단순히 묻는 것이 아니라, 현재 어떤 업무를 어떤 순서로 처리하고 있으며, 어떤 정보를 기준으로 판단하고, 어떤 지점에서 불편이 발생하는지를 파악하는 것이다.

예를 들어 다음과 같은 질문이 효과적이다.

• 현재 업무는 어떤 절차로 진행됩니까?
• 이 과정에서 직접 입력하거나 확인하는 정보는 무엇입니까?
• 현재 가장 자주 조회하는 화면이나 보고서는 무엇입니까?
• 지금 시스템에서 가장 불편한 점은 무엇입니까?
• 누락되면 가장 문제가 되는 데이터는 무엇입니까?
• 다른 부서와 데이터를 주고받을 때 자주 충돌하는 항목은 무엇입니까?

좋은 면담은 기능 요청을 받아 적는 자리가 아니라, 업무 흐름과 데이터 사용 행태를 이해하는 자리다. 특히 면담 과정에서는 사용자의 표현을 그대로 사실로 받아들이기보다, 그 뒤에 있는 업무 목적과 데이터 구조를 파악해야 한다.

2.3.3 워크숍

워크숍은 여러 부서가 동시에 참여해 공통 요구사항을 조정하고 합의점을 찾는 방식이다. 부서 간 이해관계가 얽혀 있거나, 동일한 데이터를 서로 다르게 해석하는 경우에 매우 유용하다.

예를 들어 영업 부서, 정산 부서, 재무 부서가 모두 “주문 상태”를 다른 기준으로 사용하고 있다면, 개별 면담만으로는 일관된 정의를 만들기 어렵다. 이럴 때 워크숍을 통해 상태 정의, 변경 시점, 책임 부서를 함께 조정해야 한다.

워크숍의 장점은 여러 관점을 한 자리에서 비교할 수 있다는 점이다. 반면 준비 없이 진행하면 목소리가 큰 부서의 의견만 반영될 위험이 있으므로, 사전 안건 정리와 진행자 역할이 매우 중요하다.

2.3.4 현행 업무 조사서

전체 부서를 대상으로 동일한 형식의 조사서를 배포하여 업무와 정보 요구를 수집하는 방식이다. 대규모 조직에서 광범위한 요구를 빠르게 파악할 때 유용하다.

이 방식의 핵심은 양식이 단순하고 명확해야 한다는 점이다. 작성이 어렵거나 기준이 불분명하면 회수율도 떨어지고 내용의 품질도 낮아진다. 따라서 조사서에는 작성 예시와 용어 설명을 포함해 혼선을 줄여야 한다.

2.3.5 현행 시스템 및 데이터 구조 조사

현재 운영 중인 프로그램, 테이블, 인터페이스 구조를 직접 분석하는 방식이다. 문서가 오래되었거나 실제 시스템과 일치하지 않는 경우에는 이 방법이 특히 중요하다. 경우에 따라서는 테이블 스키마, 소스 코드, 배치 로그 등을 직접 확인하는 역공학적 접근이 필요할 수도 있다.

이 과정은 단순히 현재 구조를 확인하는 데 그치지 않는다. 기존 데이터 구조의 문제점, 중복 저장, 정합성 오류, 비표준 용어 사용 등을 식별하는 데에도 큰 도움이 된다.

2.4 정보 요구사항 통합과 분할

조사 단계에서 수집된 정보 요구사항은 그대로 분석에 사용하기 어렵다. 왜냐하면 부서와 사용자별로 표현 방식이 다르고, 중복되거나 충돌하는 내용이 섞여 있기 때문이다. 따라서 조사 후에는 반드시 요구사항을 통합하고 분할하는 작업이 필요하다.

통합이 필요한 경우

• 표현만 다를 뿐 본질적으로 같은 요구인 경우
• 여러 부서가 동일한 데이터 구조 변경을 요구하는 경우
• 유사 보고서나 유사 화면 요청을 하나의 공통 기능으로 묶을 수 있는 경우

분할이 필요한 경우

• 하나의 요구 안에 여러 기능이 섞여 있는 경우
• 기능 요구와 데이터 요구, 성능 요구가 함께 섞여 있는 경우
• 책임 부서나 처리 시점이 다른 요구가 하나로 묶여 있는 경우

예를 들어 “주문 조회 화면을 개선하고, 주문 취소 이력을 남기고, 외부 정산 시스템으로 전송해 주세요”라는 요구는 하나처럼 보이지만 실제로는 다음과 같이 분리할 수 있다.

• 주문 조회 기능 개선
• 취소 이력 데이터 관리
• 외부 시스템 인터페이스 처리

이처럼 통합과 분할은 단순 편집 작업이 아니라, 이후 설계와 추적성을 확보하기 위한 구조화 작업이다.

2.5 우선순위 분석

현실에서는 모든 요구를 동시에 반영할 수 없다. 예산, 일정, 인력은 항상 제한되어 있기 때문이다. 따라서 요구사항 조사 이후에는 우선순위를 판단해야 한다.

우선순위 판단 기준으로는 보통 다음 요소가 사용된다.

• 업무 기여도
• 긴급성
• 전사적 파급효과
• 데이터 품질 영향도
• 구현 난이도
• 법규 및 컴플라이언스 대응 필요성
• 비용 대비 효과

데이터 아키텍처 관점에서는 단순히 특정 부서가 강하게 요청했다는 이유만으로 우선순위를 정하면 안 된다. 더 중요한 것은 해당 요구가 전사 데이터의 일관성, 핵심 업무 흐름, 마스터 데이터 관리, 인터페이스 안정성에 어떤 영향을 미치는가이다.

---

3장. 정보 요구사항 분석

3.1 조사와 분석의 차이

많은 경우 조사와 분석이 혼동되지만, 두 단계는 분명히 다르다.
조사는 요구를 수집하는 단계이고, 분석은 수집된 요구를 해석하고 구조화하여 데이터 설계가 가능한 수준으로 정리하는 단계이다.

즉 조사 단계에서는 “무슨 말이 나왔는가”가 중요하고, 분석 단계에서는 “그 말을 데이터와 프로세스 관점에서 어떻게 이해해야 하는가”가 중요하다.

3.2 분석의 목적

정보 요구사항 분석의 목적은 단순히 문장을 정리하는 데 있지 않다. 핵심 목적은 다음과 같다.

• 요구사항의 의미를 명확히 한다.
• 데이터 관점에서 필요한 관리 대상을 식별한다.
• 업무 흐름과 데이터 흐름의 관계를 정리한다.
• 중복과 충돌을 해소한다.
• 데이터 모델링이 가능한 수준으로 요구를 상세화한다.

예를 들어 “회원의 최근 활동을 보고 싶다”라는 요구는 분석 과정을 거치며 훨씬 더 구체적인 질문으로 바뀌게 된다.

• 회원의 정의는 무엇인가?
• 최근 활동의 범위는 어디까지인가?
• 로그인, 구매, 문의, 리뷰 작성 중 무엇을 포함하는가?
• 최근의 기준은 7일인가, 30일인가?
• 활동은 이력 데이터로 관리하는가, 요약 데이터로 관리하는가?
• 개인정보와 연결될 때 보존 정책은 어떻게 되는가?

이처럼 분석은 막연한 요구를 정의, 범위, 기준, 관계, 제약조건 수준으로 구체화하는 과정이다.

3.3 분석 대상 시스템 및 자료 확인

분석에 들어가기 전에는 현재 시스템과 관련 자료의 신뢰성을 먼저 검토해야 한다. 일반적으로 다음 네 가지 관점이 중요하다.

• 유용성
  해당 문서나 자료가 현재 요구사항 분석에 실제로 도움이 되는가

• 완전성
  필요한 정보가 빠짐없이 포함되어 있는가

• 정확성
  문서의 내용과 실제 운영 중인 시스템이 일치하는가

• 유효성
  자료가 최신 상태를 반영하고 있는가

실무에서는 설계서보다 실제 데이터베이스 구조나 운영 중인 화면이 더 정확한 경우가 적지 않다. 따라서 문서만 믿고 분석을 진행하는 것은 위험하다. 필요하다면 운영 DB 스키마, 로그, 인터페이스 메시지까지 직접 확인해야 한다.

3.4 업무 분석과 데이터 식별

정보 요구사항 분석의 핵심 결과 중 하나는 관리해야 할 데이터 대상을 식별하는 것이다. 즉 어떤 엔터티가 필요한지, 어떤 속성이 필요한지, 데이터 간 어떤 관계가 존재하는지를 도출하게 된다.

예를 들어 “주문 취소 사유를 관리하고 싶다”라는 요구를 분석하면 다음과 같은 데이터 요소가 도출될 수 있다.

• 주문
• 주문 상태
• 주문 취소 이력
• 취소 사유 코드
• 취소 요청자
• 취소 일시
• 환불 처리 여부

이때 중요한 것은 단순히 항목을 많이 뽑는 것이 아니라, 무엇이 독립적인 관리 대상인지를 판단하는 것이다. 예를 들어 취소 사유가 단순 문자열 입력인지, 아니면 전사 표준코드 관리가 필요한 값인지에 따라 데이터 구조는 달라진다. 또한 주문 상태를 주문 엔터티의 단순 속성으로 둘 것인지, 상태 이력 엔터티를 별도로 둘 것인지 역시 업무 요구에 따라 달라진다.

3.5 프로세스 분석과 데이터 흐름

데이터는 언제나 업무 프로세스와 연결되어 있다. 따라서 요구사항 분석에서는 데이터를 고립된 대상으로 보지 않고, 어떤 프로세스에서 생성되고 조회되고 수정되고 삭제되는지를 함께 파악해야 한다.

예를 들어 주문 관리 업무를 살펴보면 다음과 같이 세분화할 수 있다.

• 주문 접수
• 결제 확인
• 주문 확정
• 배송 처리
• 주문 취소
• 환불 처리
• 정산 반영

이런 흐름을 따라가면 “주문”이라는 데이터가 단순히 한 번 저장되고 끝나는 것이 아니라, 여러 단계에서 상태를 바꾸며 활용된다는 사실을 알 수 있다. 따라서 요구사항 분석 단계에서는 단순히 주문 테이블 하나만 정의하는 것이 아니라, 상태 전이, 이력 관리, 제약조건, 참조 관계까지 함께 고려해야 한다.

3.6 SWOT과 RAEW 관점의 해석

DAsP에서는 요구사항 분석 과정에서 경영 환경과 조직 구조를 이해하기 위한 도구로 SWOT과 RAEW 같은 프레임워크를 함께 활용하기도 한다.

1. SWOT 분석
   SWOT은 조직이나 시스템의 내외부 환경을 강점, 약점, 기회, 위협으로 나누어 보는 방식이다. 데이터 관점에서 보면 다음과 같이 활용할 수 있다.

• 강점: 이미 잘 관리되고 있는 핵심 데이터 자산
• 약점: 중복 데이터, 품질 저하, 표준 미흡
• 기회: 데이터 통합을 통한 신규 서비스 가능성
• 위협: 규제 강화, 보안 리스크, 외부 연계 복잡성 증가
  즉 SWOT은 단순한 경영 분석 도구가 아니라, 데이터 요구가 어떤 배경에서 등장했는지 이해하는 데 도움이 된다.

2. RAEW 분석
   RAEW는 Responsibility, Authority, Expertise, Work의 관점에서 역할 구조를 분석하는 방식이다. 데이터 요건 분석에서는 특히 누가 데이터를 생성하고, 누가 수정하고, 누가 책임지는지를 이해하는 데 유용하다.
   예를 들어 어떤 고객 마스터 데이터에 대해 영업 부서가 책임을 갖고 있지만 실제 입력은 타 부서가 하고 있다면, 데이터 품질 문제가 발생할 가능성이 높다.

3.7 정보 요구사항 명세서 작성

분석을 통해 정리된 내용은 결국 명세서 형태로 구체화되어야 한다. 정보 요구사항 명세서는 사용자, 분석가, 개발자, 테스터 모두가 참조하는 공식 기준 문서다. 작성이 잘된 명세서는 다음과 같은 특징을 가진다.

• 모호한 표현 X
• 누락 X
• 용어의 일관성
• 구체적인 처리 기준
• 명확한 데이터 항목과 제약조건
• 테스트 가능한 수준

예제)

• “빠르게 조회되어야 한다”는 표현은 좋은 명세가 아니다.
  “최근 1개월 주문 내역 조회는 3초 이내에 완료되어야 한다”처럼 정량적인 표현이 필요하다.

• “개인정보를 안전하게 관리한다”도 모호하다.
  “주민등록번호는 저장 시 암호화하며, 조회 화면에서는 마스킹 처리한다”처럼 구체적으로 명시해야 한다.

---

4장. 정보 요구 검증

4.1 정보 요구 검증의 필요성

아무리 요구사항을 잘 수집하고 분석하고 명세서까지 작성했다고 해도, 그 결과가 항상 완전하고 정확하다고 볼 수는 없다. 요구사항에는 사용자 해석의 차이, 부서 간 용어 차이, 분석 누락, 기존 시스템과의 충돌 가능성 등이 있을 수 있기 때문이다.
검증 단계는 작성된 요구사항 정의서와 명세서가 사용자의 의도와 전사 데이터 아키텍처 원칙에 부합하는지 최종 확인하는 단계이다.

4.2 검증 기준

정보 요구 검증에서는 일반적으로 다음 네 가지 기준이 있다

• 완전성
  필요한 요구가 빠짐없이 반영되었는가를 확인하는 기준이다.
  예를 들어 조회 기능은 정의했지만 생성, 수정, 삭제, 이력 관리, 예외 처리 기준이 빠져 있다면 완전성이 부족하다고 볼 수 있다.

• 정확성
  요구가 실제 업무 의도와 맞는가를 확인하는 기준이다.
  사용자는 “거래 취소”를 원했는데 문서에는 “삭제”로 적혀 있다면, 이는 단순한 용어 차이가 아니라 데이터 보존 정책과 감사 추적에 큰 차이를 만드는 심각한 문제다.

• 일관성
  문서 전체에서 같은 개념이 동일한 용어와 동일한 규칙으로 표현되고 있는지를 확인하는 기준이다.
  한 곳에서는 고객, 다른 곳에서는 회원, 또 다른 곳에서는 사용자라고 표현하고 있다면 같은 대상을 뜻하더라도 혼란을 야기할 수 있다.

• 안정성
  새로운 요구를 반영했을 때 기존 시스템이나 기존 데이터 구조에 과도한 부작용을 일으키지 않는가를 확인하는 기준이다.
  예를 들어 신규 상태값 추가가 기존 인터페이스, 배치, 정산 로직 전반에 영향을 준다면 안정성 검토가 필요하다.

4.3 검증 절차

정보 요구 검증은 보통 다음과 같은 흐름으로 진행된다.

• 검증 범위와 대상 정의
• 검토 회의 계획 수립
• 요구사항 정의서 및 명세서 검토
• 용어와 표준 검토
• 상관분석 수행
• 수정 및 보완 반영
• 베이스라인 확정

여기서 중요한 것은 베이스라인 설정이다. 검증을 마친 요구사항은 공식 기준으로 고정되어야 이후 변경 관리가 가능하다. 그렇지 않으면 개발 중간마다 구두 요청이 계속 섞이면서 통제가 어려워진다.

4.4 요구사항 명세서 검토

명세서 검토는 문서의 문장을 단순히 읽는 것이 아니라, 논리적 흐름과 데이터 구조의 정합성을 함께 확인하는 작업이다. 이 단계에서는 다음과 같은 질문이 중요하다.

• 업무 흐름이 현실과 일치하는가
• 입력과 출력이 논리적으로 연결되는가
• 데이터 정의가 모호하지 않은가
• 누락된 예외 상황은 없는가
• 테스트 가능한 수준으로 작성되었는가

특히 요구사항 명세서는 사용자 입장, 개발자 입장, 테스터 입장을 모두 만족해야 한다. 사용자는 이해할 수 있어야 하고, 개발자는 구현할 수 있어야 하며, 테스터는 검증할 수 있어야 한다.

4.5 요구사항 용어 검증

데이터 아키텍처에서 용어의 일관성은 매우 중요하다. 같은 개념을 부서마다 다른 용어로 부르면 데이터 통합과 표준화가 어려워지고, 결국 품질 문제와 해석 차이로 이어진다.

따라서 검증 단계에서는 다음을 확인해야 한다.

• 여러 문서 내의 용어의 의미 통일성
• 데이터 표준과 도메인 정의 준수
• 코드값과 상태값의 정의가 일관성
• 약어와 축약어 혼동 가능성

4.6 CRUD 매트릭스를 활용한 검증

정보 요구 검증의 대표적인 방법 중 하나가 CRUD 매트릭스이다. CRUD는 Create, Read, Update, Delete를 의미하며, 데이터 엔터티와 기본 프로세스 간의 관계를 행렬 형태로 정리하여 요구사항의 누락과 충돌을 점검한다.

예를 들어 다음과 같은 구조를 생각해 볼 수 있다.

기본 프로세스	고객	주문	주문상태이력
고객 등록	C
주문 접수	R	C	C
주문 조회	R	R	R
주문 취소	R	U	C
고객 탈퇴	U	R

• 어떤 데이터가 어떤 프로세스에서 사용되는가
• 생성은 되는데 종료나 삭제 처리가 없는 데이터는 없는가
• 중요한 데이터인데 어떤 프로세스와도 연결되지 않은 것은 없는가
• 하나의 데이터가 지나치게 많은 프로세스와 연결되어 있지는 않은가

[CRUD 매트릭스 검증 시 특히 주의할 점]

1. 모든 행과 열은 의미를 가져야 한다
   어떤 엔터티가 어떤 프로세스와도 연결되지 않으면, 도출은 했지만 실제로 쓰이지 않는 데이터일 가능성이 있다. 반대로 어떤 프로세스가 어떤 엔터티와도 연결되지 않으면, 처리 대상 데이터가 빠졌을 가능성이 있다.

2. 생성된 데이터의 수명주기 고려
   데이터는 생성만 되고 끝나지 않는다. 조회, 변경, 종료 또는 삭제까지 포함한 전체 생명주기 관점에서 검토해야 한다.

3. 과도한 연결은 복잡도의 신호
   하나의 데이터가 지나치게 많은 프로세스에서 생성·수정된다면, 이는 결합도가 높아지고 무결성 관리가 어려워지는 신호일 수 있다. 이 경우 프로세스 분리나 데이터 구조 재검토가 필요하다.