본문 바로가기
기획/PM&PO

개발 과정에서의 중간 산출물

by 랜턴K 2025. 1. 25.
반응형

요구사항 정의서 

기획 초반에 요구사항 정의서를 분명히 남겨서, 

도메인 전문가의 요구사항을 반영할 수 있도록 한다. 

 

워터폴 방식으로 진행할 때에도

도메인 전문가의 의견이나, 상호 소통 부족에 따라 요구사항은 새롭게 정의될 수 있다. 

이는 요구사항에 대한 추적표를 통해 별도 관리하여 최신화될 수 있도록 한다. 

 

요구사항 추적표

도메인 전문가 또는 프로젝트 참여자의 착오로 기존 요구사항이 변경될 수 있다.

혹은 프로젝트 진행 과정에서 터지는 현실적인 문제들도 원인일 수 있다. 

 

필요하면 다음 기회로 해당 요구사항을 넘겨야 할 수도 있고,

아예 개발요건에서 삭제도 가능하다. 

 

화면설계서

도메인 전문가와 업무를 진행할 때,

실제로 커뮤니케이션 가능한 시점은 바로 이 시점부터라고 생각이 든다. 

요구사항에 화면설계가 대응될 수 있게 되어야 한다. 

화면설계서는 이후 품질 테스트 과정에서 점검 목적으로 그대로 활용될 수 있게 작성한다. 

 

필요하면, 화면설계서와 함께 테이블 정의서의 주요한 내용을 남기는 것이 필요하다

그래야 인터페이스와 로직에서 발생할 수 있는 구현 한계를 

도메인 전문가에게 이해시킬 수 있다.

 

테이블정의서

주요 데이터에 대한 테이블 정의서를 남긴다.

테이블 구성 / 관계/  자료형 / 크기 등을 면밀히 남긴다.

필요하면, 각 테이블이 언제 참조되는 지 추가로 설명을 남긴다. 

 

인터페이스 설계서

시스템 인터페이스에 대한 정보를 남긴다

 

개발소스

 

단위테스트결과서 + 결함관리 대장 

개발은 생물이다.

마지막에 모든 인수테스트를 마치고 작업할 수는 없다. 

단위테스트를 할 때의 조건과 상황을 체크하고 

이를 통해 추후에 발생할 수 있는 문제점을 진단하여 피드백할 수 있게 작성한다.  

 

인수테스트

화면 기준으로 테스트 리스트를 작성한다.

테스트 결과를 추적하여 최종적으로 테스트 합불 여부를 판별한다. 

 

사용자매뉴얼

 

운영자인수인계확인서 운영매뉴얼

 

변경관리대장 

반응형