Developers Haven

(DH)블로그는 개발자들이 기술 정보를 찾아볼 수 있는 안식처가 되고 싶음을 희망하여 시작하게 되었습니다. 공부한 내용과 성장 과정을 기록해두었으니 편히 둘러보시길 바랍니다.

Welcome to DH's Blog

[자격증]/DAsP(데이터아키텍처 준전문가)

[DAsP 한 권으로 끝내기] Chapter2.데이터 요건 분석 - (1)

DH’s Blog 2023. 6. 3. 16:50
반응형

 

우선, 정보 요구사항을 수집하고 처리하는 전반적인 프로세스에 대해 간단히 알아보자.

 

👉 (아래 더보기) 이 단원을 시작하기 전에 복습해보는 개념

더보기

1. 정보 요구사항이란?

  • 사용자가 시스템에 바라는 기능상의 요구사항
  • 기존 시스템을 개선하거나 신규 시스템 개발을 위해 이용된다.

 

2. 정보 요구사항 처리 절차
📍 요구사항 수집 ⇒ 요구사항 분석 및 정의 ⇒ 요구사항 상세화 ⇒ 요구사항 검증

        (1) 요구사항 수집

                - 시스템 기능상에 원하는 것을 찾기 위해 인터뷰, 면담 등을 통해 요구사항을 수집


        (2) 요구사항 분석 및 정의

                - 수집된 요구사항 내용을 분석하여 중요도와 긴급성을 토대로 우선순위를 배정

 

        (3) 요구사항 상세화

                - 우선순위가 높은 요구사항을 중심으로 원하는 사항을 세부적으로 조사

 

        (4) 요구사항 검증
                - 조직 내의 다양한 관점(비즈니스, 어플리케이션 등)과 상관분석으로 요구사항을 검증

 

 

3. 정보 요구사항 관리의 업무 프로세스 (업무적으로 요구사항을 처리하는 순서도)

  • 요구사항 발송 : 사용자가 정보시스템 담당자에게 요구사항 전달
  • 요구사항 수렴 : 해당 요구사항에 처리 담당자를 배정하여 전달
  • 요구사항 검토 : (반영이 불가능할 경우) 사유를 시스템 담당자에게 전달하고, 처리 가능할 경우 영향도 분석 단계 이어서 진행
  • 영향도 분석 : 해당 요구사항에 영향을 받은 기존 시스템 파악
  • 반영 작업 계획 수립 : 요구사항 반영을 위해 관련 담당자들과 계획 수립

 

4. 업무 프로세스의 역할별 담당 업무

  • <사용자>
    • 요구사항 요청 및 반영 여부 확인

 

  • <담당자>
    • 요구사항 반영 결정을 위해 사용자와 1차 미팅
    • 요구사항 처리방식 및 처리 기한 결정
    • 사용자 정보 요구사항 반영 및 결과 전달
    • 테스트 및 검증

 

  • <데이터 아키텍처>
    • 요구사항에 대한 영향도 분석 및 보고
    • 요구사항의 표준 준수 여부 확인
    • 표준 제시 및 준수 여부 검토

 

쉽게 생각해보면 시스템 개선을 위해 사용자가 바라는 것들을 조사 및 분석하여, 최종적으로 개발될 시스템에 대한 요구사항을 확인하는 프로세스이다. 그럼 위의 각 프로세스별로 필요한 개념과 정보들을 구체적으로 알아보자.

 

[Part1. 정보 요구사항 조사]

사용자의 요구 사항을 수집 및 분석하고, 정리 및 중복 검토를 하여 최종 요구사항을 정리하는 시작 단계이다.

 

1-1. 정보 요구사항 수집

  • 시스템 기능상에 원하는 것을 찾기 위해 인터뷰, 면담 등을 통해 요구사항을 수집
  • 요구사항의 4가지 유형
    • 외부 인터페이스 요건 : 시스템 송수신 간의 요구사항
    • 기능개선 요건 : 시스템 내의 프로세스에 대한 요구사항
    • 성능개선 요건 : 시스템 내의 성능(트랜잭션 시간, 동시 사용자 수 등)에 대한 요구사항
    • 보안개선 요건 : 보안적 요소(인증, 암호화, 방화벽 등)에 대한 요구사항

 

  • 요구사항 수집의 5가지 방식
