데이터 요구사항·업무규칙·용어: 무엇을 사실로 남길 것인가

1. 고객이 이사했는데 지난 주문의 배송지도 바뀌었다

작은 문구점에서 주문을 관리한다고 하자. 고객 연락처를 고쳤더니 지난 주문의 배송지까지 바뀌고, 상품 가격을 올렸더니 지난달 매출도 달라졌다. 계산 프로그램이 틀린 것이 아닐 수 있다. 처음부터 지금의 정보와 그때의 사실을 같은 것으로 정의했기 때문이다.

데이터베이스 요구사항 분석은 이런 뜻의 혼동을 저장구조를 만들기 전에 풀어내는 일이다. 누가 무엇을 만들고 바꾸는지, 어느 시점의 값을 남기는지, 어떤 상태를 금지하는지 먼저 합의한다. 표와 열의 이름은 그 합의가 끝난 뒤 따라온다.

먼저 되찾을 세 문장

데이터는 기록, 메타데이터는 기록의 의미·구조·출처를 설명하는 데이터이며, 데이터 모델은 현실의 대상·속성·관계·제약을 추상화한 표현이다(데이터·정보·메타데이터·모델). 키는 행의 식별과 연결을 맡고, 무결성은 선언한 값·키·참조·업무규칙을 계속 지키는 성질이다(테이블·행·열·키·관계, 정규화·중복·무결성). 요구는 필요를 검증 가능한 문장으로 만든 것이며 기능·품질·제약을 구분한다(이해관계자·문제·요구사항, 기능·품질속성·제약).

데이터 요구를 분석한다는 것

데이터베이스 요구사항 분석은 업무 목적과 이해관계자의 필요를 데이터의 의미·범위·관계·변경 규칙, 품질·성능·보호 조건과 검증 가능한 산출물로 구체화하는 과정이다. 결과는 열 목록만이 아니라 요구사항 장부, 용어사전, 업무규칙, 사용 흐름과 검증 기준의 연결이다. 특정 제품이나 저장장치의 선택은 이 분석을 입력으로 받는 뒤 단계의 결정이다.

문구점의 지난 주문을 정확히 보여 달라는 요청은 아직 너무 넓다. 확정한 주문의 단가·수량·배송지는 이후 고객정보와 상품가격이 바뀌어도 주문 당시 값으로 조회되어야 한다로 바꾸면 무엇을 저장하고 어떤 변경을 시험해야 할지 보인다. 이 문장은 사례를 위해 정한 업무 계약이며 모든 상점의 공통 규칙은 아니다.

분석 결과는 모델과 시험 양쪽으로 흘러간다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

위의 근거를 모아 요구를 정한 뒤 용어·사실과 규칙·품질조건을 대조한다. 두 갈래는 모델 판단에 합류하며, 물리 선택도 같은 요구의 검증을 받아야 한다. 어떤 제품을 먼저 골라 업무규칙을 바꾸는 순서가 아니다.

같은 요구가 모델의 결정과 시험의 판정기준을 함께 낳는다. 모델에만 연결하면 구현이 규칙을 지키는지 확인하기 어렵고, 시험에만 연결하면 어느 구조가 요구를 책임지는지 찾기 어렵다. 수정할 때도 이 연결을 거꾸로 따라간다.

두 번의 주문으로 분석할 질문을 찾는다

이 장에서는 작성 중인 주문에 상품을 여러 줄 담고 확정하는 문구점을 사용한다. 배송비·세금·할인은 계산에서 제외하고 금액 단위는 원으로 고정한다. 표의 사람과 거래는 설명을 위해 만든 가상 사례다.

O101의 금액은 2×10,000 + 3×1,000 = 23,000원이고 O102는 1×12,000 = 12,000원이다. 현재 가격으로 과거 주문을 다시 계산하면 O101이 27,000원이 되어 기록의 의미가 바뀐다. 여기서 첫 질문은 어느 표를 만들지가 아니라 과거 주문의 단가는 다시 바뀌어도 되는가다.

화면·장부·담당자의 설명을 서로 대조한다

