[Requirements Engineering] #1 Overview

시스템 아키텍쳐에서 필수적인 것이 무엇을 설계할 것인가 입니다. 막연히 뭘 설계 개발해야할지 모르는 상황에서 컴퓨터 앞에 앉는 행위는 어리석은 행동입니다. 클라이언트가 어떠한 것을 요청하는지 파악해야 설계를 할 수 있습니다. 아래는 많이 보셨을 그림입니다.

고객이 설명한 것을 시스템에 관련된 이해관계자들이 이해하고 만들어나가는 과정입니다. 실제로 고객이 원하는건 나무에 타이어 하나 매달아 그네를 쓰고자 했는데 결과물은 전혀 다른 것이 나왔습니다. 이 그림은 시스템 개발 시 발생할 수 있는 문제를 웃음으로 승화시킨 그림인데요, 정말 웃고 지나갈만한 일일까요? 위와 같은 문제는 자주 발생할 수 있습니다. 이러한 문제를 방지하고 영향을 최소화 하기위해 요구공학이란 학문이 존재합니다.  

실제로 클라이언트와의 미팅 이후 요구사항 분석, 설계, 구현, 테스트 등을 진행하다 보면 문제가 발생할 수 있습니다. 여러분이 구현 후 테스트하는 단계에서 문제를 발견하였다고 합시다. 해당 문제가 발생한 부분이 구현 시 발생한 것과 아니면 클라이언트의 요구사항을 잘못 분석한 문제라고 할 때 어떤 문제가 에러 수정에 큰 비용이 들어갈까요? 당연히 클라이언트의 요구사항을 잘못 분석한 문제가 매우 큰 영향을 끼치게됩니다. 잘못하게되면 설계 자체를 수정해야하는 문제가 발생할 수 있습니다.

1-10-100 Rule

1-10-100 Rule 이란 것이 있습니다. 프로젝트에서 발견하지 못한 에러를 수정하는 드는 비용에 관련된 것입니다.

Project Stage	Relative Repair Cost
Requirements Analysis	1-2
Design	5
Coding	10
Unit Testing	20
System Testing	50
Maintenance	200

Requirements Analysis 단계의 문제를 늦게 발견하면 할수록 그 문제를 해결하기 위해 필요한 비용이 매우 크다는 것을 알 수 있습니다. 

Requirements Engineering

위와 같은 문제를 해결하기 위해 요구공학 이란 학문이 존재하는 것을 알게되었습니다. 그럼 이 학문이 정확히 무엇인지 정리해보고자 합니다. 먼저 위키피디아에 요구공학은 아래와 같이 정의되어 있습니다.

요구공학(Requirements engineering, RE)은 시스템 요구사항 문서를 생성, 검증, 관리하기 위하여 수행되는 구조화된 활동의 집합이다.

요구사항 엔지니어링은 소프트웨어 집약적 시스템의 목적 및 이 시스템이 사용될 맥락을 식별하고 전달하는 것과 관련된 일련의 활동입니다. 따라서, 요구공학 (이하 RE)는 사용자, 고객 및 소프트웨어 시스템의 영향을 받는 기타 요소의 실제 요구와 소프트웨어 집약적 기술이 제공하는 능력과 기회 사이의 다리 역할을 합니다.

쉽게 설명하면 RE는 시스템에서 고객의 요구하는 서비스와 이 시스템을 개발함에 있어서 존재하는 제한사항을 찾아내는 절차입니다. 요구공학에서 말하는 요구(Requirements)는 요구공학 절차 시 생성되는 서비스와 제한사항의 명세라고 생각하시면 됩니다.

요구사항 분석(Requirements Analysts)

그럼 요구사항 분석을 무엇을 하는 걸까요, 요구사항 분석은 문제와 그 문제를 해결하기 위한 해결책을 찾는것입니다. 실제로 이 프로젝트를 진행할지에 대한 분석부터 시작하여 이해관계자 정의와 클라이언트는 왜 이 문제 해결을 원하는가, 어떻게 소프트웨어 시스템으로 문제 해결에 도움을 줄 수 있는가 등 여러가지 관점으로 접근하게 됩니다.

RE는 무조건 Sequential하게 프로세스를 진행할 필요는 없습니다. RE 활동은 개발 프로세스에서 지속적으로 진행될수도 있습니다. 문제 상태는 항상 불완전합니다. 요구사항 분석은 추후에 발생할 위험을 줄이기 위함이지 완벽하게 문제 상황을 해결할 수 없을 수도 있습니다. 소프트웨어는 지속적으로 변경될 것이며 문제가 발생할 수 있습니다. 그러한 문제에 대해 조금이라도 줄이고자 하는 활동이 RE라고 생각하시면 될 것 같습니다.

감사합니다.