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

 

지난 장에 이어서 지금까지 정리한 요구사항을 토대로 명세서를 작성하고 최종 검증하는 과정을 배워볼 것이다. 새로운 내용을 시작하기 전에, 아래 ‘이 단원을 시작하기 전에’를 읽으며 요구사항 처리 절차에 대해 다시 상기시켜보자.

 

👉 (아래 더보기) 이 단원을 시작하기 전에

1. 정보 요구사항이란?

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

 

2. 정보 요구사항 처리 절차

📍요구사항 수집 ⇒ 요구사항 분석 및 정의 ⇒ 요구사항 상세화 ⇒ 요구사항 검증

 

(1) 요구사항 수집

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

 

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

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

 

(3) 요구사항 상세화

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

 

(4) 요구사항 검증

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

 

 

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

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

 

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

      (1) 사용자

               - 요구사항 요청 및 반영 여부 확인

      (2) 담당자

               - 요구사항 반영 결정을 위해 사용자와 1차 미팅

               - 요구사항 처리방식 및 처리 기한 결정

               - 사용자 정보 요구사항 반영 및 결과 전달

               - 테스트 및 검증

      (3) 데이터 아키텍처

               - 요구사항에 대한 영향도 분석 및 보고

               - 요구사항의 표준 준수 여부 확인

               - 표준 제시 및 준수 여부 검토

 

 

[Part1. 정보 요구 명세화]

요구사항 상세화 단계까지 모두 완료하면 정보 요구사항에 대한 명세서를 작성하는 단계를 진행하게 된다.

 

1-1. 정보 요구사항 명세란?

• 사용자 요구 분석 과정의 최종 산출물
• 사용자와 개발자를 연결시키는 문서(=사용자와 개발자 간의 일종의 계약서)
• 설계 및 구현에서 참조하고 알아야 하는 사항을 모두 포함한 문서

 

• 사용자 요구사항의 역할
  • 사용자 입장의 경우 : 개발 완료 시 요구사항 반영의 판단 기준으로 활용
  • 개발자 입장의 경우 : 요구 사항을 기반으로 분석, 설계, 코딩 진행
  • 테스터 입장의 경우 : 요구 사항을 기반으로 테스트 케이스 작성 및 판단

 

• 요구사항 명세서 작성시 주의사항
  • 사용자 입장에서 읽고 이해할 수 있도록 쉽게 작성한다.
  • 개발자 입장에서 설계와 코딩을 수행할 수 있도록 작성한다.
  • 테스터 입장에서 테스트 기준으로 사용되도록 정량적으로 작성한다.
  • 비기능적 요구를 명확히 작성한다.
  • 품질에 대한 우선순위를 명시한다.

 

 

 

 

---

[Part2. 정보 요구사항 검증 및 변경 관리]

상관 관계 분석을 통해 정보 요구사항이 업무 기능, 프로세스, 데이터별로 적절히 반영되었는지 분석하게 된다. 이 과정을 통해 누락되거나 중복된 요구사항을 수정하여 요구사항 완전성을 확보하게 된다.

 

2-1. 요구사항 검증

• 최종 작성된 요구사항 명세서에 사용자 요구가 올바르게 기술되었는지 최종 검토하는 단계
• 3가지 검증
  • 요구사항 명세서 검토 : 명세서 내용이 일관성을 가지고 적절히 작성되었는지 검토
  • 요구사항 용어 검증 : 명세서 내의 용어가 일관성, 표준성, 이해 용이성에 만족하는지 검토
  • 요구사항 베이스라인 설정 : 추후 공식적으로 사용될 요구사항 기준으로 설정

 

2-2. 요구사항 상관분석 기법

• 타 기능/프로세스/조직과 비교하여 해당 요구사항 도출이 효과적으로 이루어졌는지 파악하는 단계
• 요구사항 분석가 or 품질보증에 의해 상관분석을 진행하고, 외부 감리를 통해 객관성 및 완정성을 높이는 것이 목표이다.
• 주체별 분류
  • 요구사항 분석가
    • (장점) 업무 이해도가 높으므로 정확한 분석 가능, 업무팀과의 원할환 의사소통 가능
    • (단점) 요구사항을 도출한 분석가이므로 객관성 저하
  • 품질보증팀
    • (장점) 전체적인 인터페이스 검증에 용이
    • (단점) 낮은 업무의 이해도
  • 외부 감리
    • (장점) 제 3자의 시각으로 상관분석의 객관성 극대화 가능
    • (단점) 업무 파악에 한계 존재

 

 

2-3. 요구사항 상관분석 기법(matrix)

1. 정보요구/어플리케이션 상관분석

• 각 프로세스 액션을 정의하여 요구사항이 프로세스에 잘 반영되는지 확인한다.
• 프로세스 액션 4가지 - C(Create)/D(Delete)/U(Update)/R(Read)
• 상관분석 시 주의사항
  • 정보 항목과 기본 프로세스가 모두 누락이면 분석이 불가능하다.
  • 상태를 종료시키는 기본 프로세스가 존재해야 한다.
  • 4가지 액션 중 하나가 발생해야 한다.
  • 하나의 정보 항목 프로세스 합은 7개를 초과하지 않아야 한다.

 

2. 정보요구/업무(or 조직) 기능 상관분석

• 요구사항이 업무 기능별(or 조직 단위별)로 잘 반영되는지 확인한다.
• 상호작용 기준 - C(Create or Change) 항목 생성, 수정, 삭제 & U(Use) 단순 검색
• 상관분석 시 주의사항
  • 정보 항목과 연관성이 없는 업무는 다시 검토해야 한다.

 

 

 

두번의 섹션에 걸쳐 두번째 Chapter를 정리해보았는데, 아직 세부적인 내용까지 바로 이해하는 것은 조금 어려운 것 같다. 헷갈렸던 부분을 바로잡기 위해서 [데이터아키텍처 전문가 가이드] 책을 통해 이 책에서는 다루지 않는 세부적인 내용에 대해서 추가적으로 공부할 예정이다!

 

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