1과목. 소프트웨어 설계 > 1장. 요구사항 확인 > 요구사항 : 요구사항 개발 순서, 요구사항 검증 방법, 요구사항 관리 도구, 요구사항 도출 기법, 요구사항 명세 기법 , 요구사항 명세서 작성 기법, 요구사항 분류 , 요구사항 분석 기법
- 요구사항의 정의
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건
- 요구사항의 특징
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공
- 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들(소프트웨어 개발자 의뢰자, 개발자, 사용자 등) 간의 의사소통을 원활하게 하는데 도움을 줌
- 요구사항이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있음
- 요구사항의 분류
- 기술하는 내용에 따른 분류
- 기능 요구사항
- 기능 요구사항의 개념
- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
- 기능 요구사항의 종류
- 시스템이 반드시 수행해야 하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능
- 기능 요구사항의 개념
- 비기능 요구사항
- 비기능 요구사항의 개념
- 시스템 장비 구성 요구사항 : 하드웨어, 소프트웨어, 네트워크 등의 시스템 장비 구성에 대한 요구사항
- 성능 요구사항 : 처리 속도 및 시간, 처리량, 동적정적 적용량, 가용성 등 성능에 대한 요구사항
- 비기능 요구사항의 분류
- 제품 요구사항 : 사용성, 신뢰성, 이식성, 효율성(성능-응답속도, 처리량/공간-자원 사용량)
- 조직 요구사항 : 소프트웨어 배포, 구현, 표준
- 외부 요구사항 : 상호 운용성, 윤리성, 프라이버시 보호성, 안전성
- 비기능 요구사항의 종류
- 인터페이스 요구사항 : 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항, 다른 소프트웨어/하드웨어 및 통신 인터페이스 / 다른 시스템과의 정보 교환에 사용되는 프로토콜과의 연계도 포함하여 기술
- 데이터 요구사항 : 초기 자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축하기 위해 필요한 요구사항
- 테스트 요구사항 : 도입되는 장비의 성능 테스트(BMT)나 구축된 시스템이 제대로 운영되는지를 테스트하고 점검하기 위한 테스트 요구사항
- 보안 요구사항 : 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
- 품질 요구사항 : 관리가 필요한 품질 항목, 품질 평가 대상에 대한 요구사항
- 가용성 : 사용하고자 할 때 언제라도 사용할 수 있는 정도
- 정합성 : 데이터와 같이 서로 모순 없이 일관되게 일치하는 정도
- 상호 호환성 : 다른 소프트웨어와 정보를 교환할 수 있는 정도
- 대응성 : 발생한 상황에 대처하는 정도
- 이식성 : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
- 확장성 : 규모나 범위를 넓힐 수 있는 정도
- 제약사항 : 시스템 설계, 구축, 운영과 관련하여 사전에 파악된 기술, 표준, 업무, 법, 제도 등의 제약 조건
- 프로젝트 관리 요구사항 : 프로젝트의 원활한 수행을 위한 관리 방법에 대한 요구
- 프로젝트 지원 요구사항 : 프로젝트의 원활한 수행을 위한 지원 사항이나 방안에 대한 요구사항
- 비기능 요구사항의 개념
- 기능 요구사항
- 기술 관점과 대상의 범위에 따른 분류
- 사용자 요구사항
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 사용자를 위한 것
- 친숙한 표현으로 이해하기 쉽게 작성
- 시스템 요구사항
- 소프트웨어 요구사항
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현
- 사용자 요구사항
- 기술하는 내용에 따른 분류
- 요구사항 개발 순서 (요구사항 개발 프로세스)
- 도출(Elicitation)
- 요구사항 도출의 개념
- 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
- 요구사항 도출의 특징
- 요구사항 도출 단계에서 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별
- 다양한 이해관계자 간의 효율적인 의사소통이 중요
- 소프트웨어 개발 생명주기(SDLC) 동안 지속적으로 반복
- 요구사항 도출 기법 : 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등
- 브레인스토밍(Brain Storming) : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 산출해 내는 방법, 여러명으로부터 정보를 얻는 효과적 방법
- 프로토타이핑((Prototyping) : 프로토타입을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출, 가장 단순한 프로토타이핑 방법 - 종이에 대략적인 순서나 형태를 그려 보여주는 것
- 유스케이스(Use Case) : 사용자의 요구사항을 기능 단위로 표현한 것
- 문헌조사 : 유사 프로젝트의 업무 문서, 양식을 통해 현재 시스템 정보에 대한 이해 도출
- 업무 절차 및 양식 조사 : 기업의 내부 표준 검토를 통해 요구와 제한사항을 찾아 시스템 요구분석서의 제한 사항으로 적용
- 설문, 인터뷰 : 이해 당사자들로부터 요구를 찾는 도구, 의사결정 과정에 포함
- JAD : 사용자와 개발자가 공동참여하여 프로토타입 기반의 작업을 수행함으로써 비즈니스 요구사항을 명확히 도출하고 그에 따라 시스템을 설계 및 개발
- 사용자 스토리 : 애자일 방법에서 요구취합을 위하여 많이 사용하는 방법, 사용자가 개발팀과 함께 만들고 시스템에 바라는 역량을 간단히 기술한 문서
- 요구사항 도출의 개념
- 분석(Analysis)
- 요구사항 분석의 개념
- 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 개발의 실제적인 첫 단계, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동
- 요구사항 분석의 특징
- 사용자 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정
- 요구사항의 목표를 정하고 해결 방법 모색
- 도출된 요구사항을 토대로 소프트웨어의 범위를 파악
- 도출된 요구사항들을 토대로 소프트웨어와 주변 환경이 상호작용하는 방법을 이해
- 분석을 통한 결과는 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화함 : 소프트웨어 설계 단계의 기본 자료가 됨
- 요구사항 분석 시 고려사항
- 사용자 요구를 정확하게 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정
- 사용자 요구사항을 정확하고 일관성 있게 분석하여 문서화
- 소프트웨어 분석가에 의해 요구사항 분석 수행
- 요구사항 분석 수행 절차
- 문제 인식 : 사용자 면담, 설문조사 및 협조, 각종 문서 검토 등을 통해 요구사항 수집
- 평가와 종합 : 추출된 요구사항에 대한 정보 평가, 여러 가지 해결책 종합
- 모델 제작 : 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성
- 문서화와 검토 : 소프트웨어의 기능, 성능, 제약 조건 등에 대하여 명세화, 검토
- 요구사항 분석 기법 : 구조적 분석 기법(자료 흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명세서), 애자일 방법, UML 등
- 구조적 분석 기법
- 구조적 분석 기법의 개념
- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
- 구조적 분석 기법의 특징
- 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화
- 하향식 방법을 사용 : 시스템 세분화, 분석의 중복 배제
- 시스템 분석의 질 향상, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능
- 구조적 분석 기법의 종류
- 자료 흐름도(DFD)
- 자료 흐름도의 개념
- 자료 흐름 그래프, 버블 차트
- 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프
- 자료 흐름도의 특징
- 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용
- 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술
- 자료 흐름도의 작성지침
- 자료 흐름은 처리(Process)를 거쳐 변환될 때마다 새로운 이름 부여
- 어떤 처리가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생되어야 함
- 상위 단계의 처리와 하위 자료의 흐름도의 자료 흐름은 서로 일치되어야 함
- 입력 화살표가 있다고 하여 반드시 출력 화살표가 있어야 하는 것은 아님
- 자료 흐름도의 구성 및 표시방법
기호 표기법 처리,
프로세스
(Process)입력된 자료를 출력으로 변환하는 것 
자료 흐름
(Data Flow)발생지, 종착지, 처리 및 저장소 사이에서 자료의 흐름을 나타냄 
자료 저장소
(Data Store)시스템 상의 자료의 저장소를 나타냄 . 
단말
(Terminator)시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지 또는 외부에 존재하는 사람이나 조직을 나타냄 
- 자료 흐름도의 개념
- 자료 사전(DD)
- 자료 사전의 개념
- 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
- 자료 사전의 특징
- 데이터를 설명하는 데이터, 즉 메타 데이터
- 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용할 수 있음
- 자료 사전 작성 시 고려사항
- 갱신 용이성
- 이름으로 검색 용이
- 정의의 명확성
- 자료 사전의 표기 기호
- = : 자료의 정의, ~로 구성되어 있다(is composed of)
- + : 자료의 연결, 그리고(and)
- ( ) : 자료의 생략, 생략 가능한 자료(Optional)
- [ | ] : 자료의 선택, 또는(or)
- { } : 자료의 반복, Iteration of
- { }ₙ : n번 이상 반복
- { }ⁿ : 최대로 n번 반복
- { }ⁿₘ : m이상 n 이하로 반복
- * * : 자료의 설명, 주석(Comment)
- 자료 사전의 개념
- 소단위 명세서(Module Specification)
- 각 모듈의 기능, 입력, 출력, 제어 흐름 등을 명확히 정의
- 모듈 간의 관계를 명확히 파악하고 모듈 구현에 도움을 줌
- 개체 관계도(ERD)
- 시스템에서 사용되는 개체와 그들 간의 관계를 시각적으로 표현
- 데이터베이스 설계, 시스템 모델링에 활용
- 상태 전이도(STD)
- 시스템의 상태와 상태 전이 규칙을 시각적으로 표현
- 시스템의 동작 상태 파악, 시스템의 동작 흐름 분석에 활용
- 제어 명세서(Control Specification)
- 시스템의 제어 흐름을 명확히 정의
- 특정 이벤트 발생 시 어떤 프로세스가 실행되는지, 어떤 조건에 따라 어떤 동작을 하는지 등을 기술
- 시스템의 제어 논리 파악, 제어 흐름을 설계하는데 도움
- 자료 흐름도(DFD)
- 구조적 분석 기법의 개념
- 애자일 방법론(Agile Model) : 고객과의 소통에 초점을 맞춘 방법론을 통칭
- UML : 시스템 개발 과정에서 개발자와 고객, 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
- 구조적 분석 기법
- 요구사항 분석의 개념
- 명세(Specification)
- 요구사항 명세의 개념
- 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미
- 요구사항을 문서화할 때 규정
- 기능 요구사항은 빠짐 없이 완전하고 명확하게 기술, 비기능 요구사항은 필요한 것만 명확하게 기술해야 함
- 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성되어야 함
- 설계 과정에서 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 함
- 요구사항 명세 기법
- 정형 명세 기법
- 기법 : 수학적 기반, 모델링 기반
- 종류 : Z, VDM, Petri-Net (모형 기반), CSP, CCS, LOTOS (대수적 방법)
- 장점 : 시스템 요구 특성 명확, 명세 간결, 명세/구현의 일치성
- 단점 : 낮은 이해도, 이해 관계자의 부담 가중
- 비정형 명세 기법
- 기법 : 상태, 기능, 객체 중심 명세 기법
- 종류 : FSM (Finite state machine), Decision Table, ER 모델링, State Chart (SADT), UseCase-사용자 기반 모델링
- 장점 : 명세작성 이해 용이, 의사전달 방법 다양성
- 단점 : 불충분한 명세 기능, 모호성
- 정형 명세 기법
- 요구사항 명세서
- 소단위 명세서(Mini-Spec)
- 소프트웨어 요구사항 명세서(SRS)
- 업계 표준 용어로 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약 조건 명시
- 시스템의 모든 동작 뿐만 아니라 성능, 보안, 사용성과 같은 품질도 기술되어야 함
- 프로젝트 유형에 맞게 양식을 만들어 사용
- 소프트웨어 요구사항 명세서에 포함되는 시스템 기능, 데이터, 외부 인터페이스, 품질 요구사항은 요구사항 단위별로 개별 요구사항 명세서를 작성
- 요구사항 명세의 개념
- 확인(Validation)
- 요구사항 확인의 개념
- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
- 요구사항 확인의 특징
- 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인하는 것이 필요
- 요구사항이 실제 요구를 반영하는지, 서로 상충되는 요구사항은 없는지 등을 점검
- 개발이 완료된 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 요구사항 검증은 매우 중요
- 요구사항 명세서의 내용이 이해하기 쉬운지, 일관성은 있는지, 회사의 기준에는 맞는지, 누락된 기능은 없는지 등을 검증하는 것이 중요
- 요구사항 문서는 이해관계자들이 검토해야 함
- 요구사항 검증 과정을 통해 모든 문제를 확인할 수 있는 것은 아님
- 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서에 대한 형상 관리를 수행
- 요구사항 확인의 개념
- 도출(Elicitation)
- 요구사항 검증 방법(Verification)
- 요구사항 검증의 개념
- 인터페이스의 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지 검토하고 개발 범위의 기준인 베이스라인을 설정하는 것
- 요구사항 검증의 역할
- 인터페이스 설계 및 구현 중 요구사항 명세서의 오류가 발견되어 수정될 경우 많은 비용 소모 -> 이를 방지하기 위해 요구사항 검증은 반드시 필요
- 요구사항 검증의 순서
- 요구사항 검토 계획 수립
- 검토 기준 및 방법 : 프로젝트 규모, 참여 인력, 검토 기간 등 고려하여 검토 기준 및 방법 선정
- 참여자 : 프로젝트 규모에 따라 이해 관계자를 파악하여 요구사항 검토 참여자 선정
- 체크리스트 : 요구사항 검토 체크리스트 작성
- 관련 자료 : 인터페이스 요구사항 목록, 인터페이스 요구사항 명세서, 현행 및 표준 시스템 구성도 등
- 일정
- 검토 및 오류 수정
- 검토 체크리스트의 항목에 따라 인터페이스 요구사항 명세서 검토
- 요구사항 검토 시 오류가 발견되면 오류를 수정할 수 있도록 오류 목록과 시정 조치서 작성
- 오류 수정과 요구사항 승인 절차를 진행할 수 있도록 요구사항 검토 결과를 검토 관련자들에게 전달
- 시정 조치가 완료되면 인터페이스 요구사항 검토 작업을 완료
- 베이스라인 설정
- 소프트웨어 설계 및 구현을 위해 요구사항 명세서의 베이스 라인 설정
- 요구사항 검토 계획 수립
- 요구사항 검증 방법의 종류
- 요구사항 검토(Requirements Review)
- 요구사항 명세서의 오류 확인 및 표준 준수 여부의 결함 여부를 검토 담당자들이 수 작업으로 분석하는 방법
- 요구사항 검토 방법의 종류
- 동료검토(Peer Review) : 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 형태의 검토 방법
- 워크스루(Walk Through) : 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토 한 후, 짧은 검토 회의를 통해 결함을 발견하는 형태의 검토 방법, 동료 개발자와 함께 검토 함
- 인스펙션(Inspection) : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 형태의 검토 방법
- 프로토타이핑(Prototyping) : 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측
- 테스트 설계 : 요구사항은 테스트 할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토
- CASE 도구 활용 : 일관성 분석을 위해 요구사항 변경 사항의 추적 및 분석, 관리, 표준 준수 여부 확인
- 요구사항 검토(Requirements Review)
- 요구사항 검증의 주요 항목
- 안전성(Completeness) : 사용자의 모든 요구사항이 누락되지 않고 완전하게 반영되어 있는지
- 일관성(Consistency) : 요구사항이 모순되거나 충돌 되는 점 없이 일관성을 유지하고 있는지
- 명확성(Unambiguity) : 모든 참여자가 요구사항을 명확히 이해할 수 있는지
- 기능성(Unambiguity) : 요구사항이 어떻게 보다 무엇을에 중점을 두고 있는지
- 검증 가능성(Functionality) : 요구사항이 사용자의 요구를 모두 만족하고 개발된 소프트웨어가 사용자의 요구내용과 일치하는지를 검증할 수 있는지
- 추적 가능성(Traceability) : 요구사항 명세서와 설계서를 추적할 수 있는지
- 변경 용이성(Easily Changeable) : 요구사항 명세서의 변경이 쉽도록 작성되었는지
- 요구사항 검증의 개념
- 요구사항 관리 도구
- 요구사항 관리 도구의 필요성
- 프로젝트 생성
- 프로젝트 타입 및 기본 모듈 템플릿, 속성, 역할별 뷰 설정
- 프로젝트 생성을 도와주며 이를 저장하여 재사용
- 요구사항 작성
- 모든 요구사항에 고유의 ID가 생성, 부여
- ID는 사용자에 의한 임의 변경이 될 수 없도록 관리 기능 지원
- 요구사항 Import/Export
- 요구사항의 일괄 등록 및 추출
- 다양한 형식의 파일 Import와 Export 기능 제공
- 요구사항 이력관리
- 요구사항 별로 히스토리 관리
- 요구사항 베이스라인
- 요구사항이 확정되고 관리의 시작점이 되는 요구사항 베이스라인 관리
- 요구사항 변경에 따른 영향 평가
- 요구사항이 확정되고 관리의 시작점이 되는 요구사항 베이스라인 관리
- 요구사항 추적
- 어느 요구사항이 베이스인지를 구분하기 위한 기능
- 현재 요구사항을 기반으로 작성된 요구사항인지, 타 요구사항을 기반으로 하여 현재 요구사항이 작성되었는지를 추적하는 기능 제공
- 협업 환경
- 하나의 요구사항 문서를 여러 명이 작성할 수 있도록 협업 기능
- 공유 모드를 제공하고 선점 사용자 외엔 수정 및 삭제 권한 제한
- 외부 연동 환경
- 요구사항대로 설계되었는지를 파악하기 위해 설계 도구와 연동
- 요구사항대로 구현되었는지를 확인하기 위해 형상 관리 도구와 연동
- 프로젝트 생성
- 요구사항 관리 도구의 선택시 고려사항 : 다양한 방법론, 추적성, 협업, 가져오기/내보내기 기능, 버전 제어, 요구사항 기준선(베이스라인) 설정, 보안
- 요구사항 관리 도구의 필요성
800제-7번. 자료 사전에서 자료의 생략을 의미하는 기호는?
① { }
② **
③ =
④ ( )
정답 : 4
800제-15번. 데이터 흐름도(DFD)의 구성 요소에 포함되지 않는 것은?
① process
② data flow
③ data store
④ data dictionary
정답 : 4
800제-18번. 소프트웨어 개발 방법 중 요구사항 분석(requirements analysis)과 거리가 먼 것은?
① 비용과 일정에 대한 제약설정
② 타당성 조사
③ 요구사항 정의 문서화
④ 설계 명세서 작성
정답 : 4
800제-120번.인터페이스 요구사항 검토 방법에 대한 설명이 옳은 것은?
① 리팩토링 : 작성자 이외의 전문 검토 그룹이 요구사항 명세서를 상세히 조사하여 결합, 표준 위배, 문제점 등을 파악
② 동료검토 : 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
③ 인스펙션 : 자동화된 요구사항 관리 도구를 이용하여 요구사항 추적성과 일관성을 검토
④ CASE 도구 : 검토 자료를 회의 전에 배포해서 사전 검토 한 후 짧은 시간 동안 검토 회의를 진행하면서 결함을 발견
정답 : 2
800제-202번. 요구 사항 명세기법에 대한 설명으로 틀린 것은?
① 비정형 명세기법은 사용자의 요구를 표현할 때 자연어를 기반으로 서술한다.
② 비정형 명세기법은 사용자의 요구를 표현할 때 Z 비정형 명세기법을 사용한다.
③ 정형 명세기법은 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용한다.
④ 정형 명세기법은 비정형 명세기법에 비해 표현이 간결하다.
정답 :2
800제-213번. 다음 중 자료 사전(Data Dictionary)에서 선택의 의미를 나타내는 것은?
① [ ]
② ( )
③ +
④ *
정답 : 1
800제-215번. DFD(Data Flow Diagram)에 대한 설명으로 틀린 것은?
① 자료 흐름 그래프 또는 버블(bubble) 차트라고도 한다.
② 구조적 분석 기법에 이용된다.
③ 시간 흐름을 명확하게 표현할 수 있다.
④ DFD의 요소는 화살표, 원, 사각형, 직선(단선/이중선)으로 표시한다.
정답 : 3
800제-417번. 요구사항 관리 도구의 필요성으로 틀린 것은?
① 요구사항 변경으로 인한 비용 편익 분석
② 기존 시스템과 신규 시스템의 성능 비교
③ 요구사항 변경의 추적
④ 요구사항 변경에 따른 영향 평가
정답 : 2
800제-604번. 요구사항 명세(requirements specification)에 대한 설명 중 옳지 않은 것은?
① 비정형적 명세는 명세 작성 및 이해가 용이하며 전달 방법이 다양하다.
② 비정형적 명세기법이 전형적인 예로 Z 명세 기법을 들 수 있다.
③ 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 활동이다.
④ 정형적 명세는 정확하고 모호하지 않으며 의문의 여지가 없어야 한다.
정답 : 2
800제-611번. 비기능 요구사항에 대한 설명으로 옳지 않은 것은?
① 다른 소프트웨어와 하드웨어 시스템과의 상호 운영성, 안정성 규칙과 프라이버시 보호법 같은 사용자의 필요에 의해 발생한다.
② 소프트웨어의 배포, 구현 방법론, 표준에 관한 조직 요구사항이 포함된다.
③ 시스템에서 제공되는 서비스나 기능에 대한 제약이다.
④ 시스템이 제공해야 하는 서비스와 시스템이 특정 입력에 어떻게 반응하는지, 시스템이 특정 상황에서 어떻게 동작해야 하는지에 관한 사항이다.
정답 : 4
800제-706번. 올바른 요구사항 명세서를 작성하기 위한 주의 사항으로 가장 옳지 않은 것은?
① 요구사항 명세서는 소프트웨어 개발의 전 과정을 주도하므로, 개발자 중심으로 이해하기 쉽게 작성되어야 한다.
② 요구사항 명세서는 원하는 기능을 정확하고 완벽하게 기술해야 한다.
③ 요구사항 명세서는 2가지 이상의 해석이 발생하지 않도록 모호하지 않은 표현을 써야 한다.
④ 요구사항 명세서는 시스템 인수를 위한 테스트 기준을 제시해야 한다.
정답 : 1
1000제-14번.
①
②
③
④
정답 :
1000제-25번.
①
②
③
④
정답 :
1000제-30번.
①
②
③
④
정답 :
1000제-37번.
①
②
③
④
정답 :
1000제-39번.
①
②
③
④
정답 :
1000제-40번.
①
②
③
④
정답 :
1000제-65번.
①
②
③
④
정답 :
1000제-121번.
①
②
③
④
정답 :
1000제-144번.
①
②
③
④
정답 :
1000제-148번.
①
②
③
④
정답 :
1000제-804번.
①
②
③
④
정답 :
1000제-805번.
①
②
③
④
정답 :
1000제-913번.
①
②
③
④
정답 :
'보관함 > 정보처리기사_25년 02차' 카테고리의 다른 글
| [오답정리] 모듈 간 공통 기능 및 데이터 인터페이스 (1) | 2025.05.06 |
|---|---|
| [오답정리] 시스템 인터페이스(System Interface) (0) | 2025.05.04 |
| [오답정리] 디자인 패턴(Design Pattern) (0) | 2025.04.29 |
| [오답정리] UML(Unified Modeling Language) (0) | 2025.04.29 |
| [오답정리] HIPO(시스템 분석 도구) (0) | 2025.04.28 |