Toy Project로 알아보는 실전 기획 3 (기능명세서 작성)

SI 기획자가 마주하게 될 문서 

요구사항 수집 및 작성 ▶ IA 작성 ▶ 기능정의서 작성 ▶ 정책서 작성 ▶ StoryBoard 작성 

 

지난시간 작성한 IA를 기준으로 기능명세서를 작성해 보겠습니다.

이전글 ↓ ↓ ↓

 

Toy Project로 알아보는 실전 기획 2 (IA 작성)

 

기능명세서는 큰프로젝트의 경우 개발자가 작성할 경우도 있지만 기획자가 작성 할 경우도 있습니다.

기획자에게는 StoryBoard 작성 전 전체 기능을 뽑아 봄으로 고객과의 의사소통 시 분쟁을 줄일 수 있습니다. 

 

기능명세서에는 화면을 기준으로 제공되어야 하는 기능에 대한 목록을 정의 합니다.

한 화면에 여러 기능이 포함 될 수 있기 때문에 화면에 다수의 기능 ID가 포함 될 수 있습니다. 

기능명세서 샘플(출처 : 직접작성)

 

기능 명세서 항목은 아래와 같이 하겠습니다.

• 번호 : no
• 요구사항 ID : 요구사항시 도출됬더 ID 번호 
• 화면 ID : 기능이 필요한 화면 ID
• 화면명 : 기능이 필요한 최종 화면 ID. IA의 depth를 유지하고 작업 할 수 도 있음.
• 기능 ID : 기능 구분할 수 있는 ID
• 기능명 : 기능 명칭
• 기능상세 : 기능 상세 설명
• 변경여부  :  작성 된 후 기능 추가 삭제등의 변경 시 작성
• 변경내역 : 변경된 상세 내용 작성
• 작업구분 : 해당기능을 작업/구현해야 하는 실제 작업구분. 기획/디자인/퍼블리싱/프론트엔드개발/백엔드개발 
• 비고

 

작업구분의 경우 기능명세서 작성시 각 기능에 대한 작업 범위를 체크 합니다.

웹사이트는 디자인만 필요할 경우도 있고, 백엔드만 필요한 기능이 있을수도 있기 때문입니다.

각 파트별로 업무기간이나 난이도 등을 미리 체크해 볼 수 있습니다.

 

기획자가 작성했다면 각 파트의 담당자들이 동료검토를 해서 수정 하는 작업을 거치거나 더 필요한 기능을 고객에게 요청 받으면서 문서를 빌드업 합니다.

 

기능명세서 작성시 유의사항 

기능은 고객에 의해서 추가 요청이 생길 수 있는 부분 이므로 

최초 기능 작성시에는 필수 기능을 중심으로 최소한으로 입력하는 것이 좋습니다.

SI 의 경우 턴키 계약일 경우가 있고, 고객사에서 작업 금액이 산출되어  계약된 상태가 대부분 이기 때문에 개발사 입장에서 금액을 더 높이지 못하는 경우가 많습니다.  

 

수행사의 PM이라면 고객이 꼭 원하는 기능과 전체 업무범위 내에서 가능 한 부분을 조정 할 수 있는 능력이 요구 됩니다.

 

 

다음에는 정책서에 관련하여 알아 보겠습니다.