(7편) 분석 산출물 요구사항정의서 등 작성법 알아보기

 프로젝트 분석단계에서 사용자 요구사항과 어플리케이션, 인프라, 데이터 현황 분석을 하는 것은 매우 중요합니다. 분석이 잘못 되면 다음 단계의 설계, 구현, 테스트 등 모든 진행이 문제가 될 수 있습니다. 따라서, 분석 과정에 발생할 수 있는 문제점을 알아보고, 어떻게 작성하는 것이 좋을지에 대해 고민해 보도록 하겠습니다.

사용자 요구사항 파악하기

분석 단계에서 가장 중요한 부분입니다. 사용자 요구사항은 제안요청서의 기능 요건(SFR)을 엑셀의 상세 요구사항으로 정의합니다. ②번과 같이 SFR-01의 요구사항이 많은 경우 세분화하여 정의해야 합니다. 세분화하는 이유는 명확하게 요구사항을 파악하고 구현방안을 정의하기 위해서 그렇습니다. 구현방안은 솔루션이 납품되었을 경우는 패키지의 기본 기능으로 구현이 가능한지를 체크해야 합니다. 따라서 ③번과 같이 패키지에서 제공여부를 판단하고, 패키지에서 제공되지 않은 기능이라면 커스터마이징을 통해 지원을 해야 합니다. 커스터마이징이 필요한 경우는 ④번과 같이 고객과 협의내용을 구체적으로 기술해야 합니다. 그리고, ⑤번처럼 수용 여부를 기술하고, ⑥번에 변경내역을 요약하여 기술함으로써 의사결정 사항이나 요청해야 할 사항을 빠르게 볼수 있도록 정리합니다.

⑤번의 수용여부에는 ①번에 작성된 예시처럼 고객과 협의한 사항은 수용이 되고, 고객과 협의하여 제외하기로 한 것은 제외가 됩니다. 부분수용은 요구한 기능 중에 일부 기능은 지원하지만, 일부 기능은 미지원한다면 부분 수용으로 표시하고, 미수용의 경우는 본 사업에서 수용할 없는 경우이면 미수용으로 표시합니다. 또한, 개발 내역 중 연구소에 의뢰하여 개발이 필요한 부분이 있다면 연구소 의뢰로 표시하고 협의 중으로 표시할 수 있습니다. 이런 여러가지 수용여부가 결정되지 못하고 TF에서 결정이 필요한 경우는 TF결정으로 표시합니다.

TF 의사결정은 언제까지 해 줄것인지를 명기해야 하고, 주간 단위로 체크를 해야 합니다. 의사결정이 안되어 개발이 늦어지는 원인이 될 수 있기 때문입니다. 만일 의사결정 해주기로 한 기한까지 의사결정이 안된 경우는 이슈사항으로 올려서 주간보고와 이슈대장관리에 등록하여 관리해야 합니다. 요구사항 관련한 의사결정 사항에 대해서는 회의록을 별도로 쓰지 않고, 요구사항정의서롤 대체할 수 있기 때문에 요구사항에 의사결정사항의 날짜와 누구랑 협의를 했는지 담당자명과 직급을 기록해야 합니다.

요구사항정의서의 작성 내용은 No, 요구사항ID, 요구사항명, 요구사항설명, 상세요구사항ID, 상세요구사항설명, 구현방안, 고객사협의내용, 수용여부, 비고(변경내역 요약)의 형태로 기술하면 됩니다. 요구사항 분석 시 참석자는 각 업무별로 분리하여 어플리케이션, 데이터, 인프라 담당 PL과 전체 PM이 참석하여 업무 협의를 진행할 수 있습니다. 업무PL이 경험이 있는 분이라면 혼자 참석해도 무방합니다. 단, 이럴 경우는 녹음하는 것을 잊지 않으시길 바랍니다.

