소프트웨어 요구사항 명세서
요구사항 명세서
요구사항 명세서는 요구사항 기술서, 요구사항 정의서라고도 불린다. 이는 고객의 요구사항(모든 기능)을 상세하게 정리한 내용을 의미한다.
요구사항은 여러가지 이유로 프로젝트 수행 도중에 변경될 수 있다. 워터풀(waterfall) 모델의 소프트웨어 개발 프로세스에서는 필수적으로 작성해야하지만, 애자일(agile) 방법론을 적용한다면 요구사항 명세서를 생략하기도 한다.
📘요구사항 명세서가 필요한 이유?
요구 사항 명세서를 사용하면 프로젝트 전체 규모를 파악하고, 요구사항(기술)이 구현 가능한지 확인할 수 있고, 커뮤니케이션 비용을 절약할 수 있다. 이를 바탕으로 프로젝트 일정을 계획하는데 유용하다. 차후 개발자가 서비스의 전체적인 기능을 파악할 때 유용하다.
📘요구사항 명세서 요소
공식적으로 사용하는 양식은 없지만, 필수적으로 작성해야하는 요소들이 있습니다.
필수적으로 작성해야하는 요소
- 요구사항 구분
- 요구사항 ID
- 요청사항 (기능)
- 요청사항에 대한 설명
- 요청자/ 부서/ 작성자
- 수용 여부/진행사항
예시
RQ-ID | 요구사항 | 요구사항 내용 | 입력 | 출력 |
---|---|---|---|---|
REQ-01-01 | 로그인 | 가입된 이메일과 비밀번호를 이용해 로그인할 수 있다. | 로그인하지 않은 상태에서 서비스 방문 | 로그인 화면이 표시됨 |
REQ-01-02 | 회원가입 | 이메일과 비밀번호를 이용해 회원가입할 수 있다. | 로그인 화면에서 회원가입 버튼을 클릭 | 회원가입 화면이 표시됨 |
REQ-02-01 | 노트 목록 조회 | 생성일 기준으로 정렬된 노트 목록이 표시된다. | 메인 페이지 방문 | 화면 사이드바에 클릭 가능한 노트 목록이 표시됨 |
📘좋은 요구사항 명세서의 특징
● 요구사항 명세서를 읽는 작업자(개발자, 디자이너)가 이해하기 쉽다.
● 무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.
● 하나의 요구사항에 여러가지의 요구사항을 작성하지 않는다.
● 애매한 단어를 사용하지 않고 명확하게 작성한다. (있으면 좋겠다 X, 기능 필요O)
● 꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다. (남발X)
● 동일한 용어를 사용한다.
● 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려운 경우에는 대체 가능한 방법도 함께 작성하는 것이 좋다.
기능 명세서
최종 결과물(아웃풋)에 대한 기능을 중심으로 설명된 문서이다. 사용자 관점에서 작성되기 때문에 내부 구현 또는 설계 이슈관련 내용은 포함되지 않는다.
참고 사이트