SWEBOK - 소프트웨어 요구사항 #1

SWEBOK 해설 - Software Requirements #1



1장 Software Requirements (소프트웨어 요구사항)

(*** 필자주석) "Requirements"를 "요구사항"이라고 편의상 번역해 놓았으나 국내에서는 고객 요구사항, 기능명세서, 요구사항 명세서등 다양한 이름으로 잘못 번역되어 있기 때문에 필자는 기존의 잘못된 이해에 대한 혼란을 피하기 위한 유일한 방법으로 앞으로 계속해서 "Requirement"로 표현한다. 국내에서 시용하는 대부분의 문서와는 100% 일치하지 않으니 기존에 알고 있던 문서와 매칭시키려는 노력은 이 연재가 끝나기 전까지는 당분간 보류하기 바란다. 나중에 전체를 이해하고 나면 국내의 모든 문서가 어느 위치에 있고 다른 방법론의 어떤 문서와 매치되는지를 알 수 있으나 지금으로서는 혼란만 일으키니 지금까지 알고 있던 문서는 당분간 머리 속에서 지워버리자.

소개



소프트웨어 요구사항 지식영역은 소프트웨어 전체 생명주기에서 다음 주제를 다룬다.



* Elicitation(도출)

* Analysis (분석)

* Specification (명시)

* Validation (검증)

* Management (관리)



Requirements와 관련된 활동이 제대로 수행되지 않는다면 소프트웨어 프로젝트는 매우 위태롭다고 이론가들이나 실무자들 모두에게 인식되고 있다.

(***필자주석) 이 문장은 이론가들이라면 수도 없이 들어 보고 주장하는 문장이지만 실제로 위태로운 정도를 상상하기가 어렵다. 하지만 필자의 30년 경험상 학교숙제나 간단한 스마트폰 앱을 개발할때도 Requirements 활동을 하지 않으면 구현을 시작하지 않을 정도로 위태로움을 느낀다. 하지만 초보자들에게 아무리 위태롭다고 해야 그 심각성을 이해시키기는 불가능하다. 바로 "칩 히스"가 "스틱" 이라는 베스트셀러에서 얘기한 "지식의 저주"이다. 초등학생들에게 공부를 잘하라고 아무리 얘기한들 그 중요성을 깨달을 수는 없다. 하지만 세계 최고의 소프트웨어 실무 전문가인 수백 명의 저자들이나 30년을 실리콘밸리의 글로벌회사부터 벤처기업까지에서 일했던 필자가 그 심각성을 주장한다면 다시 한 번 고려하는 것이 좋을 것이다.

Software Requirements는 현실의 문제를 해결하기 위한 소프트웨어 제품의 필요기능과 제한사항을 표현한다. 한편으로 "Requirements Engineering" 이라는 용어는 Requirements의 체계적인 관리라고 정의되어 있다. 하지만 이 "Requirements 지식영역"에서는 용어의 혼란을 피하고 일관성을 위해서 "Software Engineering"을 의미하는 경우가 아니고는 "Engineering" 이라는 용어를 여기서는 사용하지 않는다. 같은 이유로 시중의 다른 문서들에서 사용되는 "Requirements Engineer" 라는 용어도 여기서는 사용하지 않는다.

그 대신 Requirements를 수행하는 사람들을 "Software Engineer" 혹은 "Requirements Specialist" 라는 용어를 사용하기로 한다. Requirements Specialist는 일반적으로  Software Engineer가 아닌 사람들이 분석작업을 할 경우 붙이는 용어이지만 그렇다고 Software Engineer가 분석 작업을 할 수 없다는 것은 아니다. 즉 Software Engineer이든 개발자가 아닌 Requirements Specialist이건  둘 다 분석 작업을 할 수 있다.

(*** 필자주석) 여기서 저자들이 "소프트웨어 공학"이라는 용어로 잘못 유도되는 잘못을 피하기 위해 아예 공학이라는 말을 사용하지 않겠다는 것이다. 필자도 "소프트웨어 공학" 이라는 용어를 사용하는 것을 극단적으로 피한다. 실무 경험이 없으면서 이론적으로 "소프트웨어 공학" 을 안다고 하는 것이 어불성설인데 그런 이론가들과 필자와의 차이를 두기 위해서이다. 필자는 실리콘밸리에서 자란 실무전문가이지 소프트웨어 공학 이론가는 아닌 것이다.

하여튼 "공학" 이라는 말이 많은 혼란을 일으키고 공학이라는 이름 아래 선 무당들이 국내 소프트웨어를 잘못 이끌어 가는 것을 피하기 위해서는 공학의 진정한 의미를 깨닫기 전에는 일단 공학이라는 단어를 사용하지 않겠다는 저자들의 말에 필자도 전적으로 동의한다. 필자가 평생 동안 소프트웨어 공학을 실행했으면서도 소프트웨어 공학을 한다는 말은 하지 않는 이유이다. 이 부분이 필자의 고민이었듯이 저자들의 심오한 철학적인 면까지도 엿볼 수 있다.

