요구공학 - SRS (SW Requirements Specification)

요구분석명세서

#정의: SW 에 포함될 기능과 제약조건, 성능, 정확성, 사용용이성등의 요구사항과 스펙을 정리한 요구분석 단계의 산출물

#특징: 쉽게작성, 개발자와 사용자 쌍방이 동의한 내용기술, 모든기능 정확히 기술, 모든 제약조건 기술, 테스트 기준제공(기능,특성,품질에 대한 정량적 기술) - Snowball Effect 예방

 

#요구분석 명세서 평가기준 : 명완검일수추개

- 명확성(모호하지 않게),완벽성(빠짐없이) , 검증가능성(충족여부),  일관성(모순없게), 수정용이성(요구사항 변경시), 추적가능성(요구사항근거), 개발후 이용성(운영과유지보수)

 

#요구분석 명세서 목차

1. 개요 : 시스템 목적, 범위, 정의(약어), 참조

2. 기능적 요구

 - 외부 인터페이스 요구 : 사용자, 하드웨어 인터페이스

 - 기능요구 :

3. 기타요구 및 제약사항

- 성능요구 : 반응시간, 처리요소 시간, 처리율

- H/W 요구 : 기억장치 규모, 통신수용도

- 예외조건에 이의 처리

- 자원, 인력에 대한 제약조건

 

4. 인수조건 : 기능시험 및 성능시험

#SRS 상세수준

- CASE A:  요구분석, 설계,구현 인력이 동일 ,  유사경험  있는 경우

- CASE B : 요구분석, 설계구현 인력이 다름, 유사경험 없는 경우

- CASE C : 프로젝트 일부단계 외주 운영, Critical S/W 개발, 구성원 원격지 근무 개발시 상세도 높아야 함.

 

#요구사항 종류

- 기능적 요구사항: 기능, 자료, 인터페이스

- 비기능적 요구사항: 이식성, 성능, 확장, 유연성, 품질 >> 이*성*확*유*품

 

 

 

 

요구명세(SRS; Software Requirement Specification)는 SW프로젝트의 과업, 비용, 기간을 정량화한 후 합의하여 향후 분석․설계․구현․개량 전 과정에서 의사결정의 주요 판단기준이 된다. 하지만, 그 중요성에 비해 국내 SI 프로젝트에서 많이 활용되지 못했다. 애초부터 애매한 요구사항으로 RFP를 공고한 후 계약체결까지 명세(Spec.) 수준으로 구체화되지 못한 상태에서 프로젝트를 일단 시작한 후, 구현산출물을 보면서 명세를 거꾸로 확정해 나가는 주먹구구식 개발관행이 일반적이었기 때문이다.

 

https://spri.kr/posts/view/22234?code=insight

[2018-001] 요구명세(SRS)의 중요성과 제도화 방향 - SPRi