기능 요구사항 분석 외에 비기능 요구사항에 대한 분석도 같이 해야 합니다. 비기능 요구사항의 경우는 대부분 프로젝트를 수행하기 위한 제반사항들로 대부분 수용을 하게 됩니다. 단, 이관 관련 내용이나 성능 관련하여 추가적인 요구가 있을 경우는 별도로 표시하고 이에 대한 협의를 통해 의사결정하고 회의록을 작성하고 기록해야 합니다.

비기능 요구사항은 기능요구사항과 달리 기능구분, 관련근거(출처), 최초생성일자, 변경일자, 요구사항 변경여부가 더 들어갑니다. 비기능은 관련 근거(출처)가 제안서 외에 회의록이나 기술협상서 등이 될 수 있기 때문 입니다.

현행시스템 현황 분석하기

현행 솔루션 기본 환경조사

현행 시스템 분석은 구축할 대상 기존 솔루션에 대해 기본적인 사항을 조사하는 것으로부터 시작합니다. 고객사명, 기존 사용하고 있는 솔루션 버전, 고객수, 사용자통계, 사용기간, 사용기능, 연계현황, 기타 연동사례와 용량 및 디스크 용량을 파악하여 개략적인 이관 대상을 확인합니다.

추가 개발 현황 파악하기

유관시스템 연동 현황은 제품명, 제조사, 연동현황을 조사합니다. 이를 통해 연동 대상을 파악하고, 관련 업체와 연락을 통해 기술 지원 여부를 확인할 수 있습니다. 다음으로는 서버 구성 현황에 대해 파악합니다. 서버 구성은 WAS, WEB, 솔루션 서버의 정보(제조사, OS, CPU, RAM)을 구체적으 파악하고, 이중화여부와 각 서버에 올라가는 소프트웨어를 확인합니다. 이를 통해 기존 서버의 재활용여부나 서버 이중화 여부를 결정할 수 있습니다.

마지막으로 커스터마이징 된 내역을 조사하여 추가 개발 사항이 어떤 것이 있는지를 파악합니다.

결재 서식 현황 파악하기

현재 사용중인 결재서식을 부서/팀 단위로 조사를 하며, 결재서식의 양식명, 파일명, 파일형태, 연동여부, 사용여부를 조사하고, 연동 시 인터페이스 방안을 추가적으로 조사합니다. 결재 서식을 조사하는 이유는 전환 대상 서식과 추가적으로 변경하고 싶어하는 서식을 확인하고, 안쓰는 서식은 폐기하기 위함입니다. 또한 결재서식은 서식종류, 연동현황, 사용여부 등을 통계화하여 전달하게 됩니다.

다음은 다양한 형태의 게시판 현황을 조사합니다. 상위게시판명, 게시판명, 첨부파일최대 용량 등을 조사하여 이관대상의 게시판과 이관대상 사이즈를 산출하는데 기초자료로 활용합니다. 게시판을 조사하고, 각 본부/팀별 게시판 현황과 중복 사용여부 등을 통계로 제공합니다. 게시판 조사 시 권한 또한 같이 조사를 하게 되는데, 대부분 DB Query를 돌려 권한 부여 여부도 함께 조사하여 신규 시스템 이관 후 권한을 부여할 수 있습니다. 권한 부여 방식은 세부적으로 각 팀에서 관리하기 때문에 기본 권한만 시스템에서 부여한 후 각 게시판 담당자가 세부 세팅을 하도록 안내하는 것을 권고합니다. 그렇지 않으면, 프로젝트 안정화 기간에 권한 세팅만 계속 수 있습니다.

조직현황 파악하기

조직현황을 파악하는 것은 무척중요합니다. 조직 부서코드, 부서명, 사번, 이름, 사내번호를 조사하고, 이 중에 중복되어 사용되고 있는 부서코드나 사원번호가 있는지 그리고 겸직 여부 등을 파악하여, 조직 세팅에 활용할 수 있는 중요한 자료입니다. 이 단계는 시스템적으로 인사시스템으로부터 배치로 연계하여 받지만, 실제 오프라인으로 조사하는 것은 중복여부나 정책들을 명확하게 파악하기 위함입니다. 이외에 퇴직자 관리나, 비 정규직 관리 및 임시직 관리 을 어떻게 하는지도 조사하여 시스템 반영에 활용합니다.

