본문 바로가기

더 괜찮은 개발자가 되기위한/요구사항 분석하기

요구사항 도출

□ 요구사항 도출

○ 요구사항 도출이란?


요구사항 도출 개념도


요구사항 도출이란 제안요청서, 제안서, 업무문서 등을 분석해 요구사항을 찾아내고 고객과의 인터뷰를 통해 요구사항을 이해하고 숨어있는 요구사항을 발견하는 과정이다. 요구사항 도출은 요구사항이 어디에 있고 어떻게 수집할 것인가에 초점을 두고 있으며 이해관계자와 효과적인 의사소통이 성공의 핵심 열쇠이다. 따라서 고객과의 인터뷰를 하기 전에 프로젝트에 대해 충분히 이해하고 있어야 한다. 가장 좋은 방법은 제안요청서와 제안서 내용을 반복해서 읽어는 것이다.

 

○ 제안요청서 분석


제안요청서, 제안서, 고객이 업무에 사용하는 문서를 분석해 고객이 요구하는 기능과 특성을 찾아내는 과정이 요구사항 도출이다. 여기에서 가장 기초가 되는 것이 제안요청서이다. 고객은 제안요청서에 프로젝트를 통해 개발해야 하는 시스템의 기능과 특성을 자세히 적어 놓는다. 따라서 요구 분석의 가장 기초 단계는 제안요청서를 다시 한번 자세히 들여다 보는 것이다.

제안요청서를 가장 잘 이해하고 있는 사람은 제안작업에 참여했던 제안팀원들이다. 제안서 작성 과정에는 고객과의 커뮤니케이션이 여러 번 있고 거기에서 글로 담지 못한 프로젝트와 관련된 많은 얘기가 오가기 때문에 제안요청서를 깊이 있게 이해하기 위해서는 이 과정을 알고 있어야 한다. 설계자가 제안작업에 참여하지 못했다면 PM과 영업사원에게 제안요청서에 대한 설명을 듣는 것이 좋다.


제안요청서 분석


제안요청서에 나와있는 요구사항은 기능, 시스템 장비구성, 성능, 인터페이스, 데이터, 테스트, 보안, 품질, 프로젝트 관리, 프로젝트 지원 이렇게 10가지고 나눌 수 있다. 여기에서 중심이 되는 것이 기능 요구사항이다


기능 요구사항 분석 사례


기능 요구사항을 분석하기 위해서는 제안요청서 전반부에 나와 있는 시스템 구축 목적, 배경 그리고 시스템 현황 등을 읽어보면서 전체적인 윤곽을 파악하는 것이 중요하다. 다음으로 기능 요구사항을 하나씩 읽어보면서 프로젝트에서 구축해야 하는 범위를 알아내야 한다.

스마트영업지원시스템 구축 프로젝트의 영업비용 정산 요구사항에서는 크게 명시적 요구사항과 묵시적 요구사항을 도출할 수 있다. 명시적 요구사항이란 고객이 원하는 바를 구체적으로 기술하고 이 것을 바탕으로 시스템 기능을 도출하는 것이다. 묵시적 요구사항이란 고객이 기술한 요구사항에서 설계자가 경험적으로 유추할 수 있는 요구사항을 말한다. 예를 들어 영업사원 및 관리자 비용 정산 처리 현황 조회라는 문구를 확인했을 때 경험 있는 설계자의 경우 직감적으로 재무시스템과 연동이 필요하다는 것을 알 수 있다.

 

○ 제안서 분석


제안서 분석


다음으로 제안서를 분석할 차례다. 제안서 작성에 참여한 설계자라면 제안서를 머릿속에 넣고 제안요청서를 읽어보면서 요구사항을 도출하겠지만, 제안서 작성에 참여하지 않은 설계자의 경우 제안서와 제안요청서를 번갈아 읽으며 요구사항을 도출해야 한다. 여기서 가장 중심이 되는 것은 제안요청서이며 제안서에 제안요청서에 들어있는 요구사항 중 누락된 것이 없는지 확인하고 만일 누락되었다면 이에 대한 개발 방안을 수립하는 것이 좋다.


제안서에서 한가지 중요한 것은 추가제안 사항이다. 추가제안은 고객이 요구하지 않았지만 제안사가 프로젝트에 도움이 될 수 있는 기능이나 서비스를 추가적으로 제시한 것이다. 따라서 요구사항을 도출할 때 추가제안도 함께 고려해야 한다.

