[DAsP 한 권으로 끝내기] Chapter2.데이터 요건 분석 - 추가자료

 

이번 장에서는 [DAsP 한 권으로 끝내기]에 포함되지 못한 추가 내용을 공부할 예정이다. 2장에 대해서 요약된 부분이 많아서, [DAP 전문가 가이드] 책 내용을 기반으로 할 것이다. 낯선 개념이 많지만 DA로서 사용자 요구사항을 찾아 정리하고 도출하는 업무를 진행한다는 생각으로 이해해보면 조금 쉽게 느껴질 것이다.

 

[Part1. 프로젝트의 성공과 실패]

우선, 정보요구사항에 대해 들어가기 전에 성공하거나 실패한 프로젝트에 대한 기준을 알아보자.

 

1-1. 프로젝트의 성공과 실패 기준은 무엇일까?

• 성공의 기준
  • 프로젝트 범위/일정/예산을 모두 만족시켜 목표를 달성한 경우를 의미
• 도전의 기준
  • 프로젝트 범위/일정/예산 중 일부 또는 모든 기준에 미달하거나 프로젝트를 완수했지만 고객이 마무리한 프로젝트를 의미
• 실패의 기준
  • 프로젝트가 중단되거나 납품에 실패한 경우

 

1-2. 프로젝트 실패 요인의 기준

• 프로젝트 실패 요인은 계획과 추정/실행/인간적 요인으로 구분될 수 있다.
• 계획과 추정 요인
  • 초기의 프로젝트 계획이나 추정된 원가가 올바르지 못한 경우
• 실행 요인
  • 프로젝트 범위 변경/프로젝트 방법론의 부적절한 사용/요구사항 변경/불성실한 테스트 및 검증
• 인간적 요인
  • 프로젝트 관련 실무자의 이론 부족/커뮤니케이션의 부재

 

 

 

---

[Part2. 정보요구사항]

2-1. 정보요구사항이란?

• 사용자의 업무 개선이나 신규 개발 사항을 위해 요청하는 내용
• 설계/구현/테스팅은 낮은 비용으로 수정할 수 있으나, 요구사항 수정은 처음부터 다시 개발해야하므로 많은 비용이 낭비된다.
• 요구 및 기대사항을 정량화 수치로 표현한 것도 요구사항에 포함된다.
• 요구사항이 구체화되면서 요구사항 분류 정확도 및 상세 수준도 함께 높아지게 된다.

 

2-2. 정보요구사항의 생명주기

✅ 요구사항 도출 ⇒ 분석 및 정의 ⇒ 명세화 ⇒ 검증 ⇒ (요구사항 승인 후) ⇒ [추적 → 변경 요청 → 영향 분석 → 승인 및 기각]의 반복

 

• 각 단계에 대한 설명
  • 요구사항 도출 - 사용자 인터뷰/설문/워크숍 등을 통해 사용자 요구사항을 도출한다.
  • 요구사항 분석 및 정의 - 다양한 분석 기법을 활용하여 요구사항을 분석하고 정의한다.
  • 요구사항 명세화 - 요구사항을 정보시스템에 반영하도록 세부적으로 분석하고 기록한다.
  • 요구사항 검증 - 비즈니스/조직/애플리케이션 관점에서 누락된 요구사항이 없는지 검증한다.

 

2-3. 정보요구사항 프로세스 (사용자의 요구사항을 수집하고 반영하는 전체 프로세스)

✅ 요구사항 발송 ⇒ 수렴 ⇒ 검토 ⇒ (미반영 사유 통보 or 영향도 분석) ⇒ 공식화 ⇒ 반영 작업 계획 수립

 

• 정보요구사항 프로세스에서의 전문가별 역할
  • 사용자
    • 정보 요구사항 반영을 위한 미팅/요구사항 반영 여부 확인/미결 사항에 대한 의사결정 실시 ⇒ 본인이 요구한 사항이 잘 반영되었는지 확인하는 주체
  • 담당자
    • 사용자 정보 요구사항 반영/테스트 및 검증 ⇒ 사용자와의 직접적인 커뮤니케이션을 하는 입장
  • 데이터 아키텍처(DA)
    • 요구사항의 영향도 분석/표준 준수 여부 검토 ⇒ 실제 기술적 지원을 하는 입장

 

 

 

 

