[프로젝트 수행 일기 ] 프로세스 작성 및 요구사항 정의서 작성

프로젝트 투입해서 진행되는 중요한 업무와 사건들, 프로젝트가 망하지 않으려면 주의해야할 사항을 일기 형식으로 작성해보려고 합니다. 

첫번째 이유는 제가 기억력이 좋지 않기 때문에 나중에 제가 다시 보기 위함이고

두번째 이유는 공공기관 프로젝트는 어떤식으로 진행되는지 궁금하신 분들도 참고하시면 도움이 될거 같기 때문입니다. 

 

7월 1일 공공기관 프로젝트 투입

 

각종 서류 작성

보안서약서 : 프로젝트 수행간 알게 된 사실을 외부에 알리지 않겠다

출입신청(신원진술서) : 공공기관 사업을 수행함에 있어 신원에 이상이 없다(법적으로 처벌받은 적 없다)는 것을 증명하기 위해 신원진술서와 함께 가족증명서 등을 첨부해서 제출합니다. 

신원진술서에 연락처, 주민번호, 주소, 직장, 가족관계, 학력, 경력, 병역(군대) 등을 입력합니다. 

 

컴퓨터 사용을 위한 내부망 아이피 신청

공공기관에서 사용하는 컴퓨터에는 보안프로그램이 설치되며, 별도의 내부망 아이피를 할당받아서 작업하게 됩니다. 

당연히 컴퓨터에 만든 모든 파일은 인터넷이나 USB 등을 통해 외부로 유출할 수 없습니다. 혹시 외부로 파일을 옮겨야할 경우 담당고객이 별도의 시스템을 이용해서 전송해주도록 되어 있습니다. 

그리고 프로젝트가 끝나고 사업 철수시에는 노트북을 포맷(Low포맷을 해주는 업체가 공공기관에 상주하고 있음)해야 합니다. (하드가 SSD인 경우 완전 파기)

 

그리고 내부망에 연결한 컴퓨터는 외부 인터넷이 안되기 때문에 사업에 투입하기 전에 개발까지 할 수 있도록 세팅을 완료해야 합니다. 

이클립스, JDK, 각종 jar, 소스형상관리툴, DB, 통합빌드툴, 한글, 오피스, 3대 브라우저 등등

 

내부망 아이피를 할당받아서 프로젝트 고객 및 팀원끼리 문서를 공유할 수 있는 준비가 완료되는데까지 4일 정도가 걸렸네요. 이것저것 컴퓨터 내부망 사용을 위해 결재 받는 절차가 많은데 결재권자가 결재를 안해주면 마냥 기다려야 합니다. 

 

요구사항 분석/정의

이제 고객(공무원)과 회의를 통해 요구사항을 분석하고 정의합니다. 

RFP(제안요청서)와 ISP(정보전략계획), 관련 법령, 업무 매뉴얼 등등 요구사항 분석에 필요한 모든 자료를 고객으로부터 받아서 업무분석을 합니다. 

2주 정도를 내내 회의만 한거 같습니다. 빔프로젝트나 커다란 보드판이 있는 회의실을 찾기가 힘들어서 이곳저곳 떠돌아 다니면서 회의를 해습니다. 회의실을 오랫동안 사용할 수 없어서 1시간마다 회의실을 옮기면서 회의한적도 있네요. 

 

회의를 하면서 전체적인 프로세스를 그립니다.

프로세스 예시. 문구는 일부 변경. 공식 산출물은 아님

프로세스는

지나치게 큰 기능과 발생하는 엔티티(데이터) 위주로 

RFP의 내용이 누락되지 않아야 하고(가장 중요!!!)

다른 시스템과 협의해야 할 사항을 도출해야하고

개발하는데 이슈가 생길만한 부분이 없는지 도출합니다. 

 

특히 발생되는 엔티티(데이터)와 엔티티의 구성 해당 데이터를 어디에서 사용하는지 등을 표시해야 나중에 설계(ERD)하는데 누락되는 엔티티가 없게 됩니다.  

예를 들어, RFP의 '물품'의 의미는 'C시스템에서 발생한 물품과 D시스템에서 발생한 연구장비, 그리고 B시스템에서 사용자가 직접 입력한 물품 정보로 구성된다. (C시스템과 D시스템에서는 데이터 연계가 필요하다.)'와 같이 물품정보의 엔티티가 어떤 데이터들로 구성되어 있는지 파악하는 것도 중요합니다. 

 

위의 프로세스 PPT는 공식산출물 포맷이 아닙니다. 이상하게 공식산출물에 맞추어서 회의를 하려고 하면 힘들더군요. 위와 같이 정해진 양식 없이 자유롭게 작성을 한 후에 최종 완성된 프로세스를 공식산출물 양식에 맞춰서 작성을 하게 됩니다.  

 