Software Requirements를 수행하는 방법을 프로세스의 관점(Process-based Breakdown)에서 순서대로 나열하면 마치 폭포수모델(Waterfall Model)의 Top-down 방식으로 생각할 수 있다. 하지만 그것은 착각이고 Requirements 과정을 순서적으로 설명하는 것은 각 Requirements의 상세과정을 수행하는 각 과정에서 필요한 자원과 제약사항 등에 대한 설명을 하기 위한 하나의 분류방법인 것이다. 이런 프로세스 관점의 순서대로 설명할 수도 있지만 프로세스가 아닌 제품 관점(Product-based Breakdown)으로 단계를 나눌 수도 있다. 예를 들어 System requirements, Software Requirements, Prototype, Use cases 등과 같은 방법도 하나의 방법이다.



여기에서는 프로세스의 관점에서 나누는데  그것 때문에 마치 프로젝트의 시작시점에서 Requirements의 활동을 모두 완벽하게 수행해야 하는 독립적인 프로세스로 착각할 수 있다. 하지만 Requirements Process는 매우 복잡하고 개발 후반부의 설계, 구현, 테스트, 유지보수, 형상관리 등 모든 지식영역과 매우 밀접하게 관련되어 있다. 즉 하나의 독립된 프로세스는 아니다. 순서적으로 진행할 수도 있고 다른 지식영역 활동과 병행해서 진행할 수도 있다.

(*** 필자주석) 국내에서 거의 모든 사람들이 착각하는 것이 저자들이 얘기하듯이 분석단계를 개발시작시에 첫 단계에서 작성해서 완성하는 것이라고 이론적으로 생각하는 것이다. 반대로 더 큰 착각은 그게 어려우니까 그냥 대충하고 넘어가고 나중에 상세한 부분을 정해나가겠다는 것이다. 둘 다 잘못된 것이다. 하나는 지극히 느린 국방부의 접근 방법이고 두 번째는 개집 만드는 경우에는 괜찮지만 전세계 소프트웨어의 99.9%에 해당되는 상용제품을 만드는 경우에는 나쁜 방법이다.

이미 저자들이 앞부분에서 불충분한 Requirements의 위험성에 대해서 경고했지만 지금 실감하기는 어려울 것이다. 아무튼 이것도 잘못이고 저것도 잘못이라고 하는데 일단 머리에 인식해 두고 계속 경험하면서 과연 저자들이 무엇을 전달하려고 했는지 깨달아 보자.

또 독립된 프로세스라고 생각하고 SRS를 작성하기 위한 문서 Template을 달라고 하는 사람들이 많은데 Template은 인터넷에 널려 있는 것에 불과하고 지금 이 문서에서 말하는 복잡성이나 어려움에 대한 이해를 못하고 있는 것이다. 템플릿은 음식을 담는 그릇일 뿐 중요한 것은 그릇에 담을 내용물인 음식을 만드는 것이다. 필자의 책에서도 언급했지만 더 이상 Template을 찾아 헤매는 노력은 하지 않기 바란다.

"Software Requirements 지식영역"은 다음과 같은 Topic으로 구분된다



1. Software Requirements Fundamentals (본질)

2. Requirements Process (프로세스)

3. Requirement Elicitation (도출)

4. Requirements Analysis (분석)

5. Requirements Specification (명시)

6. Requirements Validation (검증)

7. Practical Considerations (현실적인 고려사항)

8. Software Requirements Tools (도구)

(*** 필자주석) 국내에서 용어의 혼란 때문에 정확한 의미를 이해하는 것이 어려울지 모른다. 특히 Requirements와 Specification의 차이는 문서의 양으로 비교했을 때 10페이지와 1000페이지의 차이일 정도로 크다. 그런데 Requirements를 작성하고서는 Specification을 작성했다고 착각한다. 용어도 요구사항, 고객요구사항, 명세서, 기능명세서, 요구사항명세서 등을 혼용해서 사용하기도 한다. 다 똑같은 문서를 의미하는 것으로 착각하기도 한다. 그래서 필자가 영어를 그대로 사용하지 절대 번역을 하지 않는다. 지금 이 단계에서는 Software Requirements Specifications(SRS)이 위의 8가지 Topic의 결과로 나오는 문서이고 그 중간 과정에서 나오는 문서가 Requirements 라는 것 정도만 이해하고 넘어가자.

위  8개의 Topic은 다음 Post 부터 하나씩 설명하기로 한다.