좋은 명세서 만들기

비전서(제안 및 과업설정과정) -> 명세서(요구분석) -> 설계문서 -> 보고 문서

의 업무 프로세스 중에서 명세서 제작에 대한 정리입니다.

 

[필요성]
 1. 개발은 변경에 의한(또는 예측치 못했을 경우의) 손실이 크므로 최대한 줄일 수
    있는 신중한 명세를 작성
    이해할 독자 (고객,개발자,테스터,관리자,매뉴얼작성자)
 2.중요한 결정을 미루지 않을 수 있다.(프로젝트 후반의 리스크 감소)

 

[정의]
 1. 기능명세 (functional specification)
  - 기능, 화면, 메뉴, 대화상자 문구 등
  - 어떻게 동작하는지는 신경쓰지 말자
 2. 기술명세 (technical specification)
  - 자료구조, 데이터베이스모델, 프로그래밍 언어 및 도구, 알고리즘 등

 

[명세의 예]
 1. 면책조항 : 명세의 사용한계를 설명
 2. 저자 : 한사람이 작성 -> 프로그램매니저(MS에서 말하는 PM)
 3. 시나리오 : 사용자 시나리오, 가급적 상세하게 모든 가능한 액션을 담아 본다.
 4. 회피목표 : 불필요한 기능을 선별,,,상상의 산물들을 과감하게 정리
 5. 개괄 : 간단한 흐름도나 목차
 6. 세부사항
  - 화면마다 상세하게
  - 기술적 타당성을 메모할 수도 있음
 7. 미해결 문제 : 처음에는 많이 생각하고 잡아두지만 뒤로 미루면 안됩니다..
 9. Side Notes
  -  명세의 독자를 위한 개별적인 이야기를 담는다,.,
     예로 개발자만 읽어야 할 부분이 있다면, 개발 Side Note를 작성
 10. 지속적인 업데이트는 당연

[명세 작성자]
 1. 프로그램 매니저
   - 회사의 큰그림을 염두에 두고 있어야 하며, 같이 일하는 개발자는 코드조각에 집중
   - UI연구, 고객만나기, 명세서 작성이 주 업무
   - 카리스마가 필수이나, 일은 상하의 관계가 아닌 협의로 처리할 수 있어야 함.
   - 개발자나 마케터 출신이 승급하여 하는 것이 아니라 독립적인 Job 능력이다.

 

[명세서 작성팁]
 “명세서는 모두 쉽게 읽어야 됩니다!”
 1. 재미있게 쉬운단어와 예로 씁시다.
 2. 독자의 이해수준에서 컴파일 되도록 --해괴망측한 기술용어나 외계용어 사절
 3. 단순하게 작성하며, 읽기 편하게 화면이나 다이어그램도 적극 활용
 4. 여러차례 읽고 또 읽어라
 5. 표준양식으로 만들려고 하지 마라.