분석자는 주문 담당자, 고객정보 담당자와 운영 담당자가 같은 말을 다르게 쓰는지 확인한다. 인터뷰만 믿지 않고 주문서·조회 화면·입출력 파일·기존 데이터의 실제 값과 업무 절차를 함께 본다. 기존 데이터는 현재 구현의 흔적이지 업무상 허용되는 모든 상태를 증명하지 않는다.

자료마다 출처, 확인 시점, 업무 담당자와 신뢰 한계를 기록한다. 현재 데이터에 중복 이름이 없다는 관찰과 동명이인 가입을 금지한다는 업무규칙은 다르다. 표본에서 반례 하나를 발견하면 규칙 후보를 반박할 수 있지만, 반례가 없다는 이유만으로 미래에도 유일하다고 확정할 수는 없다.

앞에서 데이터 요구를 의미·규칙·검증 가능한 산출물로 구체화했다. 메타데이터는 기록의 뜻·구조·출처를 설명하는 데이터였다(데이터·정보·메타데이터·모델). 이제 같은 말을 같은 뜻으로 읽게 하는 명세를 나누어 본다.

2. 같은 이름보다 같은 뜻을 먼저 맞춘다

업무 용어사전은 업무에서 쓰는 말의 정의·동의어·구분되는 말·담당자를 모은 사전이다. 데이터 사전은 실제 데이터 항목의 의미, 형식·단위·허용값·필수 여부·출처와 변경 책임을 기록한 명세다. 코드집합은 업무상 허용한 상태나 분류를 정해진 값과 뜻으로 대응시킨 목록이다. 세 산출물은 각각 말의 의미, 항목의 표현, 허용 분류를 책임진다.

문구점의 가격은 상품의 현재 판매가격일 수도 있고 주문이 확정될 때 약속한 단가일 수도 있다. 따라서 용어부터 현재판매가격과 주문확정단가로 나누고, 둘 다 원 단위 정수이지만 변경 규칙이 다름을 데이터 사전에 남긴다. 이름을 통일한다는 이유로 다른 뜻을 하나의 항목으로 합치면 오히려 오류를 표준화하게 된다.

데이터 사전의 한 행이 막는 오해

필수라는 말에도 시점이 필요하다. 작성 중인 주문에는 배송지를 아직 입력하지 않았을 수 있지만 확정할 때는 반드시 필요하다. 수량 0은 아직 입력하지 않았다는 뜻이 아니라 개수가 0이라는 값이므로 빈값 대용으로 쓰지 않는다.

요구는 확인할 수 있는 데이터 조건으로 구체화했고, 무결성은 데이터가 정해진 값·관계·업무규칙을 지키는 성질이었다(정규화·중복·무결성). 이제 그 조건을 언제 적용하고 무엇을 예외로 볼지 문장으로 좁힌다.

규칙은 주어·조건·판정·예외를 가진 문장이다

데이터 업무규칙은 어떤 업무 상황에서 데이터가 만족해야 하는 관계·값·변경 제한을 판정 가능한 형태로 표현한 명제다. 규칙이 적용되기 시작하는 전제조건과 정상 규칙을 적용할 수 없는 예외조건을 함께 적는다. 주문은 정확해야 한다 대신 확정 상태의 주문에는 하나 이상의 주문항목이 있어야 한다고 쓰면 검사할 대상과 시점이 드러난다.

예외는 빈칸으로 남기지 않는다. 예를 들어 취소 주문의 수량을 0으로 덮어써도 되는지, 원수량을 보존하고 상태만 바꿀지에 따라 통계와 감사의 의미가 달라진다. 이 사례에서는 원주문을 보존하고 상태를 취소로 바꾸며 취소사유를 별도로 남기기로 한다.

문구점의 규칙을 일곱 문장으로 고정한다

