정보
-
업무명 : 정보처리기사 실기 : 2강 요구사항 확인 (요구사항 확인하기)
-
작성자 : 이상호
-
작성일 : 2020-05-09
-
설 명 :
-
수정이력 :
내용
[요구사항 정의]
[1] 요구공학
-
요구공학정의
-
요구공학(Requirements Engineering)이란 요구사항을 정의하고, 문서화하고, 관리하는 프로세스를 의미한다.
-
1. 요구사항 개발 프로세스
-
소프트웨어공학 지식체계(SWEBOK: SoftWare Engineering Body of Knowledge)에서는 이 프로세스를 요구사항 도출(Elicitation), 분석(Analsysis), 명세(Specification), 확인(Validation)으로 구분하고 있다(http://www.computer.org/web/swebok).
-
-
-
(1) 요구사항 도출(Requirement Elicitation)
-
(가) 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다
-
(나) 이 단계에서 이해관계자(Stakeholder)가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다.
-
(다) 이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다.
-
-
(2) 요구사항 분석(Requirement Analysis)
-
(가) 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해한다.
-
(나) 시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다.
-
-
(3) 요구사항 명세(Requirement Specification)
-
(가) 요구사항 명세란 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것을 의미한다.
-
(나) 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.
-
-
(4) 요구사항 확인(Requirement Validation)
-
(가) 분석가가 요구사항을 이해했는지 확인(Validation)이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증 (Verification)하는 것이 중요하다.
-
(나) 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리를 해야 하는데, 일반적으로 요구사항 관리툴을 이용한다.
-
(다) 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.
-
[2] 요구사항 분석 기법
-
요구사항 분석을 통해 요구사항을 기술할 때에는 아래의 작업들이 가능하도록 충분하고 정확하게 기술하여야 한다.
-
요구사항의 확인(Validation)
-
요구사항 구현의 검증(Verification)
-
비용 추정
-
분석기법으로 요구사항 분류((Requirement Classification), 개념 모델링(Conceptual Modeling), 요구사항 할당((Requirement Allocation), 요구사항 협상((Requirement Negotiation), 정형 분석(Formal Analysis) 등이 있다.
-
-
1. 요구사항 분류(Requirement Classification)
-
요구사항을 다음과 같은 기준으로 분류한다.
-
요구사항이 기능인지 비기능인지
-
요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나
다른 원천(Source)으로부터 직접 발생한 것인지 -
요구사항이 제품에 관한 것인지 프로세스에 관한 것인지
-
우선순위가 더 높은 것인지 여부
-
요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위)
-
요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부
-
-
-
2. 개념 모델링(Conceptual Modeling)
-
(1) 개념 모델의 역할
-
(가) 실 세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.
-
(나) 따라서 개념 모델은 문제 도메인의 엔터티(entity)들과 그들의 관계 및 종속성을 반영한다.
-
-
(2) 개념 모델의 종류와 표기법
-
(가) 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터액션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한 모델을 작성할 수 있다.
-
(나) 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
-
-
(3) UML 다이어그램의 사용
-
(가) 사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다.
-
(나) 구조 다이어그램(Structure Diagram)은 시스템의 정적 구조(Static Structure)와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보여 준다.
-
(다) 행위 다이어그램(Behavior Diagram)은 시스템 내의 객체들의 동적인 행위(Dynamic Behavior)를 보여 주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해 준다.
-
-
-
3. 요구사항 할당(Requirement Allocation)
-
(1) 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것을 요구사항 할당이 라 한다.
-
(2) 다른 구성 요소와 어떻게 상호 작용하는지 분석을 통하여 추가적인 요구사항을 발견 할 수 있다.
-
-
4. 요구사항 협상(Requirement Negotiation)
-
(1) 두 명의 이해관계자가 서로 상충되는 내용을 요구하거나, 요구사항과 리소스, 기능과 비 기능 요구사항들이 서로 상충되는 경우, 어느 한 쪽을 지지하기보다는 적절한 트레이드 오프 지점에서 합의가 중요하다.
-
(2) 요구사항에 우선순위를 부여하는 것은 중요한 요구사항을 필터링 할 수 있으며, 요구 사항들 간 상충되는 문제를 해결하는 데 사용될 수 있다.
-
-
5. 정형 분석(Formal Analysis)
-
(1) 형식적으로 정의된 시맨틱(Semantics)을 지닌 언어로 요구사항을 표현한다.
-
(2) 정확하고 명확하게 표현하여 오해를 최소화시킬 수 있다.
-
(3) 정형분석(Formal Analysis)은 요구사항 분석의 마지막 단계에서 이루어진다
-
[3] 요구사항확인
-
분석가가 요구사항을 이해했는지 확인(Validation)하는 것이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한 지 검증(Verification)하는 것 이 중요하다.
-
이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리를 해야 하는데 일반적으로 요구사항 관리 툴을 이용한다.
-
리소스가 요구사항에 할당 되기 전에 문제를 파악하기 위하여 검증을 수행한다
-
1. 요구사항 확인 기법
-
(1) 요구사항 검토(Requirement Reviews)
-
(가) 요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 작업을 수행하며, 검토자 그룹을 어떻게 구성하느냐가 중요하다.
-
(나) 예를 들어, 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명 이상 포함되어야 한다.
-
(다) 검토는 시스템 정의서(System Definition Document), 시스템 사양서 (System Specification), 소프트웨어 요구사항 명세서(SRS: Software Requirements Specification Document)를 완성한 시점 등에서 이루어진다
-
-
(2) 프로토타이핑(Prototyping)
-
(가) 프로토타이핑은 새로운 요구사항을 도출하기 위한 수단으로, 또한 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 많이 사용된다.
-
(나) 프로토타이핑의 장점은 분석가의 가정을 파악하고 잘못된 경우 유용한 피드백을 제공한다는 점, 사용자 인터페이스(User Interface)의 동적인 행위가 문서나 그래픽 모델보다 프로토타입으로 이해하기 쉬운 점, 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소하는 점이다.
-
(다) 단점은 사용자의 관심이 핵심 기능에서 멀어지고 프로토타입의 디자인이나 품질 문제로 집중될 수 있으며, 프로토타입 수행 비용이 발생한다는 것이다.
-
(라) 잘못된 요구사항을 만족시키기 위하여 자원을 낭비하는 것을 방지할 수 있다는 점에서 프로토타이핑을 긍정적으로 검토할 수 있다.
-
-
(3) 모델 검증(Model Verification)
-
(가) 분석단계에서 개발된 모델의 품질을 검증할 필요가 있다.
-
(나) 예를 들어, 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로(Communication Path)를 검증(Verify)하기 위하여 정적 분석(Static Analysis)을 수행하는 것이 유용 하다.
-
-
(4) 인수 테스트(Acceptance Tests)
-
(가) 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인이 가능해 야 한다는 것이다
-
(나) 각각의 요구사항을 어떻게 확인 할 것인지에 대한 계획을 세워야 한다.
-
요구사항 검증 단계에서 사용되는 기법 이외에 요구사항 품질 검증을 위한 국내 표준을 활용하여 요구사항을 검증할 수 있다. 정보통신단체표준 TTAK.KO-11.0103 "소프트웨어 요구사항 품질 평가 항목에서는 요구사항 명세의 품질을 객관적이고 정량적으로 평가하 기 위한 기준으로 평가 항목을 제시하고 있다.
-
[요구사항의 시스템화 타당성 분석]
[1] 요구사항의 기술적 타당성 검토
-
“정보화 사업 사전타당성분석 방법론 연구”(한국전산원 2004)에서 “기술적 타당성 분석 에서는 적용기술의 적합성 및 기술실현의 가능성이 분석의 핵심적 내용이 된다.”라고 명시하면서, 성능 및 용량산정의 적정성, 시스템 간 상호 운용성, IT 시장 성숙도 및 트렌드 부합성, 기술적 위험 분석을 언급하고 있다.
-
1. 성능 및 용량산정의 적정성
-
개발 기술 환경 정의 시스템 용량산정 방법에서 목표 시스템의 용량이 산정 되면, 과거 유사 프로젝트 경험치를 적용하여 필요 시 재조정한 후, 성능 관련 비 기능 요구 사항과 비교하여 적정성 여부를 판단한다
-
-
2. 시스템 간 상호 운용성
-
상호 운용성이란 다른 목적을 지닌 2개 이상 시스템들이 상호 간 정보 및 서비스를 교환 하면서 효과적으로 운용될 수 있는 시스템의 능력을 의미한다(한국전산원 2004).
-
요구사항 중에서 목표 시스템이 조직 내외 타 시스템과의 연동을 요구하는 경우, 상호 운용이 가능 한지 여부를 판단해야 한다.
-
-
3. IT 시장 성숙도 및 트렌드 부합성 시스템 구축 시 요구되는 영역별 정보 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합하는지 판단해야 한다. 시장 성숙도가 낮거나, 발전 방향에 부합되지 않는 기술들은 향후 더 이상 사용되지 않을 가능성이 높아 시스템의 유지보수가 어려운 상황이 발생할 수 있다.
-
4. 기술적 위험 분석 요구사항을 만족시키기 위하여 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대하여 위 험 발생 가능성, 영향도를 파악한다.
[연습문제]
-
다음 중 요구사항 도출(Requirement Elicitation)과 무관한 것은?
-
요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다
-
이 단계에서 이해관계자(Stakeholder)가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다.
-
이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다.
-
요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해한다.
-
-
다음 중 요구사항 확인(Requirement Validation)의 단계가 아닌 것은?
-
분석가가 요구사항을 이해했는지 확인(Validation)이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증 (Verification)하는 것이 중요하다.
-
이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리 를 해야 하는데, 일반적으로 요구사항 관리 툴을 이용한다.
-
리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.
-
시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다.
-
참고 문헌
[논문]
- 없음
[보고서]
- 없음
[URL]
- 없음
문의사항
[기상학/프로그래밍 언어]
- sangho.lee.1990@gmail.com
[해양학/천문학/빅데이터]
- saimang0804@gmail.com
본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음
'자기계발 > 자격증' 카테고리의 다른 글
[자격증] 정보처리기사 실기 : 4강 데이터 입출력 구현 (논리 데이터 저장소 확인하기, 물리 데이터 저장소 확인하기) (0) | 2020.05.09 |
---|---|
[자격증] 정보처리기사 실기 : 3강 요구사항 확인 (분석모델 확인하기) (0) | 2020.05.09 |
[자격증] 정보처리기사 실기 : 1강 요구사항 확인 (현행시스템 분석하기) (0) | 2020.05.06 |
[자격증] 정보처리기사 개편 사항 (NCS 반영)에 따른 세부 정보 : 개편 내용, 시험 일정, 출제 기준, 수수료, 취득 방법 (0) | 2020.05.05 |
[자격증] 기상감정기사 필기 : 4과목 기상통계 (시계열 분석) (0) | 2019.12.15 |
최근댓글