[DAsP] 2.데이터 요건 분석 요약,정리

1. 정보 요구 사항

• 사용자가 일상적으로 수행하는 업무의 개선 사항이나 신규 개발 사항으로 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용

 

 

2. 정보 요구사항 유형별 관리 기준 및 정의

유형	구분	설명
외부 인터페이스 요건	정의	시스템의 모든 입출력에 관한 요건. 대외기관으로의 송/수신 입출력 방식이 추가/변경 되었을 경우 발생
	관리 기준	중복성	기존에 동일한 형태의 인터페이스 존재하는지 체크
		표준 준수도	인터페이스 관련된 표준이 존재할 경우, 그에 적합한 형태로 제공해야 함
	관리 방법	항목 이름, 목적 설명, 입력의 원천 및 출력 방향, 유효 범위, 시간, 다른 입출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리되어야 함
기능 개선 요건	정의	입력을 받아들여 처리하고 출력을 만들어내는 주요 활동 및 프로세스에 대한 요건
	관리 기준	불가변성	기능 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안 요청해야 함
		범용성	많은 사용자가 편리하게 사용할 수 있는 요건을 우선적으로 요청해야 함
	관리 방법	입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응, 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어야 함
성능 개선 요건	정의	사용자가 원하는 성능 개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요 시한 등이 있음
	관리 기준	실현 가능성	해당 성능 개선 요구 사항이 현행 기술수준과 서비스 특성을 고려할 때 구현 가능한 요건인지 확인 후 제시되어야 함
		측정 가능성	측정이 불가능한 모호한 형태로 요건이 제시되면 안됨
	관리 방법	각 기관의 서비스 특성을 고려하여 정적/동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시 관리
