[Chap 4] Requirements Engineering

1) 요구사항 수집에서의 문제점

- 고객들의 요구사항들은 대체로 애매한 아이디어들이다.

- 개발자는 애매한 요구사항들을 가지고 계속 진행을 하게 된다.

- 고객들의 요구사항들은 계속해서 변한다.

예) '온라인 서점의 요구사항'에서,

"도서 검색과 주문 등이" => 비완성적인 부분(Incompleteness)

"고객", "회원" => 불일치(Inconsistency)

"카테고리 별 검색도" => 모호함(Ambiguity), 예를 들면 어떤 카테별리 별로 검색할지를 말해야함.

"효율적으로" => 모호함(Ambiguity), 어떻게 효율적으로 주문할 것인지 언급되야함

- 사용자와 개발자 사이에서의 요구사항 오해

(Misunderstanding)는 상당한 비용을 초래할 수 있다. 

=> 프로젝트가 진행됨에 따라 자꾸 비용이 커짐으로 초기에 Requirement를 제대로 수집하는 것이 중요함

- 제대로된 요구사항 수집을 어렵게 만드는 요소들은 복잡함(Complexity), 초기 요구사항의 변화(Changing Nature of Requirements), 의사 소통(Communication) 이 있다.

=> 이를 위한 해결책으로서 Requirements Engineering이 있다.

2) Requirements Engineering

- 시스템의 기능과 제약사항(속성)들로부터 고객들이 요구하는 서비스들을 확립해나가는 과정

- 이것은 설계 문서가 아니라 시스템이 무엇을 해야할지에 대한 모음이다.

- 요구사항들은 기능적인(functional) 부분 또는 비기능적인(non-functional)부분으로 되어 있다.

=> Functional requirement: 시스템 서비스 또는 기능들에 대한 요구사항

=> Non-functional requirement: 시스템 또는 개발 과정에 대한 제약사항에 관한 요구사항

2-1) 기능적 요구사항(Functional requirements)

- 시스템에 주어지는 특정 입력에 대한 시스템이 산출하는 출력 통해 정의된다. 

예) 식별자 REQ-1: 입력으로 사용자가 휴대폰의 통화버튼을 누른다. 출력으로 시스템은 최근 토오하 목록을 표시한다. 첫 항목을 선택시킨다.

2-2) 비기능적 요구사항(Non-functional requirements)

- 시스템의 속성들과 제약사항들을 정의하는 요구사항이다. 예를들면 안정성, 응답 시간, 요구 저장공간 같은 속성들

- 기능적 요구사항보다 더 결정적인 부분이 될 수 있다. 왜냐하면 이 부분이 충족되지 않으면 시스템은 이용가치가 없으므로

- 비기능적 요구사항은 기능적 요구사항과 확실히 구분을 시켜야 한다.

=> 하지만 기능적/비기능적 요구사항들은 시스템의 특성에 따라 사람마다 다르게 볼 수 있다.

- 비기능적 요구사항에서 품질 요구사항은 성능, 신뢰성, 보안성, 안전성, 가용성이 있다.

=> 성능: 시스템의 자원을 얼마나 효율적으로 사용하는가 

예) 사용자가 통화버튼을 누르면 2초 이내에 통화 연결이 성립되어야 한다.

=> 신뢰성: 시스템이 주어진 요구사항을 준수하여 동작하는 정도를 뜻한다.

예) 지대공미사일은 100개를 발사하면 90개는 목표에 명중해야한다.

=> 보안성: 허가되지 않은 사용자가 시스템에 접근하거나, 사용자가 접근권한이 없는 시스템의 정보를 접근하거 해서는 안된다.

예) 등록된 사용자만이 시스템이 접근할 수 있어야 한다.

=> 안전성: 시스템이 주변 환경, 인명, 재산에 피해를 주지 않아야 한다는 요구사항

예) 엘리베이터 문이 열린 상태에서는 엘리베이터는 이동해서는 안된다.

=> 가용성: 사용자가 원하는 순간에 시스템은 서비스를 제공해야 한다는 요구사항

예) 인터넷 뱅킹 시스템은 1년 365, 하루 24시간 동안 서비스를 제공해야 한다.

- 비기능적 요구사항에서 개발에 대한 제약사항(개발 방법과 개발 플랫폼)을 정한다.

예) 모델링 언어는 UML 2.x를 사용해하며, 개발 언어는 java언어, 운영체제는 Linux에서 동작해야 한다.

- 각자의 위치에 따라 요구사항 명세서의 역할이 다름

=> 개발자: 분석/설계/구현에 대한 기준

=> 테스터: 테스트에 대한 기준

=> 고객 및 사용자: 시스템의 개발 완료 승인에 대한 기준

- 요구사항 명세서가 위와 같은 역할로 사용되기 위해서는 다음과 같은 특징을 갖추어야 한다.

=> 명확성: 기술된 요구사항은 항상 동일한 의미로 해석되아야 한다. (모호하지 않아야 한다.)

=> 완전성: 사용자가 기대하는 모든 기능/비기능적 요구사항이 기술되어야한다.(누락되어서는 안된다.)

