SRS (Software Requirements Specifications)

소프트웨어 요구사항 정의서의 IEEE 표준 : IEEE std 830-1998



소프트웨어 요구사항 정의서 작성 - Writing Software Requirements Specifications
http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
by Donn Le Vie, Jr. 


이런 시나리오가 있다 : 당신은 최근에 HTML Help 프로젝트를 마쳤다... 더이상 야근도 주말 근무도 하지 않고 정상 근무로 돌아 간다. 그때 개발팀의 리더가 당신의 사무실로 들어와서 "다음에 진행할 주요 프로젝트를 위해서  기능 요구사항 정의서 양식에 넣어주시오" 라고 말한다.

"뭐라고요?" 당신은 약간 충격을 받은 모습으로 쳐다본다. "내가 왜 이런 대접을 받아야 하죠? 심지어는 어디서부터 시작해야 되는지 몰라요!, 기술 전문가 누군가가 도와줘 봐요... "


당신의 프로젝트를 위해서 소프트웨어 요구사항 정의서를 작성하라
Software Rquirement Specification (SRS) Template - start writing SRS for your project
http://sachinkraj.wordpress.com/2007/10/04/software-requirement-specification-srs-template-start-writing-srs-for-your-project/

SRS란 무엇인가?
SRS는 기본적으로 고객 또는 잠재적인 고객 시스템 요구사항들 또는 주로 실재적인 디자인 작업 또는 개발을 하는 사람을 이해시키는 문서이다.


좋은 SRS의 잇점
-프로덕트가 무었을 할 수 있는지 고객과 공급자 간의 동의의 원칙을 수립한다.
-개발의 수고를 줄여준다.

-비용과 스케쥴을 추정할 수 있는 논거를 제공한다.
-유효함과 검사의 기준선을 제공한다.
-품질 향상을 위한 원칙으로써 제공한다.


SRS는 어디를 지향해야 하나?
1. 기능적으로 . 소프트웨어가 무었을 할 수 있는가?
2. 외부 인터페이스들 . 소프트웨어가 사람, 하드웨어, 또는 다른 소프트웨어와 어떻게 상호작용을 하는지?
3. 성능.  다양한 기능들의 속도, 가용성, 응답시간, 복구시간이 무었인지?
4. 속성들. 휴대성(이식성), 정확성, 유지보수성, 보안성, 기타, 생각해보아야 할 것이 무었인지?
5. 구현하는데 디자인 제약성. 효과에 어떤 표준을 요구하는지, 구현언어는 무엇인지, 데이터베이스를 통합하는 정책은 무엇인지, 자원 제한은 어떻게 되는지 , 운영환경은 어떻게 되는지. 기타.?

훌륭한 SRS는 어떤 성격을 가지고 있나. SRS는 아래와 같아야 한다.
1. 정확해야한다.
2. 애매모호하지 않아야 한다.
3. 완전해야 한다.
4. 일관성이 있어야 한다.
5. 안정성 and/or 중요도의 순위가 정해져야 한다.
6. 검증할수 있어야 한다.
7. 수정가능해야 한다.
8. 추적가능해야 한다.


자료 :
IEEE Std 830-1998
http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html


Texas Department of Information Resources 의 양식
http://www.dir.state.tx.us/pubs/framework/