데이터 요구의 정의와 생명주기

핵심 요약

정보 요구 사항은 ‘화면에 항목을 추가해 달라’는 해결책 요청만을 뜻하지 않는다. 업무에서 어떤 의사결정을 위해 어떤 정보가 어떤 조건과 시점에 필요하며, 무엇을 충족하면 요구가 실현되었다고 판단할지를 표현한다. 요구는 조사부터 변경·폐기까지 상태와 근거를 관리하며, 분석 결과는 이후 데이터 모델·인터페이스·구현·시험으로 추적될 수 있어야 한다.

학습 목표

• 정보 요구 사항을 업무 필요·정보·제약·수용 기준 관점에서 정의한다.
• 업무 요구, 정보 요구, 해결책·설계안을 구분한다.
• 요구 속성과 생명주기의 주요 활동을 연결한다.
• 좋은 요구의 품질 특성과 기준선의 의미를 판정한다.

1. 개념 설명

1.1 정보 요구 사항

업무 목표나 이해관계자의 필요를 충족하기 위해 제공·관리되어야 할 정보와 그 제약·조건을 서술한 것이다. 정보의 의미, 사용 목적, 생성·사용 시점, 범위, 정확성·완전성 같은 기준, 관련 업무 규칙을 포함할 수 있다.

1.2 요구와 해결책의 구분

• 요구: “상담원은 통화 시작 시 최근 30일의 미처리 주문과 상태를 확인할 수 있어야 한다.”
• 해결책 후보: “상담 화면 오른쪽에 목록 팝업을 추가한다.”

첫 문장은 업무 목적과 필요한 정보·시점을 설명하고, 둘째 문장은 하나의 구현 방식이다. 요구 분석에서는 성급하게 특정 화면·테이블·제품으로 고정하지 않고 대안 설계가 가능하도록 필요를 명확히 한다.

1.3 요구 속성

대표 관리 항목은 식별자, 제목, 설명, 유형, 출처, 요청자·소유자, 관련 업무, 중요도·우선순위, 근거, 상태, 버전, 가정·제약, 수용 기준, 관련 요구, 변경 이력이다. 모든 조직이 동일한 필드명을 써야 하는 것은 아니지만 식별·판단·추적에 필요한 정보를 갖춰야 한다.

1.4 요구 품질

좋은 요구는 필요한 범위가 빠짐없이 표현되고, 한 가지 의미로 이해되며, 다른 요구와 충돌하지 않고, 실현 가능하며, 결과를 검증할 수 있고, 출처와 후속 산출물로 추적 가능해야 한다. 품질 속성은 서로 연관되지만 동일하지 않다.

2. 요구 생명주기

출처·이해관계자 식별
        ↓
수집 → 정리·구조화 → 통합·합의
        ↓
분석 대상 정의 → 상세화 → 이해관계자 확인
        ↓
명세화·검토·승인(기준선)
        ↓
상관분석·검증 → 추가/삭제 후보 도출
        ↓
구현·시험·운영과 추적
        ↓
변경 요청·영향 분석·재승인 또는 폐기

이 흐름은 이해를 위한 논리적 구조이며 모든 활동이 한 번씩 순차적으로만 수행되는 것은 아니다. 상세화 중 출처가 부족하면 재조사하고, 상관분석에서 누락이 발견되면 요구를 추가하여 다시 검토한다.

3. 요구의 구성과 관계

요구는 하나의 문장만으로 끝나지 않고 위 속성과 관계로 관리된다. 다만 데이터 표준 단어·도메인과 물리 설계의 상세 규칙은 후속 파트의 책임이다.

4. 사례 판별

요청: “대시보드에 예쁜 그래프를 추가해 주세요.”

이 문장만으로는 정보 요구가 충분하지 않다. 누구의 어떤 의사결정을 지원하는지, 필요한 지표의 정의와 기준 시점, 대상 범위, 갱신 주기, 비교 기준, 허용 오차, 수용 기준을 조사해야 한다. 그래프는 표현 대안 중 하나이다.

상세화 예시: “영업 관리자는 매 영업일 오전 9시에 전일 기준 지역별 순매출과 목표 대비 달성률을 확인하여 부진 지역을 식별한다. 취소·환불은 순매출에서 제외하고, 원천 거래 마감 후 30분 이내 갱신되어야 한다.”

이 예시는 정보 내용·사용자·시점·규칙을 포함하지만 최종 명세서의 모든 필수 항목을 대신하지는 않는다.

5. 비교와 구분

시험 판단 포인트

• 정보 요구 사항은 업무 필요를 정보 내용·조건·제약과 함께 표현한다.
• 요구와 구현 해결책을 분리해야 대안 설계와 정확한 검증이 가능하다.
• 요구에는 출처·소유자·우선순위·상태·버전·수용 기준·추적 관계가 관리될 수 있다.
• 요구 생명주기는 반복 가능하며 승인된 버전은 변경 통제의 기준선이 된다.
• 완전성·명확성·일관성·실현 가능성·검증 가능성·추적 가능성을 구분한다.

자주 틀리는 부분

• 사용자가 특정 화면을 요청했다는 이유로 그것을 분석이 끝난 정보 요구로 보지 않는다.
• 요구 수집 후 바로 설계로 넘어가 정리·통합·확인·검증을 생략하지 않는다.
• 우선순위와 상태, 버전과 변경 이력을 같은 관리 항목으로 혼동하지 않는다.
• 요구 기준선을 변경 금지 상태로 오해하지 않는다.