SRS(Software Requirement Specification) 혹 소프트웨어 사양서 1

제조업의 개발 조직 입장에서 가장 어려운 개발 단계는 무엇일까?

사람마다의 경험에 따라 혹 조직에서 맡은 역할에 따라 다를 수는 있지만 개발 범위를 확정하는 것이 어렵다는 점은 대부분 인정한다.

개발에 착수하게된 배경이나 사용자의 니즈와 개발 범위는 전혀 차원의 이야기이다. 외주 개발로 진행되는 경우는 개발사, 개발 조직 담당자, 사용 부서 간에 개발 범위에 대한 생각이 달라서 초기부터 개발 완료까지 지속적인 트러블이 생기곤 한다.

현업에서 갖고 있는 문제점을 해결하기 위해 솔루션을 도입할 경우는 더 복잡하다. 해당 사안에 대해 문제 정의가 제대로 되었는지, 현상 파악을 충분히 한 것인지, 대안이 최선의 선택인지가 불문명할 수 밖에 없다.

여기에 대한 최소한의 해결책이 소프트웨어 사양서이다. 사양서는 잠정 합의된 해결책을 명시적으로 드러내고 이해관계자 간 동의를 구하는 과정을 위해 꼭 필요하다. 개발계획서 등의 형태로 비슷한 역할을 하고 있는 문서가 있지만 조직의 특성에 맞는 사양서가 있어야 실패를 최소화할 수 있고 상호 간의 충돌을 막을 수 있다.

외주 개발을 위한 사양서는 개발 초기 단계에 작성하는 초기 사양서, 개발을 위해 상세하게 작성한 상세 사양서, 개발 과정의 내용이 반영된 최종 사양서의 세 단계로 구분할 수 있다. 사양서는 각 회사의 기밀 사항이기도 하고 워낙 상황에 따라 작성 수준과 범위가 달라서 참고할 만한 샘플을 찾기 어렵다. 개발 초기 단계에 RFP를작성하거나 예산 및 일정을 잡기 위한 초기 사양서 샘플로서 다음을 제안해본다. 발주사가 개발계획에 고려할 요구사항은 사양서 본문에서 드러내고, 이에 대해 구현방안에 대해 첨부 문서에서 제시한다면 상호이해도를 높인 상태에서 일을 착수할 수 있다.