서비스를 구현하기 위해 다양한 요구사항이 거론되는데, 이를 명확하게 정리해야 할 필요가 있습니다. 요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말합니다. 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세합니다.요구사항 명세서(SRS, Software Requirements Specification)은 요구사항 정의서, 요구사항 기술서도 같은 의미로 봐도 무방합니다. 주로 외주 형태에서 작성되는 문서였으나, 스타트업에서도 내부 의견을 정리하기 위해 작성하는 것이 좋습니다.
작성된 요구사항 명세서를 토대로 회의가 진행됩니다. 실제 필요한 기능인지, 개발 이슈는 없는지, 이번 단계(버전)에서 개발하는 것이 좋은 것인지에 대해 검토합니다. 피드백된 내용 또한 업데이트하여 관리합니다.
- 프로젝트 전체 규모를 파악
- 구현 가능 여부에 대한 논의
- 커뮤니케이션 비용 절약
- 프로젝트 일정 계획 수립
요구사항 명세서는 공식적으로 사용하는 양식은 없지만, 필수로 기재 해야 하는 항목은 대게 유사합니다.
- 요구사항 명세서를 읽는 작업자(개발자, 디자이너 등)가 이해하기 쉬워야 한다.
- 무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.
- 하나의 요구사항에 여러가지(복수) 요구사항을 작성하지 않는다.
- 다른 요구사항 모순 또는 중복되지 않게 한다.
- 애매한 단어를 사용하지 않고 명확하게 기재한다. ( ~ 있으면 좋겠다 → ~ 기능 필요) 오해하지 말아야 할 것이 명령하는 것이 아니고 의견을 모호하게 하지 말고 명확하게 표현하라는 의미이다.
- 꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다. 다만 모든 요구사항에 남발 해서는 안된다.
- 동일한 용어를 사용한다. 댓글, 코멘트, 덧글과 같이 모두 같은 의미를 다르게 표현하지 말라는 의미이다.
- 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달하는 것이 좋다.