요구사항 분석

<요구사항 분석>
- 도출된 불완전하고 추상적인 요구사항들을 적절한 수준으로 분해하고 정제하는 작업
- 고객과의 상호 작용을 통해 혼동 지점을 명확히 하고 어떤 요구사항이 다른 요구사항보다 더 중요한지 파악
- 명세를 만들기 위한 기반
- 요구 사항 모델링을 통해 요구사항이 보다 구체화되고 가시회되어 시스템에 대한 이해도가 크게 향상시키며 개발에 필요한 정보 제공 
- 모델링
  - 구조적 분석(자료 흐름도, DFD, Data Flow Diagram)
  - 유스케이스 분석 모델링(UML 모델링 사용)
  - 사용자 스토리(애자일 프로젝트)
  - ERD
  - State Transition Diagram
  - Dialogue Map 등



<Necessary>
- 각 요구사항이 왜 필요한지가 명확하게 설명되어야 한다
- 제거되어도 시스템 비지니스 목표를 달성하는데 영향이 없으면 필요하지 않은 것이다
- Gold plating 방지
  - Gold Plating : 고객이나 이해당사자가 요구하지 않았는데도 개발자 스스로 고객에게 이득이 된다고 믿는 부수적이나 장식적인 기능들을 추가하는 것

- ex)
  - 기능 요구사항 : 시스템은 신규 가입자에게 가입 시점에서 7일 이내에 10% 할인을 받을 수 있는 할인 쿠폰을 발행하여야 한다
 
  - 사용자 요구사항 : 신규 가입자는 할인 혜택을 받을 수 있다
  
  - 비즈니스 목표(요구사항) : 신규 가입자를 90일 이내 5% 증가한다



<Implementation Free>
- 요구사항에 불필요한 설계 및 구현 정보(제약)가 포함되지 않아야 한다
  - ex) 토핑 양식에 토핑 목록이 표시됩니다. 사용자는 토핑 옆에 있는 'checkbox'를 선택하여 베이글에 추가할 수 있다. 즉, 토핑을 선택할 수 있는 여러 기술 중 'checkbox'를 이용해야 한다



<Unambiguous>
- 요구사항은 하나 이상의 의미로 해석되지 않아야 한다
  - ex) 시스템은 출발지에서 목적지까지 '가장 좋은 길'을 찾을 수 있어야 한다. -> '가장 좋은 길'이 하나 이상의 의미로 해석된다


<Complete>
- 각 요구사항을 이해하는데 필요한 모든 정보를 가지고 있어야 하며 발생할 수 있는 모든 조건에 대해 기술하여야 한다
  - ex) 교수는 사용자 id, 비번 및 '관련된 정보'를 이용하여 시스템에 로그온 할 수 있어야 한다 -> '관련된 정보'가 명확하지 않다
  - ex) '프리미엄 약정이 선택되지 않고' '보험 증명이 제공되지 않으면' 사용자에게 기본 약정이 자동으로 선택되어야 한다 -> 선택되지 않고 제공되지 않은 나머지에 대한 조건이 서술되지 않았다. 즉, 프리미엄약정이 선택되고 보험증명이 제공된 이후에 대한 조건이 기술되지 않았다



<Atomic>
- 요구사항은 여러 요구사항으로 분리되지 않아야 한다
  - ex) 시스템은 '항공권 예약', '항공권 구매', '호텔 객실 예약', '자동차 예약', '명소 정보 제공'의 기회를 제공해야 한다 -> 5개의 요구사항으로 분해해야한다



<Feasible(실현 가능성)>
- 요구사항은 비용, 일정과 같은 제약 내에서 기술적으로 실행가능해야 한다
  - ex) 시스템은 사람의 얼굴 표정으로 명령을 인식하는 인터페이스를 제공하여야 한다



<Traceable>
- 요구사항은 요구사항의 소스(출처) 및 요구사항으로부터 파생된 다른 시스템 구성요소(설계, 코드, 테스트 케이스)등과 연결되어야 한다
- 요구사항(설계 및 구현, 테스트 케이스) -> 사용자 요구사항 -> 비즈니스 요구사항
- RTM(Requirements Tracebility Matrix)
  - RTM : 테스트 케이스와 함께 사용자 요구 사항을 매핑하고 추적하는 문서



<Verifiable>
- 요구사항은 검증 가능하여야 한다
- 시스템은 현재보다 '시간 당 더 많은 처리'를 할 수 있어야 한다
- 시스템은 모든 페이지를 '받아들일 수 있는 범위 내'에서 로드하여야 한다 



<(비기능적 요구사항을)품질속성을 검증가능한 시나리오로>
- 품질 속성 템플릿
  - 소스(Source) : 자극을 생성하는 개체
  - 자극(Stimulus) : 시스템에 영향을 주는 조건
  - 대상 또는 산출물(Artifact) : 자극에 의해 영향받는 시스템(부분)
  - 환경(Environments) : 자극이 발생된 상황
  - 반응(Response) : 자극으로 야기되는 시스템 행위
  - 반응척도(Measure) : 시스템의 반응을 평가하는 척도

- ex) 
Source : User(ATM 사용자)
Stimulus : Initiate Transactions(ATM에 대해 계좌이체를 하려고 할 때)
Artifact : System
Environment : Under Normal Operations(평일 : 9시~5시)
Response : Transcations Are Processed (계좌이체 완료)
Response Measure : With Average Latency of Two Seconds(1초 이내)



<Consistent(일관성)>
- 다른 요구사항과 모순이 없어야 하며 동일한 개념을 다른 용어를 사용하여 기술하지 않아야 한다
  - Req1 : 시스템은 'PayPal을 결제 수단'으로 제공하여야 한다
  - Req2 : 시스템은 결제 수단으로 '신용카드만'을 사용하여야 한다
  -> 일관성X, 모순
 
  - Req1 : '아웃바운드(Outbound)' 및 '인바운드(Inbound)' 항공편의 경우, 사용자는 인근의 다른 항공의 항공편 가격을 비교할 수 있어야 한다
  - Req2 : '출발(Outbound)' 및 '돌아오는(Return)' 항공편은 최소 정차 횟수에 따라 분류되어야 한다
  -> 같은 용어를 써도 다른 용어로 쓴 것은 일관성이 없다



<NonRedundant(중복X)>
- 각 요구사항은 한 번만 표현되어야 하며 다른 요구사항과 중복되어서는 안된다
  - Req1 : 사용자는 비행기 예매 날짜를 입력할 때 달력을 이용할 수 있어야 한다
  - Req2 : 시스템은 날짜를 입력하는 경우 달력을 이용할 수 있어야 한다
  -> Req2가 비행기 예매 날짜를 포함하는 경우이므로 중복