2과목 — 데이터 요건 분석

10문항 / 20 %. 공식 출제 범위는 넷이다.

정보요구사항 개요 및 관리
정보요구사항 조사    수집 · 정리 · 통합
정보요구사항 분석    상세화 · 확인
정보요구 검증        상관분석 · 도출 · 보완

절차 위주 과목이라 뼈대만 잡으면 가장 빨리 점수가 오른다.

---

1부 · 정보요구사항 개요 및 관리

1. 이 과목이 다루는 것

앞 과목이 "조직 전체를 어떤 틀로 볼 것인가" 였다면, 이 과목은 "그래서 무엇이 필요한지 어떻게 알아내는가" 를 다룬다.

현업의 말을 데이터의 언어로 바꾸는 것이 이 과목의 전부다.

✗  업무 요구를 화면 레이아웃으로 확정한다
✗  업무 요구를 프로그램 함수 목록으로 변환한다
✗  업무 요구를 서버 사양으로 환산한다

화면·함수·서버는 데이터가 아니다.

2. 정보요구사항의 유형

DAsP는 데이터 요구를 주로 다루지만 셋을 구분하는 문제가 나온다.

3. 요구사항이 갖춰야 할 특성

검증 가능성이 특히 중요하다. 확인할 수 없는 요구는 완료 여부를 판정할 수 없으므로 요구사항으로서 성립하지 않는다.

4. 요구사항 관리

4.1 기준선(Baseline)

어느 시점의 요구사항을 공식적으로 확정한 상태를 말한다.

기준선 설정 전   자유롭게 추가 · 수정 가능
기준선 설정 후   변경하려면 공식 절차를 거쳐야 함

기준선이 없으면 요구가 계속 바뀌어 무엇을 만들고 있는지 아무도 모르게 된다. 반대로 아예 못 바꾸게 하면 업무 변화를 담지 못한다. 통제된 변경이 목적이다.

4.2 변경 관리 절차

변경 요청 접수  →  영향도 분석  →  심의·승인  →  반영  →  이력 기록

영향도 분석이 승인보다 먼저다. 얼마나 영향을 주는지 모르는 상태로는 승인 판단을 할 수 없다.

4.3 추적성 (Traceability)

하나의 요구가 어디에서 왔고 어디로 갔는지 따라갈 수 있어야 한다.

요건 추적 매트릭스(RTM) 가 이 연결을 표로 관리한다.

---

2부 · 정보요구사항 조사

수집  →  정리  →  통합

5. 수집 — 네 가지 기법

5.1 어떻게 구분해 외우는가

깊이가 필요하다     →  인터뷰
합의가 필요하다     →  워크숍
범위가 넓다         →  설문
현재 상태를 알아야   →  문헌 조사

5.2 인터뷰 진행

준비   대상자 선정 · 질문지 작성 · 사전 자료 검토
진행   개방형 질문으로 시작 → 구체화 → 확인 질문
정리   면담 직후 · 원문 보존 · 확인 필요 사항 표시
확인   정리 결과를 면담자에게 회신해 검증

면담자의 표현을 분석가의 해석으로 대체하면 안 된다. 현업이 "거래처를 관리한다" 고 했는데 "공급사를 관리한다" 로 바꿔 적으면, 나중에 확인할 때 현업이 자기 말을 못 알아본다. 원래 표현을 남기고 해석은 따로 표시한다.

5.3 문헌 조사 대상

· 현행 시스템의 화면과 출력물
· 업무 매뉴얼과 규정
· 기존 장표와 대장
· 현행 데이터베이스 구조
· 관련 법규

6. 정리

수집한 요구를 다룰 수 있는 형태로 만든다.

· 중복 제거
· 표현 통일 (같은 것을 같은 말로)
· 유형 분류 (기능 / 데이터 / 비기능)
· 출처 기록 (누가 언제 요청했는가)
· 모호한 것 표시 (확인 필요 목록)

7. 통합

7.1 왜 통합하는가

영업부   "고객 연락처를 보고 싶다"
고객센터 "상담할 때 전화번호가 필요하다"
물류부   "배송 안내 문자를 보낼 번호가 있어야 한다"

세 요구가 같은 데이터를 가리킨다. 따로 처리하면 연락처를 세 군데에 만들게 된다.

통합의 목적 — 유사·중복 요구를 하나로 모아 일관성을 확보하는 것.

7.2 자주 나오는 오답

✗  부서별로 별도 시스템을 만든다        → 통합의 정반대
✗  요구 건수를 늘려 규모를 키운다       → 통합은 줄이는 활동
✗  우선순위를 없애 모두 동일 처리       → 우선순위는 별개 활동

---

3부 · 정보요구사항 분석

상세화  →  확인

8. 상세화

정리된 요구를 데이터 요건 수준까지 구체화한다.

"월별 매출을 보고 싶다"
        ↓ 무엇을 관리해야 이 요구가 충족되나
주문 (주문일자, 주문금액, 주문상태)
상품 (상품코드, 상품명)
        ↓
관리 대상 · 항목 · 발생 시점 · 보관 기간 정의

8.1 상세화 항목

8.2 우선순위 결정

· 업무 중요도
· 사용 빈도
· 구현 난이도
· 다른 요구와의 의존 관계
· 법적 의무 여부

9. 확인

상세화한 결과가 원래 요구와 맞는지 현업에게 검증받는다.

✓  현업 검토 회의
✓  프로토타입·샘플 화면 제시
✓  실제 업무 사례 대입
✓  체크리스트 점검

✗  분석가끼리만 검토하고 끝냄

---

4부 · 정보요구 검증

상관분석  →  추가·삭제 요구 도출  →  보완 및 확인

10. 상관분석 — CRUD 매트릭스

업무 기능과 데이터를 격자로 놓고 어떤 기능이 어떤 데이터를 어떻게 다루는지 표시한다.

C  Create  생성      R  Read    조회
U  Update  수정      D  Delete  삭제

11. 상관분석으로 무엇을 발견하는가

시험이 묻는 것은 표를 그려서 무엇을 찾아내는가이다.

핵심 — 상관분석은 빠진 것과 남는 것을 찾는 도구다. 성능 측정이나 인원 산정과는 아무 관련이 없다.

12. 추가·삭제 요구 도출

상관분석 결과를 근거로 요구를 조정한다.

추가    생성자 없는 데이터에 대해 → "이 데이터는 누가 만드나요?"
        기능 누락에 대해        → "이 기능은 어떤 데이터를 쓰나요?"

삭제    사용되지 않는 데이터     → "이것을 쓰는 업무가 있나요?"
        근거 없는 데이터        → 관리 대상에서 제외

13. 보완 및 확인

· 도출된 추가·삭제 요구를 현업에 확인
· 확인 결과를 요구사항 목록에 반영
· 최종 요구사항을 기준선으로 확정
· 추적 매트릭스를 갱신

---

5부 · 현행 분석 (As-Is)

14. 무엇을 보는가

· 현재 운영 중인 시스템의 데이터 구조
· 실제로 쓰이는 코드 체계와 명명 방식
· 시스템 간 데이터 연계 현황
· 중복 보관되고 있는 데이터
· 실제 데이터의 품질 상태

15. 왜 필요한가

목표 상태만 그리면 거기까지 어떻게 가는지 알 수 없다.

As-Is 파악  →  To-Be 설계  →  차이(Gap) 도출  →  이행 과제 수립
                                  ↑
                        As-Is 없으면 여기가 비어 버린다

이행 계획은 차이에서 나온다.

---

16. 흔히 틀리는 지점

---

17. 한 줄 정리