설계자가 제안요청서와 제안서를 분석하는 목적이 요구사항 도출에도 있지만 고객과의 인터뷰를 준비하는 목적도 있다. 프로젝트를 시작할 때 첫 번째 비공식적인 인터뷰는 킥오프 미팅이다. 킥오프 미팅은 사무실에서 이루어지는 것이 아니라 회식장소에서 이루어진다. 서로 대화를 나누다 보면 자연스레 업무 얘기가 나오고 이런 자리에서 설계자가 프로젝트에 대한 깊은 이해를 보인다면 고객은 자신도 모르는 사이에 설계자를 신뢰하게 된다.


훌륭한 설계자라면 고객과의 만남이 있기 전에 제안요청서와 제안서를 반드시 읽어보고 시스템의 전체적인 윤곽을 머릿속에 그려야 한다. 아무 준비 없이 고객 인터뷰에 참석해서 고객이 알려주는 것만 받아 적는 다면 고객의 설계자에 대한 신뢰 바닥을 칠 수 밖에 없다.

제안요청서와 제안서는 PM이 가장 잘 알고 있다. 일반적으로 PM은 제안서 작성 단계에 참여하고 제안발표를 진행하기 때문에 누구보다 제안서와 제안요청서를 속속들이 알고 있다. PM은 프로젝트가 시작될 때 설계자에게 제안요청서와 제안서를 아주 구체적으로 설명해 줘야 한다. 설계자가 이 부분을 이해하고 프로젝트를 시작하는 것은 요구분석을 성공적으로 이끄는 아주 중요한 요소이기 때문이다.


○ 인터뷰


인터뷰 절차


인터뷰를 시작하기 전에 먼저 제안요청서, 제안서, 업무문서 등을 사전에 분석해 기능을 도출하고 메뉴를 먼저 구성해 보는 것이 좋다. 메뉴를 구성하기 위해서는 기능에 대한 분석이 끝나야 하고 기능을 유형별로 묶을 수 있어야 한다. 신규 시스템에 대한 메뉴 구성이 완료될 즈음 설계자의 머릿속에는 고객 요구사항이 잘 정리 되어 있을 것이다. 제안서와 요청서에서 이해가 가지 않는 부분은 잘 정리해 두었다가 인터뷰 계획서에 질문 사항으로 넣으면 된다.

 

인터뷰 질의서

(출처: 소프트웨어 요구사항 분석〮적용 가이드 정보통신산업진흥원)


설계자가 고객이 원하는 요구사항을 알아내기 위해서는 먼저 업무를 이해해야 하고 이해한 것을 확인하는 과정을 거쳐야 한다. 설계자는 주로 인터뷰를 통해 고객과 커뮤니케이션을 하게 되는데 이 때 필요한 것이 인터뷰 질의서이다.


인터뷰 질의서는 인터뷰 목적이 무엇이고 인터뷰에서 설계자가 얻고자 하는 내용이 무엇인지를 고객에서 사전에 알려주는 역할을 한다. 설계자는 반드시 정성스럽게 준비된 인터뷰 질의서를 가지고 고객과 인터뷰를 진행해야 한다. 이는 고객에게 더 많은 정보를 얻어낼 뿐만 아니라 설계자에 대한 고객의 신뢰를 높여주는 훌륭한 수단이기 때문이다. 고객은 인터뷰 질의서를 받아보는 순간에 설계자의 마음가짐, 능력, 자질을 알 수 있기 때문이다.


업무에서 사용하는 문서들

(출처: http://londonmedarb.com/business-documents/)


고객 요구사항을 좀 더 자세히 이해하기 위해서는 업무에 사용하는 문서를 살펴보는 것이 좋다. 영업 보고서라던가 영업 비용 청구서 등 프로젝트와 관련이 있는 문서를 참고하면 고객 요구사항을 이해하고 고객이 미쳐 생각지 못한 추가 요구사항을 끌어 낼 수 있다. 분석 과정에서 추가로 도출되는 잠재적인 요구사항은 설계나 개발 과정에서 발생할 수 있는 추가 요구사항을 감소시켜 주기 때문에 가급적 분석 과정에서 많이 도출되는 것이 프로젝트 성공에 도움이 된다.


반응형

'더 괜찮은 개발자가 되기위한 > 요구사항 분석하기' 카테고리의 다른 글

요구사항 검증  (0) 2018.11.19
요구사항 명세  (0) 2018.11.19
요구사항 분석  (0) 2018.11.19
요구사항 분석 개념  (0) 2018.11.19