반응형
[2] 데이터 요건 분석
1) 정보 요구 사항 개요
(1) 정보 요구 사항
- 정보 요구 사항 정의
④ 정보 요구 사항이란 사용자가 일상적으로 수행하는 업무의 개선 사항이나, 신규 개발사항 등을 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용임
⑤ 현행 시스템 분석, 사용자 요구 사항 수집, 제안 요청서, 사업 수행 계획서 등을 이용하여 수집 가능 함
⑥ 사용자의 정보 요구 사항을 정해진 일정과 비용 범위 내에서 사용자가 원하는 시스템으로 개발하기까지는 많은 어려움이 존재 함
i. 불완전하고, 애매모호하게 정의된 정보 요구 사항
ii. 현실성을 배제한 이상적인 정보 요구 사항
iii. 특정 사용자만을 위한 정보 요구 사항
⑦ 잘못 분석되고 설계된 정보로 시스템을 개발한다면 사용자 요구사항을 만족하지 못하는 시스템이 되는, 이는 프로젝트 위험과 추가적인 비용을 지불하게 됨 - 정보 요구 사항의 중요성
① 2004년 Standish Group 조사 결과에 의하면 전체 프로젝트의 29%만이 계획된 예산 내에서 납기를 준수하고, 원하는 기능과 요구사항을 달성했음
② 프로젝트의 18%는 완료 전 또는 사용해 보기도 전에 취소되고, 53%는 납기가 지연 되거나 예산이 늘어나거나 기능, 품질에 문제가 있다고 보고함
③ 다양화된 사용자 정보 요구 사항과 더욱 복잡해진 정보시스템의 현행을 정확하게 분석하고 이해할 수 있는 능력이 데이터 아키텍처 전문가에게 필요함 - 정보 요구 사항 생명주기 모형
① 반복적으로 수행하여 사용자 정보 요구 사항이 누락 없이 반영되어야 함
② 정보 요구 사항 수집
사용자의 정보 요구 사항을 수집하는 단계
③ 정보 요구 사항 분석 및 정의
수집된 정보 요구 사항을 정리하고 기법을 이용하여 요구 사항을 정의하는 단계
④ 정보 요구 사항 상세화
정보시스템 관점에서 요구 사항에 상세하게 분석하는 단계
⑤ 정보 요구 사항 검증으로 구성 됨
비즈니스, 조직, 애플리케이션 관점에서 검증하는 단계 - 정보 요구 사항 유형
① 외부 인터페이스 요건
i. 시스템의 모든 입력과 시스템으로서의 모든 출력에 관한 요건으로서 대외기관으로부터 수신 및 대외기관으로 송신하는 입출력 방식이 추가 및 변경되었을 경우와 각종 제도 및 기준 등이 변경되었을 경우에 발생하는 요건
ii. 중복성 – 기존의 동일한 형태의 인터페이스가 존재하는지 여부를 체크
iii. 표준준수 – 인터페이스와 관련된 국제표준 및 국가표준이 존재할 경우 그에 적합한 형태로 제공해야 함
iv. 관리방법 – 항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입/출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리되어야 함
② 기능 개선 요건
i. 시스템에서 입력을 받아들여 처리하고, 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건
ii. 불가변성 – 기능개선 요건이 향후에 재 변경되지 않도록 근본적인 개선 방안을 요청해야 함
iii. 범용성 – 많은 사용자가 편리하게 사용될 수 있는 요건을 우선적으로 요청해야 함
iv. 관리방법- 입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응(Overflow, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어 관리되어야 함
③ 성능 개선 요건
i. 사용자가 원하는 성능개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요 시한 등이 있음
ii. 실현가능성 – 해당 성능개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지 확인한 후 제시되어야 함
iii. 측정가능성 – 측정이 불가능한 모호한 형태로 요건이 제시되면 안됨
iv. 관리방법 – 각 기관의 서비스 특성을 고려하여 정적, 동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시적으로 관리해야 함.
④ 보안 개선 요건
i. 중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근 통제(제한 구현, 통제 구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건을 말함
ii. 불가변성 – 보안 개선 요건이 향후에 재 변경되지 않도록 근본적인 개선 방안을 요청해야 함
iii. 실현가능성 – 해당 보안 개선 요구사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시되어야 함
iv. 관리방법 – 가정 먼저 보안 관리가 필요한 정보에 대한 등급 관리가 필요하며, 해당 등급별로 접근 가능한 이용자 등급 관리가 필요하며 접근 방식에 있어서의 접근 통제 기준 및 사용 통제 기준이 제시되어야 함
(2) 정보 요구 사항 관리
- 정의 및 관리 목적
① 정보 요구 사항을 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차
② 정보 요구 사항을 종합적으로 검토, 확인함으로써 요건에 맞는 정보시스템을 개발하여 사용자의 만족도를 높이고자 함
③ 정보 요구 사항 관리는 데이터, 애플리케이션, 비즈니스 등의 요구사항을 전부 포함하는 통합 관리 프로세스로 정립함 - 정보 요구 사항 관리 프로세스
① 요구 사항 발송
사용자가 정보시스템을 활용하면서 발생하는 불편사항이나 신규 개발사항 등의 요건을 정보 요구 사항 정의서 양식에 기록하여 발송
② 요구 사항 수렴
정보 요구 사항 정의서의 수집, 규칙에 맞게 정확하게 정의했는지 확인하고, 처리담당자를 지정하여 이송함
③ 요구 사항 검토
요청된 정보 요구사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영여부를 판단
반영이 가능한 경우 개발물량, 협조담당자, 관련인 등 영향도 분석 실시
반영이 불가능한 경우 미 반영 사유와 함께 요건을 발송한 담당자에게 재 전달
④ 영향도 분석
신규 개발 및 변경에 따라 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등에 대한 영향도 분석 실시
⑤ 공식화
관련 담당자를 소집, 의견 공유, 반영 유형 결정
⑥ 반영 작업 계획 수립
업무영역 및 관련 담당자들과의 미팅 후 반영계획을 수립 - 수행 조직 및 수행 업무
① 사용자
i. 변경 요청
ii. 변경 여부 확인
iii. 미결 사항에 대한 의사 결정 실시
② 담당자
i. 사용자 정보 요구 사항 접수
ii. 사용자 정보 요구 사항에 대한 기본적인 검토
iii. 반영 여부 결정을 위한 사용자와 1차 미팅
iv. 접수 요건에 대한 처리 방식 및 처리 기한 결정
v. 관련 부서별 담당자 수집 및 요건 협의 주도
vi. 사용자 정보 요구 사항 반양
vii. 테스트 및 검증
viii. 사용자 반영 결과 통보
③ 데이터아키텍처 전문가
i. 사용자 정보 요구 사항에 대한 표준/데이터베이스/애플리케이션 차원에 대한 영향도 분석 및 보고
ii. 접수된 요구 사항에 대한 표준 준수 여부 체크
iii. 영향도 분석을 통한 수정 및 변경 계획 수립
iv. 표준 제시 및 준수 여부 검토
2) 정보 요구 사항 조사
(1) 정보 요구 사항 수집
- 관련 문서 수집
① 문서 수집 목적
i. 구현 시스템의 대상과 범위를 보다 명확하게 정의하고, 기업과 업종에 대한 충분한 이해
② 문서 수집 자료
i. 경영 계획에 대한 자료 – 중장기 경영 전략, 향후 3년에 대한 경영 계획서
ii. 전산 시스템에 대한 자료 – 현행 발행 보고서, 전산 처리 의뢰서
iii. 과거 수행한 컨설팅 보고서
iv. 전산 처리 업무 매뉴얼
v. 현업 부서 업무 자료 – 실무 교육 자료
③ 문서 수집 원칙
i. 기존에 보유하고 있는 문서를 변형하지 않고 수집, 전산 시스템에 대한 자료는 별도의 정리양식을 이용하여 작성
ii. 수집된 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표를 작성
iii. 수집된 문서들은 계획 수립 기간 문서 관리자를 지정하여 운영
iv. 활용을 위하여 문서분류 방식을 결정한 후, 일정한 장소에 보관
v. 개인별로 보관하는 것을 통제하고, 문서보안 관리에 주의 - 사용자 면담
① 면담은 분석가가 특정 관점에서의 업무요건이나 업무절차를 조사하기 위하여 일반적으로 한 명(혹은 두 명)의 실무자와 대면하여 질의와 응답을 통해 정보를 수집하는 방법
② 프로세스와 프로시저에 대한 이해를 얻기 위한 준비 단계, 또는 워크숍 진행을 돕기 위한 준비 단계에서 유용함
③ 실무자와의 개별적인 면담은 워크숍보다 훨씬 융통성이 있으며 진행 측면에 있어서도 유연한 진행이 가능함
④ 참여자에게 적은 시간을 할당함으로써 일정 수립이 용이함
⑤ 누락된 부분이 발견되었을 때 추가적인 면담의 계획 및 준비가 쉽게 이루어질 수 있음 - 사용자 면담 진행
① 사용자로부터 중요한 업무 내용을 수집
② 사용자들로 하여금 시스템 개발에 대한 관심과 신임을 고조시킴
③ 전문가와 대화를 통해서 필요한 정보를 수집
④ 면담 진행 방법
i. 계획 및 준비
A. 면담 주제 선정
B. 면담 진행 팀 구성
C. 면담 대상자 선정
D. 면담 일정 수립
E. 면담 준비
ii. 면담 수행
A. 면담 시작
B. 면담 주제 토의
iii. 면담 결과 분석
iv. 분석 결과 피드백 - 면담 수행 시 고려 사항
① 면담 시간 준수
② 비밀 보장
③ 기대 수준 설정
④ 면담 범위 수준
⑤ 적절한 대상자 선정
⑥ 응답 유도
⑦ 면담 내용 문서화
⑧ 잘못된 선입견의 배제 - 워크숍 개요 및 목적
① 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의
② 정치적이거나 개인적인 요소들의 영향을 피하고, 다양한 정보의 원천으로부터 정보의 빠른 추출이나 공유를 요하는 경우, 단순한 회의나 토론 이상의 것을 요구하는 상황 등에 사용될 수 있음
③ 서로 관련 있는 부서들을 대상으로 워크숍을 실시할 수 있도록 함
④ 주요 목적 3가지
i. 경영층 또는 현업 부서장의 공통된 의견을 도출
ii. 유사한 업무 또는 관련된 업무 등을 수행하는 부서에 대한 면담에 드는 노력을 절감
iii. 전문가들의 판단력을 이용하여 최적의 결론을 도출 - 워크숍 준비
① 워크숍 과제선정과 계획 수립
② 참가대상자 선정
③ 참가대상자에 대한 사전 브리핑 및 교육훈련
④ 킥오프모임 수행
⑤ 워크숍 자료준비
⑥ 설비와 물품준비
⑦ 워크숍 장소선정
⑧ 워크숍 기간선정 프로그램 준비 - 현행 업무 조사서
① 전체 부서에 대하여 동일한 기준으로 조사하는 것을 원칙으로 함
② 각 지점이나 부서마다 다르게 업무를 수행하는 경우가 발생할 수 있고, 회사 전체의 업무 수행 빈도와 데이터 수발량을 조사하기 위해서는 전수조사가 필요함
③ 동일한 업무를 수행하는 부서 혹은 지점이 여러 개인 경우에는 표본추출 또는 발췌조사로 진행
④ 양식은 단순하고 이해하기 쉬워야 하며, 양식의 작성방법과 작성된 샘플을 첨부하여 배포하는 것이 효과적임
⑤ 내용이 불충분한 경우가 발견되므로, 업무조사서를 1차 수거한 후에 반송하여 다시 작성하는 경우가 발생할 수 있음. 이러한 상황도 일정계획 수립에 반영
⑥ 사용자가 처리하고 있는 업무기능 틀을 정리된 양식으로 기록하여 향후 작업에 도움이 되도록 함 - 현행 프로그램/데이터 관련 문서
① 향후 사용자 요구사항을 보다 세부적으로 진행하기 위한 사전단계로서 반영되어야 할 현행 시스템의 업무요건을 빠짐없이 파악하기 위한 작업임
② 현행 시스템 프로세스(프로그램)의 구조는 프로세스 계층도와 유사하게 계층적 구조로 표현하며, 이러한 현행 시스템 프로세스(프로그램) 계층도는 향후에 업무모델의 완전성을 검증하기 위한 비교자료로 활용됨
③ 현행 시스템의 데이터에 대한 분석은 현행 시스템에서 사용되는 현행 데이터 저장소의 구조를 파악함으로써 현행의 업무 프로세스에서 사용되는 데이터의 구조를 이해할 수 있음
④ 현행 데이터 저장소의 구조는 현행 시스템 데이터 목록 및 세부 내역을 분석함으로써 현행 데이터에 대한 업무 요건 및 업무 규칙, 현행 데이터저장소의 구조와 화면, 양식, 보고서 레이아웃 등을 이해할 수 있음
(2) 정보 요구 사항 정리
- 사용자 면담 정리
① 사용자 면담 시 제공된 자료의 샘플이나 관련 문서를 체계적으로 정리 기록
② 정리가 완료되면 주요한 관점(업무흐름, 수치, 주관부서, 책임부서 등)의 내용에 대해서는 다시 한번 기록된 부분의 오류가 있는지 사용자에게 확인을 받도록 함 - 업무 조사서 정리
회사차원에서 활용하는 업무문서 및 팀에서 사용하는 업무문서를 포함하여 전체 리스트를 파악할 수 있도록 체계적인 양식으로 정리함 - 워크숍 정리
① 사용자 워크숍을 통해 도출된 요구사항이나 해결 과제들은 명백하고 간결한 문장으로 정리한 후 사후 대처할 수 있도록함
② 해결과제에 대해서는 별도의 ID를 부여하여 관리함
③ 워크숍 결과 정리 시에는 다음 사항을 포함함 (워크숍 목적/진행내용/ 해결과제에 대한 상태/기타 특이사항) - 화폐가치 산출 방법
① 최종적으로 구해진 가치가 높을수록 우선순위가 있음, 그러나 최종 순위는 산출된 수치에 의존하지 않고 고유의 상황에 따라 다르게 적용될 수 있음
② 정보 요구 사항을 전부 나열
③ 각각의 정보 요구 사항에 대하여 기업 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여
④ 각각의 정보 요구 사항에 대하여 시스템 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여
⑤ 각각의 정보 요구 사항이 다른 정보 요구 사항에 대해 얼마나 도움을 주는가를 평가하여 1점부터 5점까지의 점수를 부여
⑥ 앞서 부여한 세 가지 점수를 모두 곱함
⑦ 전체 정보 요구 사항에 대하여 앞서 계산된 점수를 더하고, 점수 합계를 100으로 하여 각각의 정보 요구 사항 가치를 퍼센트로 환산
⑧ 회사 전체의 이익에 앞에서 구한 퍼센트를 곱하여 각각의 정보 요구 사항 가치를 금액으로 환산 - 상대적 중요도 산성 방법
① 정보 요구 사항이 업무에 기여하는 수준에 따라 1점부터 5점까지의 점수 부여
예를 들어 목적을 지원하면 5점, 목표를 지원하면 4점, 전략을 지원하면 3점 등의 방법으로 업무를 분류한 체계에 따라 결정
② 정보 요구 사항 대 정보 요구 사항 매트릭스를 작성하여, 각각의 정보 요구 사항이 다른 정보 요구 사항에 얼마나 관련되어 있는가를 계산
가장 관련이 큰 정보 요구 사항에 9점을 부여하고, 나머지 정보 요구 사항에는 이에 대한 상대 점수 부여
③ 현재 정보시스템이 각각의 정보 요구 사항을 얼마나 충족하는가에 대하여 1점에서 3점까지의 점수 부여
예를 들어 만족스러운 경우에는 3점, 보통인 경우에는 2점, 지원하지 않는 경우에는 1점 등의 방식으로 부여
④ 앞서 부여한 세 가지 점수에 대하여 가중치를 결정
예를 들어 업무 지원 정도는 50%, 다른 정보 요구 사항과의 관련도는 20%, 현행 시스템 지원 정도는 30% 등의 방법으로 정함
⑤ 가중치에 따라 앞에서 계산한 세가지 요인의 가중평균을 구하여 각각의 정보 요구 사항에 대한 중요도를 평가
(3) 정보 요구 사항 통합 - 정보 요구 사항 목록 검토
전사 관점에서 동일한 정보 요구 사항을 여러 부서 및 사용자가 제시 했는지를 검토하기 위하여 별도의 양식으로 취합 - 정보 요구 사항 통합/분할
① 통일 부서 내 중복 요구 사항 검토
i. 부서 내 정보 요구 사항 목록을 정렬
ii. 정보 요구 사항 제목을 기준으로 부서 내 동일 요건의 요구 사항이 존재하는지 파악
iii. 정보 요구 사항의 세부 요청 내용을 기준으로 세밀하게 중복 여부 파악
iv. 부서 내 동일 요건이 도출된 경우 관리 대상 요구 사항에 통합할 정보 요구 번호를 ‘비고’에 기입
v. 동일 부서 내 중복성을 배재한 요구 사항 목록 완성
② 서로 다른 부서간 중복 요구 사항 검토
i. 동일 부서 중복 요구 사항 검토와 동일하게 진행
ii. 분석 범위를 부서간으로 확장
③ 최종적으로 전사관점의 검토된 정보 요구 사항 목록을 작성
3) 정보 요구 사항 분석
(1) 분석 대상 정의
- 현행 업무 분석 대상 정의
① 분석 대상 자료
i. 현행 업무 흐름도
ii. 현행 업무 설명서
iii. 현행 업무 분장 기술서
② 분석 대항 업무 영역 선정
i. 현행 업무 흐름 및 관련 데이터를 파악하여 분류기준에 따라 분석 대상 현행 업무 목록을 작성
ii. 정보 요구 사항 분석을 위한 대상으로 선정할 것인지 결정을 하고 분석 대상 업무 목록표에 표기
③ 분석 대상 현행 시스템 선정
i. 분석 대상을 선정하기 위하여 업무 영역/현행 시스템 매트릭스를 작성 - 분석 대상 현행 시스템 관련 자료
① 현행시스템 구성도, 분석, 설계 및 개발 보고서
② 화면, 장표 및 보고서 레이아웃
③ 현행 시스템 테이블 목록 및 테이블 정의서
④ 사용자 및 운영자 지침서
⑤ 시스템 자원 및 유지보수 이력
⑥ 시스템 개선 요구사항 등 - 수집 문서의 평가 관점
① 유용성: 문서의 활용가능성 여부
② 완전성: 문서의 내용에 누락된 부분이 없는 지의 여부
③ 정확성: 문서의 내용이 현재의 시스템과 일치하는 지의 여부
④ 유효성: 문서가 최신의 내용을 반영하고 있는 지의 여부 - 추가적인 분석 대상
① 현행 데이터 측면의 업무 요건 혹은 업무 규칙을 h다 상세하게 분석하기 위하여 사용자 뷰(View)도 분석대상에 포함
② 사용자 뷰가 종합되어 나타나는 것이 화면, 수작업 파일, 수작업/전산 양식, 보고서 등의 레이아웃임
(2) 정보 요구 사항 상세화
- 정보 요구 사항 상세화 개요
① 분석 산출물을 토대로 하여 정보 요구 사항을 보완
② 추가적으로 비기능적 정보 요구 사항을 포함하여 추가 보완 - 프로세스 관점의 정보 요구 사항 상세화
① 프로세스는 실제로 업무가 수행되는 행위를 뜻함
② 프로세스는 기본 기능이 분해되면서 나타나 다시 프로세스로 분해됨
③ 업무기능은 기업의 목표달성을 위하여 지속적으로 수행되기 때문에 시작시점과 종료시점이 명확이 구분되지 않지만, 프로세스는 명확한 업무활동을 의미
④ 프로세스는 Input/Output을 동반하며, 최소 단위의 업무를 갖게 되는 기본 프로세스가 있음 - 수행 절차
① 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스 계층도, 프로세스 정의서를 작성
② 도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 것과 산출되는 정보 항목을 정리하고, 산출 항목 중 기본 로직을 필요로 하는 경우 정리
③ 해당 정보 항목에 대해서 통합 및 분리 여부를 검토한 후 최종적으로 사용자의 정보요구 사항을 충족하는 정보항목 목록에 정의 - 수행 작업 내용
① 프로세스 분해/상세화
i. 단위업무기능별 하향식으로 프로세스를 분해 및 도출
ii. 프로세스계층도 및 프로세스정의서를 작성
② 정보항목 도출 및 표준화
i. 기본프로세스별 정보항목을 정리
ii. 정보항목에 대한 표준화 정리
iii. 정보항목 목록 정의
③ 정보항목별 통합성, 분리성 여부 검토
i. 프로세스별로 관리되는 정보항목을 분류
ii. 정보항목별 동음이의, 이음동의 존재여부 파악
iii. 통합/분리여부 검토 후 최종 정보항목 목록 정의 - 수행 작업 지침 – 프로세스 분해/상세화
① 프로세스 분해
i. 단위 업무기능으로부터 출발하여 점진적으로 수행
ii. 단위 업무기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스 만으로 구성된 업무 기능을 의미
iii. 전체 단위업무기능에 대하여 프로세스 분해 수준을 맞추어 점진적으로 분해
iv. 업무 기능계층도가 단위 업무기능 수준까지 분해되지 않았을 경우에는 단위 업무기능 수준까지 더 분해한 후 프로세스 도출
② 프로세스 분해 깊이
i. 일반적으로 3차 수준까지 분해함
ii. 기본 프로세스 수준까지 도출되는 경우가 있으며 최종적으로 기본 프로세스의 도출에 있음
iii. 초기에는 균형 잇게 분해하는 데에 주의를 기울임
iv. 업무적으로 중요한 의미를 가지는 조회용 또는 수작업 프로세스는 필요에 따라 명명규칙을 달리하여 도출함 - 프로세스 분해/상세화
① 프로세스 명명 - 명명규칙을 준수하여 가급적 업무 용어로 유일하게 이름을 부여함
② 프로세스 계층도 - 높은 응집도(Cohesion), 낮은 결합도(Coupling)를 유지
프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려함
③ 프로세스 정의서 - 업무를 구체적으로 이해할 수 있도록 작성 - 정보 항목 도출 및 표준화
① 기본 프로세스별로 등록, 조회, 변경, 삭제 기능을 구분하여 기술
② 기능별 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사상의 내용을 파악하여 관리하고자 하는 정보 항목을 도축
③ 도출한 정보 항목은 명명 규칙을 준수, 업무용어를 그대로 사용하며, 명사형 - 정보 항목별 통합성 검증
④ 정보 유형별 정보 항목별로 전사 관점에서의 통합/분리여부를 검토
⑤ 동일한 정보 항목에 대해서 통합 시 다음과 같은 장점이 존재함
i. 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함
ii. 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용가능
⑥ 단, 아래와 같은 단점도 존재함
i. 통합 작업으로 인한 정보 항목의 애매모호성 존재
ii. 통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재 - 객체지향 관점의 정보 요구 사항 상세화
① USECASE 다이어그램
i. 사용자와의 의사소통을 원활하게 진행할 수 있음
ii. 액터(Actor) – 정보 시스템과 상호 작용하는 개인, 그룹, 회사, 조직 등 정보 서비스를 받는 객체
액터의 역할을 명확하게 나타내는 이름으로 정의
iii. Usecase – 도출된 액터별로 개발 시스템에서 제공해야 하는 기능을 나타냄
사건흐름에 대한 개요를 간략하게 기술
iv. Actor와 Usecase 간의 관계
A. 확장(Extend): 다른 유즈케이스의 행동을 추가함을 나타내는 관계, 다른 유즈케이스를 선택적으로 수행되는 경우에 사용
B. 포함(include): 다른 유즈케이스를 사용함을 나타내는 관계, 다른 유즈케이스를 반드시 수행되는 경우에 사용
C. Communicates: 행위자가 어떤 유즈케이스에 참가함을 나타냄, 행위자와 유즈케이스 사이의 유일한 관계임
② USECASE 상세화
i. Usecase의 사건 흐름을 구조화하는 작업으로 모든 선택 또는 대안 흐름을 기술
ii. Usecase의 특별 정보 요구 사항을 정의, Usecase에는 관련이 있지만 사건 흐름에는 고려되지 않는 정보 요구 사항을 Usecase의 특별 요구 사항으로 정의
iii. 이러한 특별 정보 요구 사항은 비기능적인 정보 요구 사항으로 기술
iv. 사건 흐름을 기술할 때 정상적인 흐름에 대해 먼저 기술한 후, 예외 사항에 대해 사건 흐름을 기술
: Usecase에 대한 개략적인 설명, 사건 흐름, 사전.사후 조건, 비기능적인 정보 요구 사항, 주된 사건 흐름에 대체될 수 있는 대안 흐름, 예외처리 사항
③ 클래스다이어그램 작성
i. 엔티티클래스 도출
A. 유즈케이스 모형을 검토하여 엔티티 클래스를 도출하여 정의
B. 식별된 클래스에 이름을 부여하고, 간략한 설명을 기술
C. 클래스 이름은 간결하고 업무적 의미를 함축한 단수형 명사로 부여
D. 이음동의어 및 동음이의어를 고려하여 선정
E. 유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑
ii. 관계도출 및 클래스도 도출
A. 관계란 의미 있고, 관심 있는 연결을 나타내는 클래스 간의 관계임
B. 클래스간의 집단화 관계를 식별하고 명명
C. 집단화 관계란 전체적인 클래스와 부분적인 클래스의 포함관계를 표현
iii. 속성 정의
A. 클래스가 나타내는 객체의 특성을 의미
B. 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도추
C. 속성에 대한 이름을 부여하고 간략한 설명을 기술
(3) 정보 요구 사항 확인
- 정보 요구 사항 확인 개요
사용자 및 부서로부터 접수해서 최종적으로 작성된 산출물에 대하여 정보 요구 사항을 제시한 담당자와 세부 재검토를 통하여 누락 사항 및 보완 사항을 도출하기 위한 계획을 수립하고 재검토를 실시함 - 수행 절차
① 분석결과 도출된 산출물에 대해서 재검토 기준을 정의하고, 계획을 수립
② 재검토대상 산출물의 안전성, 정확성, 일관성, 안정성 등 다양한 측면서 실시
③ 재검토 결과 추가 및 보완 사항이 존재하는 경우 내용을 문서로 정리한 후 해당 산출물에 추가 반영여부 확인하고, 미 반영 시 사유의 타당성을 검토 - 수행 작업 지침 - 재검토 계획 수립
① 안전성 – 사용자의 정보요구 사항이 누락됨이 없이 모두 정의되었는지 확인
② 정확성 – 사용자의 정보요구 사항이 정확히 표현되었는지의 여부
DASP / www.boramjeong.com - 22
③ 일관성 – 표준화 준수 여부 확인
④ 안전성 – 추가 정보요구 사항 변경에 따른 영향도 파악
⑤ 재검토 계획서 포함 사항 – 정보요구 사항 재검토 개요 및 목적, 재검토 일자, 재검토 장소 및 시간계획, 재검토 참석 대상 및 재검토 업무, 참석대상별 재검토 세부시간 계획, 재검토 시 준비물, 재검토 후 산출물, 재검토 후 지적사항 반영계획 수립 - 수행 작업 지침 - 재검토 실시
① 재검토 기준 및 재검토 대상 산출물을 준비, 대상자에게 배포
② 재검토 관련 장소, 시간, 준비 등 제반 준비와 역할 주지
③ 재검토 세션 이전에 재검토대상 산출물을 예습
④ 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항에 대한 정리
⑤ 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항에 대한 정리
⑥ 재검토 시 재검토 진행자는 정해진 일정 내에 마칠 수 있도록 주의
⑦ 통합성 검증을 위하여 해당 업무 영역과 관련 있는 업무영역 담당자가 참여
⑧ 진행자는 세션 별로 적절한 시간 배분 및 조정의 역할을 충실히 수행
⑨ 재검토 결과가 정리되면 해당 정보 요구 사항 별 보완 사항을 유형에 따라 보완목록에 작성
⑩ 재검토 결과의 지적 사항 외에 분석결과 산출물의 일관성 유지를 위해, 특정내용이 변경됨으로써 함께 변경되어야 할 대상도 함께 기록함
⑪ 보완 사항 반영 시 정보 요구 사항간의 일관성이 유지되도록 유의
⑫ 반영 완료 후 누락은 없는지, 잘못 반영된 사항은 없는지 전체적으로 검토 - 수행 작업 지침 - 보완 결과 확인
① 재검토 결과, 보완 목록, 보완 사항이 반영된 정보 요구 사항 정의서 배포
② 미 반영 사유가 존재할 경우에는 미 반영 사유가 타당한지 검토
③ 미 반영 사유가 업무 규칙이나 정책의 변경을 수반하는 경우 프로젝트 기간 내에 해결 가능한 것은 개선 과제로 정리하여 해당 부서에 의뢰 - 수행 시 고려 사항
① 일관성 있는 기준 및 명확한 일정을 수립
② 모든 참여인력이 공감대를 형성하고 재검토 작업을 수행하야 함
③ 재검토는 2번 이상을 진행하되 세션마다 재검토 기준을 명확히 하여 수행
④ 재검토 세션 진행의 효율성을 감안하여 적정한 참여대상을 선정
⑤ 세션의 집중력을 상실하거나 결론에 도달하지 못하는 경우에 주의
4) 정보 요구 검증
(1) 정보 요구 사항 상관분석 기법
- 정보 요구 사항 개요
① 도출된 정보 유구 사항을 타 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항의 도출이 완전하게 효과적으로 이루어졌는지 파악
② 이를 기반으로 향후 안정적이고 확장 가능한 데이터 모델을 설계할 수 있음
③ 매트릭스 분석 기법 활용
④ 정보 요구 사항/ 애플리케이션의 기본프로세스, 비즈니스의 업무 기능, 조직과의 매트릭스 분석 기법을 소개 - 정보 요구 사항의 충족도 파악을 위한 상관분석수행의 주체분류
① 요구 사항 분석가 수행
② 품질보증 팀 수행
③ 외부 감리 수행 - 요구 사항 분석가 수행
정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관 분석을 수행
① 자체 분석에 의한 객관성 저하의 문제점이 발생 할 수 있음
② 관련 업무팀과의 의사소통이 원활하므로 원할하게 진행할 수 있음
③ 업무에 대한 이해도가 높기 때문에 상관분석을 통한 정확한 업무 분석이 가능 - 품질보증 팀 수행
프로젝트 팀 내의 통합 검토 팀이나 품질보증 팀의 협조를 얻어 분석 수행
① 업무에 대한 이해도가 낮아 검증에 어려움이 있을 수 있음
② 전체적인 시각과 각 요건 및 팀간 인터페이스의 검증에 용이 - 외부 감리 수행
외부 감리 인력을 이용한 상관분석을 수행
① 업무 파악의 한계가 있으나 제 3자의 시각으로 검토할 수 있음
② 내부 인력의 효과적인 지원이 없을 경우 품질이 낮은 분석 결과를 초래 할 수 있음
③ 상관분석의 객관성을 극대화 할 수 있음 - 정보 요구/애플리케이션 상관 분석
① 정보 요구 사항을 바탕으로 도출된 정보 항목들과 애플리케이션 영역에서 도출한 기본 프로세스를 사용하여 매트릭스를 작성
② 기본프로세스의 액션(CRUD)을 빠짐 없이 작성
③ 모든 정보 요구 사항들이 기본프로세스에 의해 사용되고 있는가?
④ 모든 기본 프로세스를 수행하는데 필요한 정보 요구 사항이 도출되었는가? - 정보 요구 상관 분석 기법
① 매트릭스의 각 셀에는 기본프로세스가 사용하는 정보 항목에 대한 액션이 CRUD로 표현
② 복수 액션이 발생할 경우에는 C>D>U>R의 우선순위에 따라 하나만을 기록(그러나 분석기법의 활용 시 CRUD가 복수로 발생할 경우 모두 기록 할 수 있으며, 이는 분석기법을 활용하는 분석가의 매트릭스 활용 목적에 다라 선택가능)
③ 모든 정보 항목이 모든 기본프로세스에서 사용되었는지, 혹은 모든 정보 항목을 사용하고 있는지 확인
④ 정보 요구와 애플리케이션 중에서 한가지가 누락되거나 잘못 정의된 경우는 분석이 가능
⑤ 정복 항목과 기본프로세스가 모두 누락된 경우는 분석이 불가능함
⑥ 따라서, 매트릭스가 작성되기 전과 분석하는 중에도 수시로 확인해야 함 - 정보 요구/업무 기능 상관 분석
① 일관성 확보, 품질수준 향상, 누락 및 중복된 정보요구 사항 점검
② 가치 사슬 분석의 기법을 통해 도출된 최하위 전사 업무 기능과 정보 요구 사항에 따라 도출된 정보 항목을 매트릭스에 배치 - 정보 요구/업무 기능 상관 분석
① 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서 매핑하고, 향후 정보 항목에 대한 오너쉽 부여하여 효율적인 데이터관리
② 조직 단위명은 기업의 조직도에 나타난 순서로 입력, 만일 기업이 둘 이상의 소재지에서 운영된다면 조직단위를 분할하고 소재지 타입에 따라 클러스터링 함. 매트릭스에 소재지 타입(예: 본서, 영업소, 공장)에 의해 그룹핑된 조직 단위명을 입력
③ 조직과 정보 항목 간의 상호작용을 다음과 같이 정의
i. 정보항목의 생성, 수정, 삭제를 “C”로 표시
ii. 값의 변경 없이 정보항목을 검색만 하는 경우에는 “U”로 표시
iii. 아무 관련이 없는 것은 빈칸으로 남겨둠
(2) 추가 및 삭제 정보 요구 사항 도출
- 애플리케이션 충족도 분석 매트릭스
① 애플리케이션 충족도 분석 매트릭스는 다음 기준에 따라 점검하며 추가되거나 삭제되어야 할 정보 요구 사항을 도출 함
② 정보 항목을 생성하는 기본프로세스가 반드시 존재해야 함
③ 정보 항목의 상태를 종료 시키는 기본프로세스가 존재해야 함
④ 생성된 정보 항목은 조회, 수정, 삭제 액션 중 하나가 발생해야 함
⑤ 하나의 정보 항목을 생성/수정/삭제하는 프로세스의 합은 7개를 초과하지 않는 것이 보통이며 초과하는 경우에는 재차 검토
⑥ 수작업 및 조회 전용으로 정의된 기본프로세스 이외의 기본프로세스는 반드시 생성, 수정, 삭제 액션 중의 하나를 수행함 - 매트릭스 분석
① 매트릭스 분석은 추가 및 삭제되어야 할 정보요구 사항을 도출 함
② 조치 사항이 애플리케이션과 관련된 것일 경우에는 해당 팀에 전달해서 프로세스와의 일관성을 가져야 함 - 정보 요구/업무 기능 상관분석
① 매트릭스 분석
② 정보 항목과 연관성이 없는 업무 기능의 경우, 관련 팀과의 협의 하에 업무 기능 도출의 적절성이나 관련 정보 항목을 다시 파악하여 매트릭스를 보완함
③ 정보 항목과 매핑이 없는 업무 기능의 경우, 관련 팀과의 협의하여 정보 요구 사항 보유 여부를 확인한 후 추가적인 정보 요구 사항이 있을 경우 정보 요구 조사 프로세스에 따라 정보 요구 목록에 신규로 추가함 - 정보 요구/조직 기능 상관분석
① 매트릭스 분석
② 정보 항목의 활용도를 파악할 수 있으며, 정보 항목의 수요가 많은 경우에는 해당 정보의 물리모델링 단계에 성능/활용 측면의 모델링 기법을 적용하여 정보 활용의 효율성을 고려함
③ 정보 항목을 생성하는 조직 단위가 복수로 존재할 경우, 데이터 관리의 복잡성으로 인해 향후 문제가 발생할 수 있으므로 해당 정보 항목에 대한 데이터 관리 주체의 선정에 주의를 기울임
(3) 정보 요구 보안 및 확인
- 정보 요구 보완
① 애플리케이션/정보 요구 사항, 업무 기능/정보 요구 사항, 조직/정보 요구 사항 매트릭스 분석을 통해 파악된 추가 및 삭제 정보 요구 사항에 대하여 담당자와 구체적인 미팅을 실시
② 일정 계획 시 설정된 반영계획에 따라 정보 요구 목록을 보완함 - 정보 요구 확정
① 보완된 정보 요구 사항에 대하여 재차 사용자 검토를 실시하며 추가 반영사항에 대한 반영여부 의사결정을 실시하고, 최종 정보 요구 목록에 대한 확정을 실시함
② 정보 요구 목록을 통해 향후 데이터 모델과 관련된 모든 산출물을 추적할 수 있으므로 누락된 정보 항목이 없게 정확하게 작성함
반응형
댓글