1. R01 식별: 고객번호·상품번호·주문번호는 각 업무 대상을 유일하게 식별하며 이름의 유일성은 가정하지 않는다.
2. R02 관계: 주문 한 건은 고객 한 명에 속하고, 고객은 주문이 없어도 등록될 수 있다.
3. R03 거래값: 주문항목은 확정 당시 단가를 보존하며 현재 상품가격 변경으로 다시 계산하지 않는다.
4. R04 항목: 확정 주문은 하나 이상의 항목을 가지며 항목수량은 양의 정수다. 같은 상품을 한 주문의 여러 줄에 넣을 수 있다. 수량은 확정 전에만 직접 변경하며 확정 뒤에는 원수량을 보존한다.
5. R05 시간 의미: 주문 배송지는 그 주문의 사실이며 고객 현재주소 변경과 독립된다.
6. R06 상태: 작성중에서 확정 또는 취소로, 확정에서 취소로 바꿀 수 있지만 취소를 직접 확정으로 되돌리지 않는다. 취소는 원주문 값과 수량을 보존한 상태 변경이며 취소사유를 별도로 남긴다.
7. R07 계산: 할인·세금·배송비를 제외한 주문금액은 확정단가와 수량을 곱한 항목금액의 합이다.

R04의 같은 상품 여러 줄 허용 조건이 특히 중요하다. 같은 상품이 두 줄에 들어갈 수 있으므로 주문번호+상품번호만으로 항목을 식별할 수 없다. 다음 절에서는 주문 안의 항목번호를 추가해 이 규칙을 구조에 옮긴다.

값 규칙·관계 규칙·시간 규칙을 구분한다

모든 규칙을 입력값 검사 하나로 부르면 책임이 사라진다. 분석 단계에서는 어떤 범위의 사실을 함께 보아야 하는지까지 적고, 구체적인 데이터베이스 제약과 처리단위는 설계 단계에 넘긴다. 한 화면에서만 막는다고 다른 입력경로도 같은 규칙을 지킨다고 가정하지 않는다.

앞에서 요구의 분석 결과에 사용 흐름과 검증 기준도 포함된다고 설명했다. 이제 데이터가 있다는 사실에서 더 나아가, 어떤 업무가 그 기록을 만들고 사용하는지 점검한다.

누가 만들고 고치는지 빠지지 않게 본다

CRUD는 데이터의 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)라는 네 기본 사용을 묶은 말이다. CRUD 행렬은 업무 처리와 데이터 대상이 만나는 칸에 이 사용을 적어 생성·변경·조회 책임과 누락을 점검하는 표다. 표의 가로·세로 방향보다 칸의 의미와 범례가 일관되는지가 중요하다.

고객을 조회하는 업무는 많은데 생성하는 업무가 하나도 없다면 고객의 입력원이나 연계를 빠뜨렸을 수 있다. 반대로 생성만 있고 조회·후속 사용이 없다면 불필요한 수집인지 묻는다. 외부에서 받는 데이터라면 생성 칸이 비어 있다는 이유로 곧바로 오류로 판정하지 않고 외부 입력의 책임을 명시한다.

취소는 이 사례에서 삭제가 아니라 상태 수정이다

취소 업무가 D가 아닌 것은 R06에서 원주문 보존을 선택했기 때문이다. 이 표에 삭제가 없다고 고객이나 주문을 영구 보존한다는 뜻도 아니다. 보존 종료·정정·삭제 업무는 적용 근거와 책임을 확인한 별도 생명주기 요구로 추가해야 한다.

행렬의 R이 같아도 허용 역할과 목적은 다를 수 있다. 주문 담당자는 배송에 필요한 주소를 보지만 통계 담당자는 같은 정보를 볼 필요가 없을 수 있다. CRUD는 권한정책 자체가 아니라 권한 요구를 찾기 위한 입력이다.

데이터 모델은 현실의 대상·속성·관계·제약을 표현하며, 분석한 요구는 어떤 사실을 남길지와 변경 규칙을 정하는 입력이다(데이터·정보·메타데이터·모델). 앞의 가격 변경 사례를 이 두 관점으로 다시 읽으면 한 기록의 범위와 시점을 먼저 정해야 하는 이유가 보인다.

3. 한 기록이 무엇을 어느 시점에 말하는가

사실의 단위는 기록 한 건이 표현하는 대상·사건·범위다. 현재 사실은 지금 유효한 대상의 상태를, 이력 사실은 과거의 사건이나 당시 상태를 남긴다. 같은 값이라도 사실의 단위와 시점이 다르면 별도 의미를 가질 수 있다.

