다잇소


[비지니스] 나의PM이야기 #6 요구사항정의, 범위 확인

2016.01.29
나의PM이야기 Main img_770x523

 

요구사항 정의 단계에서 요구사항을 확정 하는 것이 중요하며, 요구사항에는 프로젝트 전체 범위가 포함되어 있어야 한다.

 

 

요구사항을 정의하고, 범위를 확인하는 방법은 시스템 구축 방법에 따라 차이가 있다.
– 처음 시스템을 구축하는 프로젝트
– AS-IS 시스템을 개선하기 위해 재구축 또는 고도화하는 프로젝트
– 패키지로 시스템을 구축하는 프로젝트 등으로 구분할 수 있다.

 

 

PM이야기_01

 

 

처음 시스템을 구축하는 프로젝트의 경우
현업이나, IT 담당자가 처음 구축하는 경우 시스템의 실체를 모르거나, 현업의 요구사항이 구체화되어 있지 않은 경우가 많다.
이런 프로젝트는 현업으로부터 요구사항을 도출하고, 구체화하여 확정하는데 많은 어려움이 존재한다.
요구사항 도출과정을 보면, 현업과의 인터뷰나 규정집, 법령 등의 자료를 분석하여 요구사항을 잘 정리해서 현업이 시스템을 이해할 수 있도록 만드는 것이 중요하다.

단순하게 텍스트 기반의 산출물로 이해시키는 것보다는 컨텍스트 다이어그램이나, 상위개념의 업무 분해도, 상위개념의 ERD(Entity Relationship Diagram) 등의 다이어그램을 통해 설명을 하면 좀 더 쉽게 목적을 달성할 수 있다.

PM의 입장에서는 전체 업무범위가 요구사항으로 도출되었는지 확인하기 위해 필요하다.
왜냐하면, 현업 담당자가 전체 업무범위가 도출되지 않았다고 생각하면, 결국 나중에 더 많은 요구사항을 꺼내 놓기 때문이다.

프로젝트에서 요구사항 정의 단계의 목표는 전체 업무범위의 도출이다.
물론 모든 프로젝트가 마찬가지 겠지만, 처음으로 구축하는 시스템은 범위를 정하는 것이 어렵기 때문에 범위에 대해 더욱 강조하는 것이다.

 

 

PM이야기_02

 

 

시스템을 개선하기 위해 재구축 또는 고도화하는 프로젝트의 경우

최근 수행하는 대부분의 프로젝트는 신규시스템 구축 보다는 현행 시스템이 존재하지만, 새로운 비즈니스에 대응하기 위해 혹은 IT운영상 문제점을 해결하기 위한 프로젝트가 많다.

AS-IS시스템이 존재하기 때문에 개발 대상범위는 AS-IS시스템 전체와 새로운 비즈니스를 위한 신규 요구사항이나 IT개선 요구사항이 그 범위이다.

따라서, AS-IS시스템의 기능을 TO-BE시스템 환경에 맞춰 그대로 전환하거나, 개선 후 전환하는 요구사항으로 분류할 수 있다.

이때 변환 없이 전환하거나 제외하는 기능도 요구사항으로 꼼꼼히 관리해야 한다. 분석/설계, 구현단계에서 변환이 없을 것이라 예상했거나, 삭제한 기능도 TO-BE시스템에 포함되는 경우가 종종 발생하기 때문이다.

TO-BE시스템의 신규 요구사항은 기능 및 비기능 요구사항으로 분류하여 관리한다.

간혹, IT의 요구사항을 누락하여 분석/설계, 구현 시 이슈가 되는 경우도 있으니, 요구사항 정의단계에 반드시 IT의 시스템 운영상 개선사항이나, 새로운 요구사항을 수집하도록 해야 한다.

시스템 고도화 프로젝트는 이미 구축해야 할 범위가 어느 정도는 정해져 있어서 요구사항을 도출하고 확정하는 과정을 대충하는 경우가 있다. PM은 AS-IS시스템의 기능이 빠짐이 없는지 확인하고, 개선되는 내용이 있는지 꼼꼼히 확인해야 한다.
PM이야기_03

 


패키지로 시스템을 구축하는 프로젝트의 경우


AS-IS시스템과의 GAP분석 결과가 반드시 있어야 한다.

GAP분석은 패키지를 기준으로 AS-IS 시스템의 기능과 매핑 작업을 통해 매핑되거나, 매핑되지 않는 기능에 대해 어떻게 할 것 인지 정의해야 한다.

매핑되는 않는 기능은 다음과 같이 분류할 수 있다.

AS-IS시스템의 기능 중 패키지에 없는 기능 : TO-BE시스템 구축 시 필요 여부를 결정하여 신규 요구사항으로 도출하거나, 필요없는 경우 삭제 요구사항으로 분리하여 관리

AS-IS시스템에 없는 기능 (패키지에 만 있는 기능) : 신규기능으로 분류하여 관리

매핑되는 기능과 패키지에만 있는 기능은 TO-BE시스템에서 계속 유지 여부를 결정하고, 패키지의 기능을 그대로 사용하거나, 개선여부를 정의하고 관리해야 한다.

패키지에 새로운 요구사항을 반영할 때는 반드시 영향도를 검토 후 수용 여부를 결정해야 한다.

패키지가 갖는 특성을 흔들게 되면 프로젝트를 실패 할 확률이 높아지기 때문이다.

요구사항 정의 시 AS-IS시스템과의 GAP분석을 통해 패키지의 기능의 누락여부를 파악하고, 개발대상 업무를 명확히 정의를 해야 한다.

 

 

 

