* 요구공학(Requirements Engineering)
- 어떤 시스템에서 필요한 서비스(기능)과 제약사항(비기능)을 정의하는 학문
- 요구사항의 기술 방법은 높은 단계의 추상화부터 수학적 기능 명세까지 다양하게 표현이 가능하다.
- 요구사항의 종류는 2가지가 있으며 2가지가 하는 일이 다르기 때문에 2종류 모두 작성해준다.
ⓐ User requirements
- 계약을 성립시키기 위한 요구사항
- 사용자의 요구사항이며, 이를 자연언어와 다이어그램, 표 등을 사용해서 표시한다.
- 사용자, 고객을 위해서 작성된 요구사항이며, Client manager, System end-users, Client engineers
Contractor managers, System Architects등이 읽는다.
ⓑ System requirements
- 시스템적 요구사항으로 계약서 자체로의 역할도 할 수 있다.
- 구조화된 문서로 애매모호함이 없이 정의되어야 한다.
- User requirements의 어느 부분에 해당하는지도 명시해 준다.
- 개발자와 고객을 위해서 만들어 졌으며, System end-users, Client engineers, System architects,
Software developers가 주로 읽는다.
- 요구사항의 종류는 다음과 같이 3가지로 다르게 분류가 되며, 이것 또한 3종류 모두 작성되야 한다.
ⓐ Functional requirements : 기능적 요구사항
ⓑ Non-functional requirements : 비기능적 요구사항
- 제약사항을 나타내는 부분으로 시스템이 지니는 속성적 제약사항(신뢰성, 반응시간, 저장공간, ...)
개발에 따른 제약사항(언어, 플렛품, ...)등을 잘 나타내야 한다.
- 비기능적 요소는 기능적 요소보다 프로그램에 치명적으로 작동할 수 있다.
- 하나의 비기능적 요구사항이 전체시스템에 영향을 줄 수 있다.
- 하나의 비기능적 요구수항은 다른 기능적 요구사항의 집합이다.
- 사용의 편의성, 시간과 공간의 효율성, 의존성, 보안, 개발환경, 기능, 윤리적, 법률적 요소로 나눠서 생각한다.
- 대분류
> 제품의 수행속도, 신뢰성
> 프로세스 모델, 언어, 실행환경
> 법률
- 비기능적인 요구사항을 평가하기 위해서는 테스트 가능한 목적을 만들어야 한다.
ex) 시스템은 사용하기 편해야한다.(Goal)
시스템을 4시간 교육하면 모든 기능을 사용해야 한다.(Verifiable Goal)
ⓒ Domain requirements : 도메인 요구사항
- 해당 System분야에서만 사용되는(존재하는) 요구사항
※ 요구사항서는 2개의 분류 조합으로 총 6개로 나타나게 된다.
ex) Functional User requirements & Functional System requirements ...
* 요구사항 추출시 주의 사항
- 요구사항은 Complete(완전성)하며 Consistence(일관성)해야한다.
- Complete : 해당 시스템에 있는 모든 기능을 파악
- Consistent : 서로의 요구사항이 다른 요구사항에 영향을 주면안된다.
(하나의 제한 사항에 의해 다른 요구사항이 성립안되는게 존재해서는 안된다.)
- software requirement document는 디자인 문서가 아니다. 무엇을 하는지만 정하면 된다.
시스템 요구사항과 사용자 요구사항을 모두 작성해야한다.
---------------------------------
* Agile methods and requirements
- agile methods에서 요구사항은 매우 자주 변경되기 때문에 요구사항명세서 작성이 불가능하다.
- 요구사항 명세서 대신 user story로 요구사항을 작성한다.
- 예전에 말했듯이, 여러 팀이 모여서 하는 프로젝트나 치명적 시스템 개발에는 agile을 사용하지 않는다.
(이럴 경우는 반드시 요구사항 명세서를 작성해야 하므로...)
----------------------------------
* 요구사항 명세서
- model에 따라서 세세한 정도가 달라진다.
- IEEE에서 문서의 대략적인 목차를 정했다.
서문, 소개, 사용자 요구사항 정의, 시스템 아키텍쳐(전체적 큰 아키텍쳐를 그린다), 자세한 시스템 요구사항 명세
시스템 모델(그래픽적인 요소), 진화, 부록, 색인
- 언어
> Natural language : 자연언어. 애매모호함이 존재
> structured natural language : 구조화된 자연언어. 표 등으로 구조화된 형식이다.
> design description language : programming 언어처럼 제작된 디자인 묘사 언어가 존재한다.
> graphical notation : 정형화된 그림으로 표현해준다.
> Mathematical specification : 수학과 논리만을 사용
※ 아래로 올수록 치명적인 시스템에서 사용한다.
- 요구사항은 설계와 밀접한 관계를 가지고 있으며, 실제로 설계와 요구사항 명세는 동시에 발생한다.