(정보처리기사 실기 정리) 1-02. 요구사항 확인

1. 요구사항 정의

• 요구공학이란 ?
  - 시스템의 개발, 변경의 목적을 식별하기 위해 이해관계자들의 요구를 이해 및 조정한 후 
  체계적으로 수집, 분석, 명세화, 확인하는 공정 또는 이에 관한 학문
  
  - 프로젝트의 과제 범위 산정, 프로젝트 종료 시 감사 수행에 있어서 감사 범위의 기준이 됨.
• 요구사항 개발 프로세스
  IEEE에서 SW 분야의 지식을 정리한 체계인 SWEBOK에 정의되어 있는 요구사항 프로세스를 기반
  도출, 분석, 명세, 확인의 과정을 거치는 요구사항 확인 과정
  
  도출  -> 분석 -> 명세 -> 확인
  
  요구사항 도출
  : SW가 어떤 문제를 해결해야 할지 이해하는 첫 번째 단계
    요구사항 정보 수집을 위한 활동 등을 총칭
  
  요구사항 분석
  : 요구사항들 간 상충되는 것들을 해결
    SW의 범위 및 환경과의 상호작용 이해
  
  요구사항 명세
  : 체계적으로 검토, 평가, 승인 될 수 있는 문서 작성
     시스템 정의, 요구사항, 소프트웨어 요구사항 작성
  
  요구사항 확인
  : 분석가가 요구사항을 제대로 이해했는지 확인
    요구사항 문서가 표준에 적합하고 이해 가능한지 확인
    일관성과 완전성이 충족되는지 검증
  
  요구사항 도출 필요성
  - 범위 기준선 제공 / 일정, 원가 영향 / 추적성 제공 

2. 요구사항 도출 기법

• 요구사항 도출 기법
  : 핵심그룹 / 심층워크숍 / 인터뷰 / 집단창의력기법 / 설문지 및 설문조사 / 사용자업무관찰기법 / 프로토타입 / 집단의사결정기법
• 요구사항 분류에 따른 추출 방법
  기능적 : 기능 / 자료 / 인터페이스 / 사용자
  비기능적 : 자원 / 성능 / 보안 / 품질
• 요구사항 분석 필요성
  : Snowball Effect 현상 방지, Gold plate 방지 등 명확한 요구사항을 통해 프로젝트 과제의 범위를 명확화 하기 위함

3. 요구사항 분석 기법

• 요구사항 분석을 통해 요구사항을 기술할 때는 요구사항의 확인, 요구사항 구현의 검증, 비용 추정 등을 확실히 해야함
  분석 기법
  : 요구사항 분류 / 개념 모델링 / 요구사항 할당 / 요구사항 협상 / 정형 분석

요구사항 분류	기능, 비기능, 요구사항 범위, SDLC 등 여러가지 기준을 가지고 분류
개념 모델링	실세계 문제에 대한 모델링이 SW 요구사항 분석의 핵심
요구사항 할당	요구사항을 만족시키기 위한 아키텍처 구성 요소 식별
요구사항 협상	복수의 이해관계자가 서로 상충되는 내용을 요구거나, 요구사항과 리소스, 기능과 비기능 요구사항들이 서로 상충될 경우 진행되는 협의
정형 분석	정확하고 명확하게 표현

• UML (Unified Modeling Language)
  시각적 모델을 만들기 위해 도안 표기법을 사용하고, 객체 관리를 위한 표준화 된 범용 모델링 언어
  
  UML 특징
  - 가시화 언어
  : 개념 모델 작성 / 오류 없이 전달 / 의사소통 용이 / Graphic 언어
  - 명세화 언어
  : 정확한 모델 제시 / 완전한 모델 작성 / 분석, 설계의 결정 표현
  - 구축 언어
  : 다양한 프로그램 언어와 연결 / 왕복 공학 가능 (순,역공학) / 실행 시스템 예측 가능
  - 문서화 언어
  : 시스템에 대한 통제, 평가, 의사소통의 문서
  
  UML 4+1 View Model
  - 고객 요구사항을 중심으로 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture을 구축하는 설계 방법
  - 다양항 이해관계자들이 SW Architecture을 바라보는 Architecture View의 관점 간 관계를 정의한 사실상의 표준
  - 기존 단순 View Model의 한계를 극복하고, 기능/비기능적 요구사항을 동시에 만족
  
  Use-case View
  : 사용자 관점, 요구사항 분석을 통한 시스템 기능 명세
  Logical View
  : 설계자 관점, 전체 레이어 구성
  Implementation View
  : 개발자 관점, 컴포넌트와 이들 간의 상호관계 정의
  Process View
  : 시스템 통합 관점, 비기능적 요구사항 기술
  Deployment View
  : 시스템 엔지니어 관점, 물리적 노트 프로세스 분산 및 배치
• SRS
  요구분석 단계의 요구사항과 스펙을 정리한 산출물, SW 요구사항 명세 문서
  개발 목적, 다양한 계층 사용, 여러 개발 산물 문서의 출발점
  
  SRS 목차 
  : 개요 / 전체 설명 / 환경 / 외부 인터페이스 요구사항 / 성능 요구사항 / 비기능 요구사항 / 기능 요구사항
• 요구사항 명세
  시스템의 목표를 기술하고, 사용자가 기대하는 기능 요구사항 및 품질 특성을 작성하는 단계
  
  평가 기준 
  : 정확성 / 명확성 / 완전성 / 일관성 / 중요성 / 검토가능 / 수정가능 / 추적가능 
  
  명세서 작성 시 유의사항
  : 이해성  / 상호성 / 기능 정의 / 제약 조건 / 테스트 기준 / 품질 측정
• 요구사항 확인(검증)
  개발 단계에서 요구 변경을 최소화 하고, 최초 정의된 요구사항에 맞게 구현되었는지 확인하는 단계
  
  확인 기법 
  : 요구사항 검토 / 프로토타이핑 / 모델 검증 / 인수 테스트 
• 프로젝트 수행 시 요구사항 보장을 위한 방안
  상세 요구사항 -> 요구분석 -> 분할 발주 -> 보증 활동 -> 감리 시행 -> 요구 사항 보장
  
  품질보증활동에서 요구 검증
  프로세스 : 품질보증계획, 엔지니어링 활동 검토, 품질 측정 평가, 문서화, 승인, 보고통보
  품질활동 : 형상관리, 문서관리, 품질 기록, 합동 검토, 위험 관리

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

• 요구사항의 기술적 타당성 검토 과정
  성능 및 용량산정 적정성 -> 시스템 간 상호 운용성 -> IT시장 성숙도 및 트렌드 부합성 -> 기술적 위험 분석
  
  성능 및 용량산정 적정성
  : 성능 관련 비기능 요구사항과 비교하여 적정성 여부 판단
  
  시스템 간 상호 운용성
  : 복수의 이종 간 시스템 사이의 정보 및 서비스 교환 등 시스템 능력
  
  IT시장 성숙도 및 트렌드 부합성
  : 유지보수 관점에서 시스템의 시장성과 향후 발전 가능성 확인
  
  기술적 위험 분석
  : 복잡성, 검증 여부, 의존성 등에 대하여 위험 발생 가능성 및 영향도 파악
  
  출처 : 이기적 정보처리기사 실기 핵심이론 1권