[자격증] 정보처리기사 실기 : 2강 요구사항 확인 (요구사항 확인하기)

 정보

• 업무명     : 정보처리기사 실기 : 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

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음