=> 일관성: 서로 상충되는 요구사항이 있어서는 안된다. (중복되는 부분이 있으면 안된다.)

=> 검증가능성: 객관적으로 검증할 수 있도록 구체적이어야 한다. (기준이 명확해야함.)

=> 구현가능성: 가용한 기술과 한정된 일정/비용으로 구현이 가능해야 한다.

3) Requirements Engineering Process

- 다음과 같은 과정을 거침

- Inception(시작) 

=> Stakeholder들을 확인하여, 다양한 관점들을 인식한다. 요구사항들 뒤에 어느 사람들이 있는지 확인하며, 해결방안을 누가 사용하며, 이 해결방안으로 인한 경제적 이익은 무엇인지 등을 질문하며 시작

- Eliciting Requirements(요구사항 수집)

=> 요구사항 수집을 위해 미팅을 가장 대표저으로 수행하며, 미팅시에는 요구사항에 대한 준비가 되어 있어야 함. 또한 미팅의 agenda가 제시되어 있어야 하며, 미팅을 이끌어가는 중계자도 요구된다. 

=> 요구사항 수집을 톨해 문제를 확인하며 여러 해결방안들을 제안하는 것을 목적으로 함.

- Elaborating Requirements(요구사항 검토)

=> 모델 분석을 만듦으로써 요구사항을 검토(Elaborate)할 수 있다.

=> 모델링 하는 방법에는 Data Domain, Function, Behavior, Partition, Essence등을 이용한 방법이 있다

=> Data domain: 데이터 오브젝트를 정의하고 그 데이터의 속성들과 데이터 간의 관계를 확립하여 모델링함

=> Function: 데이터가 Input으로 들어가서 어떻게 transform되는지 확인하며 데이터가 어떻게 시스템을 통해가는지에 대한 모델링

=> Behavior: 시스템의 동적인 상태들에 대한 모델링

=> Partition: 각각의 모델들을 분할(partitioning)하여 조금 더 상세하게 재정의해 나가는 모델링

=> Essence: 문제의 핵심적인 부분에 초점을 두고 시작하며, 필수적인 정보로부터 자세한 구현사항까지 나가아가는 모델링

=> 요구사항을 검토하는데 있어서 객체가 될만한 것들과 오퍼레이션이 될 것들을 찾아야 하는데 어떻게 찾아 낼까?

=> 요구사항 명세서에서 모든 명사들은 오브젝트가 될 수 있는 것들이며, 동사들은 모두 Operation이 될 가능성이있다!

- Negotiating Requirements(요구사항 협상)

=> 협상과 연관될 수 있는 핵심 Stakeholder들(Customer, user, ...)을 확인한다.

=> Stakeholder들이 만족할만한 것들을 결정한다.

=> 개발자와 모두 win-win할 수 있도록 요구사항 명세서를 협상한다.

- Validating Requirements

=> 수집한 요구사항들을 검증한다

=> 사용자가 원하는 것인가?(모호함이 있으면 안됨), 일관성이 있는가?(요구사항이 충돌하는가?), 완전한가?(모든 요구사항을 밝혔는가?), 현실적으로 실현가능하며 검증이 가능한가? 등에 대한 판단을 실시

=> 검증 방법으로는 Review, Prototype 기법, Test case 등이 있다

# 요구사항 분석을 통한 산출물로 요구사항 정의서와 요구사항 명세서, 소프트웨어 명세서가 나온다.

=> 요구사항 정의서: 요구사항이 높은 수준으로 추상화 되어 기술된 것. 자연어로 명시되며 전문가가 아니더라도 이해할 수 있는 문서이다.(보통 고객들로 부터의 정보를 이용하여 만들어짐)

=> 요구사항 명세서: 시스템이 무엇을 해야하는지에 대한 자세한 기술이 적혀있음. 더 자세하고 형식적인 표기법으로 명시. 클라이언트와 계약자 사이의 계약에 있어 기본이 됨. 전문가들이 이해할 수 있는 수준의 문서임

=> 소프트웨어 명세서: 소프트웨어 개발자(설계자)들을 위해 작성된 문서로, 설계와 구현에 기초를 둔 문서이다.

# 이러한 요구사항 문서들은 다음과 같은 특징이 요구된다

=> 외부시스템과 어떻게 연결되는가?

=> 구현에서의 제약사항은 어떻게 되며, 유지보수를 위한 참조(Reference)는 어떻게 제공 할 것인가?

=> 변화를 예측할 수 있는가?

=> 요구사항이 어떻게 만들어 졌는지 추적(trace)할 수 있는가?

=> 변화(진화)는 항상 일어난다는 점을 유의해서, 이 요구사항들은 잘 수긍해서 반응 할 수 있는가?

4) Requirements Document Structure

- 예를 들면, 서론/용어/시스템모델/기능적요구사항 정의/비기능적 요구사항 정의/시스템 변화 방향/요구사항 명세/index와 같은 구조로 작성된다.

# Requirement Engineering이 어려운 이유는,

유저들이 매우 많고 그 많은 유저들의 요구사항을 모두 만족시키고 합리적인 방향으로 나아가야 하므로 어렵다!