---

[Part3. 요구사항 반영 프로세스에서의 각 단계별 특징]

3-1. 요구사항 수집

(1) 사용자 면담

• 사용자와의 인터뷰를 통해 그들이 생각하는 요구사항을 수집하는 방법
• 👉 (아래 더보기) 사용자 면담의 특징에 대하여
  •  - 면담자와 기록자(2명)으로 진행되며 필요시 관찰자가 함께 면담에 참여한다.
     - 면담 요지(질문)은 1주일 전에 배포하여 답변을 준비할 수 있도록 하지만, 면담 시나리오(면담 진행 방식 및 종료 수칙 관련)는 면담 대상자에게 공개하지 않는다.
     - 가능하면 면담 일정은 하향식(상위 관리자부터 진행)으로 진행하고, 1.5시간(상위 관리자)~3시간(실무자)을 초과하지 않도록 한다.
    
    
    <면담의 종류>

    • 면담 대상자 인원에 따라
      • 개인 면담 : 일대일로 직접 면담하는 방식
      • 집단 면담 : 일대다로 많은 사람들과 면담하는 방식(=워크숍)

     

    • 면담 진행방식에 따라
      • 표준화(=구조화/지시적) 면담 : 질문과 진행 방식이 모두 동일하게 진행
      • 비표준화 면담 : 상황에 따라 질문의 순서와 내용이 달라지는 면담

     

    • 면담 질문 및 내용에 따라
      
      • 피라미드 구조(위에서 밑으로 내려가는 방식)
        • 구체적(=선택적/단답식)인 질문으로 시작해서 일반적(=서술적)인 질문으로 나가는 방식
        • 아이디어 발굴 및 주제에 대한 부담감 완화에 도움이 된다.
        • 면담자가 구체적인 아이디어가 없어 단답식의 단순한 얘기부터 시작한다고 생각!
      • 퍼널 구조(피라미드와 반대로 올라가는 방식)
        • 일반적인 질문에서 구체적인 질문으로 발전해나가는 방식
        • 면담자가 본인만의 아이디어를 갖고 있거나 면담에 대한 부담감 완화에 도움이 된다.
        • 면담자가 본인만의 아이디어가 있으므로 직접 얘기를 시작하도록 유도한다고 생각!
      • 다이아몬드 구조(피라미드&퍼널 구조의 장점을 합친 방식)
        • 피라미드 식의 면담 진행 후 퍼널 식으로 이어서 면담 진행

 

(2) 현행 업무 조사서

• 전체 부서가 수행하는 업무를 조사하여 업무 표준화 부진을 확인하는 방법
• 현행 업무 조사서는 완벽하게 작성되어야 하며, 잘못 작성되거나 내용이 불충분한 경우 반송하여 다시 작성하도록 한다.

 

(3) 관찰

• 피관찰자의 행동이나 태도를 살펴보면서 자료를 수집하는 귀납적 방법
• 일정 기간 동안 사용자의 업무를 옆에서 관찰하며 요구사항을 도출한다.

 

(4) 브레인스토밍

• 소속 인원들이 어떤 문제의 해답을 찾기 위하여 창의적인 아이디어를 생산하는 방법
• 브레인스토밍의 4가지 법칙
  • 아이디어의 질보다는 양이 중요하며 최대한 다양한 아이디어를 제시한다.
  • 아이디어에 대한 비난이나 비판없이 계속 창의적인 아이디어를 유도한다.
  • 독창적인 아이디어는 환영한다.
  • 도출된 아이디어를 함께 조합하거나 개선하면서 더 좋은 아이디어를 만들어간다.

 

(5) 프로토타이핑

• 요구사항 분석 (핵심 요소만을 반영하여 프로토타입 개발 → [사용자가 프로토타입을 사용하면서 의견제시 → 프로토타입 반영]의 반복)
• 개발 초기에 시스템 모형(Prototype)을 만들어 사용자가 직접 사용하게 함으로써 요구사항 수집 및 반영하는 과정
• 사용자가 만족할때까지 프로토타입 반영 과정을 반복하게 된다.
• 참고로 프로토타입은 시스템의 모든 기능을 표현한 것이 아니며, 일부만 구현해서 해당 기능의 장단점/반드시 필요한 기능/불필요한 기능들을 알기 위해 사용한다.

 

 

 

