1. 정보 요구사항 개요
정보 요구사항
업무의 개선 사항이나 신규 개발 사항으로 시스템을 통해 기능상의 목적을 달성하기 위해 요청하는 내용
→ 일반적으로 사용자가 해당 시스템에 대해 바라는 것이 무엇인지 기술한 것
정보 요구사항 생명주기 모형
정보 요구사항 수집→정보 요구사항 분석/정의→정보 요구사항 상세화→정보 요구사항 검증
정보 요구사항 유형
외부 인터페이스요건,기능 개선요건,성능 개선요건,보안 개선요건외부 인터페이스 요건
- 정의 : 모든 입출력에 관한 요건으로서 내외기관 간의 송수신하는 입출력 방식이 추가, 변경되었을 경우와 각종 제도 및 기준 변경 시 발생하는 요건
- 관리 기준
중복성: 기존에 동일한 인터페이스가 존재하는지 체크표준 준수도: 관련 국제, 국가 표준 존재 시 그에 적합한 형태로 제공해야 함`기능개선 요건
- 정의 : 시스템에서 입력을 받아들여 처러하고 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건
- 관리 기준
불가변성: 향후에 재변경되지 않도록 근본적인 개선방안 요청범용성: 많은 사용자가 편리하게 사용할 수 있는 내용 우선 요청 `성능개선 요건
- 정의 : 동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소요시한 등
- 관리 기준
실현 가능성: 현행 기술 수준과 서비스 특성을 고려해 구현 가능한지 확인 후 제시해야 한다측정 가능성: 측정이 불가능한 모호한 형태로 제시하면 안됨`보안개선 요건
- 정의 : 물리적 접근통제 (제한구역, 통제구역 등) 및 사용 통제(인증, 암호화, 방화벽 등)에 대한 요건을 말한다.
- 관리 기준
- 보안관리가 필요한 장비에 대한 등급 관리가 필요하고 해당 등급별 이용자 등급관리가 필요하며, 접근 방식에 대한 기준이 있어야 한다.
- 해당 기준에 따라 모니터링 작업을 통해 안정적인 서비스가 제공되도록 관리해야 한다.
※ 매트릭스 분석에서 기본프로세스가 사용하는 정보 항목이 없을 경우, 분석과 대처 방안으로 적절하지 않은 것은?
→ 정보 항목을 사용하는 프로세스가 여러 개일 수 있다. → 기본 프로세스를 합성해야 한다.
정보 요구사항 관리 프로세스
요구사항 발송→요구사항 수렴→요구사항 검토→반영 여부→영향도 분석→공식화→반영 작업 계획 수립→데이터 모델 변경,데이터 표준 변경
- 요구사항 발송 : 요구 사항 정의서 양식에 기록하여 정보시스템 담당자에게 발송한다.
- 요구사항 수렴 : 정보 요구사항 정의서를 수집 후 규칙에 맞는지 확인하고 해당 건을 처리할 담당자를 지정하여 이송한다.
- 요구사항 검토 : 반영 여부 판단하고 불가능할 경우 미반영 사유와 함께 발송한 담당자에게 전달한다.
- 영향도 분석 : 영향을 받는 설계서, 기존 어플리케이션, 데이터베이스 등을 파악한다.
- 공식화 : 담당자들과의 협의를 통해 규모 및 시간, 시급성에 따라 반영 유형을 결정한다.
- 반영 작업 계획 수립 : 영향 분석 결과를 근거로 관련 담당자들과의 미팅 후 반영 계획 수립한다. 작업 일정 계획에는 표준과 설계서 변경, 데이터베이스 및 어플리케이션 수정, 테스트, 이관 등의 작업이 명시되어야 한다.
2. 정보 요구사항 조사
정보 요구사항 수집 형태
- 요구 : 시스템이 가져야 할 기능이나 시스템이 만족하여야 할 조건
- 기능 요구 : 데이터 등록, 조회, 수정, 삭제 등의 업무적으로 필요한 사항
→ 구현 기술과 별개, 시스템이 사용자를 위해 무엇을 하는가를 거시적으로 기술해야 함- 비기능 요구 : 성능, 효율, 반응 시간, 제약 조건 등의 시스템(H/W)적으로 필요한 사항
→ 신뢰성, 확장성, 이식성, 보안이 중요함
→ 시스템이 수행하는 기능 이외의 사항
→ 비기능적 요구가 만족되지 못하면 시스템 자체가 쓸모없게 될 수 있기 때문에 기능적 요구보다 더 중요할 수 있음
- 요구 사항 명세 : 요구사항 추출과 분석을 통해 얻어지는 "고객이 시스템에 요구하는 기능 또는 제약사항에 대한 설명"
→ 프로젝트 수주/발주를 위한 제안의 기초가 됨
→ 프로젝트 계약의 기초가 됨
면담 수행 시 고려사항
- 면담 시간 준수
- 비밀 보장
- 기대 수준 설정
- 면담 범위 준수
적절한대상자 선정 (무작위X)- 적절한 응답 유도
- 면담 내용 문서화
- 잘못된 선입견의 배제
- 애매한 질문의 배제
사용자 면담
- 실무자와 대면하여 질의응답을 통해 정보를 수집
- 개별 면담은 워크숍보다 융통성이 좋고 유연한 진행이 가능
- 적은 시간으로 면담이 가능하므로 일정 수립이 용이하고 추가 계획을 세우기가 쉽다
사용자 면담 진행 절차
계획 및 준비면담 일정, 면담 지침, 면담 요지, 기록 양식
면담 수행핵심 사항, 상세 면담 기록 책.임 소재, 분석 양식
면담 결과 분석면담 분석 결과, 현안 정보 요구, 정보화 과제
분석 결과 피드백면담 분석 결과 승인
워크숍 개요 및 목적
전문 진행자의 진행 하에 프로젝트의 현업부서, 전산부서 주요 구성원들이 함께 참여하는 회의로
정치적/개인적 요소를 피하고 다양한 정보를 빠르게 추출하여 공유할 수 있다.
- 경영층 또는 현업 부사장의 공토오딘 의견을 도출해낸다.
- 유사한 업무 또는 관련된 업무 등을 수행하는 부서를 따로 면담하는 데 드는 노력을 절감한다.
- 전문가들의 판단력을 이용하여 최적의 결론을 도출해낸다.
3. 정보 요구사항 분석
현행 업무 분석 대상 정의
- 분석 대상 자료 : 현행 업무 흐름도, 현행 업무 설명서, 현행 업무 분장 기술서
- 분석 대상 업무 영역 선정 : 분류기준에 따라 현행 업무 목록 작성
분류 기준이란 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무 분장상의 구분 등을 의미
현행 시스템 분석 대상 정의
- 분석 대상 현행 시스템 선정 : 업무 분석 프로젝트의 수행범위를 정확히 파악하는 것이 선행되어야만 업무 영역별 대상 현행 시스템 선정 작업이 가능
분석 대상 현행 시스템 관련 자료
- 현행 시스템 구성도
- 현행 시스템 분석, 설계 및 개발 보고서
- 화면, 장표 및 보고서 레이아웃
- 현행 시스템 테이블 목록 및 테이블 정의서
- 프로그램 목록
- 사용자 및 운영자 지침서
- 시스템 지원 및 유지보수 이력
- 시스템 개선 요구 사항 등
수집된 문서 평가 수행 기준
유용성: 문서 활용 가능성완전성: 문서 내용에 누락된 부분정확성: 현재 시스템 일치 여부유효성: 문서가 최신 내용 유지
객체지향 관점의 정보 요구사항 상세화
유즈케이스 다이어그램
액터와 유스케이스 간의 관계
- 확장
<<extend>>: 하나의 유스케이스가 다른 유스케이스의 행동을 추가함에 따라 나타나는 관계
→ 도움말이나 오류, 기타 예외적인 조건을 처리할 때- 포함
<<include>>: 하나의 유스케이스가 다른 유스케이스를 사용하는 것을 나타내는 관계
→ 한정된 개수의 유스케이스들이 공통으로 가지는 기능을 유스케이스로 나타낼 때- 참가 Communicate : 행위자가 어떤 유스케이스에 참가함을 나타냄, 행위자와 유스케이스 사이의 유일한 관계