문구점에서 고객 한 명의 현재주소와 주문 한 건의 배송지는 처음에는 같은 문자열이다. 그러나 전자는 고객정보 변경에 따라 바뀌고 후자는 그 주문을 설명하므로 다른 사실이다. 이를 나누는 것은 조회 성능을 위해 같은 사실을 복사하는 비정규화와 구별해야 한다. 이 교재에서 반정규화도 이 의도적 비정규화와 같은 뜻으로 사용한다.

값은 같아도 변경 이유가 다르면 섞지 않는다

9월 2일 고객 C1의 현재주소를 A에서 B로 바꾼다. 이 사건 뒤에도 이미 확정한 O101의 배송지는 A이고, 다음 날 새로 확정하는 O102의 배송지는 B다. 마찬가지로 공책 P1의 현재가격은 12,000원이지만 O101의 확정단가는 10,000원이다.

이를 검사할 때 고객주소와 주문배송지가 항상 같아야 한다는 비교는 잘못된 규칙이다. 대신 고객정보 변경이 이미 확정한 주문값을 바꾸지 않아야 한다는 전후 비교를 쓴다. 무엇을 같은 사실로 볼지 먼저 정하지 않으면 정규화와 품질검사 모두 잘못된 값을 정상으로 만들 수 있다.

데이터가 맞아도 필요한 때 못 읽으면 요구를 놓친 것이다

사용 흐름에는 조회조건·정렬·결과크기·동시성·빈도와 변경량을 붙인다. 사례 요구를 최근 90일 주문을 고객별 최신순으로 20건씩 조회하고, 동시 조회 100건을 유지한 30분 시험구간에서 요청부터 결과 수신까지 p95 300ms 이내처럼 쓰면 물리 설계의 입력이 된다. 이 수치는 설명을 위해 정한 요구값이며 제품의 보장 성능이나 시험의 공식 권고값이 아니다.

p95와 동시성을 읽는 법. 응답시간의 p95는 측정값을 작은 순서로 정렬했을 때 95% 지점의 값이다. 이 절의 계산 연습은 보간 없이 올림(0.95×측정 건수)번째 값을 선택하는 방식으로 고정한다. 100건이면 95번째 값이 300ms 이하여야 하므로 평균만 300ms 이하인 결과로 이 요구를 통과시킬 수 없다. 실제 시험에서는 백분위수 계산 방식, 측정 구간, 성공·실패 요청의 집계 범위를 명시한다. 동시 조회 100건은 동시에 진행 중인 조회의 수이지 초당 100건을 처리한다는 뜻이 아니다. 응답시간과 처리량을 나누어 측정해야 한다(Google SRE의 지연시간·트래픽·느린 꼬리 설명).

용량은 예상 행 수의 근거부터 남긴다. 하루 주문 1,000건, 주문당 평균 3줄이면 1년 365일 동안 주문항목은 약 1,000×3×365 = 1,095,000행이다. 이는 논리적 건수 예상일 뿐이며 실제 저장 바이트는 열 길이·인덱스·이력·복제와 운영 여유를 반영하는 다음 물리 설계에서 계산한다.

보호 요구에는 수집 목적, 접근 역할, 보존·정정·삭제 조건과 감사 필요를 적는다. 허용 중단과 허용 데이터 손실도 업무가 받아들일 수 있는 값으로 확인한다. 법정 보존기간 같은 외부 의무를 임의의 숫자로 채우지 않고 적용대상·공식 근거·확인일이 있는 요구로만 확정한다.

충돌은 조용히 덮지 않고 결정과 미결을 남긴다

영업 담당자가 고객정보는 즉시 최신값으로라고 하고 주문 담당자가 당시 거래정보는 그대로라고 해도 반드시 모순은 아니다. 고객 현재 사실과 주문 당시 사실로 범위를 나누면 둘 다 충족할 수 있다. 반면 같은 데이터에 같은 조건으로 즉시 삭제와 계속 보존을 요구하면 실제 충돌이므로 근거와 결정권자를 확인해야 한다.

분석자는 채택안, 기각안, 결정 이유와 영향받는 요구 ID를 남긴다. 이 사례는 고객주소를 주문마다 최신값으로 따라 바꾸는 안을 기각하고 주문 배송지를 독립적으로 보존한다. 결정을 못 한 항목은 가정을 확정 사실로 숨기지 않고 미결 상태·담당자·결정기한을 기록한다.