이관 대상 데이터 파악

그룹웨어 프로젝트 경우, 결재, 게시판, 메일이 그 대상이 됩니다. 하지만, 최근 메일의 경우 이관에 대한 방식이나 이기종간의 메일의 경우 메일 사라짐 현상 등으로 인해 메일은 개인별 이관을 권고하고 있습니다. 전자결재 건수는 년도별로 부서별 문서 총건수, 본문 건수 ,첨부 건수 등을 파악하고, 게시판은 게시판 약 5레벨별로 게시판 종류, 게시판 구분, 사용권한정보, 게시판 관리자, 게시물 건수, 공개여부, 첨부개수, 첨부파일 용량 등을 파악합니다. 이관 대상은 각 기관 및 기업에 따라 다를 수 있으며, 대상에 따라 조사 양식을 작성하여 배포해야 합니다.

인터페이스 관련 현황 파악

송수신 시스템 간 처리형태, 인터페이스방식, 연계정보, 개발 지원담당자가 누구인지 파악을 합니다. 인터페이스 대상에 따라 추가적인 분석 과정을 거치게 되며, 연동 대상의 경우는 세부적으로 연동데이터, 처리형태, Request Type, 연계 프로토콜, 연동 Query, 내용설명 등에 대해 추가적으로 파악을 합니다.

조직 직위 코드 및 직위명, 서열 조사하기

직위코드, 직위명, 서열을 조사하는 것은 조직 서열 등급을 정의하여 권한등급으로 활용하기 위함입니다. 서열(Leveling)은 중복가능하며, 조직의 서열을 정하여 위에 나타날 수 있도록 정의하기 위함이며, 서열은 낮은 숫자가 높은 권한을 의미합니다. 조직코드 및 조직명은 기존 그룹웨어시스템의 조직 정보를 받아 이관하는 방식으로 처리가 가능하기 때문에, 시스템으로 받을 경우, 조사를 생략하는 것이 일반적입니다. 기타 사용자정보, 겸직정보 등을 요청합니다.

마치며

오늘은 분석단계 산출물의 작성법에 대해 알아보왔습니다.

분석단계 산출물에 가장 중요한 것은 요구사항정의서이며, 요구사항 정의 시 커스터마이징 내역과 수용여부를 명확히 구분하고, 추가요구사항과 커스터마이징은 별도의 탭으로 분리하여 관리해야 합니다. 별도로 관리하는 것은 매일 진척 상황을 체크하고 어떻게 해결할지에 대해 방안을 강구해야 한다는 뜻입니다. 이 부분이 프로젝트 초기에 결정되지 않으면 결국 사업 지연으로 갈 수 밖에 없습니다. 반드시 사업초기에 이슈가 될만한 사항은 의사결정과 논의를 해서 어떻게 해결할지를 모색해야 합니다. 묻어 두고, 프로젝트 중간에 터뜨리거나 모르는 척하다가는 결국 큰 피해로 이어지니 주의하셔야 할 부분입니다.

분석 단계 산출물은 설계단계의 산출물의 기초가 되니, 필요한 자료는 요청하여 받아 두시고, 기초 조사가 필요한 사항은 빠뜨리는 것이 없도록 미리미리 검토하여 조사를 하는 습관을 가지시기 바랍니다.

다음편에서는 설계 단계 산출물 작성법에 대해 알아보도록 하겠습니다.

 

프로젝트 관련하여 다른 사항이 궁금하시면 아래 링크를 클릭하세요

(1편) 프로젝트: 기술협상서 작성하기

(2편) 프로젝트: 사업수행계획서, WBS 작성하기

(3편) 프로젝트: 프로젝트 착수 보고 작성하기

(4편) 프로젝트: 사업관리 산출물 작성하기

(5편) 프로젝트: 주간보고, 월간보고 작성하기

 

(6편) 프로젝트: 회의록 종류 및 작성법 알아보기