제2절 정보 요구 사항 관리

1. 정의 및 관리 목적

정보 요구 사항을 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차를 말한다. 정보 요구 사항을 종합적으로 검토, 확인함으로써 요건에 맞는 정보시스템을 개발하여 사용자의 만족도를 높인다.
정보 요구 사항 관리는 데이터, 애플리케이션, 비즈니스 등의 요구 사항을 전부 포함하는 통합 관리 프로세스를 정립해야 한다.

2. 정보 요구 사항 관리 프로세스

가. 업무흐름 프로세스

사용자로부터 정보 요구 사항을 접수하고, 반영 여부를 결정하여 통보하고, 최종적으로 시스템 개 발로 완료되는 전체적인 업무 흐름 프로세스는 [그림 2-1-4]와 같다.

[그림 2-1-4] 정보 요구 사항 업무 흐름 프로세스
요구 사항 발송

사용자가 정보시스템을 활용하면서 발생하는 불편 사항이나 신규 개발 사항 등의 요건을 정보 요 구 사항 정의서 양식에 기록하여 정보시스템 담당자에게 발송한다. 정보 요구 사항 정의서는 [그림 2-1-5]와 같이 구성할 수 있다.

요구 사항 수렴

사용자로부터 접수한 정보 요구 사항 정의서를 수집하여 규칙에 맞게 정확하게 정의했는지 확인하 고, 해당 요건을 검토할 처리 담당자를 지정하여 이송한다.

요구 사항 검토

요청된 정보 요구 사항과 관련된 자료 및 작성 기준, 구성요소, 원칙 등을 확인해서 반영 여부를 판단한다. 반영이 가능한 경우는 개발 물량, 협조 담당자, 관련자 등의 영향도 분석을 한다. 반영이 불가능한 경우는 미반영 사유와 함께 요건을 발송한 담당자에게 재전달하여 결과를 알 수 있게 한다.

영향도 분석

요청된 내역을 토대로 신규 개발 및 변경에 따른 영향이 얼마나 되며, 이로 인해 영향을 받는 설계서, 기존 애플리케이션, 데이터베이스 등을 파악해서 영향도 분석을 마무리한다.

공식화

영향도 분석 후 관련되는 담당자를 소집하여 의견을 공유하고, 담당자들과의 협의를 통해 반영 유형을 결정한다. 반영 유형은 규모 및 기간, 시급성에 따라 결정되며 처리 방법은 신규 시스템 개발 또는 기존 시스템 변경에 의해 발생한다.

반영 작업 계획 수립

영향 분석 결과를 근거로 업무 영역 및 관련 담당자들과의 미팅 후 반영 계획을 수립한다. 작업 일정 계획에는 표준과 설계서 변경, 데이터베이스 및 애플리케이션 수정, 테스트, 이관 등의 작업이 명시되어야 한다.

[그림 2-1-5] 정보 요구 사항 정의서 예

나. 수행 조직 및 수행 업무

사용자 정보 요구 사항을 반영하기 위해 필요한 역할별 담당 업무는 [표 3-1-2]과 같다.

[표 2-1-2] 역할별 담당 업무

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

장 요약

제1절 정보 요구 사항
- 사용자의 정보 요구 사항이란 사용자가 일반적으로 수행하는 과정에서 정보시스템 개발의 필요성에 의해 수집되고 요약된 요청 사항이다.
- 정보 요구 사항은 요구 사항 수집, 요구 사항 분석 및 정의, 요구 사항 상세화, 요구 사항 검증의 단계로 진행된다.
- 사용자의 정보 요구 사항을 유형별로 분류하면 인터페이스 요건, 기능 개선 요건, 성능 개선 요건, 보안 개선 요건의 4가지로 분류할 수 있다.
제2절 정보 요구 사항 관리
- 정보 요구 사항은 통합적인 관점에서 관리되어야 하며, 데이터나 애플리케이션 한쪽만 반영된 요구 사항 관리는 적절하지 못하다.
- 정보 요구 사항을 관리하기 위한 프로세스는 6개의 주요 모듈로 이루어져 있다(요구 사항 발송, 요구 사항 수렴, 요구 사항 검토, 영향도 분석, 공식화, 반영 작업 계획 수립).
- 사용자 정보 요구 사항을 반영하기 위해 사용자는 요청 사항 중 미결 사항이 있는 경우 담당자와 확인을 통해 확정해야 한다.
- 데이터아키텍처 전문가는 전체적인 표준 및 애플리케이션에 대한 영향도 분석을 한다.

