[프로젝트 개발 공정 가이드] 3. 요구 분석 및 정의 단계

3. 요구 분석 및 정의 단계

---

 요구 분석 및 정의 단계는 기획 문서를 바탕으로 해야 할 일이 무엇인지 파악하는 단계입니다.

 

 그런데 비지니스 프로젝트에서 해야 할 일은 개발자 마음대로 하는 것이 아니라 프로젝트와 이해 관계가 있는 이해 관계자들의 요구 사항에 맞게 만들어야 하는 것입니다. 따라서 요구 분석 및 정의 단계에서 제일 먼저 해야 할 일은 어떠한 이해 관계자들이 있고 이들의 요구 사항이 무엇인지 파악하는 것에서 출발합니다.

 

 중요한 이해 관계자와 이들의 요구 사항은 기획 문서로 만들어져 있다면 요구 분석 비용을 줄일 수 있습니다. 따라서 아키텍트는 개발자 뿐만 아니라 기획자와 의뢰자와 의사 소통이 필수적입니다. 특히 기획자에게 요구 사항 및 정의 단계를 진행하기 위해 의뢰자가 무엇을 원하는 것이 무엇인지 구체적으로 파악한 문서가 필요하다는 것을 전달하고 필요한 정보를 얻는 것은 프로젝트를 진행하는데 있어 매우 중요합니다.

 

 아키텍트는 이해 관계자와 이들의 요구 사항을 파악하였다면 이를 기반으로 액터를 정의합니다. 액터란 시스템을 사용하는 사용자 및 외부 시스템과 시스템에서 사용할 외부 시스템을 말합니다.

 

 예를 들어 대학 학사 관리 시스템이라고 할 때 학생, 교수, 교직원, 시스템 관리자처럼 사용자와 DBMS와 결제 시스템 등이 액터입니다. 이와 같은 액터를 정의하였으면 이를 액터 개요를 Usecase 다이어그램으로 작성합니다.

 

 이와 같은 작업은 기획 문서를 기반으로 아키텍트에 의해 진행하며 기획 담당자에게 확인을 받을 필요가 있습니다.

[그림 3.1] 액터 개요

 

 그리고 시스템을 사용하는 액터들이 어떨 때 사용하는지를 파악하고 외부 시스템을 언제 사용하는지 파악합니다. 그리고 이와 같이 파악한 것을 Usecase 다이어그램으로 작성합니다. Usecase는 타원으로 표현합니다.

[그림 3.2] 학생 Usecase 다이어그램

 이처럼 작성한 Usecase 다이어그램은 모두가 접근할 수 있는 문서입니다. 특히 개발 팀의 그래픽 디자이너는 스케치할 때 이를 기반으로 뷰를 정의해야 함을 인지시켜야 할 것입니다.

 

 그리고 다음 단계를 진행하기 위해 Usecase 별로 액터와 시스템 사이에 어떠한 흐름으로 진행하는지 Usecase 상세 기술서를 작성합니다. Usecase 상세 기술서를 만드는 별도 다이어그램은 없기 때문에 적당한 문서 편집기를 사용합니다. 이 문서는 그래픽 디자이너의 스케치에 사용하며 이후 다음 단계인 아키텍쳐링에서 아키텍쳐를 정의하고 시퀀스를 정의하는 등의 작업에서 필요합니다.

[표 3.1] 학생 로그인 유즈케이스 상세 기술서

 

 이러한 작업을 아키텍트가 진행하였다면 그래픽 디자이너는 이를 기반으로 스케치를 진행합니다.

 

 스케치 작업은 먼저 모든 화면을 정하고 흐름을 맵으로 작성합니다. [그림 3.3]은 제가 감수했던 대학생 프로젝트였던 “누구나 농부”의 스케치 플로우 맵입니다.

[그림 3.3] “누구나 농부” 스케치 플로우 맵

 

 그리고 화면에 어떠한 요소가 필요한지 파악한 후에 이를 스케치합니다. 필요에 의해 아키텍쳐와 회의를 요청하여 필요한 요소를 파악합니다.

[그림 3.4] "언제나 농부" 작물 목록 화면 스케치

 

 이와 같은 작업을 진행 후에는 각 화면은 어떠한 액터와 유즈케이스와 관련이 있는 것인지를 스케치 상세 기술서를 작성하게 합니다. 이러한 작업은 기획 담당자에게 전달하여 이해 관계자의 요구 사항에 맞게 분석한 것인지 1차적으로 확인합니다.