다시 정리하면, 요구사항 정의단계에서 개발 담당자들은 요구사항을 도출하고 확정하고, PM은 프로젝트 범위를 확인한다.

제안요청서 내용과 제안서의 내용을 맵핑하고, 제안서와 요구사항정의서를 매핑하여 범위를 확인한다.

일부 개발 담당자들은 신규, 변경(개선)요구사항 만을 정의하는 경우가 있는데 변경이 없는 단순 전환이라도 요구사항 정의에 포함해서 관리해야 한다. 이유는 요구사항단계에서 변경이 없다고 했더라도 이후 단계에서 변경 될 수 있기 때문이다.

그리고 요구사항 정의를 할때는 기능, 비기능적 요구사항을 구분하여 표시하여 관리해야 한다.

요구사항은 프로젝트가 종료될 때까지 추적 관리가 할 수 있도록 관리하고, 단계가 마무리 되는 시점에는 전체 범위에 누락이 있는지 확인을 하며, 프로젝트 검수가 완료될 때까지 관리해야 한다.

 

 

 

PM은 범위를 관리하고, 통제하지만

변경은 고객의 요청에서 시작된다.

따라서, 요구사항이 도출하고 정리가 완료되면 고객과 함께 검토하고 확인받아야 한다.

 

 

PM이야기_04

 

Tip_img인터뷰 요령

요구사항을 도출하기 위한 인터뷰 방법은 다음과 같다.

 

 

1) 인터뷰 계획 수립

– 인터뷰 대상을 선정을 선정한다.

인터뷰가 필요한 대상 업무를 정리하여 고객PM에게 해당 업무의 실무자와 의사결정을 할 수 있는 중간관리자를 지정해 줄것을 요청한다.

 

 

– 인터뷰를 수행 할 인원을 구성한다.

최소 2인 이상으로 구성하여 한명은 인터뷰를 진행하고, 다른 한명은 기록하는 역할을 수행하는 것이 좋다.

그리고 인터뷰 내용을 녹음을 하는 경우가 있는데, 이런 경우는 인터뷰 대상자에게 불편을 줄 수 있으니 사전에 양해를 구하고 해야 한다.

 

 

– 인터뷰 일정을 정한다.

인터뷰 일자와 시간을 정할때 인터뷰 시간은 1시간 정도가 적당하며, 길어도 2시간을 넘기지 말고, 시간은 정각으로 정하여 참석자들에게 공지한다.

 

 

– 인터뷰 장소는 대상자가 편하게 인터뷰에 응할 수 있는 곳으로 정한다.

IT부서와 현업부서가 떨어져 있는 경우 가능하면 IT부서쪽에서 하는게 좋다. 사무실에서 하는 경우 업무로 인해 회의가 집중하지 못하는 경우가 있기 때문이다.

 

 

– 인터뷰 약속은 정해진 일정에 따라 인터뷰 대상자에게 연락하고, 필요한 경우 인터뷰 문서를 작성하여 일정을 약속한다.

 

 

– 인터뷰 대상자별 질문지 정리한다

인터뷰 대상자별로 질문 할 내용을 준비하고, 인터뷰에 앞서 대상자에게 배포한다.

 

 

2) 인터뷰 실시

– 소개 : 인터뷰 진행자는 인터뷰에 참석인원을 소개하고, 인터뷰를 진행하는 목적을 명확하게 설명하고, 인터뷰 수행 방식 등을 설명한다.

– 인터뷰 진행

> 진행자는 사전에 준비한 질문 순서에 따라 진행하고, 기록자는 인터뷰 내용을 빠짐없이 기록한다.

> 진행자는 시간 조절을 하고 주제에 벗어나더라도 적당한 정도에서 여유를 갖고 인터뷰를 진행한다.
기록자는 이해되지 않는 부분은 다시한번 확인해서 기록하도록 한다.

 

 

– 인터뷰 종료

> 인터뷰중 기록된 내용은 인터뷰 참석자와 함께 확인하고 동의를 구한다.

> 인터뷰결과를 정리하여 요구사항정의를 하고, 정리된 요구사항은 다시 검토할 것이라고 설명한다.
인터뷰 내용을 상호 확인하여 신뢰감을 갖도록 한다.

 

 

3) 인터뷰 결과 정리

– 인터뷰가 완료되면 기록된 사실을 빨리 결과를 정리해서 인터뷰참석자와 공유한다.

– 인터뷰 결과로 정리된 내용을 요구사항으로 정리한다.

– 인터뷰 정리결과 내용이 불충분하면 추가적인 인터뷰를 수행하여 보충한다.

 

 

4) 인터뷰 시 질문요령

~에 대해 어떻게 생각하십니까 ? 와 같이 OPEN형 질문을 하면, 인터뷰대상자가 자유롭게 답변을 할 수 있으나 주제에서 벗어날 수 있는 단점이 있고,

~보고서는 하루에 몇 건 정도 보고합니까 ?와 같은 CLOSE형 질문을 하며, 대답의 범위를 제한하게 되는 단점이있으나, 원하는 답을 얻을 수 있는 장점이 있다.

 

 

따라서, 인터뷰 진행자는 적절하게 질문을 OPEN형과 CLOSE형을 섞어가면 인터뷰를 진행해야 한다.

 

 

이전글 바로가기 ▶ 나의 PM 이야기를 시작하며….

                              ▶ #1 프로젝트 착수 -인력투입

                              ▶ #2 프로젝트 착수 -프로젝트준비

                              ▶ #3 프로젝트 착수 -프로젝트 계획수립

                              ▶ #4 프로젝트 착수 -착수보고

#5 PM의 역할
유경근의 프로필 사진
| 경영진
관심분야

카테고리 레이어 닫기