보안 개선 요건	정의	중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근 통제(제한 구역, 통제 구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건
	관리 기준	불가변성	보안 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청해야 함
		실현 가능성	해당 보안 개선 요구 사항이 현행 기술과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인 후 제시되어야 함
	관리 방법	보안 관리가 필요한 정보에 대한 등급 관리, 해당 등급 별 접근 가능한 이용자 등급 관리, 접근 방식에 있어서 접근 통제 기준 및 사용 통제 기준 제시되어야 함. 해당 기준에 따라 모니터 작업을 통해 안정적 서비스 제공될 수 있도록 관리해야 함

 

 

 

3. 정보 요구 사항 업무 흐름 프로세스(순서)

• 요구 사항 발송
• 요구 사항 수렴
• 요구 사항 검토
• 영향도 분석
• 공식화
• 반영 작업 계획 수립

 

 

4. 정보 요구 사항 생명주기 모형

요구 사항을 명확하게 정의하고 개발하기 위해 필수적으로 진행할 단계

• 정보 요구 사항 도출
• 정보 요구 사항 분석 및 정의
• 정보 요구 사항 명세화
• 정보 요구 사항 검증

 

 

5. 정보 요구 사항 역할별 담당 업무

• 사용자 : 정보 요구 사항 정의 및 상세화/ 변경 요청/ 반영을 위한 미팅/ 반영 여부 확인, 미결 사항에 대한 의사결정 실시
• 담당자 : 요구 사항 접수, 기본 검토, 반영 여부 결정을 위한 사용자와 미팅, 처리 방식 및 처리 기한 결정, 담당자 수집 및 요건 협의 주도, 테스트 및 검증, 반영 결과 통보
• 데이터 아키텍처 전문가 : 정보 요구 사항에 대한 표준.데이터베이스.애플리케이션 영향도 분석 및 보고, 요구 사항에 대한 표준 준수 여부 체크, 계획 수립

 

 

6. 사용자 정보 요구 사항 수집을 위한 다양한 소스 형태

• 관련 문서 수집
  • 기존문서를 통해 현재 시스템이 동작하는 방법이나 앞으로 필요한 것을 알 수 있음.
  • 시스템 비즈니스 프로세스, 요구 사항 명세서, 경쟁사 분석 등의 문서
• 사용자 면담을 통한 수집
  • 분석가가 특정 관점에서의 업무 요건이나 업무 절차를 조사하기 위하여 실무자와 대면하여 질의와 응답을 통해 정보 수집
  • 특히 프로세스와 프로시저에 대한 이해를 얻기 위한 준비 단계 또는 워크숍 진행을 돕기 위한 준비 단계에 유용함
  • 피면담자의 수에 따라 개인 면담/ 집단 면담(워크샵)으로 구성
  • 면담 조사 방식 (대상자에 적용되는 질문의 유형과 순서에 따라 구분)
    • 피라미드 구조 : 피라미드 꼭대기에서 밑면으로 내려오는 형태의 질문. 구체적이며 선택적인 질문으로 시작하여 일반적이고 서술적인 질문으로 진행. 면담 대상자로 하여금 아이디어 발굴에 도움을 주거나 주제에 대한 논의를 부담스럽게 느낄 때 사용
    • 퍼널 구조 : 피라미드 구조아 상반되게 일반적이고 서술적인 질문으로 시작하여 점차 구체적이고 선택적인 질문으로 진행. 감정적이거나 자신의 아이디어를 강조하고 싶어하는 사람이나 면담조사에 부담을 느낄 때 사용
    • 다이아몬드 구조 : 피라미드 구조 + 퍼널 구조. 피라미드 형태의 진행이 이루어지고 난 후, 다시금 퍼널 형태의 진행으로 마무리
  • 면담팀 구성
    • 각 그룹 별 2인 이상 구성원 배정
    • 면담자 : 면담 진행, 면담 취지 설명 및 질문
    • 기록자 : 면담자 답변내용 기록(요약없이), 기록 위해 업무 사전 지식 숙지 필요
    • 관찰자 : 면담 목적에 맞게 진행하고 있는지 관찰, 면담 주제에 벗어나는 경우 목적에 맞게 면담이 진행되도록 가이드
• 워크숍을 통한 수집
  • 목적 달성을 위해 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의.
  • 정치/개인적 요소의 영향을 피하면서 다양한 정보의 원천으로부터 정보의 빠른 추출이나 공유를 필요로 하는 경우나, 단순 회의나 토론 이상의 무언가를 요구하는 상황 등에 사용
  • 워크숍의 주요 목적
    • 경영층 또는 현업 부서장의 공통 의견 도출
    • 유사/관련 업무 등을 수행하는 부서에 대한 면담에 드는 노력 절감
    • 전문가들의 판단을 이용하여 최적의 결론 도출
• 현행 업무 처리 매뉴얼을 통한 수집 ( 현행 업무 조사서)
• 현행 정보 시스템 관련 산출물을 통한 수집 (현행 프로그램/데이터 관련 문서)
• 관찰
  • 사용자의 업무를 관찰하는 과정에서 대화에서 놓치기 쉬운 자세한 사항 파악 가능
• 브레인스토밍
  • 창의적 아이디어 생산 위해 여러명으로부터 정보를 얻고자 할 때 사용
  • 자연스럽게 제시된 아이디어 목록을 통해 특정한 문제에 대한 해답을 찾고자 노력하는 것
  • 4가지 기본 원칙
    • 양에 포커스 맞추기
    • 비판, 비난 자제
    • 특이한 아이디어 환영
    • 아이디어 조합 및 개선
• 프로토타이핑
  • 개발 초기에 시스템의 모형(프로토타입)을 간단히 만들어 사용자에 공유하고, 사용자가 정보시스템을 직접 사용해 보게 함으로써 기능의 추가, 변경 및 삭제 등을 요구하면 이를 반영하여 프로토타입을재구축하는 과정을 사용자가 만족할 때까지 반복

 

 

7. 질문법

• 참여자로부터 새로운 요구 사항에 대한 의견과 아이디어 및 방향을 도출하고자 할 때.
• 타이-다운(Tie-down) 질문법 : 어떤 사항에 대한 승인이나 동의, 사고, 현안점검 등에 대한 반응을 조사하는 질문
• 대안진보(Alternate Advance) 질문법 : 선택사항을 제시하고 어떤 사실을 확인하는데 사용
• 포커핀 또는 부메랑 질문법 : 그래프가 포커핀과 유사하여 이름지어진 질문법으로, 부메랑은 어떤 질문에 대하여 질문으로 응답하는 방식.

 

 

8. 정보 요구 사항의 우선순위를 분석하는 방법

• 화폐가치 산출법
  • 최종적으로 구해진 가치가 높을수록 우선순위가 있음. 최종 순위는 산출된 수치에 의존하지 않고 고유의 상황에 따라 다르게 적용 가능
  • 정보 요구 사항 전체를 나열하고 기업 차원 중요성/ 시스템 차원의 중요성/ 다른 정보 요구 사항에 얼마나 도움을 주는가를 각각 점수 부여하여 세 점수를 모두 곱함.
  • 앞서 계산된 점수를 퍼센트로 환산
• 상대적 중요도 산정법
  • 정보 요구 사항이 업무에 기여하는 수준에 따라 점수 부여
  • 정보 요구 사항 매트릭스 작성, 정보 요구 사항 간 상관관계 계산
  • 현재 정보시스템이 각각의 정보 요구 사항에 얼마나 충족하는가에 대하여 점수 부여
  • 세가지 점수에 대하여 가중치 결정
  • 가중치에 따라 앞서 계산한 세가지 요인의 가중평균을 구하여 각각의 정보 요구 사항에 대한 중요도 평가.

 

 

9. 수집 문서 검토 기준

• 유용성 : 수집된 문서가 활용가능한지 검토
• 완전성 : 문서의 내용에 누락된 부분이 없는지 검토
• 정확성 : 문서의 내용이 현재 시스템과 일치하는지 검토
• 유효성 : 문서의 최신 내용 반영 여부

 

 

10. 프로세스 관점의 정보 요구 사항 상세화

• 프로세스 : 실제로 업무가 수행되는 행위. 기본 기능이 분해되면서 나타나 다시 프로세스로 분해됨.
• 프로세스를 분해하다 보면 더이상 분해되지 않는 최소 단위의 업무를 찾게 되는데 이를 기본 프로세스라 함.
• 수행 절차
  • 프로세스 중심으로 정리된 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서 작성
  • 도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 정보 항목과 산출되는 정보항목을 정리하고, 산출되는 정보 항목 중 기본 로직이 필요한 경우 기본 로직 정리.
  • 표준화 과정을 통해 해당 정보 항목에 대해 통합성/분리성 여부를 검토한 후 최종적으로 사용자의 정보 요구 사항을 충족하는 정보 항목 목록 정의.

 

 

11. 프로세스 계층도의 모듈성 확보를 위한 분해 기준

• 프로세스 계층도 작성 목적 : 기본 프로세스의 도출
• 높은 응집도와 낮은 결합도를 유지하도록 모듈성을 확보하는 것이 중요.

 

 

12. 객체지향 관점의 정보 요구 사항 상세화

• 유스케이스 다이어그램을 중심으로 정보 시스템의 기능적 정보 요구 사항 정리
• 유스케이스 다이어그램은 사용자와의 의사소통이 원활하게 진행될 수 있도록 도움
• 각 시스템 영역 내의 유스케이스와 액터, 그들 간의 관계를 유스케이스 다이어그램으로 도식화하고 도출된 유스케이스의 사건 흐름을 상세화 함

 

 

13. 유스케이스 다이어그램

• 액터 : 정보 시스템과 상호 작용하는 개인,그룹,회사 등 서비스를 받는 객체
• 유스케이스 : 도출된 액터별로 개발 시스템에서 제공해야 하는 기능
• 액터와 유스케이스 간의 관계
  • 확장 : 하나의 유스케이스가 다른 유스케이스의 행동을 추가함에 따라 나타나는 두 유스케이스의 관계
  • 포함 : 하나의 유스케이스가 다른 유스케이스를 사용함을 나타내는 두 유스케이스의 관계
  • Communicates : 행위자가 어떤 유스케이스에 참가함을 나타냄. 행위자와 유스케이스 사이의 유일한 관계

 

 

14. 정보요구 상관분석

• 도출된 정보 요구 사항을 타 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항 도출이 완전하게 효과적으로 이루어졌는지 파악
• 이를 기반으로 향후 안정적이고 확장 가능한 데이터 모델 설계
• 매트릭스 분석 기법 활용

 

 

15. 정보요구 상관분석 수행 주체

• 요구사항 분석가
  • 정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관 분석 수행
    • 자체 분석에 의한 객관성 저하의 문제점 발생 가능
    • 관련 업무팀과의 의사소통이 원활하므로 상관분석에 추가인력 투입 없이 원활하게 진행 가능
    • 업무에 대한 이해도가 높기 때문에 상관분석을 통한 정확한 업무 분석 가능
• 품질보증팀
  • 프로젝트 팀 내의 통함 검토 팀이나 품질보증 팀의 협조를 얻어 분석 수행
    • 업무에 대한 이해도가 낮아 검증에 어려움이 있을 수 있음
    • 전체적인 시각과 각 요건 및 팀간 인터페이스의 검증에 용이
• 외부 감리
  • 외부 감리 인력을 이용한 상관분석 수행
    • 업무 파악의 한계가 있으나 제 3자의 시각으로 검토 가능
    • 내부 인력의 효과적인 지원이 없을 경우 품질이 낮은 분석 결과 초래 가능
    • 상관분석의 객관성 극대화 가능

 

 

16. 정보요구/애플리케이션 상관분석 매트릭스

• 각 셀은 기본프로세스가 사용하는 정보 항목에 대한 액션이 생성(C),조회(R), 수정(U),삭제(D)로 표현
• 복수 액션이 발생할 경우C>D>U>R의 우선순위에 따라 하나만을 기록
• 분석기법 활용 시 CRUD가 복수로 발생할 경우 모두 기록가능하며, 분석기법을 활용하는 분석가의 매트릭스 활용 목적에 따라 선택 가능
• 모든 정보 항목이 모든 기본프로세스에서 사용되었는지, 혹은 모든 정보항목을 사용하고 있는지 확인
• 정보요구 / 애플리케이션 중 한가지가 누락되거나 잘못 정의된 경우는 분석 가능
• 모두 누락된 경우는 분석 불가능
• 매트릭스가 작성되기 전과 분석 중에도 수시로 확인해야 함

 

 

17. 정보요구/업무 기능 상관분석

• 일관성 확보, 품질수준 향상, 누락 및 중복된 정보요구 사항 점검
• 비즈니스에서 요구하는 정보 항목은 “데이터 모델링”의 근간이 되므로 업무기능별 필요 정보 항목의 누락 여부 확인은 매우 중요

 

 

18. 정보요구/조직 기능 상관분석

• 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서를 매핑하고, 정보 항목의 오너십 부여하여 효율적인 데이터 관리
• 조직명은 기업의 조직도에 나타난 순서로 입력, 기업이 둘 이상의 소재지에서 운영되면 조직단위를 분할하고 소재지 타입에 따라 클러스터링 함
• 매트릭스에 조재지 타입(ex. 본사, 영업소, 공장)에 의해 그룹핑된 조직 단위명 입력
• 정보항목의 생성,수정,삭제를 “C”로표시 (Change)
• 값의 변경 없이 정보항목을 검색만 하는 경우는 “U”로 표시 (Use)

 

 

19. 정보 요구 사항 재검토 계획 수립

• 완전성 : 사용자의 정보요구 사항이 누락됨 없이 모두 정의되었는지 확인
• 정확성 : 사용자의 정보요구 사항이 정확히 표현되었는지의 여부
• 일관성 : 표준화 준수 여부 확인
• 안정성 : 추가 정보요구 사항 변경에 따른 영향도 파악

 

 

 

20. 매트릭스 점검 내용

• 기본 프로세스가 사용(CRUD)하는 정보 항목이 없음
  • 정보 항목 누락 → 정보 항목 도출
  • 기본 프로세스 필요 없음 → 기본 프로세스 삭제
  • 기본 프로세스가 분석 대상 업무 영역에 속하지 않음 → 해당 업무 영역으로 이동
• 정보 항목이 7개 이상의 기본 프로세스에서 사용됨
  • 정보 항목이 너무 큼 → 정보 항목의 세분화 필요
• 정보 항목을 생성하는 기본 프로세스가 없음
  • 기본 프로세스의 누락 정보 항목이 필요 없음 → 기본 프로세스의 도출 정보 항목 삭제
  • 정보 항목이 분석 대상 업무 영역에 속하지 않음 → 해당 업무 영역으로 이동
• 정보 항목을 생성하는 기본 프로세스가 둘 이상 존재
  • 기본 프로세스 중복 → 기본 프로세스 합성
• 엔터티를 삭제하는 기본 프로세스가 없음
  • 기본 프로세스 누락 → 기본 프로세스 도출
  • 업무에 삭제가 존재하지 않음 → 전산상의 오류인 경우에 삭제가 필요한지 확인
  • 기본 프로세스가 분석 대상 업무 영역에 속하지 않음 → 해당 업무 영역으로 이동
• 정보 항목을 삭제하는 기본 프로세스가 둘 이상 존재
  • 기본 프로세스 중복 → 기본 프로세스 합성
• 정보 항목이 생성만 되고 사용하는 곳이 없음
  • 기본 프로세스 누락 → 기본 프로세스의 도출
• 기본 프로세스가 정보 항목을 조회만 함
  • 기본 프로세스가 아님 → 모듈 검토
• 기본 프로세스가 여러 액션을 수행함
  • 정의된 기본 프로세스가 너무 큼 → 프로세스 추가 분해