1) 요구사항 관련 문서 수집
    - 필요한 문서를 수집하여 구현 시스템의 범위를 명확하게 정의하는 것이 목적이다.
    - (수집 문서) 경영 계획 / 정보시스템 / 과거 컨설팅 보고서 / 전산 처리 업무 매뉴얼 / 현업 부서 업무 자료 등

2) 면담
    - 실무자와의 질의응답을 통해 필요 정보를 수집하는 것이 면담의 목적이다.
    - 현업 및 전산 부서에서의 면담 (아래 표 참고)

현업 부서용 면담 전산 부서용 면담
업무의 수행 방향에 대한 의견 기획 분야 (연혁, 계획, 문제점, 과제)
소속 부서의 업무 현황 및 개선 사항 시스템 분야(시스템 구성, 네트워크 구성, 시스템 운영 절차, 향후 계획)
소속 부서의 업무 현황 및 개선 사항 어플리케이션 분야(어플리케이션 구성, DB구성, 개발 및 유지 보수 계획, 향후 계획)

    - 면담에는 ‘면담자/기록자/관찰자’가 필요하며, 각 담당자별 역할을 구분할 수 있어야 한다.
        - 면담자 : 실질적임 면담 진행을 하며, 대상자에게 질문한다.    
        - 기록자 :  면담 내용을 있는 그대로 기록하고, 종료 후 내용을 한번 더 확인한다. (면담 대상 업무에 대한 사전 지식 필요)
        - 관찰자 : 면담이 주제를 벗어나는 경우, 주의 환기 / 면담자가 놓치는 부분에 대해 보충 질문 / 최종적으로 면담 종료 판단

    - 면담 과정별로 반드시 지켜야 하는 부분과 선택사항을 구분할 수 있어야 한다.
        📍대상자 선정 ⇒ 일정 수립 ⇒ 면담 준비 ⇒ 면담 진행 ⇒ 면담 결과 분석

        (1) 면담 대상자 선정
              * (필수) 면담 대상자는 관련 업무에 대해 명확하게 이해하는 사람이어야 한다.
              * (선택사항) 프로젝트 후원자나 사용자 측에서 추천받을 수도 있다.
       (2) 면담 일정 수립
              * 면담 대상자에게 프로젝트 목적과 범위 전달
              * 관련 문서 자료 요청
       (3) 면담 준비
              * 면담 대상자들에 대해 파악(업무, 신상 명세, 경력, 개인적 성향)
              * 면담 시나리오 준비(단, 면담 대상자에게는 배포하지 않음)
              * 면담 수행 30분 전에 최종 준비 상황을 점검한다.
       (4) 면담 진행
              * 준비한 내용을 기반으로 진행하며, 필요시 주제나 질문을 수정할 수 있다.
              * 면담 과정에서 발생한 면담 내용은 기록자에 의해 모두 기록된다.
       (5) 면담 결과 분석
              * 면담 종료 후 팀 전원이 참석하여 이슈를 정리한다.
              * 추가 의문 사항이 있는 경우 추가 면담을 진행할 수 있다.
       (6) 분석 결과 피드백
              * (필수) 면담 대상자 본인에게 결과지를 승인 받아야 한다.



3) 워크숍
    - 워크숍은 공통의 의견을 도출하는 것을 목표로 한다.
    - 워크숍의 목적
              * 경영층 또는 현업 부서장의 공통된 의견을 도출한다.
              * 유사 업무를 수행하는 부서 간의 면담 시간을 절감한다.
              * 전문가의 판단력으로 최적의 결론을 도출한다.

    - 워크숍 진행 과정
        📍워크숍 개시 ⇒ 워크숍 준비 ⇒ 워크숍 수행 ⇒ 워크숍 종료
         - 워크숍 수행 준비
               * 워크숍 목적과 개요를 설명하는 시간
         - 워크숍 종료
               *진행 사항과 도출 결과를 전체 인원에게 검토받아야 한다.


4) 현행 업무 조사서
         - 전체 부서(지점 포함) 대상으로 현행 업무를 조사하여 향후 작업에 참고자료로 사용하는 것을 목표로 한다.
         - 만약 동일 업무를 수행하는 부서 혹은 지점이 다수인 경우에는 표본 조사를 진행해도 된다.


