정보처리기사 필기 소프트웨어 설계 - 요구사항 확인(NCS학습모듈) (2)

 

2. 요구사항 확인하기

2-1. 요구사항 정의

• 요구공학(Requirements Engineering) : 요구사항을 정의하고, 문서화하고, 관리하는 프로세스
• 요구사항 개발 프로세스

요구사항 도출 (Requirement Elicitation)	- 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로서 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다. - 이 단계에서 이해관계자(Stakeholder)가 식별되고, 개발 팀과 고객 사이의 관계가 만들어진다. - 이 단계에서는 다양한 이해관계자와 효율적인 의사소통이 중요하다.
요구사항 분석 (Requirement Analysis)	- 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해한다. - 시스템 요구사항을 정제하여 소프트웨어 요구사항을 도출한다.
요구사항 명세 (Requirement Specification)	- 요구사항 명세란 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것을 의미한다. - 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성한다.
요구사항 확인 (Requirement Validation)	- 분석가가 요구사항을 이해했는지 확인(Validation)이 필요하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)하는 것이 중요하다. - 이해관계자들이 문서를 검토해야 하고, 요구사항 정의 문서들에 대해 형상 관리를 해야 하는데, 일반적으로 요구사항 관리 툴을 이용한다. - 리소스가 요구사항에 할당되기 전에 문제를 파악하기 위하여 검증을 수행한다.

• 요구사항 분류(Requirement Classification)

- 요구사항이 기능인지 비기능인지 - 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 또는 이해관계자나 다른 원천(Source)으로부터 직접 발생한 것인지 - 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지 - 우선순위가 더 높은 것인지 여부 - 요구사항의 범위(요구사항이 소프트웨어에 미치는 영향의 범위) - 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부

• 개념 모델링(Conceptual Modeling)

개념 모델의 역할	- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다. - 따라서 개념 모델은 문제 도메인의 엔터티(entity)들과 그들의 관계 및 종속성을 반영한다.
개념 모델의 종류와 표기법	- 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터액션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등과 같은 다양한 모델을 작성할 수 있다. - 대부분의 모델링 표기법은 UML(Unified Modeling Language)을 사용한다.
UML 다이어그램의 사용	- 사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다. - 구조 다이어그램(Structure Diagram)은 시스템의 정적 구조(Static Structure)와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보여 준다. - 행위 다이어그램(Behavior Diagram)은 시스템 내의 객체들의 동적인 행위(Dynamic Behavior)를 보여 주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해 준다.

• 요구사항 확인 기법

요구사항 검토 (Requirement Reviews)	- 요구사항 검증의 가장 일반적인 방법으로, 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 등을 찾아내는 작업을 수행하며, 검토자 그룹을 어떻게 구성하느냐가 중요하다. - 예를 들어, 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자가 1명 이상 포함되어야 한다. - 검토는 시스템 정의서(System Definition Document), 시스템 사양서(System Specification), 소프트웨어 요구사항 명세서(SRS: Software Requirements Specification Document)를 완성한 시점 등에서 이루어진다.
프로토타이핑 (Prototyping)	- 프로토타이핑은 새로운 요구사항을 도출하기 위한 수단으로, 또한 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 많이 사용된다. - 프로토타이핑의 장점은 분석가의 가정을 파악하고 잘못된 경우 유용한 피드백을 제공한다는 점, 사용자 인터페이스(User Interface)의 동적인 행위가 문서나 그래픽 모델보다 프로토타입으로 이해하기 쉬운 점, 요구사항의 가변성이 프로토타이핑 이후에 급격히 감소하는 점이다. - 단점은 사용자의 관심이 핵심 기능에서 멀어지고 프로토타입의 디자인이나 품질 문제로 집중될 수 있으며, 프로토타입 수행 비용이 발생한다는 것이다. - 잘못된 요구사항을 만족시키기 위하여 자원을 낭비하는 것을 방지할 수 있다는 점에서 프로토타이핑을 긍정적으로 검토할 수 있다.
모델 검증 (Model Verification)	- 분석단계에서 개발된 모델의 품질을 검증할 필요가 있다. - 예를 들어, 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로(Communication Path)를 검증(Verify)하기 위하여 정적 분석(Static Analysis)을 수행하는 것이 유용하다.
인수 테스트 (Acceptance Tests)	- 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인이 가능해야 한다는 것이다. - 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 세워야 한다.

 

2-2. 요구사항의 시스템화 타당성 분석

• 요구사항의 기술적 타당성 검토

성능 및 용량산정의 적정성	개발 기술 환경 정의의 시스템 용량산정 방법에서 목표 시스템의 용량이 산정되면, 과거 유사 프로젝트 경험치를 적용하여 필요시 재조정한 후, 성능 관련 비기능 요구사항과 비교하여 적정성 여부를 판단한다.
시스템 간 상호 운용성	상호 운용성이란 다른 목적을 지닌 2개 이상 시스템들이 상호 간 정보 및 서비스를 교환하면서 효과적으로 운용될 수 있는 시스템의 능력을 의미한다. 요구사항 중에서 목표 시스템이 조직 내외 타 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단해야 한다.
IT 시장 성숙도 및 트렌드 부합성	시스템 구축 시 요구되는 영역별 정보 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합하는지 판단해야 한다. 시장 성숙도가 낮거나, 발전 방향에 부합되지 않는 기술들은 향후 더 이상 사용되지 않을 가능성이 높아 시스템의 유지보수가 어려운 상황이 발생할 수 있다.
기술적 위험 분석	요구사항을 만족시키기 위하여 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대하여 위험 발생 가능성, 영향도를 파악한다.  - 복잡성: 기술의 안정성, 시장성, 개방성을 저해하는 모든 요소 / 하드웨어, 소프트웨어, 솔루션의 적용이 아키텍처와 불일치  - 검증 여부: 적용 기술에 대한 조직 내 무경험 / 외부 지원 불가능  - 의존성: 특허 및 라이선스에 따른 문제 / 특정 업체 기술에 대한 의존

---

※ 자료 출처 : 국가직무능력표준 ☞ ncs.go.kr