3-2. 요구사항 분석 및 우선순위 선정

• 화폐가치 산출이나 상대적 중요도 산정 방법 등을 통해 요구사항 간의 우선순위를 선정한다.
• 때로는 이러한 기준 없이 상황에 맞는 우선순위를 부여하고 진행할 수도 있다.

 

 

3-3. 요구사항 상세화

• 현행 시스템을 프로세스 단위로 분해하여 (프로세스별) 요구사항을 보완하는 단계
• 요구사항 상세화의 특징
  • 시스템을 프로세스 단위로 분해 시 업무적 특성을 고려하여 3차 수준까지 분해한다.
  • 일반적으로 데이터의 상태를 변화시키는 (생성/수정/삭제) 관련 프로세스를 대상으로 하지만, 업무적으로 중요한 조회용/수작업 프로세스를 도출하기도 한다.
  • 프로세스 계층도는 응집도는 높게, 결합도는 낮게 유지하도록 한다.
• (참고)
  • 응집도 - 모듈(=기능) 간의 독립성
  • 결합도 - 모듈 간의 상관관계를 의미하며 종속성을 의미
  • 모듈의 독립성이 중요한 이유는 오류 해결 및 수정 작업이 쉬워 유지 보수에 용이하기 때문이다.

 

 

3-4. 요구사항 명세

• 위에서 정리하고 분석한 요구사항을 정리하여 문서로 작성하는 단계로, 개발에 사용될 최종 공식 문서이다.
• 요구사항 명세서의 특징
  • 요구 분석 과정의 최종 산출물로 사용자와 개발자를 연결시키는 문서이다.
  • 사용자와 개발자 모두의 관점을 종합해야 하고, 정확하고 완벽하며 수정하기 쉽게 작성되어야 한다.
  • 사용자가 쉽게 읽고 이해할 수 있어야 한다.
  • 비기능적 요구(ex.제약사항, 품질 등)를 명확히 작성해야 한다.
  • 테스트에 사용되도록 정량적으로 작성하며 품질에 대한 우선순위를 명시해야 한다.

 

• 담당자별 요구사항 명세서의 역할
  • 사용자 입장 - 제시한 요구사항 내용이 반영되었는지 확인하는 기준으로 사용
  • 개발자 입장 - 명세서를 기반으로 분석/설계/코딩 진행
  • 테스터 입장 - 명세서를 기반으로 테스트 케이스 사용 후 오류 판단

 

 

3-5. 요구사항 검증

• 작성된 요구사항 명세에 대해 사용자의 처음 요구사항이 올바르게 기술되었는지 검토하는 단계
• 정보요구/애플리케이션 상관분석 or 정보요구/업무기능 상관분석을 통해 요구사항이 반영되었는지 확인한다.

 

• 요구사항 검증을 위한 상관분석 기법
  1. 정보요구/애플리케이션 상관분석
     • 목표: 애플리케이션의 각 프로세스별로 요구사항이 반영되었는지 확인
     • 설명: 기본 프로세스가 각 프로세스에서 정보를 (Create, Delete, Update, Read) 하는지 2차원 매트릭스로 표현하여 확인
     • 모든 요구사항은 기본 프로세스에 의해 사용되어야 한다.
     • 기본 프로세스를 수행하기 위한 요구사항이 모두 도출되어야 한다.
  2. 정보요구/업무기능 상관분석
     • 목표: 업무 기능별로 요구사항이 반영되었는지 확인
     • 설명: 해당 업무 기능이 정보를 (Create or Change, Use) 하는지 2차원 매트릭스로 표현하여 확인
     • Create or Change - 정보 생성/수정/삭제 과정
     • Use - 단순히 정보를 검색하는 과정

 

 

 

 

 

추가 내용을 공부하며 기본 교재에서 이해가 어려웠거나 모호했던 부분들을 해결할 수 있었다. 1,2장에 걸쳐 아키텍처 구축을 위해 사용자의 요구사항을 수집하고 반영하는 과정에 대해 배우게 되었다. 다음장부터는 아키텍처 구축 과정에서 필요한 기술적인 개념에 대해 알아볼 예정이다.

 

 

📘참고 서적: [데이터아키텍처 전문가 가이드]
한국데이터산업진흥원 지음