5) 현행 프로그램(=시스템) 및 데이터 관련 문서
         - 현행 시스템의 업무 요건을 파악하기 위해 더 세부적으로 진행하는 자료 수집 단계이다.
         - 현행 시스템의 구조는 향후 업무 모델의 완전성을 검증하기 위한 비교 자료로 사용된다.
         - 현행 데이터 구조는 업무 프로세스에서 사용되고 있는 데이터 구조를 이해하는 것에 도움을 준다.

 

 

1-2. 정보 요구사항 통합

  • 면담/워크숍/업무 조사 등의 단계를 통해 도출한 요구사항을 최종 정리하는 단계
📍 면담 내용 정리 ⇒ 우선순위 분석 ⇒ 요구사항 통합

 

1. 면담 내용 정리

  • case1) 사용자 면담 : 면담 결과 기록에 문제가 없는지 사용자에게 확인을 받아야 한다.
  • case2) 워크숍 : 워크숍 진행내용 및 결과물을 정리한다.
  • case3) 그외 : 설문조사법/심층면접법/초점집단면접법/투사법/인적 관찰과 기계적 관찰/인위적 관찰과 자연적 관찰

 

2. 요구 우선순위 분석

  • 👉 (아래 더보기) 요구 우선순위 분석에 대하여
    • 더보기
      - 요구사항 간의 우선순위 도출하는 것을 목표로 한다.
      - 우선순위를 산정하는 방법들의 특징에 대해 구분할 수 있어야 한다.


      <화폐가치 산출 방법>
      (1~3번 순서는 상관 없음)
      1. 기업 차원의 중요성을 평가한다. (1~3점)
      2. 시스템 차원의 중요성을 평가한다. (1~3점)
      3. 다른 요구사항에 영향을 주는 정도를 평가한다. (1~5점)
      4. 전체 점수를 합산하여 백분율로 환산한다.
      5. 백분율을 금액으로 환산하여, 금액이 높은 순으로 우선순위를 배정한다.

       <상대적 중요도 산정 방법>

      1. 업무 기여도를 평가한다. (1~5점)
      2. 현행 정보시스템이 해당 요구사항을 충족하는 정도를 평가한다. (1~3점)
      3. 요구사항 관의 연관성을 평가한다. (가장 관련성이 높은 것에 9점을 주고, 나머지는 상대적으로 평가)
      4. 평가한 점수를 기준으로 가중치를 결정한다.

 

3. 요구사항 통합

  • 최종적으로 (동일 부서 내/타 부서 간) 요구사항의 중복 여부를 검토한다.
  • 부서 내 중복사항을 먼저 검토하고, 이후에 부서 간 중복사항을 검토한다.

 

 

 


[Part2. 정보 요구사항 분석]

수집한 요구사항을 바탕으로 분석 대상을 정하고, 현행 업무 및 시스템에 대한 분석 대상을 다이어그램 및 도식화로 표현하여 요구사항을 상세화하는 과정을 진행하게 된다. (간단히 말하면, 필요한 요구사항 도출을 위한 후속 단계이다.)

 

2-1. 정보 요구사항 분석

📍 분석 대상 현행 시스템 선정 ⇒ 자료 수집 및 평가 ⇒ 요구사항 분석 ⇒ 요구사항 명세서 작성

 

1. 분석 대상 현행 시스템 선정

  • 업무 영역별로 분석 대상이 되는 현행 시스템을 선정하는 것이 목표이다.
  • 매트릭스를 통해 업무 영역별 분석 대상 시스템 목록을 작성하고 파악하는 과정이다.

 

2. 분석 대상 현행 시스템 관련 자료 수집 및 평가

  • 앞서 선정된 현행 시스템 대상으로, 시스템 관련 문서(시스템 구성도, 보고서, 요구사항 등)를 수집하여 아래 기준에 대해 문서를 평가한다.
    • 유용성 : 문서 활용 가능성
    • 완전성 : 문서에 누락된 내용이 없는지
    • 정확성 : 문서 내용이 현재 시스템과 일치하는지
    • 유효성 : 최신 내용의 문서인지

 

3. 추가 분석 대상

  • 현행 데이터 측면에서 더 상세히 분석하기 위해 추가 분석이 필요한 경우 사용자 뷰를 포함시키기도 한다.
  • ex) 화면/수작업파일/수작업양식/보고서 등

 

4. 분석 단계

  • 현행 시스템 상태를 파악하고 구현될 시스템의 목표를 도출한다.

 

5. 명세서 작성

  • 위의 분석 과정을 통해 요구사항 명세서를 작성한다.

 

 


