제1장 정보 요구사항 개요
제1절 정보 요구 사항
가.정의
-정보 요구 사항이란 사용자가 일상적으로 수행하는 업무의 개선 사항이나 신규 개발 사항으로 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용
나.정보 요구사항 생명주기 모형
-정보요구사항 도출, 분석 및 정의, 명세화, 검증으로 구성
1)정보요구사항 도출
-사용자의 정보 요구 사항을 도출하는 단계로서 사용자 인터뷰, 설문서, 워크숍, 현행 시스템 분석 등을 통해 도출
2)정보요구사항 분석 및 정의
-사용자로부터 수집된 정보 요구 사항을 정리하고 방법론에서 제시하는 다양한 기법을 이용하여 분석해서 정보 요구 사항을 정의하는 단계
3)정보요구사항 명세화
-확정된 정보 요구 사항의 개별 사항에 대하여 세밀하게 분석하고 기록하는 단계
4)정보요구사항 검증
-사용자의 정보 요구 사항을 비즈니스 관점, 조직 관점, 애플리케이션 관점과 상관분석을 통해 누락 없이 반영되었는지를 검증하는 단계
다.정보 요구사항 유형
요구사항분류: 기능, 비기능(성능, 시스템장비구성, 인터페이스, 데이터, 테스트, 보안, 품질, 제약사항, 프로젝트관리, 프로젝트 지원), 기타(유지관리수행, 유지관리인력, 컨설팅, 공사)
-유형:외부/기능/성능/보안 요건
1)외부 인터페이스 요건
-시스템의 모든 입·출력에 관한 요건으로서 대외기관으로부터 수신 및 대외기관으로 송신하는 입출력 방식이 추가 및 변경되었을 경우와 각종 제도 및 기준 등이 변경되었을 경우에 발생하는 요건
#관리기준: 중복성, 표준준수도
중복성:기존에 동일한 형태의 인터페이스가 존재하는지 체크
표준준수도:인터페이스와 관련된 국제 표준 및 국가 표준이 존재할 경우, 그에 적합한 형태로 제공
#관리방법:항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입/출력과의 관계, 데이터 포맷, 최종 메시지 등이 포함되어 관리
2)기능 개선 요건
-시스템에서 입력을 받아들여 처리하고 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건
#관리기준: 불가변성, 범용성
불가변성: 기능 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청
범용성:많은 사용자가 편리하게 사용할 수 있는 요건을 우선적으로 요청
#관리방법
-입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응(오버플로우, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등이 포함되어 관리
3) 성능 개선 요건
-사용자가 원하는 성능 개선 사항으로는 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요시간 등
#관리기준: 실현가능성, 측정가능성
실현가능성: 해당 성능 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시
측정가능성: 측정이 불가능한 모호한 형태로 요건이 제시되면 안됨
#관리방법
-각 기관의 서비스 특성을 고려하여 정적, 동적 기준을 마련하고 해당 기준에 맞게 서비스되고 있는지를 모니터링 작업을 통해 항시 관리
4) 보안 개선 요건
-중요 데이터에 대한 훼손, 변조, 도난, 유출에 대한 물리적 접근통제(제한구역, 통제구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건
#관리기준: 불가변성, 실현가능성
불가변성: 보안 개선 요건이 향후에 재변경되지 않도록 근본적인 개선 방안을 요청
실현가능성: 해당 보안 개선 요구 사항이 현행 기술 수준과 서비스 특성을 고려할 때 구현 가능한 요건인지를 확인한 후 제시
#관리방법
-가장 먼저 보안 관리가 필요한 정보에 대한 등급 관리가 필요하며, 해당 등급별로 접근 가능한 이용자 등급 관리가 필요하며 접근 통제 기준 및 사용 통제 기준 제시
제2절 정보 요구 사항 관리
가.정의 및 관리 목적
-정보 요구 사항을 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차
나.정보 요구사항 관리 프로세스
1)업무흐름 프로세스
요구사항 발송 | 사용자가 정보시스템을 활용하면서 발생하는 불편 사항이나 신규 개발 사항 등의 요건을 정보 요구 사항 정의서 양식에 기록하여 정보시스템 담당자에게 발송 |
요구사항 수렴 | 사용자로부터 접수한 정보 요구 사항 정의서를 수집하여 규칙에 맞게 정확하게 정의했는지 확인하고, 해당 요건을 검토할 처리 담당자를 지정하여 이송 |
요구사항 검토 | 요청된 정보 요구 사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영 여부를 판단 |
영향도 분석 | 요청된 내역을 토대로 신규 개발 및 변경에 따른 영향이 얼마나 되며, 이로 인해 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등을 파악 |
공식화 | 영향도 분석 후 관련되는 담당자를 소집하여 의견을 공유하고, 담당자들과의 협의를 통해 반영 유형을 결정 |
반영 작업 계획 수립 | 영향 분석 결과를 근거로 업무 영역 및 관련 담당자들과의 미팅 후 반영 계획을 수립 |
2)수행조직 및 수행 업무
#사용자
- 정보 요구 사항 정의 및 상세화
- 정보 요구 사항 변경 요청
- 정보 요구 사항 반영을 위한 미팅
- 정보 요구 사항 반영 여부 확인
- 미결 사항에 대한 의사결정 실시
#담당자
- 사용자 정보 요구 사항 접수
- 사용자 정보 요구사항에 대한 기본적인 검토
- 반영 여부 결정을 위한 사용자와 1차 미팅
- 접수 요건에 대한 처리 방식 및 처리 기한 결정
- 관련 부서별 담당자 수집 및 요건 협의 주도
- 사용자 정보 요구 사항 반영
- 테스트 및 검증
- 사용자 반영 결과 통보
#데이터아키텍처 전문가
- 사용자 정보 요구 사항에 대한 표준/데이터베이스/애플리케이션 차원에 대한 영향도 분석 및 보고
- 접수된 요구 사항에 대한 표준 준수 여부 체크
- 영향도 분석을 통한 수정 및 변경 계획 수립
- 표준 제시 및 준수 여부 검토
-요청사항 내용 중 미결 사항에 대한 검토
제2장 정보 요구 사항 조사
제1절 정보 요구 사항 수집
가.정보요구사항 수집 형태
-관련 문서 수집
-사용자 면담을 통한 수집
-워크샵을 통한 수집
-현행 업무 처리 매뉴얼을 통한 수집
-현행 정보시스템 관련 산출물을 통한 수집
*정보시스템 현황조사기법: 경쟁환경분석, SWOT분석, RAEW분석(책임,권한,전문능력,일)
나.관련문서 수집
-사용자및시스템관점의 정보요구사항수집시 소스문서: 현행시스템분석서, 현행 사용자 요구사항정리문서, 현행시스템개선과제 및 문제점 정리문서
-관련 문서에는 업종에 대한 이해에 도움이 되는 자료
-기업에 대한 전체적인 상황 이해시 도움이 되는 자료
-사용자가 업무 처리를 위해 참고로 하는 상세한 업무 매뉴얼,
-업무 처리시 활용하는 정보 처리 매뉴얼, -정보시스템으로부터 산출되는 보고서 및 각종 장표,
-처리 화면 등이 포함
1)문서수집 목적
-구현 시스템의 대상과 범위를 좀더 명확하게 정의하고 기업과 업종에 대해 잘 이해하기 위하여 업종, 경영 전략, 정보시스템 등에 대한 과거 실적 자료 및 향후 계획 등의 자료를 수집
2)문서수집 자료
-경영 계획에 대한 자료
-정보시스템에 대한 자료
-과거 수행한 컨설팅 보고서
-전산처리 업무 매뉴얼
-현업부서 업무 자료
3)문서 수집 원칙
-문서는 기존에 보유하고 있는 문서를 변경하지 않고 수집하고, 정보시스템에 대한 자료는 별도의 정리 양식을 이용하여 작성
-수집된 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표를 작성하여 그 내용을 숙지
-수집된 문서들은 계획 수립 기간, 문서 관리자를 지정하여 운영
-유형별 문서를 향후 활용을 위하여 문서 분류 방식을 결정한 후에 일정한 장소에 보관
-수집된 문서는 통상 대외비의 성격이 강하므로 개인별로 보관하는 것을 통제하고 문서 보안 관리에 주의
다.사용자 면담
-면담은 분석가가 특정 관점에서의 업무 요건이나 업무 절차를 조사하기 위하여 일반적으로 한 명 (혹은 두 명)의 실무자와 대면하여 질의와 응답을 통해 정보를 수집하는 방법
1)사용자면담종류
면담조사방법
-개인면담: 일대일
-집단면담(워크샵): 일대다
-표준화면담: 동일 내용과 절차 반복
-비표준화면담: 질문 내용이나 순서가 변함
면담조사방식
-피라미드 구조: 구체적 선택형> 일반적 서술형 질문 진행
-퍼널구조: 일반적 서술형> 구체적 선택형 질문 진행
-다이아몬드 구조: 피라미드 + 퍼널
1)사용자 면담 진행
-계획및준비, 면담수행, 면담결과분석, 분석결과피드백
#계획 및 준비: 면담일정, 면담지침, 면담요지, 기록양식
*면담 주제 선정
-수행 대상 작업과 면담 대상자의 책임 수준에 따라 결정.
면담 대상자 및 대상 작업별 면담 주제에 따라 면담 요지를 작성
-질문 항목은 면담을 통해 얻고자 하는 것이 무엇인지를 명확히 선정
-면담의 취지, 목적, 수행 방법, 시간
-프로젝트의 개요: 목표, 범위, 기간, 조직
-업무의 향후 수행 방향에 대한 의견
-면담 대상자가 소속된 부서의 업무 현황 및 개선 요구 사항
-현재 사용하는 정보시스템에 관한 의견
-프로젝트에 관한 의견 : 요구 사항, 프로젝트 참여 방안 등
*전산 부서용 면담 요지
면담의 취지, 목적, 수행 방법, 시간 등
프로젝트의 개요 : 목표, 범위, 기간, 조직
기획 분야 현황 및 계획 : 전산 부서 조직 및 인력, 연혁, 계획, 문제점, 과제 등
시스템 분야 현황 및 계획 : 조직 및 인력, 시스템 구성, 네트워크 구성, 시스템 운영 절차, 향후 계획, 문제점 및 과제 등
애플리케이션 분야 현황 및 계획 : 조직 및 인력, 애플리케이션 구성, 데이터베이스 구성, 진행 중인 개발 업무, 개발 및 유지보수 계획, 문제점 및 과제 등
*면담 진행 팀 구성
-가능하면 2~3인으로 구성
-면담팀원간 역할 구분
-기록자나 관찰자는 사전에 업무를 습득
면담자
- 면담을 진행.
- 면담의 취지를 설명하고 면담 대상자에게 질문.
기록자
- 면담 대상자의 답변 내용을 기록.(요약말고 그대로)
- 면담 대상자의 답변 내용을 충분히 이해하고 기록하기 위하여 면담 대상 업무에 대한 사전 지식 보유.
- 면담 종료 시에 기록 내용 중 주요 사항(수치, 업무 분장 및 책임소재 조직 등에 대한 내용)을 확인.
관찰자
- 면담이 수행 의도대로 진행되고 있는가를 관찰.
- 면담이 주제의 범위를 벗어나면 주의 환기
- 면담자가 놓치는 부분에 대하여 보충 질문.
- 최종적으로 면담의 종료에 대해 판단.
*면담 대상자 선정
-수행 작업에 따라 면담 대상을 선정
-적절한 대상을 선택하기 위하여 전체 조직 구성도와 프로젝트 범위를 검토하고, 프로젝트 후원자나 사용자측으로부터 추천
-여러 명의 사용자나 조직들이 유사한 업무를 수행하고 있는 경우에는 차이점 파악을 위하여 해당 업무에 대하여 적어도 두 명 이상의 면담 대상자를 선정
*면담 일정 수립
-면담 실시가 공표되고 프로젝트 후원자의 지원을 얻은 후 선정된 면담 대상자들에게 프로젝트의 목적과 범위를 통보하고 사용 가능한 관련 문서 자료를 요청
-면담은 초기 단계에서 일정(전체 일정)이 정해져 있어야 하며, 면담 개시 최소 1주일 전에 면담 대상자별로 세부 일정을 확정
-면담 시간은 1.5시간(상위 관리자)에서 3시간(실무자)을 초과하지 않도록 하며, 필요시 집단 면담을 수행
*면담 준비
-면담 수행 전에 모든 이용 가능한 자료를 활용하여 면담 대상자가 담당하는 업무 활동을 검토
-면담 대상자의 업무에 대한 태도나 해당 업무 종사 기간, 경험 등을 알아두고 면담 시나리오를 준비
-도표를 이용할 경우 면담의 효율성 높음
-면담 수행 직전 30분 동안에는 수행될 면담에 관한 최종 준비 상황을 확인
2)면담: 핵심사항, 상세면담기록, 책임소재, 분석양식
#면담 시작
-면담 시작 30분 전에 다른 면담 진행팀과 함께 필요한 정보 요구와 진행 순서를 점검하고, 면담 진행팀원들 각자의 역할을 확인
-면담은 정시에 시작. 면담이 시작되면 면담자는 면담 대상자에게 면담 진행팀을 소개하고, 프로젝트의 목적, 범위, 일정 등을 먼저 설명한 후 면담의 목적과 주요 질문 및 진행 방식, 예정 시간, 면담 진행팀원들의 역할을 설명
-면담은 복수의 팀에서 수행될 수 있으므로 면담 진행팀들 간의 수행 방식을 통일하기 위하여 모든 절차가 면담 지침에 세세한 문구까지 모두 반영
#면담 주제 토의
-면담자는 준비된 면담 요지에 따라 면담을 진행하고 면담 내용은 모두 면담 기록지에 기록
-질문 시 개방적 질문을 사용하며 면담 주제나 질문지의 순서와 범위를 벗어나지 않도록 노력하고 대화의 흐름이 끊기지 않도록 주의
-기록자는 토의된 내용을 가능한 한 모두 기록
-모든 면담 결과의 후속 분석 작업을 위한 공통의 기준으로 사용될 수 있는 표준 기록 양식이 있어야함
-토의가 진행되는 동안 면담 대상자의 주요 책임 업무를 명확히 정의하고 면담 대상자의 각 업무가 시간과 같은 논리적인 순서에 따라 진행되는지를 확인
3)면담 결과 분석: 면담분석결과, 현안정보요구, 정보화과제
-면담 진행팀은 기록된 내용과 면담 중의 응답에 대한 개인적 의견을 고려하여 면담 결과를 정리
-기존의 업무 모델을 틀로서 사용할 수 있으나 현재 업무와의 사이에 발생하는 차이점에 주의하고, 가능하면 면담 대상자의 업무 용어를 사용
-의문 사항이나 추가 사항이 있으면 즉시 면담 대상자에게 확인을 하고, 필요한 경우에 추가 면담을 실시
4)분석 결과 피드백: 면담분석결과 승인
-별도의 정리 내용이 없거나, 필요한 경우 면담 기록지 내용 전체에 대하여 확인을 받을수 있음
-면담 대상자는 정리된 내용에 대한 수정 사항을 제시 가능
-일정상 개인별로 결과에 대한 피드백이 곤란한 경우에는 현업실무자 전원을 대상으로 워크숍을 진행 가능
4)면담 수행시 고려사항(시비기범 대응문선)
#면담 시간 준수
#비밀보장
#기대수준 설정
#면담 범위 준수
#적절한 대상자 선정
#응답 유도
#면담 내용 문서화
#잘못된 선입견의 배제
*질문법
-타이다운(Tie-down) 질문법: 어떤 사항에 대한 승인이나 동의, 사고, 현안점검 등에 대한 반응을 조사하는 질문
-대안진보: 선택사항을 제시하고 어떤 사실을 확인하는데 사용되는 질문
-포커핀/부메랑: 대안의 그래프가 포커핀과 유사하여 이름지어진 질문법, 부메랑은 어떤 질문에 대하여 응답하는 방식
다.워크숍
1)워크숍 개요 및 목적
-어떠한 목적을 달성하기 위하여 전문 진행자의 진행 아래 프로젝트의 현업 부서 측과 전산 부서 측의 주요 구성원들이 함께 참여하는 회의
-경영층 또는 현업 부서장의 공통된 의견을 도출.
-유사한 업무 또는 관련된 업무 등을 수행하는 부서에 대한 면담에 드는 노력을 절감
-전문가들의 판단력을 이용하여 최적의 결론을 도출
2)워크숍 준비
워크숍 과제 선정과 계획 수립
참가 대상자 선정
참가 대상자에 대한 사전 브리핑 및 교육 훈련
킥오프 모임 수행
워크숍 자료 준비
설비와 물품 준비
워크숍 장소 선정
워크숍 기간 선정 프로그램 준비
3)워크숍 수행
-워크숍 개시, 수행준비, 수행, 종료
#워크숍 개시
-워크숍의 시작을 알리고 간략한 인사말, 부수적인 항목들(휴게실 위치, 흡연구역 등)에 대해서 공지
-일정 확인
#워크숍 수행 준비
-워크숍의 목적과 접근방법의 개요를 설명.
-사용자로 하여금 워크숍의 목적을 재확인.
-워크숍 기간 동안 작업을 수행하기 위하여 필요한 기법들을 습득.
#워크숍 수행
-구체적인 워크숍 수행 방식은 형태나 특정 목적에 따라 다르게 수행
-워크숍의 목적에 맞게 진행될 수 있도록 조정하고 관찰
-세부적인 진행 방법 등은 기법을 이용
#워크숍 종료
-종료할 때는 진행 일정을 확인하고 진행사항을 요약
-워크숍 과정에서 도출된 요구 사항을 요약하고 책임자가 전체에게 공유하여 1차적으로 검토받음
라.현행 업무조사서
-업무조사는 전체 부서에 대하여 동일한 기준으로 조사
마.현행 프로그램/데이터 관련 문서
-현행 시스템에 대한 자료 수집은 향후 사용자 요구 사항을 좀더 세부적으로 진행하기 위한 사전 단계로서 반영되어야 할 현행 시스템의 업무요건을 빠짐없이 파악하기 위한 작업
-현행 시스템 프로세스(프로그램)의 구조
-현행 시스템의 데이터
-현행 데이터 저장소의 구조
바.관찰
-관찰하는 대상의 자료를 수집하는 귀납적 방법 피관찰자의 행동이나 태도를 살펴보는 행위
사.브레인스토밍
1)브레인스토밍 개요 및 목적
-창의적인 아이디어를 생산하기 위한 학습도구이자 회의기법
-원리: 판단보류, 가능한 많은 아이디어를 이끌어 낼 것
2)브레인스토밍 4가지 기본원칙
-양에 포커스를 맞추기
-비판, 비난 자제
-특이한 아이디어 환영
-아이디어 조합 및 개선
3)진행방법
-목적, 특징, 원칙, 진행방법 설명
-제한시간 정하고 시작
-아이디어는 게시하여 남의 아이디어로 더 참신한 아이디어 도출
아.프로토타이핑
-개발접근법의 하나로서 개발초기에 시스템의 모형을 간단히 만들어 사용자에게 보여 주고, 사용자가 정보시스템을 직접 사용해 보게 함으로써 기능의 추가, 변경 및 삭제 등을 요구하면 이를 즉각 반영하여 정보시스템 설계를 다시 하고 프로토타입을 재구축하는 과정을 사용자가 만족할 때까지 반복해나가면서 시스템을 개선시켜 나가는 방식
#프로토타이핑 4단계
-1단계: 사용자 요구사항 분석
-2단계: 프로토타입 개발
-3단계: 프로토타입 사용/보완 제안
-4단계: 프로토타입 수정/보완
제2절 정보 요구 사항 정리
가.정보 요구사항 정리
1)사용자 면담 정리
-사용자 면담 시 제공된 자료의 샘플이나 관련 문서를 체계적으로 정리 기록
2)업무 조사서 정리
-회사 차원에서 활용하는 업무 문서 및 팀에서 사용하는 업무 문서를 포함하여 전체 리스트를 파악 할 수 있도록 체계적인 양식으로 정리
#수행 중인 프로세스 목록
-대/중/소 분류별 프로세스명
-프로세스 설명 및 수행 빈도
-전산화 정도 / 전산화 필요성
#프로세스의 업무 흐름
-정보시스템을 포함하여 관련 부서 간의 업무 흐름을 시스템 흐름도 형태로 도식화
#타부서 또는 외부 기관으로부터 받은 문서
- 문서명 및 설명
- 접수 부서(기관)
- 접수 주기, 접수 수단
- 활용 형태 / 단위 문서량
#사용 중인 시스템
- 시스템명
- 사용 범위, 사용 방법, 사용 빈도
- 유용성
- 편리성
3)워크숍 정리
워크숍의 목적
워크숍 진행 내용
해결과제에 대한 상태
기타 특이사항
나.정보 요구 우선순위 분석
-사용자로부터 수집된 모든 정보 요구 사항을 전부 시스템에 반영할 수 없다면, 필요한 기법을 동원하여 우선순위를 부여하고 부여된 우선순위에 맞게 절차적으로 진행
1)화폐가치 산출방법
-최종적으로 구해진 가치가 높을수록 우선순위가 높음
-정보 요구 사항을 전부 나열
-정보 요구 사항에 대하여 기업 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여
-정보 요구 사항에 대하여 시스템 차원의 중요성을 평가하여 1점부터 3점까지의 점수를 부여
-정보 요구 사항이 다른 정보 요구 사항에 대해 얼마나 도움을 주는가(상호관련성)를 평가하여 1점부터 5점까지의 점수를 부여
-앞서 부여한 세 가지 점수를 모두 곱함
-전체 정보 요구 사항에 대하여 앞서 계산된 점수를 더하고, 점수 합계를 100으로 하여 각각의 정보 요구 사항 가치를 백분율(%)로 환산
-회사 전체의 이익에 앞에서 구한 백분율을 곱하여 각각의 정보 요구 사항 가치를 금액으로 환산
2)상대적 중요도 산정 방법
-정보 요구 사항이 무엇을 지원하느냐에 따라 점수를 부여하고 이를 가중치에 따라 계산하여 중요도를 산정하는 방식
-정보 요구 사항이 업무에 기여하는 수준에 따라 1점부터 5점까지의 점수를 부여. 목적을 지원하면 5점, 목표를 지원하면 4점, 전략을 지원하면 3점 등의 방법으로 업무를 분류한 체계에 따라 결정
-정보 요구 사항 대 정보 요구 사항 매트릭스를 작성하여, 각각의 정보 요구 사항이 다른 정보 요구 사항에 얼마나 관련되어 있는가를 계산.
가장 관련이 큰 정보 요구 사항에 9점을 부여하고, 나머지 정보 요구사항에는 상대 점수를 부여
-정보시스템이 각각의 정보 요구 사항을 얼마나 충족하는가에 대하여 1점에서 3점까지의 점수를 부여. 만족스러운 경우에는 3점, 보통인 경우에는 2점, 지원하지 않는 경우에는 1점 등
-앞서 부여한 세가지 점수에 대하여 가중치를 결정. 예를 들어 업무 지원 정도는 50%, 다른 정보 요구 사항과의 관련도는 20%, 현행 시스템 지원 정도는 30% 등의 방법으로 정하되, 기업의 특성을 감안하여 결정.
-가중치에 따라 앞에서 계산한 세 가지 요인의 가중 평균을 구하여 각각의 정보 요구 사항에 대한 중요도를 평가.
제3절 정보 요구 사항 통합
가.정보요구사항 목록 검토
-전사 관점에서 동일한 정보 요구사항을 여러 부서 및 사용자가 제시했는지를 검토하기 위하여 별도의 양식으로 취합 조정한 후 중복 도출 여부를 검토
나.정보 요구사항 목록 통합/분할
-취합된 전체 정보 요구사항을 대상으로 최종 분석할 정보 요구사항을 도출
1)동일 부서 내 중복 요구사항 검토
-부서 내 정보 요구사항 목록을 작성.
-정보 요구사항 제목을 기준으로 부서 내 동일 요건의 요구사항 존재여부 파악.
-정보 요구사항의 세부 요청 내용을 기준으로 세밀하게 중복 여부를 파악
-부서 내 동일 요건이 도출된 경우 관리대상 요구사항에 통합할 정보 요구 번호를 ‘비고’란에 기입.
-동일 부서 내 중복성을 배재한 요구사항 목록을 완성.
2)서로 다른 부서간 중복 요구사항 검토
-부서 내 정리된 정보 요구사항 목록과 부서간에 동일한 정보 요구사항 존재여부 파악.
-정보 요구사항의 세부 내용을 세밀하게 검토하여 중복여부를 파악.
-부서 간에 동일 요건이 도출된 경우 관리 대상 요구사항에 통합할 정보 요구 번호를 기입하여 관리.
-최종적으로 전사 관점의 검토된 정보 요구사항 목록을 작성.
제3장 정보 요구사항 분석
제1절 분석 대상 정의
-사용자로부터 수집한 정보 요구 사항을 바탕으로 업무 현황을 파악. 이를 근간으로 관련 업무 및 시스템의 문서를 조사, 수집 및 파악함으로써 현행 업무 및 현행 시스템에 대한 분석 대상을 정의
가.현행 업무 분석 대상 정의
1)분석 대상 자료
-현행 업무 흐름도, 현행 업무 설명서, 현행 업무 분장 기술서
2)분석 대상 업무 영역 선정
-수집된 사용자의 정보 요구 사항을 바탕으로 현행의 업무흐름 및 관련 데이터를 파악하여 분류기준에 따라 분석 대상 현행 업무 목록을 작성
-작성된 분석 목록을 가지고 정보 요구 사항 분석을 위한 대상으로 선정할 것인지 결정을 하고 분석 대상 업무 목록표에 표기.
-분류기준: 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무분장상의 구분 등
나.현행 시스템 분석 대상 정의
1)분석 대상 현행 시스템 선정
-정리된 정보 요구 사항에 대해서 업무 영역별 분석 대상 현행 시스템을 선정하기 위하여 업무 영역/현행 시스템 매트릭스를 작성
-업무 영역/현행 시스템 매트릭스를 바탕으로 업무 영역별 분석 대상 시스템 목록을 작성
2)분석 대상 현행 시스템 관련 자료
-현행 시스템 구성도
-현행 시스템의 분석, 설계 및 개발 보고서
-화면, 장표 및 보고서 레이아웃
-현행 시스템 테이블 목록 및 테이블 정의서
-프로그램 목록
-사용자 및 운영자 지침서
-시스템 지원 및 유지보수 이력
-시스템 개선 요구 사항 등
*수집된 문서의 평가 기준(완유정효)
-유용성 : 문서의 활용 가능성 여부
-완전성 : 문서의 내용에 누락된 부분이 없는지의 여부
-정확성 : 문서의 내용이 현재의 시스템과 일치하는지의 여부
-유효성 : 문서가 최신의 내용을 반영하고 있는지의 여부
3)추가적인 분석 대상
-현행 데이터 측면의 업무 요건 혹은 업무 규칙을 보다 상세하게 분석하기 위하여 사용자 뷰도 분석 대상에 포함
제2절 정보 요구 사항 상세화
-정보 요구 사항 분석 대상이 정의된 현행 업무 영역 관련 자료 및 현행 시스템 관련 자료에 대하여 분석을 하고, 분석 결과인 분석 산출물을 토대로 사용자의 정보 요구 사항을 보완하고 비기능적 정보 요구사항을 포함하여 문서 작업을 통한 정보 요구사항정의서를 보완
#비기능적 정보 요구 사항
-시스템이 만족시켜야 하는 제약 조건(기술적 제약 조건, H/W, S/W와 관련된 제약 조건)
-시스템이 반드시 만족시켜야 하는 주요 성능 척도(반응 시간, 저장 능력, 동시 처리 능력)
-신뢰성, 확장성, 이식성, 보안
가.프로세스 관점의 정보 요구사항 상세화
1)수행절차
-프로세스 중심으로 정리된 프로세스 목록, 프로세스의 업무 흐름도 내용을 수반하는 업무 조사서를 바탕으로 프로세스계층도, 프로세스정의서를 작성.
-도출된 기본 프로세스를 기준으로 기본 프로세스에서 필요로 하는 정보 항목과 산출되는 정보 항목을 정리하고, 산출되는 정보 항목 중 기본 로직이 필요한 경우 기본 로직을 정리
-표준화 과정을 통하여 해당 정보 항목에 대해서 통합성/분리성 여부를 검토한 후 최종적으로 사용자의 정보 요구 사항을 충족하는 정보 항목 목록을 정의
2)수행 작업 내용
#프로세스 분해/상세화
-단위 업무 기능별 하향식으로 프로세스를 분해 및 도출
- 프로세스 계층도 및 프로세스 정의서를 작성
#정보 항목 도출 및 표준화
- 기본 프로세스별 정보 항목을 정리
- 정보 항목에 대한 표준화 정리
- 정보 항목 목록 정의
#정보 항목별 통합성, 분리성 여부 검토
- 프로세스별로 관리되는 정보 항목을 분류
- 정보 항목별 동음이의, 이음동의 존재 여부 파악
- 통합/분리 여부 검토 후 최종 정보 항목 목록 정의
기능정의와 하부프로세스를 분해하여 논리적으로 계층화할때 분석기법: 가치사슬, 전문성, 생명주기는 모두 기업의 본원적 활동과 지원활동을 분류하고 체계화.
3)수행 작업 지침
#프로세스 분해 / 상세화
*프로세스의 분해
-프로세스의 분해는 단위 업무 기능으로부터 출발하여 점진적으로 수행
-단위 업무 기능은 하위에 더 이상 업무 기능을 포함하지 않고, 프로세스만으로 구성된 업무 기능을 의미
-단위 업무 기능별로 상세하게 프로세스를 분해하지 않고, 해당 업무 영역의 전체 단위 업무 기능에 대하여 프로세스의 분해 수준을 맞추어 점진적으로 분해
-업무 기능 계층도가 단위 업무 기능 수준까지 분해되지 않았을 경우에는 단위 업무 기능 수준까지 더 분해한 후 프로세스를 도출
*프로세스 분해 깊이
-프로세스 분해시 업무적인 특성을 고려하여 분해의 수준은 3차 수준까지 분해
-3차 수준까지 프로세스를 도출하는 과정에서 기본 프로세스 수준까지 도출되는 경우도 있음
-대상 범위의 모든 프로세스를 균형 있게 분해
-도출할 프로세스의 대상은 일반적으로 데이터의 상태를 변화시키는(생성, 수정, 삭제) 것만을 프로세스로 정의
*프로세스 명칭
-명명규칙을 준수하여 명명하되 업무 용어를 그대로 사용하고 이름만으로도 개략적인 수행 내용의 파악이 가능하도록 함축적이며 유일한 이름을 부여
*프로세스 계층도
-프로세스 계층도를 작성하는 목적이 기본 프로세스의 도출
-프로세스 계층도는 높은 응집도 및 낮은 결합도를 유지하도록 모듈성을 확보
-프로세스정의서(설명)는 업무를 구체적으로 이해할 수 있는 수준으로 상세하게 작성. 기본 프로세스의 경우에는 반드시 작성
-작성된 프로세스 계층도를 재검토해 해당 업무 영역에 포함되는 모든 업무 요건 및 업무 규칙이 반영되었는지 확인하고, 프로세스 계층도를 조정
-현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무의 최소 단위인 기본 프로세스까지 도출
#정보 항목 도출 및 표준화
-프로세스 분해 및 상세화에서 도출한 기본 프로세스별로 등록(C), 조회(R), 변경(U), 삭제(D) 기능을 구분하여 기술
-기능에 따라 구분된 프로세스별로 정보 요구 분석에서 정의된 정보 요구 사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 정보 항목을 도출
-도출한 정보 항목은 명명규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술
#정보 항목별 통합성 검증
-정보 유형별 및 정보 항목별로 전사 관점에서의 통합/분리여부를 검토
*동일한 정보 항목에 대해서 통합시 장점
- 통합 정보 항목으로 도출 시 정보 항목의 관리가 용이함
- 동일한 유형의 정보 항목이 존재 시 통합 정보 유형으로 수용 가능
*단점
- 무리한 통합 작업으로 인한 정보 항목의 애매모호성 존재
-통합 정보 항목에 대한 관리 부족으로 통합의 의미 상실 가능성 존재
통합 작업 후 해당 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록을 작성
나.객체지향 관점의 정보 요구사항 상세화
-객체지향 방법론에서는 유즈케이스 다이어그램을 중심으로 정보시스템의 기능적 정보 요구 사항을 정의
1)유스케이스 다이어그램
액터(ACTOR)
정보시스템과 상호작용하는 개인, 그룹, 회사, 조직, 장비 등 정보 서비스를 받는 객체
엑터의 이름은 명확하게 액터의 역할을 나타내는 이름으로 정의
유스케이스(USECASE)
도출된 액터별로 개발 시스템에서 제공해야 하는 기능
사건 흐름에 대한 개요를 간략하게 기술
액터(ACTOR)와 유스케이스 간의 관계
-확장(Extend) : 하나의 유즈케이스가 다른 유즈케이스의 행동을 추가함에 따라 나타나는 두 유즈케이스의 관계. 하나의 유스케이스가 다른 유스케이스를 경우에 따라 선택적으로 수행되는 경우에 사용.
-포함(Include) : 하나의 유스케이스가 다른 유스케이스를 사용함을 나타내는 두 유스케이스의 관계. 하나의 유스케이스가 다른 유스케이스를 반드시 수행하는 경우에 사용
-Communicates : 행위자가 어떤 유즈케이스에 참가함을 나타냄. 이것은 행위자와 유스케이스 사이의 유일한 관계
2)유스케이스 상세화
-유즈케이스의 사건 흐름을 구조화하는 작업으로 모든 선택 또는 대안 흐름을 기술
-유스케이스에 대한 개략적인 설명
-사건 흐름(Flow or Event)
-사전, 사후 조건
-비기능 정보 요구 사항
-주된 사건 흐름에 대체될 수 있는 대안 흐름
-예외 처리 사항
3)클래스 다이어그램 작성
#엔티티 클래스 도출
-유즈케이스 모형을 검토하여 문제 영역 내의 개념을 나타내는 엔터티 클래스를 도출하여 정의
-유즈케이스 다이어그램을 조사하여 명사 및 명사구를 후보 객체로 선정
-의미가 모호한 것은 제거
-이음동의어 및 동음이의어를 고려하여 선정
-문제 영역과 관련이 없는 것은 제거
-유사한 구조와 행위를 가진 객체들을 클래스로 그룹핑
#관계 도출 및 클래스 도출
-관계란 의미있고 관심있는 연결을 나타내는 클래스간의 관계. 클래스간의 집단화 관계를 식별하고 명명
#속성 정의
-속성이란 클래스가 나타내는 객체의 특성. 유즈케이스 다이어그램을 검토하여 클래스를 구성하는 속성을 도출
제3절 정보 요구 사항 확인
-사용자 및 부서로부터 접수해서 최종적으로 작성된 산출물에 대해 정보 요구 사항을 제시한 담당자와 세부 재검토를 통하여 누락 사항 및 보완 사항을 도출하기 위한 계획을 수립하고 재검토를 실시
가.수행절차
-분석 결과 도출된 산출물에 대해서 재검토 기준을 정의하고, 재검토 계획 수립
-재검토 대상 산출물의 완전성, 정확성, 일관성, 안정성 등 다양한 측면에서 재검토를 실시
-재검토 결과, 추가 및 보완 사항이 존재하는 경우에 내용을 문서로 정리한 후 해당 산출물에 추가 반영 여부를 확인하고, 미반영시 미반영 사유의 타당성을 검토
나.수행작업 내용
#재검토 계획 수립
-재검토의 대상이 되는 분석 결과 및 정보 요구 사항 정의서 산출물 확인
- 대상 산출물별로 재검토 기준(체크리스트) 정의
#재검토 실시
- 재검토 계획서 작성 및 승인
- 재검토 대상 산출물 준비 및 배포와 재검토 담당자별 역할 분담
- 업무 영역별로 재검토 대상 산출물을 재검토
#보완 결과 확인
- 재검토 결과를 토대로 업무 영역별로 산출물 보완
- 재검토 결과 반영 여부 확인 및 미반영 사유 검토
- 정보 요구 사항 정의서의 안정성 분석
- 재검토 결과를 토대로 보완 목록 수정
다.수행작업 지침
1)재검토 계획 수립
-재검토 대상이 되는 분석 결과 산출물을 확인
#검증기준(완정일안)
-완전성: 사용자의 정보 요구 사항이 누락없이 모두 정의되었는지 확인
-정확성: 사용자의 정보 요구 사항이 정확히 표현되었는지의 여부
-일관성: 표준화 준수 여부 확인
-안정성: 추가 정보 요구 사항 변경에 따른 영향도 파악
#재검토 계획서에 포함되어야 할 사항
-정보 요구 사항 재검토 개요 및 목적
-재검토 일자
-재검토 장소 및 시간 계획
-재검토 참석 대상 및 재검토 업무
-참석 대상별 재검토 세부 시간 계획
-재검토 준비물
-재검토 후 산출물
-재검토 후 지적사항 반영 계획 수립
2)재검토 실시
-재검토 기준 및 재검토 대상 산출물을 준비하고 재검토에 참여할 대상자에게 배포
-재검토 관련 장소, 시간, 준비 장비 등 재검토를 실시하기 위한 제반 준비를 수행하며, 재검토 담당자별로 재검토 세션에서 수행해야 할 역할을 충분히 주지시킴
-재검토 세션 실시 이전에 반드시 배포된 산출물을 예습. 실제 재검토 세션에서의 재검토는 재검토한 결과를 토대로 의문사항, 잘못 정의된 사항 등에 대하여 의견을 개진하고 결론을 도출하여 반영 대상을 정리.
-재검토시 진행자는 제기되는 이슈에 대해서 참석자들간에 결론을 도출하기 위한 토론이 발생하지 않도록 이슈 목록으로 정리
-재검토시에는 통합성 검증을 위하여 해당 업무 영역과 관련 있는 업무 영역 담당자가 참여
-재검토는 많은 인원이 함께 작업을 수행하는 경우에, 진행시간이 초과되어 충분한 검증이 이루어지지 못할 수도 있으므로, 진행자는 세션별로 적절한 시간 배분 및 조정
-재검토 세션이 종료되면 세션별로 그 결과를 재검토 결과로 정리
3)보완 결과 확인
-재검토 준비와 마찬가지로 보완 결과에 대한 확인 준비.
-재검토 결과, 보완 목록, 보완 사항이 반영된 정보 요구 사항 정의서를 준비하고 배포
-보완 목록에 준하여 정보 요구 사항 정의서 반영 여부 확인.
-검토 결과 미반영 사유가 업무 규칙이나 정책의 변경을 수반하는 경우에 프로젝트 기간 내에 해결 가능한 것은 개선과제로 정리하여 해당 부서에 의뢰
-보완 목록에 있는 보완 사항이 모델에 모두 반영된 것을 확인하면 본 작업은 종료
라.재검토 수행시 고려사항
-일관성 있는 기준 및 명확한 일정을 수립함으로써 모든 참여 인력에 공감대를 형성하는 것이 중요
-재검토는 한번으로 종료되지 않는 것이 보통이므로 두번 이상을 진행하되 세션마다 재검토 기준을 명확히 하여 해당 기준에 초점을 맞추어 수행
-재검토 세션을 수행시 세션 진행의 효율성을 감안하여 적정한 참여 대상을 선정
제4장 정보 요구 사항 명세화
제1절 정보 요구 사항 명세 정의
1.정보요구사항명세정의
-정보요구분석명세서는 분석가가 작성하지만 쉽지 않음
2.요구분석명세서작성시 주의사항
-사용자가 쉽게 읽고 이해할 수 있도록 작성
-개발자가 설계와 코딩에 효과적으로 사용할 수 있도록 작성
-비기능적 요구를 명확히 작성
-테스트 기준 용도로 사용할 수 있도록 정량적으로 작성
-품질에 대한 우선순위 명시
1.요구사항 상세내역 작성
고유번호, 명칭, 분류, 상세설명(정의, 세부내용), 산출정보, 관련요구사항, 요구사항출처
2.요구사항 상세내역 작성시 고려사항
-초기 자료구축 및 데이터 이관을 위해서는 데이터의 자료명, 자료내용, 자료의 크기, 건수*주기, 보존기한,예상 자료량, 자료형태, 자료 위치 등을 파악
-대상자료 중 지적재산권 및 보안과 관련된 문제가 수반되는 부분에 대해서 구축 가능 여부를 확인하고, 데이터 전환 시 수행 시간, 데이터 표준화 등 제약사항이 존재하는지 파악
-데이터 요구 사항과 기능 요구 사항 사이에는 추적관리가 되어야 함
제5장 정보 요구 사항 검증 및 변경 관리
제1절 정보요구사항 검증 정의
#요구사항검증활동
-요구사항명세서 검토
-요구사항 용어 검증: 일관성,표준성,이해용이성
-요구사항 베이스라인 설정: 공식검토, 승인
제2절 정보 요구 사항 상관분석 기법
-도출된 정보 요구 사항을 다른 영역(기능, 프로세스, 조직 등)과 비교 분석함으로써 정보 요구 사항의 도출이 완전하게 효과적으로 이루어졌는지를 파악
가.주체별 분류
1)요구사항 분석가 수행
-정보 요구 사항을 수집하고 분석한 주 담당자를 기준으로 검토 기준 항목을 마련하고 상관분석을 수행하는 방법
-정보 요구 사항을 도출한 분석가에 의해 수행되므로 자체 분석에 의한 객관성 저하의 문제점 발생가능
-정보 요구 사항의 도출 절차 및 관련 업무팀과의 의사소통이 원활하므로 상관분석에 추가 인력의 투입 없이 원활하게 진행
-요구 사항 분석가의 업무에 대한 이해도가 높으므로 상관분석을 통한 정확한 업무의 분석 가능성이 높음
2)품질보증팀 수행
-프로젝트팀 내의 통합 검토팀이나 품질보증팀의 협조를 얻어 도출된 정보 요구 사항의 상관분석을 수행
-요구 사항 분석가보다 업무에 대한 이해도가 낮으나 상관분석 작업의 수행을 통한 업무 이해도를 높일 수 있으며 전체적인 인터페이스의 검증에 용이
-낮은 업무의 이해도로 인해 일부 사안에 대한 정확한 분석을 통해 단점을 지적하여 수정하기 어려움.
3)외부 감리 수행
-외부 감리 인력을 이용한 정보 요구 사항 상관분석을 수행
-업무 파악의 한계가 있으나 제 3자의 시각으로 검토
-프로젝트 내부 인력이 효과적으로 지원하지 않을 경우 상황에 맞지 않는 분석 결과를 초래
-상관분석의 객관성 극대화
나.정보 요구/애플리케이션 상관분석
-정보 요구 사항을 바탕으로 도출된 정보 항목을 애플리케이션 아키텍처에서 정의된 프로세스 모델과 비교하여 상호간의 일관성을 확보하고 품질 수준을 향상시키는 동시에 누락 혹은 중복된 정보 요구 사항을 점검
-정보 요구/애플리케이션 상관분석을 위해 정보 요구 사항을 바탕으로 도출된 정보 항목들과 애플리케이션 영역에서 도출한 기본 프로세스를 사용하여 매트릭스를 작성
-매트릭스 분석은 기본 프로세스와 정보 요구 사항을 기반으로 기본 프로세스의 액션 (C: 생성, R: 조회, U: 수정, D: 삭제)을 빠짐없이 정의
-매트릭스의 각 셀에는 기본 프로세스가 사용하는 정보 항목에 대한 액션이 생성(C), 조회(R), 수정(U), 삭제(D)로 표현되는데, 복수의 액션이 발생할 경우에는 C > D > U > R의 우선순위에 따라 하나만 기록
-모든 정보 항목이 모든 기본 프로세스에서 사용되었는지 혹은 모든 정보 항목을 사용하고 있는지 확인
-정보 요구/애플리케이션 상관분석 매트릭스는 두 가지 객체 중에서 한가지가 누락되거나 잘못 정의된 경우에는 분석이 가능하지만 정보 항목과 기본 프로세스가 모두 누락된 경우에는 분석이 불가능. 사전확인 필요
다.정보 요구/업무 기능 상관분석
-정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 업무 기능과 비교하여 상호 간의 일관성을 확보하고 품질수준을 향상시키는 동시에 누락 및 중복된 정보 요구 사항을 점검
-가치 사슬 분석 등의 기법을 통해 도출된 최하위 수준의 전사 업무 기능을 도출하고 이렇게 도출된 업무 기능을 매트릭스의 열에 배치
-정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치
-업무 기능과 정보 항목 간의 상호작용을 정의. C(Create, Change), U(Use)
라.정보 요구/조직 기능 상관분석
-정보 요구 사항을 바탕으로 도출된 정보 항목을 비즈니스 아키텍처에서 도출된 조직 단위와의 매트릭스 분석을 통해 정보 항목의 생성 주체 및 활용 부서의 매핑이 가능
-조직 단위명은 기업의 조직도에 나타난 순서로 입력
-정보 요구 사항에 따라 도출된 정보 항목을 매트릭스의 행에 배치
-조직과 정보 항목 간의 상호작용을 정의. C(Create, Change), U(Use)
제3절 3추가 및 삭제 정보 요구 사항 도출
가.정보 요구/애플리케이션 상관분석
1)애플리케이션 충족도 분석 매트릭스
#점검 기준
-정보 요구 사항에 따라 발생하는 정보 항목을 생성하는 기본 프로세스가 반드시 존재
-정보 항목의 상태를 종료시키는 기본 프로세스가 존재
-생성된 정보 항목은 조회, 수정, 삭제 액션 중 하나가 발생
-하나의 정보 항목을 생성, 수정, 삭제하는 프로세스의 합은 7개를 초과하지 않는 것이 보통. 이를 초과하는 경우에는 올바르게 정의되었는지를 확인
-수작업으로 정의하거나 조회 전용으로 특별히 정의된 기본 프로세스를 제외한 나머지의 기본 프로세스는 반드시 생성, 수정, 삭제 액션 중의 하나를 수행
2)매트릭스 분석
점검내용 | 분석결과 | 조치사항 |
기본 프로세스가 사용 (CRUD)하는 정보 항목이 없음 | 정보항목 누락 | 정보항목 도출 |
기본프로세스 필요없음 | 기본 프로세스 삭제 | |
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 | 해당업무영역으로 이동 | |
정보 항목이 7개 이상의 기본 프로세스에서 사용됨 | 정보항목이 너무 큼 | 정보항목 세분화 |
정보 항목을 생성하는 기본 프로세스가 없음 | 기본프로세스의 누락 | 기본프로세스 도출 |
정보항목이 필요없음 | 정보항목삭제 | |
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 | 해당업무영역으로 이동 | |
정보 항목을 생성하는 기본 프로세스가 둘 이상 존재 | 기본 프로세스 중복 | 기본프로세스 통합 |
정보 항목을 삭제하는 기본 프로세스가 없음 | 기본프로세스 누락 | 기본프로세스도출 |
업무에 삭제가 존재하지 않음 | 전산오류시 삭제가 필요한지 확인 | |
기본 프로세스가 분석 대상 업무 영역에 속하지 않음 | 해당업무영역으로 이동 | |
정보 항목을 삭제하는 기본 프로세스가 둘 이상 존재 | 기본 프로세스 중복 | 기본프로세스 통합 |
정보 항목이 생성만 되고 사용되는 곳이 없음 | 기본 프로세스 누락 | 기본프로세스 도출 |
기본 프로세스가 정보 항목을 조회만 함 | 기본 프로세스가 아님 | 모듈검토 |
기본 프로세스가 여러 액션을 수행함 | 정의된 기본 프로세스가 너무 큼 | 프로세스 추가분해 |
나.정보 요구/업무 기능 상관 분석
#매트릭스 분석
-모든 업무 기능은 정보 항목과 연관이 있는가?
-각 정보 항목은 적어도 한번 이상의‘C’를 갖는가?
-생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?
#정보 항목과 연관성이 없는 업무 기능은 관련 팀과의 협의 하에 업무 기능 도출의 적절성이나 관련 정보 항목을 다시 파악하고, 이를 바탕으로 매트릭스를 보완
#정보 항목에 매핑이 없는 업무 기능의 경우 관련 팀과 협의하여 정보 요구 사항 보유 여부를 확인한 후 추가적인 정보 요구 사항이 있을 경우 정보 요구 조사 프로세스에 따라 정보 요구 목록에 신규로 추가
다.정보 요구/조직 기능 상관분석
#매트릭스 분석
모든 업무 기능은 정보 항목과 연관이 있는가?
각 정보 항목은 적어도 한번 이상의‘C’를 갖는가?
생성된 정보 항목은 다른 업무 기능에 의해 사용( ‘U’)되는가? 이것은 정말 단순조회인가?
#정보 항목의 활용도를 파악할 수 있으며, 정보 항목의 수요가 많은 경우에는 해당 정보 항목의 물리 모델링 단계에 성능/활용 측면의 모델링 기법을 적용함으로써 정보 활용의 효율성 확보
#정보 항목을 생성하는 조직 단위가 복수로 존재할 경우 데이터 관리의 복잡성으로 인해 향후 문제가 발생할 수 있으므로 해당 정보 항목에 대한 데이터 관리 주체의 선정에 주의
제4절 정보요구사항 변경 관리
-프로젝트 진행과정에서 발생하는 요구사항 변경에 대하여 일치성과 무결성을 제공하기 위하여 변경제어와 추적등의 활동을 수행
-요구사항 변경제어: 비용, 일정 등에 따라 변경 식별 및 평가, 제어 및 재설정
-요구사항 추적제어: 요구사항변경에 영향을 받는 요구사항 추적
-요구사항 버전제어: 형상관리 기반으로 요구사항 명세 베이스라인과 요구사항 관리공정 전과정에 걸쳐 축적된 모든 요구사항 정보를 관리
1.요구사항 추적
2.요구사항 변경요청
-고객이나 사용자, 외부환경의 원인에 의해 발생
-변경요청서를 작성
3.변경 영향분석
-변경요청서에 영향분석 기록
4.변경 승인/기각
-변경통제위원회(CCB)는 발주자측 사업책임자와 사업자측 PM이 함께 협의하여 수용여부를 최종 결정
-양측간 대립으로 결정이 불가한 경우, 상위 의사결정위원회가 결정
'IT 자격증 > DAP,DAsP' 카테고리의 다른 글
DAP 6과목 데이터 품질 관리 이해 (0) | 2024.05.14 |
---|---|
DAP 5과목 데이터베이스 설계와 이용 (0) | 2024.05.14 |
DAP 4과목 데이터 모델링 (0) | 2024.05.14 |
DAP 3과목 데이터 표준화 (0) | 2024.05.13 |
DAP 1과목 전사아키텍처 이해 (0) | 2024.05.13 |