요구공학 — 소프트웨어공학 기출 모아보기

X신뢰성, 성능, 안전성은 기능적 요구사항에 해당한다.

신뢰성, 성능, 안전성은 시스템이 어떻게 동작해야 하는지를 규정하는 품질 속성으로 비기능적 요구사항에 해당한다.

O비기능적 요구사항인 MTBF는 (MTTF + MTTR)로 나타낸다.

MTBF(평균 고장 간격)는 평균 무고장 시간(MTTF)과 평균 수리 시간(MTTR)의 합으로 정의된다.

OWindows에서 C++ 언어로 개발하라는 것은 비기능적 요구사항으로 분류된다.

개발 환경, 플랫폼, 사용 언어 등에 대한 제약은 시스템 기능이 아니라 구현 제약을 규정하므로 비기능적 요구사항에 해당한다.

O비기능적 요구사항인 가용성을 높이기 위해서는, MTTF를 증가시키고 MTTR을 감소시켜야 한다.

가용성은 MTTF/(MTTF+MTTR)로 표현되므로, MTTF를 늘리고 MTTR을 줄이면 가용성이 높아진다.

O인터뷰는 사용자 또는 관련자들과의 직접적인 대화를 통하여 요구사항을 추출한다.

인터뷰는 이해관계자와의 직접 대화로 요구사항을 도출하는 기법이므로 옳다.

X워크스루는 업무에서 사용하고 있는 다양한 종류의 문서를 분석하는 기법이다.

워크스루는 산출물을 동료들이 함께 검토하는 정적 검토 기법이며, 문서를 분석하는 기법은 문서 분석(document analysis)이므로 옳지 않다.

OJAD(Joint Application Development)는 프로젝트 관리자, 사용자, 개발자 등이 모여 상호 토론하는 방법이다.

JAD는 관리자·사용자·개발자가 함께 모여 워크숍 형태로 요구사항을 도출하는 기법이므로 옳다.

O관찰은 개발될 소프트웨어의 사용자가 수행하는 활동을 살펴보는 기법이다.

관찰(observation)은 사용자의 실제 업무 활동을 지켜보며 요구사항을 파악하는 기법이므로 옳다.

X전자레인지 시스템은 쿠킹 중일 때 남은 쿠킹 시간을 계산하여 표시한다.

이는 시스템이 수행하는 동작(기능)을 기술한 기능적 요구사항이므로, 비기능 요구사항을 묻는.

O프로그램은 400 MB 이내의 메모리를 사용해야 한다.

메모리 사용량 제약은 성능·자원에 대한 품질 제약으로 비기능 요구사항에 해당하므로 정답이다.

X입력한 문서의 음절, 단어, 문장, 줄, 문단, 문장당 단어의 수를 분석하여 표 형태로 보여 줄 수 있어야 한다.

이는 시스템이 제공해야 할 분석·표시 동작을 기술한 기능적 요구사항이므로.

X예약 시스템은 특정일에 예약한 고객의 리스트를 출력한다.

이는 시스템이 수행하는 출력 동작을 기술한 기능적 요구사항이므로.

O완전성 － 사용자 요구사항이 빠짐없이 완전히 반영되었는가?

완전성은 모든 요구사항이 빠짐없이 반영되었는지를 검증하는 항목이므로 옳다.

O일관성 － 요구사항 간의 모순이나 충돌이 존재하는가?

일관성은 요구사항 간 모순·충돌이 '없는지'를 검증하는 항목이다. 모순이 '존재하는가'로 기술한 것은 일관성의 정의에 부합하지 않아 옳지 않다.

X추적성 － 개발 결과와 요구사항 일치를 검증할 수 있는가?

추적성은 요구사항과 개발 결과 간의 연관·일치를 추적·검증할 수 있는지를 보는 항목이므로 옳다.

O명확성 － 서술된 명세서의 내용이 모호하지 않고 간결하고 명쾌한가?

명확성은 명세 내용이 모호하지 않고 명확한지를 검증하는 항목이므로 옳다.

O서로 모순되는 부분이 없어야 한다.

요구분석 명세서는 무모순성(consistency)을 갖추어야 하므로 서로 모순되는 부분이 없어야 한다. 바람직한 특성이 맞다.

O고객과 개발자가 동의한 것이어야 한다.

요구분석 명세서는 고객과 개발자가 합의(동의)한 내용이어야 하며 이는 검증 가능성의 기반이 된다. 바람직한 특성이 맞다.

O고객과 개발자 모두 쉽게 이해할 수 있어야 한다.

요구분석 명세서는 이해성(understandability)을 갖추어 고객과 개발자 모두 쉽게 이해할 수 있어야 한다. 바람직한 특성이 맞다.

X시스템의 구조와 서브 시스템의 구조를 포함하여 기술해야 한다.

요구분석 명세서는 '무엇(what)'을 기술하는 것이며 시스템·서브시스템의 구조 같은 '어떻게(how)'에 해당하는 설계 정보를 포함하지 않는다. 바람직한 특성이 아니다.

O개요는 유스케이스가 제공하는 기능을 나타낸 것으로, 그 기능을 사용하는 사용자 액터까지 표현해야 한다.

유스케이스 명세의 개요는 제공 기능과 그 기능을 사용하는 액터를 함께 기술하므로 옳은 설명이다.

O이벤트 흐름(시나리오)은 유스케이스 기능에 대한 액터와 시스템 간의 대화로, 문자나 순차 다이어그램을 사용해 표현한다.

이벤트 흐름(시나리오)은 액터와 시스템 간 상호작용을 텍스트나 시퀀스(순차) 다이어그램으로 기술하므로 옳다.

X기능 요구사항은 성능, 신뢰성, 보안성, 가용성 등 여러 요구 품질 요소를 나타낸다.

성능·신뢰성·보안성·가용성 등 품질 요소는 비기능 요구사항이다. 기능 요구사항은 시스템이 수행해야 할 동작/기능을 의미하므로 설명이 틀렸다.

O후행 조건은 유스케이스의 수행 완료 후에 만족되어야 하는 조건으로 상태나 수치의 바뀐 모습을 명확하고 구체적으로 기술해야 한다.

후행 조건(postcondition)은 유스케이스 종료 후 보장되어야 할 시스템 상태를 명확히 기술하는 것으로 옳은 설명이다.

O사용자의 요구 사항을 구체적으로 파악하기 위해 소프트웨어의 일부 기능을 빠르게 구현한 프로토타입을 이용한다.

프로토타이핑은 일부 기능을 빠르게 구현해 사용자 요구를 구체화·검증하는 대표적 요구사항 수집 기법으로 옳다.

O소프트웨어 사용 관련자들이 브레인스토밍을 통해 다양한 요구 사항을 도출한다.

브레인스토밍은 이해관계자가 모여 다양한 요구사항을 발굴하는 유효한 요구사항 도출 기법이므로 옳다.

O현재 시스템의 문제를 파악하기 위해 관련 직원으로부터 시스템의 문제점을 파악하고 자료를 수집한다.

현행 시스템 사용자/직원 인터뷰 및 자료 수집은 문제점 파악을 위한 정당한 요구사항 수집 활동으로 옳다.

X수집한 요구 사항은 프로그래밍 언어를 이용해서 구체적으로 기술한다.

요구사항은 자연어, 명세 언어, 모델(UML) 등으로 기술하며 프로그래밍 언어로 기술하지 않는다. 프로그래밍 언어는 구현 단계의 산출물이므로 틀렸다.