정상·경계·반례를 읽으면 규칙의 빈틈이 보인다

이 표는 독자가 실행해야 하는 실습이 아니라 분석자가 어떤 질문을 했는지 보여 주는 완성 사례다. 정상 예만 있으면 없는 항목, 바뀐 현재값, 허용되지 않은 전환을 놓친다. 시험문항에서도 규칙 한 줄과 그 규칙을 깨는 반례를 함께 쓰면 판단 근거가 분명해진다.

조건을 바꾸어 확인하기. 작성중 주문 O103에 공책 P1을 1번 줄 2개, 2번 줄 1개로 담고 각 줄의 확정단가를 12,000원으로 정했다고 하자. 배송지 B로 확정한 다음 현재가격을 15,000원으로 바꾸고 주문을 취소한다. 취소 뒤 원주문의 두 줄·금액·배송지는 어떻게 남아야 하며, 취소 업무의 CRUD 기호는 무엇인가? 기존 O101의 숫자를 옮겨 쓰기 전에 R03~R07을 순서대로 적용해 본다.

먼저 풀어 본 뒤 해설과 교정 보기

해설과 교정. 확정 직전 두 줄은 R04가 허용하므로 합치거나 거절할 이유가 없다. 확정금액은 2×12,000 + 1×12,000 = 36,000원이고, 가격변경 뒤에도 R03에 따라 그대로다. 취소는 R06에 따라 상태를 바꾸고 사유를 남기는 U이며 두 줄의 수량·단가와 배송지 B는 보존한다. 45,000원은 현재가격으로 과거값을 다시 계산한 오답이고, 0원·두 줄 삭제·D는 취소를 원기록 제거로 읽은 오답이다. 전자는 현재 사실과 과거 사실의 전후 비교로, 후자는 R06 상태 규칙과 CRUD 행렬로 돌아가 고친다. 이 예의 원주문 금액과 취소 주문을 매출 집계에 포함할지의 정책은 별개이므로 집계 정책은 새 요구로 확인한다.

분석과 설계는 답하는 질문이 다르다

분석 중 모델을 스케치해 애매함을 찾을 수는 있다. 다만 스케치의 열 이름이나 제품 기능을 업무 요구의 근거로 거꾸로 사용하지 않는다. 물리 설계의 자료형·인덱스 세부 선택은 물리 DB 설계·인덱스·파티션이 담당한다.

4. 요구를 확정하고 다음 설계로 넘긴다

1. 범위와 근거 수집: 업무 목적·담당자·연계 경계와 기존 자료의 출처·시점을 기록한다.
2. 뜻과 사실 단위 합의: 용어·단위·코드·필수 시점, 현재 사실과 이력을 구분한다.
3. 규칙 작성: 식별·관계·값·상태·집계 규칙을 전제·예외와 함께 문장으로 적는다.
4. 사용과 품질 분석: CRUD, 역할·입출력, 조회조건·빈도·건수·성능·보호·복구 요구를 적는다.
5. 충돌·미결 처리: 근거를 비교해 채택·기각·보류와 책임자를 남긴다.
6. 모델·검증 연결: 요구별 설계 대상과 정상·경계·반례의 기대 결과를 연결한다.
7. 기준선 관리: 합의한 버전·결정자·미결 목록을 고정하고 변경 시 모델·시험·기존 데이터 영향을 다시 확인한다.

이 절차는 여러 1차 자료의 요구 명세 원리를 데이터 분석에 적용한 편집상 종합이다. 한 표준이 모든 조직에 이 일곱 단계를 같은 순서로 의무화한다고 주장하지 않는다. 실제 업무 특성에 따라 반복하되 뜻·규칙·사용·검증의 빠진 연결이 없어야 한다.

분석 실패는 나중에 데이터 오류로 나타난다

잘못된 요구가 구현된 뒤에는 명세만 고쳐서 끝나지 않는다. 이미 저장된 값이 잘못된 의미로 바뀌었는지 조사하고, 복구 가능 범위·원천 근거·재검증 대상을 정해야 한다. 데이터의 정정 이력도 새로운 사실이므로 변경 사유와 책임을 잃지 않게 한다.

