소프트웨어 공학에서 특화된 분야 중 하나가 바로 요구 공학
이것은 요구 사항이 커다란 비중을 차지하고 있음을 보여줌
1. 요구 공학(requirements engineering)이란?
소프트웨어의 요구 사항을 정의하고 관리하는 방법을 연구하는 학문.
소프트웨어의 규모가 커지면서 요구 사항의 중요성이 날로 커지고 있음.
뿐만 아니라 요구 사항을 어떻게 만드는가에 따라 소프트웨어 제품 개발의 성공을 좌우.
이에 따라 요구 사항에 대한 연구가 늘고 있다.
그것이 요구 공학이라는 학문이 탄생하게 된 이유.
2. 요구 공학의 요소
각 요소들은 요구 사항들을 개발하고 관리하기 위해 해야 할 일들이 무엇인지를 정의하고 있다.
요구 공학 요소 | 설명 | 세부 요소 | 설명 |
요구 사항 개발 (requirements development) | 요구 사항을 처음부터 개발하고 완성하는 것이 요구 사항 개발에 해당 됩니다. | 요구 사항 도출 (requirements elicitation) | 고객으로부터 (때로는 자체적으로) 소프트웨어의 요구 사항들을 도출하는 일이다.
|
요구 사항 분석 (requirements analysis) | 도출된 요구 사항들이 구현 가능한지, 어떤 요구 사항들이 더 중요하고 급한지, 구현할 수 있는 요구 사항들의 범위가 어디까지인지를 고려하고 결정하는 일이다.
| ||
요구사항 명세화 (requirements specification) | 도출하고 분석한 요구사항들을 명세서로 작성하는 일이다.
| ||
요구 사항 검증 및 확인 (requirements verification & valication) | (1) 요구 사항들에 오류가 없는지를 검증하고 (2) 요구 사항대로 소프트웨어를 만들면 고객이 만족하는지를 확인하는 작업
| ||
요구 사항 관리 (requirements management) | 이미 개발된 요구 사항을 수정하거나 그것의 이력을 만든다. 나중에 오류가 발견되면, 요구 사항의 이력을 추적하는 것도 요구 사항 관리에 포함. 요구 사항의 수정을 승인 받기 위해 고객과 대화나 협상을 해야 하는 경우도 있다. | 요구 사항 협상 (requirements negotiation) | 이것은 요구 사항에 대하여 고객과 협상하는 것을 말한다.
고객이 요구하는 사항들이 구현 자체가 불가능하거나 일정 내에 구현하는 것이 불가능할 수 있다. 그렇다면 프로젝트 리더는 그 이유를 고객에게 설득할 수 있어야 한다. 이것은 프로젝트 중간에 고객이 요구 사항을 추가하거나 변경하려는 경우에도 해당 설득할 수 있어야 한다.
|
요구 사항 베이스라인 (requirements baseline) | 일반적으로 요구 사항의 변경은 프로젝트 리더의 승인을 받아야 한다. 이후 변경된 내용들이 문서에 반영될 수 있고 베이스라인이 형성된다. 매 변경마다 베이스라인이 만들어지며, 이것을 이용해 과거에 반영된 요구 사항들이 무엇인지 파악할 수 있다.
| ||
요구 사항 변경 관리 (requirements change control) |
요구 사항의 변경은 언제든지 개발 조직이 요청 받을 수 있다. 그것을 받아들여야 할지가 결정되어야 한다. 그리고 그것이 언제, 어떻게, 왜 변경되는지가 이력(history)으로 기록되어야 한다. | ||
요구 사항 추적 (requirements traceability) | 만약 요구 사항의 변경으로 인해 프로젝트에 문제가 발생했다면, 그것이 언제, 왜 변경되었는지를 추적할 수 있어야 한다.
|