이렇게 회의를 하면서 전체적인 프로세스를 그리면서 고객이 원하는 시스템 기능들을 전부 도출한 이후 요구사항 정의서를 작성합니다. 수많은 회의를 통해 전체적인 프로세스를 그린 이후이기 요구사항 정의서는 금방 작성합니다. 

 

요구사항 정의서 양식. 내용은 삭제 함. 프로젝트마다 조금씩 다르지만 큰 차이 없음

 

 

요구사항 분석은 아주 디테일하게!

이제는 실제로 개발을 해서 시스템을 오픈해야 하기 때문에 RFP의 애매한 문구를 아주 디테일하게 정의를 해야 합니다. 

 

예를 들면, RFP에 명시된 고객 요구사항이 '물품 인수인계 관리' 라고 되어 있는 경우(실제로 이렇게 되어 있음)

아래와 같이 개발에 필요한 모든 사항을 도출해서 고객에게 확인을 해야 합니다. 

1. 물품을 인수인계할 수 있는 주체는 누구인지? 기관 대 업체? 기관 대 기관? 업체 대 업체? 
2. 어떤 권한을 가진 사용자가 인수인계를 등록할 수 있는지? 업체에 속한 사람 아무나 가능한지? 특정권한을 가진 사용자만 가능한지? (사용자 권한관리에까지 영향을 미칠 수 있음)
3. 인계자가 인수자를 지정할 때 기관(업체)만 정하면 되는지? 아니면 실제 인수할 사용자까지 정해야 하는지?
4. 인수할 사용자를 지정할 경우 인수할 기관(업체)의 사용자 정보는 준비되어 있는지? (즉, 인수할 기관(업체)의 인수담당자가 시스템에 회원가입을 하고 권한을 획득해야 인수인계 프로세스가 진행되어야 할 수 있음). 
   그리고 동명이인이 있을 수 있으므로 사용자명 이외에 식별할 수 있는 항목(부서, 연락처 등)이 따로 저장하고 있는지?
5. 인수할 사용자를 지정하지 않을 경우 인수 최종 확인은 누가 하는지? 권한없는 사람, 아무나 인수를 한 경우 어떻게 되는지? 
6. 혹시 인수 확정 또는 반려를 인수자가 잘못 선택한 경우 다시 되돌리는 프로세스가 필요한지? 다시 되돌리는 프로세스가 필요하다면 이력으로 남겨야 하는지? 
7. 인계 등록, 인수 확정(반려), 인수 확정(반려) 취소 등의 행위가 일어났을 때 대상자들에게 알림(메일, 문자 등)이 가야하는지? 알림이 갔는지 또는 확인했는지 여부도 조회가능 해야하는지?

물론 위에서 확인한 모든 사항을 요구사항 정의서에 작성할 필요가 없습니다. 요구사항 정의서는 중요한 내용만 요약해서 작성하거든요.  

프로젝트 사업관리에서 산출물 테일러링을 어떻게 하느냐에 다르겠지만 가끔 '인터뷰 결과서'를 산출물로 작성하는 경우도 있죠. 위의 예시와 같이 고객에게 질문할 목록을 만든 후에 인터뷰를 하고, 그 결과를 산출물로 작성하는 거죠. '회의록'으로 대체하는 프로젝트도 있고요

 

이렇게 해서 요구사항 정의서까지 작성하면 큰 산은 넘어간 겁니다. 요구사항 정의가 가장 중요하거든요. 이후 모든 산출물에 영향을 미치며, 요구사항 추적하는데에도 영향을 미칩니다. 

 

감리가 자주 지적하는 부분이 요구사항을 세분화하라고 명확하게 정의하라는 겁니다. 

요구사항을 세분화 하는 것은 차후 실적(개발 완료율 등)을 체크하는데에도 영향을 미치므로 큰 기능을 하나의 요구사항ID에 몰아넣으면 실적이 확 떨어질 수 있습니다. 

예를 들어, 화면이 대충 10개 정도 나올거 같은 요구사항을 하나의 요구사항ID에 몰아서 정의할 경우 차후 검사검수 등을 위해 테스트를 했을 때 그 중 1개라도 부적합 판정을 받을 경우 해당 요구사항ID는 미완료로 판정받게 됩니다. 

즉, 완료율을 98%로 하느냐, 90%로 하느냐에 영향을 미치는게 요구사항ID 세분화라는 거죠.

 

이렇게 요구사항을 정의한 이후에 유스케이스 다이어그램과 정의서(명세서)를 작성하게 됩니다. 

유스케이스 다이어그램은 전체적인 시스템 기능과 액터간의 관계

유스케이스 정의서는 각 액터가 시스템의 기능들을 어떻게 사용하는지 흐름을 작성하는 겁니다. 

 

유스케이스 다이어그램과 정의서 작성은 다음 편에....