공식 요구를 답안의 네 층으로 묶는다

데이터베이스 요구사항 분석의 답안은 업무·데이터·품질 요구를 함께 다룬다. 답안은 근거와 범위 → 뜻·규칙·사용 → 품질·충돌 → 모델·검증·변경관리의 인과를 가져야 한다. 용어사전이나 CRUD 하나만 설명한 것은 전체 분석의 부분 증거다.

정의에서는 분석의 입력과 산출물을, 구조에서는 각 산출물의 연결을 쓴다. 판단에서는 현재와 이력, 규칙과 표본, 분석과 물리 설계를 구분한다. 실패에서는 모호성·상태 누락·품질조건 누락·추적 단절을 반례와 검증으로 통제한다.

5. 시험에서는 설명·분석·검증을 연결한다

현재 기출 장부에는 81회 1교시 9번의 요구사항 모호성 제거, 69회 2교시 6번의 사용자 자료·업무규칙에서 대상 도출, 133회 1교시 7번의 CRUD 행렬 목적·표현이 관련 후보로 있다. 여기서는 원문 전체와 표를 전재하지 않고 논점만 연결한다. 원문·범위·현행성의 독립 사람 승인은 아직 없다.

모호성 제거는 이 절의 뜻·조건·반례 설명으로, CRUD는 생성·변경 책임 점검으로 이어진다. 업무 대상으로 변환하는 세부 과정은 다음 절과 함께 읽는다. 아래 두 문제는 기출 복원이 아닌 자체 제작 문제이므로 실제 기출의 문구나 난이도를 재현했다고 표시하지 않는다.

10점: 분석 산출물과 모호성 제거

데이터베이스 요구사항 분석의 목적·주요 산출물을 설명하고, 요구의 모호성을 제거하는 방법과 검증 기준을 제시하시오.

목적·산출물과 방법·검증을 모두 다뤄야 한다. 도구 이름을 나열하기보다 가격의 현재값과 주문 당시 값이 달라지는 반례 하나로 모호성이 어떻게 제거되는지 보여 준다.

10점 풀이의 목차·도식·답안 보기

10점 목차

1. 분석의 목적과 입력·산출물
2. 용어·단위·현재와 이력의 구분
3. 규칙의 주어·조건·판정·예외
4. 정상·경계·반례와 모델·시험 추적
5. 충돌·미결·변경관리 결론

10점 도식

앞의 같은 요구를 모델과 검증까지 연결한다 그림을 R03에 적용하면 다음 두 증거가 함께 남는다.

구체화한 요구	모델에 남길 사실	시험에서 확인할 결과
지난 주문을 정확히 조회한다: 확정단가는 현재가격 변경과 독립이다.	주문항목의 당시 단가	가격변경 뒤에도 O101은 23,000원이다.

10점 모범답안

데이터베이스 요구사항 분석은 업무 필요를 데이터 의미·범위·관계·변경 규칙과 품질·보호·검증 조건으로 구체화하는 과정이다. 담당자·업무자료·기존 데이터를 대조해 요구 장부, 용어사전, 업무규칙, 사용 흐름과 검증 기준을 연결한다.

모호성을 줄이려면 같은 말의 다른 뜻, 단위, 필수 시점과 현재·이력 사실을 구분한다. 예를 들어 현재판매가격과 주문확정단가는 서로 다른 사실이므로 상품가격 변경이 과거 주문금액을 바꾸지 않게 요구를 적는다. 규칙은 대상·전제·판정·예외를 명시하며, 표본에 중복이 없다는 관찰을 업무상 유일성으로 승격하지 않는다.

검증은 정상·경계·반례의 기대 결과를 요구 ID에 연결한다. 현재가격 변경 후에도 O101의 금액이 23,000원인지 확인하고, 같은 요구가 어느 모델과 시험에 반영됐는지 추적한다. 충돌은 근거·결정권자와 함께 조정하며 미결은 담당자·기한을 남긴다. 확정한 기준선이 바뀌면 모델·시험·기존 데이터의 영향을 재검토한다.

25점: 문구점의 요구분석 결과를 만든다

