반응형
다른 기업들과 협업할 때 우리가 원하는 제품이 무엇인지 공유하는 것이 쉽지 않다는 것을 알게되었다.
기능 명세서를 작성해서 공유하면 된다는 말에 생각하는 기능들을 나열해보았는데 그것도 좋은 방법은 아닌 것 같다는 생각이 들었다.
명확한 기준이 없고 훌륭한 기능 명세에 대한 예시를 본 적이 없기 때문일 것이다.
구글링을 통해 얻을 수 있는 몇 가지 글들을 참고하여 다시 내 언어로 소화해 보려고 한다.
Software Requirements Specification(이하 SRS)로 검색해서 가장 처음 등장하는 글을 읽어봤더니 유용한 정보가 많이 있었다[1].
이글에서 참고하는 사이트는 IEEE 라는 곳에서 고민한 SRS 이다. http://standards.ieee.org
얼핏봐도 SRS뿐만 아니라 프로젝트의 시작부터 끝까지 제대로된 형태를 만들기 위한 노력이 있었다는 것을 알 수 있다.
아래 영상을 보면 어떤 항목들로 정리해두었는지 간단히 알려준다[2].
1. Introduction
1.4 Project Scope
2. Overall Description
2.1 Product perspective : 전체적인 서비스는 어떻게되고, 지금 이 버전에는 어떤 것을 포함할 것인가
2.2 Product Features : 주요한 특징을 말하는 듯. major feature
2.3 User Classes and Characteristics
2.5 Design & Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies : 예를들어 어떤 고객은 이전 버전을 쓰고, 어떤 고객은 현재 버전을 사용하고, 어떤 고객은 third party library를 사용할 때 어떤 서비스를 제공할 것인가
3. System Features : SRS에서 핵심. use-case를 쓸 수 있고, functional area를 쓸 수 도 있음
3.x.1 Description and Priority : SRS에 명세된 기능들 가운데 우선순위
3.x.2 Stimulus/Response Sequences : very top level의 use case
3.x.3 Functional Requirements : 기능 필요사항들을 아이템화 시킴. 여기서 중요한 것은 기능을 구현하는 것이 아니라, 기능의 필요를 정의하는 것.
4. External Interface Requirements : 대부분 여기까지 작성하는데 지쳐서 이것을 생략할 때가 많음. 하지만 이것이 있어야 커뮤니케이션하기 좋음
4.1 User Interface
5. Other Nonfunctional Requirements : 소프트웨어 품질에 많은 영향을 끼침. safety와 security는 정말 중요한 부분.
5.4 Software Quality Attributes : System Features에 나왔던 것을 보완해줌
6. Other Requirements : 나머지 것들
Appendix A : Glossary : 중요한 용어, 훌륭한 아이디어 정리해둠
Appendix B : Model 레벨의 내용들 정리
Appendix C : TDD를 통한 내용, 이슈들 정리
[1]
How to write a software requirements specification - MicroTools Inc.pdf[2]
https://www.youtube.com/watch?v=_XTQjKhh6hQ
SRS 소프트웨어 기능명세 IEEE.pdf[3]
http://blog.naver.com/pronaman/60169350981
SRS 작성 가이드.pdf반응형