요구공학 - SRS (SW Requirements Specification)

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.) 수준으로 구체화되지 못한 상태에서 프로젝트를 일단 시작한 후, 구현산출물을 보면서 명세를 거꾸로 확정해 나가는 주먹구구식 개발관행이 일반적이었기 때문이다.

 

■ 목 차

Ⅰ. 배경

Ⅱ. 요구명세(SRS; Software Requirement Spec.)의 중요성과 역할

Ⅲ. 공공SW사업 이행방안 : SRS중심의 SW사업 관리 

 1. 제안요청서와 SRS
 2. SRS와 계약
 3. SRS에 근거한 과업변경
 4. SRS와 사업검수
 5. SRS와 사업비
 6. SRS와 선행사업 분리

Ⅳ. 민간SW사업 방식의 변화방향

 1. 공정계약의 원칙과 표준계약서의 활용
 2. 분쟁의 조정

Ⅴ. 시사점

 

 

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

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