고객·상품·주문을 관리하는 문구점의 데이터베이스 요구사항을 분석하시오. 현재정보와 거래이력의 구분, 용어·업무규칙·CRUD, 품질·보호 조건과 모델·검증의 추적방안을 제시하시오.

절차만 외워 적지 말고 각 단계가 만든 실제 결정 하나를 넣는다. 상품가격·고객주소 변경, 같은 상품의 복수 주문 줄, 취소와 삭제의 차이를 모두 처리하면 뜻·식별·상태·시간 요구가 연결된다.

25점 풀이의 목차·도식·답안 보기

25점 목차

1. 분석 범위·근거·입력과 산출물
2. 용어·단위·코드·필수 시점
3. 사실 단위와 현재·거래이력 분리
4. 식별·관계·값·상태·계산 규칙
5. CRUD·입력원·업무 책임
6. 품질·성능·보호·복구 요구
7. 충돌·반례검증·모델추적·기준선 관리
8. 근거 수집부터 의미·규칙·사용·품질·검증으로 이어지는 전체 분석

25점 도식

고객·주문·상품 담당자의 설명을 자료·값과 대조하여 요구 장부에 뜻·규칙·CRUD·품질·보호를 남긴다. 앞의 연결 그림에서 각 요구의 모델과 시험을 다음처럼 함께 추적한다.

요구 ID·규칙	모델·처리 책임	검증 결과
R03 확정단가 보존	주문항목	가격변경 후 과거금액 동일
R04 동일상품 여러 줄	항목번호	두 줄 허용, 수량 0 거절
R06 취소 원기록 보존	상태규칙	취소→확정 직접전환 거절

기준선·미결·변경영향을 관리하며 모델과 검증을 함께 갱신한다.

25점 모범답안

데이터베이스 요구사항 분석은 업무 목적을 데이터의 의미·범위·관계·변경·품질·보호 조건과 검증 가능한 산출물로 변환한다. 문구점의 고객·상품·주문 담당자와 주문서·화면·기존 데이터·외부 입력을 대조하고 출처·시점·책임자를 기록한다. 결과는 요구 장부, 용어사전, 업무규칙, CRUD와 검증 기준으로 연결한다.

용어사전은 현재판매가격과 주문확정단가를 구분한다. 데이터 사전에는 원 단위, 수량의 양의 정수 조건, 확정 시 배송지 필수, 작성중·확정·취소의 허용 상태를 명시한다. 빈값을 수량 0으로 대체하거나 같은 이름을 같은 의미라고 가정하지 않는다.

사실의 단위는 고객, 상품, 주문과 주문의 한 항목으로 나눈다. 고객 현재주소와 주문 당시 배송지, 상품 현재가격과 확정단가는 변경 이유가 다르므로 별도 사실로 취급한다. 9월 2일 현재가격·주소가 바뀌어도 O101의 배송지 A와 금액 23,000원은 유지되어야 한다.

업무규칙은 고객·상품·주문번호의 유일성, 주문의 고객 필수, 확정 주문의 한 개 이상의 항목, 양의 수량, 현재정보 변경과 거래이력의 독립을 포함한다. 같은 상품이 한 주문의 여러 줄에 들어갈 수 있으므로 상품번호만으로 항목을 식별하지 않는다. 취소는 원값을 보존한 상태 변경이며 취소에서 확정으로의 직접전환은 금지한다. 주문금액은 사례에서 제외한 세금·배송비·할인 없이 확정단가와 수량의 곱을 합한 값이다.

CRUD로 고객 등록·수정, 상품가격 변경, 주문 작성·확정·취소·조회와 각 대상의 사용을 대조한다. 생성 없는 대상은 외부 입력이나 책임 누락인지, 사용 없는 수집은 필요한지 확인한다. 취소의 U와 물리 삭제의 D를 구별하고 보존 종료·정정·삭제는 적용 근거와 별도 책임을 둔다.

품질 요구에는 조회 대상·정렬·결과크기·동시성·시간창을 붙인다. 하루 1,000건의 주문과 평균 3줄이면 연간 항목 약 1,095,000행이라는 가정을 물리 설계에 넘기되 이를 저장 바이트로 오인하지 않는다. 접근 목적·역할, 보존·삭제 근거, 허용 중단·데이터 손실과 감사 요구도 확인한다.

