Specification 작성 방법 -1

 어느 경우에도 설계도를 그리지 않고 뭘 만드는 경우는 인류 역사 5000년 이래 없다. 아무리 단편 소설을 쓰더라도 최소한 플롯은 적어두고 시작한다.

 그런데 소프트웨어를 만드는 데는 어떻게 해야 하는지 잘 모르는 사람이 많다. 물론 어려운 본질에서 벗어난 온갖 문서질에 치이다 보니 아예 하지 말자는 사람들도 있다.

그럼 뭘 써야 하느냐? 이렇게 해보면 어떨까 싶다.

1. GUI Specification: 만들고자 하는 소프트웨어가 어떤식으로 화면이 구성되어야 하고 어떤 입력을 받아서 어떤 결과를 보여주어야 하는지를 ‘그린다’. 하다보면 사실상 그림과 설명으로 구성이 되는 경우가 많다.

출처:http://www.startuprocket.com/blog/how-to-create-a-user-interface-specifications-document-ui-spec

2. Software design specification: 만들고자 하는 소프트웨어가 기술적으로 어떻게 구성이 되어야 하는지를 적는다. 어떤 플랫폼을 이용하게 될지, 구조는 어떻게 할지, 어떤 식으로 Deployment되어야 하는지를 적는다.

출처:https://code.google.com/p/tactical-cloud/wiki/SoftwareDesignSpecification

3. Test plan : 앞서 작성한 Specification의 항목 하나하나를 어떤 식으로 Test할 지를 적는다. 실제 이 문서는 QA를 담당하거나 고객측에서 제품을 검증하거나 자신들이 만든 소프트웨어가 어떻게 테스트가 되어야 하는지를 적는 과정에서 다른 두 문서를 계속 수정하는데 도움을 주기도 한다. 

V-Model이라는 개념으로 이것들을 이어볼 수 있다. (참조만 하시라... ) 

출처:http://www.pmstecnoelectric.it/en/pms/automazione.aspx

 방법론은 여러가지지만 기본 원칙은 '의사소통'이 되야 한다는 것이다. 이에 대해서는 뭐 수많은 애자일 코치들이 이야기 할 거라서 패스. 언제나 교조적인 적용은 문제를 키우므로 조직의 맥락에 따라 팀의 구성원에 따라 유동적으로 적용해야 한다.

각 문서들의 뭐 좋은 예는 없을까? 그건 다음 시간에.