[Part3. 요구사항 상세화]

현행 시스템 분석 산출물을 토대로 사용자 요구사항을 보완하고, 비기능적 요구사항을 추가하여 요구사항 정의서를 보완하는 단계이다.

 

3-1. 요구사항 상세화에 대하여

  • 기능적 요구사항이란?
    • 실세 시스템에 요구하는 기능 또는 서비스를 의미

 

  • 비기능적 요구사항이란?
    • 시스템이 만족시켜야 하는 제약 조건을 의미
    • 시스템이 반드시 만족시켜야 하는 주요 성능 척도 (ex. 반응 시간/저장 능력/동시 처리 능력)
    • 비기능적 요구가 만족되어야 유의미한 시스템이 되기 때문에, 기능적 요구보다 중요하게 판단될 수도 있다. (ex. 기술적 관련 제약 조건)

 

 

3-2. 프로세스 관점의 요구사항 상세화

  • 전체 업무 과정을 프로세스 단위로 구분하고, 각 프로세스 별로 정보 요구사항을 상세화 한다.
  • 프로세스란?
    • 실제로 업무가 수행되는 행위를 의미하며, 시작 및 종료 시점이 명확하고 실행 횟수를 셀 수 있는 것이 특징이다.
    • 이때, 더이상 쪼갤 수 없는 시점의 프로세스를 ‘기본 프로세스’라고 부르게 된다.

 

  • 프로세스 도출 과정의 중요사항
    • 프로세스 간의 높은 응집도(Cohesion), 낮은 결합도(Coupling)를 통해 모듈성을 확보하는 것이 중요하다.
    • 하위 프로세스가 7개를 초과하는 경우 상위 프로세스 분리를 고려해야 한다.

 

 

3-3. 정보 요구사항 확인 (재검토 단계)

  • 요구사항 분석 결과 산출물에 대해 누락 사항 및 보완 사항을 도출하기 위한 재검토 단계
  • 재검토시 주의할 점
    • 재검토는 두 번 이상 진행하되, 세션별로 재검토 기준을 명확히 해야한다.
    • 너무 많은 인력이 참여하면 재검토 결론을 못내릴 수 있으므로, 참여 대상은 적정하게 선정되어야 한다.

 

  • 👉 (아래 더보기) 재검토 절차에 대하여
    • 더보기
      📍 재검토 계획 수립 ⇒ 재검토 실시 ⇒ 보완 결과 확인

      1. 재검토 계획 수립

      • 아래 4가지 기준으로 요구사항 분석 작업이 모두 완료되었는지 확인한다.
        • 완전성 : 요구사항이 누락되지 않았는지
        • 정확성 : 요구사항이 정확이 표현되었는지
        • 일관성 : 표준화를 준수하였는지
        • 안정성 : 해당 요구사항이 다른 업무 영역에 영향을 미치는지

       

      • 재검토 계획서에 포함되어야 하는 사항
        • 재검토 개요 및 목적
        • 일자/장소/시간 계획
        • 참석 대상/재검토 업무/세부 시간 계획
        • 재검토 당시 준비물
        • 재검토 후 산출물/지적한 사항에 대한 반영 계획

      2. 재검토 실시

      • 재검토 진행시
        • 재검토 담당자별로 수행 업무를 충분히 숙지시킨다.
        • 재검토 담당자는 재검토 전에 배포된 산출물을 반드시 예습해야 한다.
        • 재검토는 해당 업무와 관련있는 영역 담당자가 진행한다.
        • 진행자는 충분한 검증이 이루어지도록 적절한 시간 배분 및 조정을 해야한다.

       

      3. 보완 결과 확인

      • 재검토 결과/보완목록/보완사항이 반영된 요구사항 정의서를 배포한다.
      • 보완 사항이 모델에 모두 반영되었으면 재검토 작업은 종료된다.

 

 

 

 

이번 장에서는 사용자 요구사항이 무엇이고, 요구사항을 상세화하기 위해 어떤 과정을 거쳐야 하는지에 대해 알 수 있었는 것 같다. 다음장에서는 지금까지 정리한 요구사항을 정리하고 최종 검증하는 과정을 이어서 배워볼 것이다.

 

📘참고 서적: [데이터아키텍처 준전문가(DAsP) 한 권으로 끝내기]
김상목 지음

 

반응형