현재와 이력의 뜻을 나눠 충돌을 해소하고 남은 미결은 담당자·기한을 기록한다. 동명이인, 가격변경, 항목 없는 확정, 수량 0, 취소 역전환을 반례로 검증한다. 각 요구 ID를 모델의 책임 대상과 시험의 기대 결과에 연결하고, 합의한 기준선이 바뀌면 모델·시험·기존 데이터에 미치는 영향을 함께 재검토한다.

전체 분석은 담당자·자료의 근거를 수집하고 용어·시점·사실 단위를 합의한 뒤 업무규칙·CRUD·품질·보호 조건을 확정하는 연결 과정이다. 충돌·미결을 드러내고 각 요구를 모델과 정상·경계·반례의 기대 결과에 연결하여 기준선을 만든다. 규칙 하나나 열 목록만 완성하는 데 그치지 않고 이 연결 전체를 변경 시에도 유지해야 분석의 범위를 충족한다.

출처와 검토 상태

요구 명료성·검증·추적 원리는 NASA Systems Engineering Handbook 부록 C~E와 NASA Software Engineering Handbook의 요구사항 지침을 근거로 사용했다. 데이터 항목의 의미·단위·형식·허용값을 명세하는 근거는 후자가 직접 연결한 NASA SWE-110 데이터 사전 지침 §3에서 확인했다. 이 구판 지침들의 안정적인 요구공학 원칙만 적용하며 NASA의 현행 의무나 한국의 법적 의무로 제시하지 않는다.

CRUD 네 동작은 Microsoft의 CRUD 공식 설명, 처리와 데이터 사용의 대응은 IBM의 CRUD 행렬 공식 설명, 현재값과 과거 버전의 구분은 Microsoft의 시간 데이터 공식 설명을 확인했다. HTTP 동작 대응이나 제품 기능을 모든 데이터베이스에 일반화하지 않으며 주문시점 사실의 보존을 시스템 변경이력과 동일시하지 않는다.

문구점 규칙·숫자·표·도식과 분석 절차의 사례 적용은 직접 작성한 편집상 종합이다. 2026-09-05에 근거 위치를 확인한 집필 후보이며 원문 보존본·권리·독립 기술검토와 초보 독자 검증은 승인되지 않았다. 실제 법정기간이나 제품 성능을 이 사례의 숫자로 대신하지 않는다.

30초 정리

데이터 요구는 이름·열 목록보다 뜻·시점·규칙·사용·검증의 계약이다. 현재정보와 거래 당시 사실을 구분하고, 정상값뿐 아니라 경계와 반례로 모호성을 찾는다. 다음 절에서는 이 계약을 대상·관계·키·표로 옮기며, 같은 뜻을 잃지 않고 나누었다는 근거까지 확인한다.

추가 연습: 평균으로 p95 요구를 판정해도 될까? 앞의 p95 300ms 이내라는 시간 요구만 따로 검산한다. 정한 측정 구간에 정상 완료된 조회 100건이 있고, 94건은 각각 240ms, 4건은 각각 310ms, 2건은 각각 900ms 걸렸다. p95는 이 절에서 정한 보간 없는 순위 방식으로 계산한다. 평균과 p95를 구하고 시간 요구 충족 여부를 설명하라. 이 표본만으로 30분 동안의 동시 조회 100건 조건까지 검증했다고 주장할 수 있는지도 구분하라.

추가 연습의 계산과 판정 보기

평균은 (94×240 + 4×310 + 2×900)÷100 = 256ms다. 정렬하면 1번째부터 94번째까지는 240ms, 95번째부터 98번째까지는 310ms, 99번째부터 100번째까지는 900ms이므로 p95는 95번째 값인 310ms다. 평균은 300ms보다 작지만 p95는 크므로 시간 요구를 충족하지 못한다. 평균 하나가 느린 요청을 가릴 수 있다는 반례다. 이 표본은 응답시간 계산 연습에 필요한 자료만 주며, 실제 동시 진행 수나 30분 시험구간의 유지 여부는 주지 않는다. 따라서 원래 성능 요구 전체의 부하시험을 완료했다고 볼 수 없다.