Requirements Engineering - 프롤로그 -

 컴퓨터 소프트웨어 SI, 또는 SM에 한정해서라도 고객의 요구사항을 추출해 내는 과정은 지극히 중요한 작업중의 하나라고 할 수 있다. 정의된 요구사항은 뒤따르는 모든 프로젝트 작업들의 가장 기초가 되는 핵심이다.

제목 그대로 'Crafting High-Quality Requirements' 를 해 보자는 것이다. 프로젝트나 SM이나, 비단 소프트웨어 시스템 뿐만 아니라 세상의 모든 프로젝트들에서 수많은 프로젝트 매니저, 혹은 개발자들은 사용자들이 내던진 부실하고 썩은 사고방식으로 가득 찬 요구사항 명세서 한 장 달랑 들고 작업을 할 것인가. 그 종이쪼가리에 적힌 요구사항도 프로젝트가 중반에 이르게 되면 '주간조선' 두께로 늘어나게 된다. 얼마나 밤을 세워서 말도 안되고 가변적인 사용자들의 요구사항을 맞추어 주어야 할 것인가. 게다가, 프로젝트가 끝나고서 '어, 이런건 당연히 되어야 하는 것 아니에요? 기본적인 것 인데, 이야기 안 했다고 안 만들고 그러면 너무 하는거 아닙니까? 게다가 추가 요구사항이라고 비용도 더 내라구요??' 라는 망언까지 들어야 하니..

 먼저, 요구사항이라는 것이 무엇인지에 대해 정의를 생각해 보자.

 요구사항이란, 무엇이 구현되어야 하는가에 대한 명세이다. 요구사항은 시스템이 어떻게 동작하여야 하는지, 또는 시스템 특징이나 속성들에 대한 설명이다. 요구사항은 시스템 개발 프로세스 상의 제한사항일 수도 있다.

[More About Software Requirements, 정보문화사]

여기에는 현업의 목표와 입장 그리고 비젼에 대한 'Business Requirements'가 있으며, 순수 사용자단의 입장에서 이 제품을 가지고 무엇을 할 수 있는지에 대한 'User Requirements', 또한 시스템 자체 내에서 그러한 기능이 구현되기 위해서 필요한 요구사항들인 'Functional Requirements'가 있다. 그 외에도 많은 요구사항 형태가 있을 수 있다. 

 이러한 요구사항들을 고객에게서 어떻게 하면 잘 뽑아낼 수 있고 합의할 수 있는지, 이러한 요구사항들이 어떻게 전달되고 관리될 것인지에 대한 학문이 ' Requirements Engineering' 인 것이다.

 요구사항 공학은 크게 개발과 관리라는 2가지 분야로 나눌 수 있다. 개발은 요구사항의 식별과 합의, 그리고 기능 요구사항과 함께 비지니스 목표에 부합하는 하나의 세트를 만드는 것이고, 관리는 합의된 요구사항 세트에 대한 변경사항을 관리하는 것이다. [Karl E. Wiegers] 

 언제가 될 지 모르겠지만, 요구사항 공학에 대해서 조금 자세히 포스팅을 해 보고자 한다. 거창한 지식공유 보다도, 내 것으로 온전히 만들기 위한 과정이라고 생각하며.