해설 보기
정답아키텍처 명세는 요구분석이 아닌 설계 단계의 산출물이므로 SRS에 포함되지 않습니다.
핵심 개념
소프트웨어 요구분석 명세서(SRS)의 구성 요소
SRS(Software Requirements Specification)는 요구분석 단계의 최종 산출물로, '무엇(What)을 만들 것인가'를 기술하는 문서입니다. IEEE Std 830을 기준으로 개발 시스템의 목적과 범위, 전체 개요, 기능적 요구사항, 성능·신뢰성·보안 등 비기능적 요구사항, 외부 인터페이스 요구사항, 제약사항 등이 포함됩니다. 또한 구조적 분석 기법을 적용한 경우 자료흐름도(DFD), 자료사전(DD), 소단위명세서(Mini-Spec) 같은 분석 모델링 산출물도 명세서에 함께 실립니다. 반면 아키텍처 설계나 모듈 구조 명세는 '어떻게(How) 만들 것인가'에 해당하므로 요구분석이 아닌 설계 단계의 산출물입니다.
선지별 해설
①개발 시스템의 목적(Purpose)과 범위(Scope)는 SRS 서두의 개요(Introduction)에 반드시 기술되는 항목이므로 SRS에 포함되는 내용입니다.
②인터페이스 '요구사항'은 SRS에 들어가지만, 아키텍처 명세는 요구사항을 어떻게 구현할지 결정하는 설계 단계 산출물입니다. 요구분석은 What, 설계는 How를 다루므로 아키텍처는 SRS의 내용이 아닙니다.
③자료흐름도·자료사전·소단위명세서는 구조적 요구분석의 대표적 모델링 도구이자 산출물로, 요구사항을 명세화한 결과이므로 SRS에 포함됩니다.
④기능적 요구사항과 비기능적 요구사항은 SRS의 핵심 본문에 해당하는 가장 대표적인 구성 요소입니다.
해설 보기
정답중요한 문제점이 프로젝트 후반부에 발견된다는 것은 프로토타입 모델이 아닌 폭포수 모델의 단점입니다.
핵심 개념
프로토타입(Prototype) 개발 모델의 특징
프로토타입 모델은 고객의 요구사항이 불명확할 때 시제품(견본)을 빠르게 만들어 보여주고, 고객의 피드백을 반영해 요구사항을 구체화해 나가는 개발 모델입니다. 개발자와 사용자 사이의 의사소통 오류와 견해 차이를 조기에 해소하고, 불완전하거나 상호 모순되는 요구사항을 초기에 발견할 수 있다는 것이 가장 큰 장점입니다. 또한 완전하지는 않아도 실제로 동작하는 시스템을 보여주므로 기능성과 유용성을 관리자·사용자에게 실증할 수 있습니다. 반대로 문제점이 프로젝트 후반부에 가서야 드러나는 것은 요구분석을 초기에 확정하고 단계를 순차 진행하는 폭포수(Waterfall) 모델의 단점입니다.