연습문제

문제 1. K대리는 그 동안 현장에서 영업을 하면서 불편했던 업무적인 보완사항과 신규 개발사항들을 이번 프로젝트를 통해서 시스템에 적용하고자 한다. 다음 중 이러한 상황에서프로젝트 팀에게 전달해야 문서로 적합한 것은?

① 정보 분석서
② 정보 요구 사항
③ 정보 목록
④ 정보 항목 분류표

정보분석서는 대상이 되는 시스템 분석을 분석한 후 결과를 정리한 문서이다. 정보 목록은 취합된 요구 사항을 목록화 한 것이나 어떤 프로그램을 목록화 한 것이다. 정보 항목 분류표는 정보 요구사항에 포함된 항목을 분류한 것이다.

문제 2. K대리는 전사 자원관리 프로젝트를 위해 사내 부서들과 사전 협의를 통해 분석 단계의 주요 소스로 사용될 사용자 및 시스템 관점의 정보 요구 사항들을 수집하고 있다.다음 중 현 단계의 문서로 부적합한 것은?

① 현행 시스템 분석서
② 현행 사용자 요구 사항 정리문서
③ 현행 업무처리 매뉴얼
④ 현행 시스템 개선과제 및 문제점 정리문서

세 가지 문서에 비해 상대적으로 현행 업무처리 매뉴얼은 적당한 문서가 아니다. 세부 분석 단계에 있어서 개별 업무를 정확하게 이해하기 위해서는 꼭 필요한 문서이나 초기에 정보 요구 사항을 수집하기에는 세 가지 문서에 비해 부적절하다.

문제 3. A기업은 재무정보시스템 구축 프로젝트의 분석단계에서 사용자의 정보 요구 사항을수집 및 정리하는 작업을 진행 중이다. 수집된 정보 요구 사항을 정리하는 과정에서정보 요구 사항의 유형을 외부 인터페이스, 기능, 성능, 보안 등의 개선요건으로 구분하였다. 다음 중 정보 요구 사항 유형에 대한 관리기준으로 부적절한 것은?

① 외부 인터페이스 : 기존과 동일한 형태의 인터페이스 존재 여부
② 보안 개선 : 측정이 불가능한 형태 판단 여부
③ 기능 개선 : 많은 사용자가 편리하게 사용할 수 있는 요건의 우선 적용 여부
④ 성능 개선: 현행 기술 수준과 서비스 특성을 고려한 구현 가능 여부

보안 개선 요건에 대한 관리 기준은 불가변성(향후에 재변경 되지 않도록 근본적인 개선 방안인지 여부), 실현 가능성(현행 기술 수준과 서비스 특징을 고려하여 구현 가능 여부) 등이다. 2번에서 제시한 측정가능성은 성능 개선 요건에 대한 관리기준에 해당한다.

문제 4. 기획부서로부터 ‘월별 영업점 상품 실적’ 화면에 대한 수정·보완 의뢰서를 접수하였다. 다음 중 이를 반영하기 위해서는 어떤 영향을 미치는지 전체적인 영향도 분석 및조사를 실시하기에 가장 적합한 사람은?

① 요구 사항을 요청한 사람
② 전사 관점의 데이터아키텍처 담당자
③ 요구 사항을 개발하는 담당자
④ 담당 부서의 관리자

전체적인 프로그램이나 데이터베이스 관리 요소에 대한 이해를 하고 있고, 표준절차에 따라 수행이 가능한 데이터아키텍처 담당자가 다른 사람들 보다는 가장 적합하다.

문제 5. A기업의 H대리는 회계팀 P과장으로부터 현행 시스템의 불편사항을 해결해달라는 요건을 접수받았다. P과장의 불편사항 중 하나는 매일아침 당일의 B/S(재무제표) 실적을 조회하는데, 동시 사용자 수가 많아서 처리시간이 과다하게 소요되어 불편하다는것이었다. 다음 중 접수받은 요건을 분류하여 담당자에게 할당하려고 할 때, 분류 유형으로 적합한 것은?

① 보안 개선 요건
② 성능 개선 요건
③ 기능 개선 요건
④ 외부 인터페이스 개선 요건

P과장에게 접수한 요건은 사용자 인터페이스 성능을 개선해 달라는 시스템의 성능에 관한 요건으로 분류할 수 있다. 따라서 업무담당자 보다는 시스템의 하드웨어를 담당하는 쪽으로 할당하는 것이 바람직하다.