학부생 수준의 프로젝트 할 때는 요구사항명세서 보단 기능설계명세서가 더 정확한 표현이겠다. 그렇다. 나는 여태껏 요구사항 명세서란 그런 것인 줄 알았다.
고객이 원하는 기능사항에 따라 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세한 명세서
이건 학문적으로 잘 뜻을 눌러바른 것이고, 이것이 그러니까 **왜 필요한데?**를 이해하지 못 했다.
SRS의 필요성과 기능은 단 하나이다.
고객 설득. 합의서.
그러니까 진짜 개발사에서 고객이 원하는 것은, 시장이 원하는 것은 무엇인지 분석하고 기능사항들에 대해 자세하게 명세하는 문서이다 이것이다.
물론 실제 개발을 위해 테스트 가능해야 하고 블라블라 따져야할 조건들, 그리고 이것을 명세하고 진행해가는 방법론은 수두룩 백백이고 상황 및 팀원에 따른 적합한 개발법도 존재한다. // 진짜 생각보다 복잡하다고…아니 찐으로..;;
그렇다면 우리가,내가 작성하고자하는 문서는 무엇이었을까?
화면설계서 (Wireframe)와 기능명세서 (Functional Specification)
그렇다. 사실 이론적으론, 학문적으론, 교수님한테 듣기론 -방법론에 따라 다르겠지만- 요구사항이 완전하고 제대로 작성되어야 설계가 편해지고 품질이 높아진다.
그러나 이건 학부생 수준에서의 적합한 멘트가 아니다. 학부생 수준에서는 만들고 고치고 만들고 고치고 만들고 고치고가 적합하다. 우리는 구현만 되면 되는 수준이다. 애초에 배운 것을 쓰기 위해서 프로젝트 진행을 하는 것이므로 실제 개발 프로젝트들과 목적성이 다르다 이거다.
내가 실수했던 부분이 이거다. 실제 고객이랑 소통하고 그들로부터 피드백을 통해 요구사항명세서를 세세하게 작성하는 부분을 간과한 채, 양식을 다운로드 받아 그대로 이행하다가 그것을 또 테이블화 시키는 미친짓을 했다…
이제 배웠으니 “학부생 수준에서의 프로젝트 진행 시” , 이해하기 쉽고 수정하기도 용이한 “*기능/화면설계서”*를 작성해봐야겠다.