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

SWEBOK 해설 Software Requirements #6

(***필자주석) 요구사항의 도출, 분석을 지나 명시(Specification)하는 단계에 왔다. 여기에서 SWEBOK의 본질이 무엇인지를 다시 회상해 보자. SWEBOK은 가이드이다. 방법을 가르쳐 주는 문서가 아니다. 가이드 없이 방법을 준다면 시행착오는 필연적이다. 필자의 경험으로 보면 SWEBOK과 같은 가이드는 인생의 가이드와 같다. 그 가이드 아래에서 학교를 가야겠다든지 전공을 전산학을 하겠다든지 하는 큰 골격이 생긴다. 그 골격을 따라가다 보면 실제 실행할 자세한 내용이나 따라 할 모델이 필요하다. 그런 모델이 소프트웨어 요구사항에서는 템플릿이나 샘플이라고 할 수 있다. 하지만 모델이 있다고 혼자서 배울 수 있는 것은 아니고 학교와 같이 스승이 필요하다.

SWEBOK은 방법이 아니라 가이드이다. 매우 중요한 가이드이지만 경험 없이 SWEBOK이 말하는 문장이나 단어를 공감하고 가슴으로 느끼기는 쉽지 않다. 그렇지만 지속적으로 인식하고 있어야 나중에 경험을 할 때 진정으로 도움이 된다. Chicken-and-Egg 문제이다. 필자도 실리콘밸리에서 많은 경험을 먼저 하고 나서 SWEBOK을 나중에 접했기 때문에 진정으로 공감을 할 수 있었지만 독자의 경험의 정도에 따라서 별 도움이 되지 않을 수도 있다는 생각을 한다. 특히 1,2년 경험의 개발자들에게 SWEBOK이 도움이 될지는 회의적이다. 마치 유치원생에게 명심보감을 가르치는 상황과 같다. 그런 경우에 지속적으로 가르쳐서 외우게 하여 인생관을 형성한 것이 선조들의 지혜로운 교육방법이었다. 경험이 없는 상태에서 "왜" 해야 하는 지를 이해하기 어려운 상황에서는 외우는 것이 가장 좋은 가르침의 방법이다. 필자가 태극권을 배우면서 초보자들은 "왜" 를 물어보지 않고 관장님이 시키는 대로 그냥 따라 하는 것이 가장 좋은 배움의 방법이라는 것을 나중에 깨달았다. 경험의 정도에 상관 없이 혹은 지금 얼마나 공감하는 지에 상관없이 SWEBOK을 읽고 또 읽고 하는 것은 결국은 누구에게나 도움이 된다고 생각한다.
 

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)

대부분의 엔지니어링 전문가들에게는 "명시(Specification)" 라는 용어는 제품의 목표를 숫자로 표현하는 것을 의미한다. 소프트웨어 공학에서는 Software Requirements Specification(SRS)는 "시스템적으로 검토될 수 있고 평가될 수 있고 승인될 수 있는 문서" 를 의미한다. 하드웨어 컴포넌트를 포함하는 복잡한 시스템에서는 System Definition (시스템 정의서), System Requirements (시스템 요구사항), 그리고 Software Requirements(소프트웨어 요구사항)과 같은 3가지 종류의 문서가 작성되기도 한다. 간단한 소프트웨어 제품의 경우에는 세 번 째 문서인 소프트웨어 요구사항만 작성이 된다. 이 꼭지에서는 이 3가지 종류의 문서가 적절히 조합해서 사용될 수 있도록 모두에 대해서 설명한다. System Engineering은 SWEBOK의 다른 챕터인 "Related Disciplines of Software Engineering" 에서 설명된다.

(***필자주석) 위에서 3가지 종류의 문서라고 말하는데 그 문서들을 하나씩의 파일로 착각하기 쉽다. 아주 간단한 소프트웨어의 경우에는 하나의 파일로 충분할 수도 있지만 보통은 하나의 파일이 아니라 여러 개의 단위 문서가 집합해서 만들어진 문서의 집합을 말한다. 예를 들어 SRS만 해도 비행기와 같은 거대한 시스템을 만들 때에는 수십개, 수백개, 수천개의 문서로 만들어 지기도 한다. 그 중의 한 부류가 필자가 계속 SRS와 다르다고 언급하는 기능명세서(Functional Description)이다. 기능명세서는 SRS의 극히 일부분일 뿐이다. 각 회사나 정부기관마다 SWEBOK이 말하는 원칙은 모두 동일하게 따르지만 실제 문서의 이름들은 다 다를 수 있다. 실제로 필자는 문서 이름까지 같은 회사는 경험해 본 적이 없다. 즉 모든 회사마다 사용하는 템플릿은 다 상이하다는 얘기이다. 하지만 원칙과 내용은 동일하니 한 회사에서 SRS를 적을 수 있으면 다른 회사에 가서도 SRS를 무난히 적을 수 있다.

5.1 System Definition Document (시스템 정의)

가끔 "사용자 요구사항 문서 (User Requirements Document)" 혹은 "운영문서(Operations Document)"이라고 부르기도 하는 문서인데 시스템의 요구사항을 적는 문서이다.

이 문서는 산업 도메인의 관점에서 상위 수준의 시스템 요구사항을 적는다. 이 문서는 시스템 사용자나 고객 혹은 회사의 마케팅부서(대중에게 파는 소프트웨어인 경우)의 관점을 대표한다. 그러므로 여기에 사용하는 용어도 기술이 아닌 산업 도메인의 관점에서 사용해야 한다. 다음과 같은 내용이 적힌다.

* 시스템 요구사항
* 목표와 배경
* 운영될 환경 (Target Environment)
* 제약 사항 (Constraints)
* 가정 (Assumptions)
* 비기능 요구사항 (Non-Functional Requirements)
* 시스템 전체를 이해할 수 있는 개념 모델(Conceptual Model)
* 사용 시나리오 (Usage Scenario)
* 주요 조직과 사용 워크플로어(Workflow)

(***필자주석) 개발자 경험에 따라 각 항목에 무슨 내용을 적어야 할지 모르는 경우가 많다. 첫번째 항목인 시스템 요구사항은 기능을 적는다고 가정하고 나머지 항목들은 왜 필요한지 조차도 인식하기가 쉽지 않다. 하지만 현실에서 큰 문제가 생기고 외국에서 소송의 대상이 되는 것들은 기능이 아니고 기능 외의 것들이다. 기능은 모든 사람들이 신경 쓰고 있기 때문에 빠뜨리기가 어렵다. 하지만 다른 것들은 무엇을 적는 것인지도 잘 모르는 상태에서 실제 적어야 할 것의 극히 일부분만 적는 경우도 생긴다. 불행히도 책에서는 원칙적인 가이드를 줄 수 있을 뿐 구체적인 항목을 나열해 줄 수는 없다. 모든 소프트웨어가 다르기 때문이다. 그래서 원칙을 특정한 자신의 환경에 적용할 수 있는 응용 능력이 필요하고 그 응용능력은 경험에서 나온다. 이런 역량을 학교나 학원이나 정부기관에서 가르칠 수는 없는 것이다.

5.2 System Requirements Document (시스템 요구사항)

비행기와 같이 소프트웨어와 하드웨어가 같이 필요한 시스템을 개발하는 사람들은 소프트웨어 요구사항과 시스템 요구사항을 따로 적는 것이 통상적이다. 이런 방식에서는 시스템 요구사항을 먼저 적고 거기서 소프트웨어 요구사항이 파생되어 나온다. 엄격하게 말하면 System Requirements Specification은 시스템공학(System Engineering)의 분야이고 소프트웨어 가이드인 SWEBOK의 영역 밖이다.

(***필자주석) 바로 위에서 "엄격히 말하면 System은 SWEBOK의 영역이 아니다"라고 말하지만 사실은 System이나 Hardware나 Software나 모두 Requirements나 Specification을 적는 원칙도 같고 유사한 분석 역량을 필요로 한다. 다만 도메인 영역이 다르므로 거기서 특성의 차이가 있기 때문에 다르다고 할 수 있지만 현실적으로는 90% 이상이 같다. Template도 비슷하고 문서의 구조도 비슷하고 많은 경우에 똑같은 Template을 사용하기도 한다. 필자의 이전 책인 "글로벌 소프트웨어를 꿈꾸다(2010년)"에서 차이점과 유사점에 대해 설명한 적이 있다.

5.3 Software Requirements Specification (SRS, 소프트웨어 요구사항 명세서)

이 Specification 행위가 끝나면 나오는 산출물이 바로 SRS이다. 이 SRS는 다음의 행위를 하기 위한 기반으로 이용된다.

* 고객과 개발자와 계약에 사용된다. 대중에게 파는 제품을 만드는 경우에는 회사의 마케팅부서와 동의를 해야 한다. 제품에서 구현 할 것과 구현하지 않을 것을 명시한다.

(***필자주석) 여기서 무엇을 구현할 것을 적는 것은 당연한데 무엇을 구현하지 않겠다는 것이 생소해 보일 지 모르나 무척이나 중요하다. 개발외주 소송의 원인의 많은 부분을 차지하는 것이 무엇을 안 하겠다는 것을 계약서에 확실히 얘기하지 않았기 때문이다. 예를 들어 우리 제품은 "한글, 영어, 중국어를 지원한다"라고 적으면 정확한 의미를 전달하지 못한다. "한글, 영어, 중국어 외에는 어떤 언어도 절대 지원하지 않는다" 라고 적어야 조금은 더 정확한 의미를 전달할 수 있다. 이 문장만 해도 아직 더 자세히 적어야 할 것이 많지만 나중에 SRS 작성법을 가르치게 되면 그 때에 설명하기로 하고 이것은 가이드인 만큼 여기서 중단한다.

* 설계가 시작되기 전에 철저한 평가를 통해 나중에 재설계가 벌어지는 일을 줄인다.

(***필자주석) 분석과 설계를 대충하고 날코딩으로 들어갈 때의 문제가 바로 재설계와 재구현이다. 잘못된 관행을 고치는 방법도 모르고 관행적으로 그렇게 하고 있는 것이 불행한 현실이다. 열심히는 일하지만 비효율적이고 품질도 낮아진다.

* 검증(Validation)과 테스트(Verification)를 위한 목적으로 사용한다.

(***필자주석) 용어의 혼동을 피하기 위해 설명하자면 Validation은 무엇을 구현할 것인가를 검증하는 것이고 Verification은 구현하기로 약속한 것을 제대로 구현했는지를 검증하는 것이다. 즉 Validation은 스펙검토이고 Verification은 테스트이다.

* 소프트웨어 제품을 고객에게 설명하는 목적으로 사용한다.

(***필자주석) 이 문장이 너무 당연한 것처럼 보일지 모르나 이 원칙을 지키면서 SRS를 작성하는 경우를 국내에서는 본 적이 없다. 구체적으로 말하자면 SRS가 완성되면 개발자들은 개발을 시작하지만 마케팅 부서는 SRS를 기반으로 카탈로그도 만들고 언론기사도 작성하고 영업활동도 준비할 수 있다. 기술문서 부서는 SRS를 보고 사용자 매뉴얼을 작성하기 시작한다. 물론 완성하기 위해서는 화면 이미지와 같이 나중에 나오는 것도 있지만 대부분의 내용은 SRS에 나와 있다. 만약 발주자인 고객이라면 SRS를 보고 자기가 원하는 제품인지를 알 수 있어야 하고 나중에 분란의 소지가 전혀 없을 정도로 자세히 적혀야 한다. 그러니까 국내에서 통상적으로 벌어지는 현상인 개발한 다음에 보고 나서 이것 저것 고쳐 달라고 하는 것은 이 꼭지의 원칙을 지키지 않은 것이다. 단 한 줄의 원칙이지만 해야 할 일로 보면 지금 하고 있는 일의 몇 배의 일을 해야 할 지 모른다.

* 마지막으로 제품 향상을 위한 기반으로 사용된다.

(***필자주석) SRS는 항상 제품이 진화함에 따라 같이 진화한다. 새 제품이 나온다고 처음부터 SRS를 다시 적는 것은 잘못된 것이다. 제품과 소스코드와 SRS는 항상 같은 버전을 최신으로 유지해야 한다.

SRS는 보통은 자연언어(Natural Language)로 적는다. 하지만 정규식(Formal)이나 준정규식(Semi-Formal)을 이용한 설명이 보충되게 된다. 아키텍처의 설명이나 어떤 특정한 내용을 자세히 쉽게 설명하기 위해 필요한 적절한 표기법의 선택이 필요하기도 하다. 특정한 표기법이 좋다 나쁘다가 아니고 일반적인 원칙은 Requirements를 정확히 표현하는 표기법을 사용하라는 것이다. 안전 요구사항(Safety Requirements)이나 법규(Regulation)와 같이 외적인 요소가 치명적일 경우에 특히 정확하게 명시할 수 있어야 한다. 하지만 표기법 선택은 직원들의 교육 유무, 보유스킬, 작성자의 선호도, 검토할 사람들의 선호도에 따라 결정되기도 한다.

SRS를 프로젝트 비용, 인수조건, 성능, 일정, 재사용성 등의 수치를 측정하는 품질 지표(Quality Indicator)가 이미 개발되어 있다. 그리고 SRS에 적히는 각 문장의 품질을 측정하는 지표에는 꼭 할 것 (Imperative), 불충분한 문장, 선택적인 문장 등의 특성이 있다. 그리고 전체 SRS 문서의 품질을 측정하는 지표에는 문서의 양, 가독성, 명시화, 깊이, 문장 구조 등이 있다.

(***필자주석) 여기에서 말하는 품질지표(Quality Indicator)는 필자가 요구공학을 가르칠 때 채점을 하기 위한 항목이기도 한데 예를 들어 가독성만 해도 관련자들이 읽어서 쉽게 이해하지 못한다면 가독성이 낮은 것이다. 작성자만 이해하는 SRS는 잘 작성된 것이 아닌 것이다. 또 불충분한 문장의 경우에는 너무 많은 잘못된 경우가 있다. "빨리", "사용자 친화적", "안정적인" 이런 용어들은 모두 다 감점이 되는 용어들이며 SRS에서는 사용하면 안 되는 용어이다. 이런 용어들은 이전 단계인 고객요구사항 문서에서는 어느 정도 허용될 수도 있지만 SRS에서는 이런 용어를 변경해서 정량적으로 정확히 명시해야 한다.

이 꼭지까지 도출, 분석, 명시(즉 SRS를 작성)하는 가이드까지 설명했지만 현실적으로 작성할 수 있는 능력이 생길 수는 없다. 일단 여기서는 SRS가 자신이 생각하고 있던 것과는 다르다는 것 정도만 인식해도 많은 도움이 된다.

6. Requirements Validation (검증) - 다음 Post에서 다룬다
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

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

SWEBOK 해설 Software Requirements #5

(***필자주석) 이 꼭지는 "분석" 이라는 행위에 대한 설명인데 가장 핵심적인 행위인 "Specification(명시)"는 다음 꼭지에 있다. 지금까지 요구사항 도출도 하고 이 꼭지에서 분석을 한 다음에야 마지막 단계인 "Specification(명시)"를 한다. 도출, 분석, 명시란 단어가 다 비슷하게 들리는 이런 것들의 차이가 무엇인지는 사실 어느 정도 경험해 보기 전에는 이해하기가 어려울지 모른다. 진정한 이해를 위해서 경험이 있으면 좋겠지만 경험이 없어도 이해하고 행동할 수 있는 선각자들도 있으니 IEEE에서 SWEBOK을 출간했을 것이라고 믿는다. 필자는 SWEBOK을 읽으면서 그 동안의 경험을 회상하며 다시 한 번 정리를 할 수 있는 기회가 되었으니 SWEBOK의 가치를 가슴 깊이 느낀다.

SWEBOK에서도 말했지만 필자가 책이나 기사에서 수 없이 얘기한 "SRS는 기능명세서(Functional Specification)가 아니다" 라고 했음에도 불구하고 아직도 기능명세서가 SRS라고 착각하고 있는 독자들도 있다. "기능명세서는 작성할 필요가 없을지도 모르나 SRS는 꼭 작성해야 한다" 라고 말한다면 더 착각을 불러일으킬지 모르지만 나중에 SRS에 관한 것을 다 이해하고 나면 저절로 이해가 될 것이다. 하지만 지금은 이해는 가지 않더라도 앞 꼭지에서도 여러 번 설명했듯이 더 이상 착각은 하지 않았으면 하는 바램이다.

그리고 이 꼭지를 이해하기 위해서는 앞 꼭지들에서 언급한 기초적인 용어와 지식을 확실히 알고 있어야 한다. 앞 꼭지들을 소화하지 않고 이 꼭지를 이해한다는 것은 불가능하다. 아마도 실용가치 없는 표면적인 지식만 습득할 수 있을 뿐이다. 앞 꼭지들에서 소개된 많은 용어들이 나오니까 다시 한번 읽어 보는 것도 좋을 것이다. 필자도 SWEBOK을 여러 번 읽었지만 읽을 때마다 새로 느끼는 것이 있다. 그만큼 심오한 문서이다.

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

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

3. Requirement Elicitation (요구사항 도출)

4. Requirements Analysis (요구사항 분석)


이 꼭지는 요구사항의 분석(Analysis)를 하기 위해 필요한 프로세스를 설명하며 그 목적은 다음과 같다

* 요구사항들 간에 상충되는 부분을 발견하고 조율한다.

* 소프트웨어가 어떤 조직과 어떤 운영환경에서 사용되는 지에 대한 범위를 명확히 한다.

* 소프트웨어 요구사항을 추출하기 위해 상위의 시스템 요구사항을 자세히 명시한다.

(***필자주석) 대부분의 소프트웨어는 시스템의 일부분으로 동작된다. 예를 들어 휴대폰이나 자동차 등과 같이 하드웨어를 컨트롤하는 임베디드 소프트웨어뿐만 아니라 대부분의 소프트웨어는 알게 모르게 소프트웨어가 사용되는 전체 환경 즉 시스템이 요구하는 요구사항에 따라서 소프트웨어 요구사항이 나오게 된다. 그러기 위해서는 시스템 요구사항을 먼저 정확히 도출하는 것이 필수이다.

전통적으로 요구사항 분석(Requirements Analysis)은 구조분석방법(Structured Analysis Method)과 같은 구조적인 분석을 이용한 개념모델을 만드는 것이었다. 그런 구조분석방법으로 명시하는 것도 중요하지만 그 전에 상충되는 요구사항을 먼저 조율해야 하고 조율을 위한 요구사항 협상(Requirements Negotiation)시에 각 이해관계자의 손익관계를 계산하기 쉽도록 먼저 요구사항 분류(Requirements Classification)에 대한 설명을 하기로 한다.

결론적으로 요구사항은 다음 목적을 위해서 정확히 명시되도록 모든 노력을 기울여야 한다.

- 요구사항이 검증될 수 있어야 한다
- 실현가능성이 있다는 것을 증명할 수 있어야 한다
- 비용이 얼마나 들지를 측정할 수 있어야 한다

4.1 Requirements Classification (요구사항 분류)

요구사항은 다음과 같은 여러 가지 관점에서 분류되어야 한다.

* 요구사항이 기능요구사항(Functional Requirements)인가 비기능요구사항(Nonfunctional Requirements)인가? 이에 대한 설명은 앞 꼭지 1.3에서 설명되었다.

* 요구사항이 상위 시스템에서 명시된 것인가? 혹은 출현되는 특성(Emergent Properties. Section1.4 참조)인가? 혹은 이해관계자가 직접 명시한 요구사항인가?

(***필자주석) 근본적으로 요구사항은 직접적으로 명시한 것 외에도 아무도 말하지 않았지만 암묵적으로 생겨나는 것들이 있다. 그런 것들을 놓치지 않고 찾아내어 명시하는 것이 중요하다. 만약 누가 말한 것만을 적어서 요구사항이 완성될 수 있다면 타이피스트의 역할에 불과할 것이다. 경험이 많으면 많을 수록 그런 암묵적인 요구사항을 되도록 많이 적을 수 있다.

* 요구사항이 제품의 요구사항인가? 제품을 만들기 위한 프로세스에서 요구되는 사항인가? (Section 1.2 참조). 프로세스에서 요구되는 사항의 예에는 특정한 개발자가 개발하도록 계약에서 명시할 수도 있고 소프트웨어 공학 방법론을 명시할 수도 있고 특정한 표준기법을 준수하도록 결정할 수도 있다.

(***필자주석) 실제로 UML을 사용하기로 결정했더라도 EA를 사용할 지 랩소디를 사용할 지와 같이 도구의 선호도는 다를 수가 있고 생산성에 영향을 끼친다. 혹은 java를 사용할 지 C++을 사용할지도 마찬가지이다.

* 요구사항의 우선 순위(Priority)를 정한다. 소프트웨어를 만드는 목적에 가깝게 부합할수록 우선 순위가 높다. 우선 순위를 분류하는 방법의 한 예로는 필수 사항, 매우 중요, 중요, 선택사항 등으로 분류하는 방법도 있다. 우선순위는 제품의 기능으로서의 중요성 뿐 아니라 개발비용을 고려해서 균형 있게 평가되어야 한다.

* 요구사항의 범위(Scope of requirements) - 어떤 요구사항이 영향을 미치는 범위를 의미한다. 어떤 비기능요구사항은 Global Scope로서 전체 소프트웨어에 영향을 미치고 모든 컴포넌트에서 그 사항을 고려하여야 한다. 반면에 어떤 요구사항은 일부 컴포넌트에만 영향을 미친다. Global Scope는 소프트웨어의 아키텍처에 지대한 영향을 미치고 그에 따라 모든 하위 컴포넌트의 설계가 결정된다. 반면에 부분적인 범위(Narrow Scope)의 요구사항은 소수의 컴포넌트 설계에만 영향을 미친다.

* 요구사항의 변동성과 안정성 (Volatility/Stability) - 어떤 요구사항은 소프트웨어의 생명주기가 끝날때까지 계속 변해 간다. 심지어는 개발하는 중간에도 변하는 경우도 있다. 이런 요구사항이 미래에 변동할 가능성에 대한 예측을 어느 정도 할 수 있어야 한다. 예를 들어 금융권 전산 시스템에서 "예금이자를 지급해야 한다"는 요구사항은 "어떤 금융상품이 면세상품이다"를 결정하는 것보다는 훨씬 변할 확률이 적을 것이다. 이자는 금융권의 근원적인 기반이기 때문에 변하지 않는다고 가정해도 되지만 면세인 금융상품은 정부의 정책에 따라 수시로 변할 수 있다. 이런 가정에 따라 미래의 변화를 적용할 수 있도록 컴포넌트를 미리 인식하고 설계를 유연하게 해야 한다.

요구사항 지식영역(KA)의 마지만 부분인 Section 7.3 에서 Requirements Attributes(요구사항 특성)을 다루는데 요구사항 분류와 중복되는 부분이 있으니 참조하기 바란다.


4.2 Conceptual Modeling (개념모델)

소프트웨어가 해결하려고 하는 실제 세상의 문제를 모델로 만드는 것이 요구사항 분석의 핵심이다. 개념모델의 목적은 해결하려는 문제가 무엇이고 해결책이 무엇인지를 이해하는데 도움을 주는데 있다. 이 꼭지는 Software Engineering Models and Methods 지식영역과 밀접한 관계가 있다.

다음과 같은 여러 종류의 개념 모델 방식이 사용될 수 있다.
- 유스케이스 다이어그램 (Use-case Diagram)
- 데이터 흐름도 모델(Data Flow Model),
- 상태모델(State Model),
- 목표지향 모델 (Goal-based Model),
- 사용자관계 모델(User Interaction Model),
- 객체지향 모델(Object Model),
- 데이터 모델
- 등등

이 중에 많은 모델은 UML (Unified Modeling Language) 표기법 중의 일부분이기도 하다. 특히 유스케이스 다이어그램은 통상적으로 내부의 구조와는 상관 없이 행위자(Actor, 즉 사용자일 수도 있고 외부의 시스템일 수도 있다)의 유스케이스로 시스템의 기능을 외부의 관점에서 묘사하는 것이 가능할 때 흔히 사용된다. 이런 모델링 표기법의 선택은 다음과 같은 요소를 고려하여 결정된다.

* 문제의 본질 - 어떤 소프트웨어는 엄청난 분석 작업을 요구하기도 한다. 예를 들어 SysML의 방식 중의 하나인 "상태 파라미터 모델"(State and Parametric Model)은 정보시스템(Information System) 관련 소프트웨어보다는 실시간 소프트웨어에 적합하다. 이와 정 반대되는 시스템에서는 객체(Object) 다이어그램이나 액티비티(Activity) 다이어그램이 통상적으로 사용된다.

(***필자주석) 현실에서 가장 어려운 결정은 어떤 다이어그램을 사용할 것인가 하는 결정이다. 모든 다이어그램을 작성하는 것은 가장 나쁜 결정이다. 많은 중복이 생기고 시간 낭비이기 때문이다. 이 결정은 논리보다는 경험에 의한 통찰력이 우선인 인간 고유의 영역이다. 이런 영역에서 방법론에서 열거한 모든 다이어그램을 만든다는 것은 소프트웨어 공학의 목표와는 정 반대인 최악의 결정이다.

* 소프트웨어 개발자의 전문성 - 개발자가 익숙한 모델링 표기법을 사용하는 것이 개발 생산성이 높다는 것을 고려해야 한다.

* 고객의 프로세스 요구사항 (1.2 Product and Process Requirements 참조) - 고객이 자기들이 이해하기 쉬운 표기법으로 개발하도록 요구할 수 있다. 이 요구사항은 당연히 바로 위의 개발자들이 익숙한 표기법과 상충될 수 있다.

어떤 표기법을 사용하든 소프트웨어 전체를 이해할 수 있는 콘텍스트(Context)을 묘사하는 것이 중요하다. 소프트웨어 콘텍스트는 개발하려는 소프트웨어와 그 소프트웨어가 작동되는 외부환경과의 인터페이스를 보여주는 것이 핵심이다. 이 꼭지는 어떤 특정한 표기법을 가르쳐 주는 것인 목적이 아니고 모델링의 의도와 목적에 대한 가이드를 하는 데 있다.

(***필자주석) 모델링 표기법은 UML도 계속 버전이 바뀌면서 변경되어 왔고 SysML이 나오기도 하고 계속 변화하기 때문에 어떤 특정한 표기법이 최선이라고 할 수가 없다. 위의 상황에 따라 적절한 표기법을 사용하는 것이 최선이다. 국내에서는 UML이 거의 정답으로 생각할 정도로 편중되어 있지만 다른 표기법이 더 유용하다면 그럴 필요는 없다. UML도 만능이 아니고 표현 능력에 한계가 있다. 그냥 하나의 표기법일 뿐이니 생각의 폭을 넓히기 바란다.

4.3 Architectural Design and Requirements Allocation (아키텍처 설계와 요구사항 할당)

개발의 어느 시점인가에 아키텍처가 만들어져야 한다. 요구사항 단계에서의 아키텍처 설계는 소프트웨어 설계 단계와 중복되는 부분인데 분석과 설계 단계를 깨끗하게 나눈다는 것은 현실적으로 불가능하다. 즉 아키텍처는 요구사항 분석 때 시작해서 설계 단계에서 마무리 한다. 이 꼭지는 당연히 소프트웨어 설계 지식영역과 밀접히 관련되어 있다.

소프트웨어 분석가는 소프트웨어 설계자로서의 역할도 해야 한다. 요구사항을 분석하고 상세히 명시하는 과정에서 이 요구사항들을 구현할 수 있는 아키텍처가 만들어 져야 한다. 어떤 컴포넌트에 할당된 요구사항을 만족시키기 위해 설계를 하다 보면 다른 컴포넌트와의 인터페이스를 더 자세히 추가적으로 생각하게 되고 그런 과정을 계속 지나다 보면 분석 작업의 완성도가 높아지는 결과를 얻는다.

대규모의 프로젝트에서는 이런 하나의 컴포넌트에 부과된 요구사항들에 따라 구조 설계를 하다 보면 모든 하위 시스템의 분석을 다시 되풀이하게 하는 상황을 만든다. 자동차 브레이크의 예를 들어보자. 브레이크의 요구사항에는 제동거리, 열악한 환경에서의 안전성, 부드러운 제동, 페달 압력 등이 있고 이런 요구사항들이 ABS(Antilock Braking System) 시스템에 요구된다고 하자. 이런 ABS에 대한 소프트웨어 기능과 요구사항이 정해진 다음에야 자동차의 무게와 브레이크에 사용될 하드웨어 등 파생되는 요구사항들이 결정될 수 있다.

4.4 Requirements Negotiation (요구사항 협상)

"협상"이라는 용어는 여기서는 "상충점 해결(Conflict Resolution)" 과 같다. 여러 이해관계자들 사이의 상충되는 문제를 해결하는 것을 의미한다. 상충되는 문제에는 기능요구사항, 비기능요구사항, 자원 등이 있다. 개발자가 일방적인 결정을 하는 것은 현명하지 않고 각 이해관계자들과 의논하여 동의를 구하거나 적절한 조율점을 찾아야 한다. 대부분의 경우 이런 결정들이 최종 고객이 원하는 것인지를 항상 확인하는 것이 계약상 문제를 일으키지 않기 위해 중요하다. 요구사항 분석이 진행됨에 따라 새로운 문제가 계속 발생하고 기존의 요구사항이 변하는 상황이 계속된다. 이런 변화에 따른 소프트웨어 검증에 대한 이슈도 계속 따라온다.

요구사항 우선순위 결정은 단순히 중요한 사항이 무엇인지를 인지하는 것으로써가 아니라 단계적인 출시를 할 경우에 어떤 요구사항을 포함할지를 계획하고 상충되는 문제를 미리 해결하기 위해서 사용하는 것이 중요하다. 이를 위해서는 산업 도메인 지식, 정확한 개발기간 측정역량에 기반한 복잡한 결정 역량이 필요하다. 현실에서는 이를 위한 정확한 데이터를 얻기가 어려운 것이 문제이다.

요구사항은 독립적인 것이 아니고 서로 영향을 주는 경우가 많다. 현실에서는 분석가가 모든 요구사항을 다 알지 못하는 상태에서 요구사항의 우선순위를 결정하는 잘못을 저지르기도 한다. 우선순위의 결정에는 "비용과 가치" 의 상대적인 분석을 해야 하는데 이는 모든 이해관계자에게 주는 혜택과 구현하지 않았을 때 발생하는 불이익에 대한 평가를 할 수 있어야 한다. 이는 모든 요구사항의 개발에 드는 비용을 다 분석하고 비교해야 한다는 것을 의미한다.

또 다른 우선순위 결정 방법으로는 "계층분석 프로세스" 로서 모든 기능을 2개씩 비교해서 어느 것이 얼마나 더 중요한지를 선발해 내는 방식도 있다.

(***필자주석) 여기에서 글로 설명한 것 보다 현실에서 우선순위를 정하는 것은 무척이나 어렵다. 어떤 기능을 안 만들면 다른 기능이 자동적으로 의미가 없어지는 의존적인 경우와 같이 상관관계가 복잡하게 나타난다. 비용측정도 어렵고 안 했을 때의 피해측정도 어렵고 우선순위 결정은 결국 아무리 많은 데이터를 수집하더라도 대부분은 통찰력에 의한 결정이 된다.

4.5 Formal Analysis (형태적 분석)

(***필자주석) 이 부분은 정확한 의미로 번역하기가 어렵지만 이해를 돕기 위해 미리 설명을 하자면 프로그래밍 언어와 같이 정해진 공식을 이용해서 요구사항을 표현하는 방법을 말한다. 대부분의 소프트웨어 개발의 경우는 이런 방법을 사용하지 않지만 State Machine 과 같이 특수한 경우에는 이런 방식이 유용할 수도 있다. 일단 번역은 하지만 이 꼭지는 상대적으로 덜 중요한 주제이니 가볍게 넘어가는 것을 권장한다.

형태적 분석은 후반부 꼭지인 5.3과 6.3과도 관련되어 있다. 또 다른 지식영역인 Formal Method in Software Engineering Models and Methods Knowledge Area 와도 관련되어 있다.

형태적 분석은 일체성이 높은 특수한 소프트웨어의 경우에 많은 영향을 끼쳤다. 요구사항의 형태적인 표현은 규칙을 가진 언어(Semantic Language)로 표현한다는 것을 의미한다. 그런 형태적인 표현은 두 가지 혜택이 있다. 첫째, 요구사항을 애매모호하지 않게 표현하여 잘못 이해하는 경우를 없앤다. 둘째, 논리적으로 검증하기가 쉽다. 형태적 표현은 그를 분석할 수 있는 도구를 필요로 하며 두 종류의 도구가 있다. "정리 증명기(Theorem Provers)"와 "모델 검증기(Model Checker)" 가 있다. 하지만 이런 도구조차도 100% 자동으로 검증할 수 있는 방법은 없다. 그래서 형태적 분석 방법을 유용하게 사용할 수 있는 소프트웨어는 매우 제한적이다.

그래서 형태적 분석은 요구사항 분석의 후반부에 사용하는데 초점을 둔다. 분석 초기에는 아직 비즈니스 목표나 사용자 요구사항도 정해지지 않은 상태에서 형태적 분석을 사용한다는 것은 매우 비생산적이다. 그러나 일단 모든 요구사항이 안정적으로 정해지고 상세히 설명되어 있다면 일부분의 핵심 요구사항은 형태적 분석을 사용하는 것이 좋을 수도 있다.

5. Requirements Specification (명시) - 다음 Post에서 다룬다

6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

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

SWEBOK 해설 Software Requirements #4

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

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

3. Requirement Elicitation (요구사항 도출)

(***필자주석) 먼저 시작하기 전에 국내의 프로젝트 발주과정의 하나인 RFP(Request For Proposal, 제안요청서)와 비교해 보자. 지금 이 요구사항 도출 단계가 지나면 말 그대로 요구사항이 도출될 것이다. 그럼 이 요구사항이 도출된 다음에 RFP가 나가야 할까 아니면 그 전에 나가야 할까? 요구사항 도출단계 전에 나가야 한다면 추상적이고 큼직큼직한 희망사항 정도 적힐 수 밖에 없다. 국내의 RFP는 대부분 이 정도 수준에 속한다. 요구사항을 도출하는 것도 많은 시간과 비용이 들기 때문에 계약을 하기 전에 그런 비용을 지불할 개발업체는 없다. 과거 유사한 프로젝트에 사용했던 문서를 하루 밤새거나 며칠 정도 걸려 수정해서 만들어 내는 경우가 대부분이다.

그러니까 결국 요구사항 도출의 행위도 계약이 끝난 다음에 하게 될 테고 그러다 보면 그 다음 단계인 Software Requirements Specification(SRS)는 계약도 이미 다 끝난 마당에 더욱 더 제대로 적을 이유도 없다. 결국 대부분의 프로젝트는 "요구사항 도출" 마저도 계약이 체결된 후이기 때문에 제대로 작성하려는 동기가 없다. 이런 상황에서 SRS가 제대로 적히길 바란다는 것은 어떻게 보면 망상이다.

그러나 전세계 개발방법론들은 기본적으로 SRS를 만드는 과정이 존재하고 계약상 제출해야 하는 의무가 있으니 제출용 문서를 작성하기는 한다. 대부분은 프로젝트가 종료되기 바로 전에 만든다. 개발에 도움이 되지 않는 문서를 제출용으로 만든다는 것은 시간낭비이고 불행한 일이다. 건물 다 지어 놓고 설계도를 만드는 것과 같다.

요구사항 도출은 요구사항의 출처가 무엇인가와 소프트웨어 엔지니어가 어떻게 요구사항을 수집하는가에 관한 주제를 다룬다. 요구사항 도출은 소프트웨어가 해결하려고 하는 문제에 대한 이해를 하기 시작하는 가장 최초 단계이다. 이것은 전적으로 인간이 하는 행위이다. 이해관계자(Stakeholder)가 인식되고 개발자와 고객과의 관계가 설정되는 단계이다. 요구사항 도출은 다른 용어로 "Requirement capture(요구사항 포착)" 혹은 "Requirement Discovery(요구사항 발견)" 혹은 "Requirement Acquisition(요구사항 수집)"이라는 용어를 사용하기도 한다. 요구사항 도출을 잘 하기 위한 가장 기본적이고 중요한 원칙은 다양한 이해관계자들 사이의 적절한 커뮤니케이션이다., 이 커뮤니케이션은 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)동안 계속된다. SDLC의 여러 단계에서 다른 종류의 이해관계자들이 관련된다. 분석책임자(Requirement Specialist)는 개발이 시작되기 전에 이 이해관계자들 사이의 커뮤니케이션 채널을 위한 연결고리를 미리 만들어 두어야 한다. 크게 도메인 전문가들과 기술 전문가들 사이의 중재를 해야 하는 것은 필수이다.

(***필자주석) 요구사항 도출은 전적으로 인간이 하는 행위라고 적혀 있다. 물론 문서편집기등 도구는 사용하겠지만 근본적으로 인간의 결정이 수시로 필요한 창조적인 영역이다. 즉 Doors와 같은 요구사항 작성도구나 표준 템플릿에다 내용만 적기만 하겠다는 생각이 얼마나 한심한 생각인지를 알 수 있을 것이다. 개발자들이 스스로의 가치를 비하하는 잘못된 생각이다.

요구사항 도출의 가장 중요한 요소는 프로젝트의 범위를 모두에게 인식시키는 것이다. 이를 위해 개발하려고 하는 소프트웨어의 목적과 기능의 우선순위를 명시하여 고객이 원하는 중요한 기능이 먼저 만족되도록 항상 명심해야 한다. 그럼으로써 분석책임자가 낮은 우선순위의 기능에 쓸데없이 시간을 낭비하거나 필요도 없는 기능을 개발하지 않도록 해야 한다. 또 다른 한편으로는 초기 단계에서는 명시되지 않는 기능들을 나중에 수용할 수 있도록 확장성 있게 요구사항들을 표현해야 한다.

(***필자주석) 나중에 여러 템플릿을 보면 알겠지만 SRS의 초반부는 소프트웨어를 왜 개발하려는 가에 관한 목적과 비지니스 전략에 관한 내용들이다. 왜 개발하는지를 알아야 무엇을 개발할 내용이 결정되는 것이다.

3.1 Requirements Sources (요구사항 출처)

요구사항은 많은 출처로부터 온다. 그런 모든 출처를 하나도 빠짐 없이 밝혀야 하고 정보를 받아야 한다. 다음과 같은 다양한 출처를 인식하고 그들을 관리해야 한다.

* Goal(목적) - 목적은 "Business Concern(사업의 관심)" 혹은 "Critical Success Factor(핵심성공요소)" 라고 하기도 하는데 상위수준의 목표를 의미한다. 그러다 보니 개발을 위한 동기부여를 하기도 하지만 애매모호하게 적히기도 한다. 소프트웨어 개발자들은 이 애매모호함 속에서 개발할 가치가 있는 것을 알아 내고 개발비용의 산정을 할 수 있게 많은 노력을 기울여야 한다. Feasibility Study(실현성조사)가 이런 결정을 하기 위해 사용하는 저렴한 방법이다.

(***필자주석) 실현성조사가 아무리 저렴하다고 해도 시간적으로 모든 기능의 실현성을 조사해 볼 수는 없는 것이 현실이다. 되도록 해보지 않고 결정할 수 있는 역량이 중요하다. 리스크관리 중의 하나가 해보지 않은 기능을 관리하는 것이다. 그래서 경험자의 통찰력이 필수이다.

* Domain Knowledge(도메인 지식) - 소프트웨어 개발자는 제품 도메인에 대한 지식을 습득하거나 가지고 있어야 한다. 도메인 지식은 요구사항이 도출되면서 전체적으로 이해되기 쉽게 도와준다.

(***필자주석) 필자의 저서에서 소프트웨어 개발자로서 도메인과 소프트웨어 기술의 비율에 대한 설명을 20:80 정도라고 했다. 도메인 전문가가 따로 있고 개발 전문가가 다르니 개발자가 도메인 전문가가 되기 위해 너무 많은 비중을 투입하는 것은 옳지 않다.

* Stakeholder(이해관계자) - 앞 꼭지에서 "Process Actor((행위자)" 라고 했었다. 많은 소프트웨어들이 불만족스럽게 만들어 진 이유가 한 그룹의 이해관계자들의 목소리를 다른 그룹을 희생하면서 들어주기 때문이었다. 그렇게 만들어진 제품은 사용하기 어렵거나 고객의 문화나 고객의 회사구조를 뒤엎어야 하는 경우가 생긴다. 그러므로 소프트웨어 개발자는 여러 이해관계자의 관점(Viewpoints)을 인식하고, 그들을 모두 대표할 수 있어야 하고, 관리해야 한다.

* Business Rules (비지니스 규칙) - 비지니스가 운영되는 규칙에 대한 내용이다. 예를 들면 대학교의 학과등록 소프트웨어를 개발한다면 "학생은 등록금을 내지 않으면 코스를 등록할 수 없다" 와 같은 규칙을 말한다.

* Operational Environment (운영환경) - 소프트웨어가 운영되는 환경으로부터도 요구사항이 도출된다. 예를 들어 실시간 시스템에서는 타이밍(Timing)에 관한 제약사항이 있을 수 있고 비지니스 영역에서는 정보처리량이나 대응시간과 같은 성능 문제가 있을 수 있다. 이 요구사항은 실현가능성의 문제가 있을 수도 있고 개발비용이나 설계 구조에 큰 영향을 미칠 수 있기 때문에 능동적으로 찾아내야 하는 중요한 정보이다.

* The Organizational Environment (조직 환경) - 소프트웨어는 비지니스 프로세스를 구현하기도 한다. 비지니스 프로세스는 고객의 회사구조, 문화, 내부정책에 따라 달라진다. 개발자는 이런 점을 민감하게 인식하고 있어야 하고 새로운 소프트웨어가 이런 고객 환경을 강제로 변경해야지만 작동할 수 있도록 만들면 안 된다.


3.2 Elicitation Techniques (도출 기법)

요구사항 출처가 모두 알려지면 소프트웨어 개발자는 요구사항 도출을 시작할 수 있다. 명심해야 할 것은 요구사항은 이미 만들어져 있어서 가서 주워오기만 하면 되는 완성품이 아니다. 대부분은 개발자가 여러 정보를 종합해서 요구사항을 조립해 내야 한다. 이 꼭지에서는 이해관계자인 인간이 요구사항에 관련된 정보를 표현하도록 유도하는 기법을 다룬다. 이것은 매우 어려운 작업이다. 개발자는 이해관계자들이 자신들이 원하는 것을 잘 표현하는 능력이 없다는 것을 잘 인지하고 있어야 한다. 그들은 중요한 사항들을 빼먹기도 하고 비협조적이기도 하고 협조할 능력 조차가 없을 수도 있다.

요구사항 도출 행위는 수동적인 행위가 아니고 심지어는 매우 협조적인 이해관계자들에게서 조차 정확한 정보를 얻어내기 위해서도 매우 열심히 일해야 한다. 많은 비지니스 정보나 기술 정보들은 암묵적 정보라서 너무 당연해 보이기 때문에 얘기를 해주지 않는다. 혹은 고객으로부터 제품을 주고 피드백을 얻기 전까지는 알 수 없는 정보도 많다. 그러므로 요구사항 도출을 위한 사전계획, 확인과 검증은 매우 중요하다. 많은 도출 기법들이 존재하는데 다음과 같은 방법들이 있다.

* 인터뷰 - 가장 전통적인 방법인 이해관계자들과의 인터뷰인데 장점과 단점이 있다는 것을 이해하고 인터뷰를 어떻게 진행할 지를 잘 계획하고 있어야 한다.

* 시나리오 작성 - 시나리오는 요구사항에 대한 전후 사정과 전체 맥락을 이해하는데 좋은 방법이다. 이 방법은 개발자들이 "혹시 이런 경우라면" 이나 "이렇게 되는 건가요" 와 같은 질문을 던지고 확인할 수 있게 도와준다. 가장 통상적인 방법은 유스케이스(Use Case) 를 이용한 표현방식이다. 요즈음에는 이 방식이 가장 많이 사용되고 있다.

* 프로토타입 - 이 방식은 애매모호함을 없애는 가장 좋은 방법이다. 여러가지 방법이 있는데 종이에다가 화면 시나리오를 그린 Paper Mockup(종이 모형)도 있고, 베타 버전을 사용할 수도 있고 여러가지 방법을 여러 단계에서 적절히 중복해서 사용할 수도 있다. 통상적으로 너무 자세하지 않게 대충 만든 모델 (Low Fidelity Model)을 사용하는 것이 좋다. 그 이유는 너무 자세하게 적어서 유연성을 없애고 설계에 제약이 가해지는 경우가 있다.

(***필자주석) UI에서 너무 자세하게 명시함으로서 설계나 구현 방식을 몇 배 어렵게 만드는 경우를 자주 보았다. 중요한 것은 사용자가 편하고 목적을 성취하면 되는 것이지 구체적인 방법을 미리 명시할 필요는 없다. 구현방법은 개발자에게 자유롭게 맡겨놓음으로써 개발의 효율성을 높이고 비용과 일정을 절감할 수 있다.

* 그룹 회의(Facilitated Meeting) - 이 회의의 목적은 종합적인 내용을 정하는 것이다. 한 개인이 정할 수 없는 경우에 여러 명의 이해관계자들이 모여서 좋은 의견을 낼 수 있다. 또 중요한 것은 상충되는 요구사항들이 이 방법으로 모든 이해관계자들에게 초기에 노출되도록 하는 것이다. 이 방법이 잘 이용되면 일관성 있고 깊이 있는 여러 요구사항들의 집합이 도출되는 것도 장점이다. 하지만 그룹회의는 중재자의 지휘아래 매우 조심스럽게 진행되어야 한다. 목소리 큰 그룹이나 직위가 높은 이해관계자의 주장이 받아들여지고 다른 이해관계자는 무시될 수가 있는 것이 조심해야 할 사항이다.

* 관찰 (Observation) - 실제 운영환경에서 소프트웨어를 어떻게 사용하고 주위의 어떤 자원과 교류하고 소통하는지를 개발자가 옆에서 구경하면서 관찰하는 기법이다. 이 방식은 비용이 많이 드는 반면에 말로 설명하기 어렵거나 보기 전에는 감지하기 어려운 비지니스 프로세스 등을 알아내는 데는 효과적이다.

* 사용자 이야기 (User Stories) - 이 방식은 애자일 방법론과 같이 단계적인 개발 방법론에서 많이 사용된다. 주로 사용자 수준의 상위 요구사항을 간단하게 고객의 용어를 이용하여 설명한다. 통상적인 문장은 "이런 "역할" 로 이런 "혜택"을 얻기 위해 "무엇"을 하기 원한다." 와 같은 방식으로 적힌다. 사용자 이야기는 개발자가 개발하는 비용을 측정할 수 있을 만큼만 최소한의 정보만을 적는 것이 좋다. 잘못 사용되면 너무 많은 자세한 정보를 초기 단계에서 받고 나서 나중에 쓸모 없이 되거나 수정해야 하는 경우이다. 이 방법은 도출 초기 단계에 사용하는 것이고 구현단계에 가기 전에는 자세한 수준의 내용이 적혀져야 한다.

* 나머지 기법들 - 다른 많은 기법들이 존재한다. 경쟁사 제품 분석도 있고 데이터 마이닝 기법도 있고 고객이 요청한 기능목록 등 다양한 출처가 있을 수 있다.

(***필자주석) 위에서 나열한 여러 방법들을 이용하여 요구사항을 도출했다고 하자. 이 시점에서 저지르는 가장 빈번하고 치명적인 실수는 이제 코딩을 시작할 만큼 내용을 안다 라고 착각하는 것이다. 실제로 여기서 도출한 내용을 버젓이 SRS라고 부르기도 한다는 것이다. 혹은 기능명세서 또는 요구사항 명세서라고 부리기도 한다. 큰 착각이다. 절대 SRS가 아니다. SRS를 작성하려면 지금까지 작성한 문서 양의 몇 배를 작성해야 한다. 아마 10배의 양을 작성해야 할지도 모른다. 이제 시작에 불과한데 마치 끝났다고 착각할 수 있는 것을 조심해야 한다.

4. Requirements Analysis (분석) - 다음 Post에서 다룬다
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

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

SWEBOK 해설 -  Software Requirements #3

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

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

2. Requirement Process (요구사항 프로세스)

(***필자주석) 이 블로그를 가끔 가다 읽는 독자를 위해 이 쯤에서 다시 한번 Software Requirements Specification (SRS)라는 용어를 살펴보자. SRS는 Software Requirements를 Specify 한 문서이다. 즉 Requirements와 Specification이 다르다는 것을 의미한다. 달라도 엄청 다르다. 양적으로 10배 100배의 차이가 나기도 한다. 하여튼 일단은 Requirements를 잘 수집해야 Specification을 잘 적을 수 있다는 것은 상식적이다. 이 꼭지는 Requirements 프로세스에 대한 주제를 다룬다. 아직까지 Specification에 관한 내용은 전혀 다루지 않았다. Specification은 Requirements를 도출한 다음에 다른 꼭지에서 다루게 된다.

독자들이 만약에 이 꼭지가 잘 이해가 안되거나 한다면 전혀 걱정하지 말고 그냥 넘어가라고 하고 싶다. 프로세스에 관련된 영역은 사실 꽤 높은 수준에 오른 사람들이 효율적으로 운영할 수 있는 영역이다. 이해를 하더라도 실행을 하기는 어려운 영역이다.

이 토픽에서는 "1장 소프트웨어 요구사항" 의 나머지 5개 토픽에 대한 소개와 요구사항 프로세스가 전체 소프트웨어 공학 프로세스와 어떻게 연관되어 돌아가는 지를 보여준다.

2.1 Process Model (프로세스 모델)

프로세스 모델은 요구사항 프로세스에 대한 다음 3가지 특성을 이해하도록 돕는다.

• 1. 요구사항 프로세스는 소프트웨어 생명주기의 앞 쪽에만 존재하는 분리된 단계가 아니다. 대신 프로젝트의 출발과 함께 시작되어서 생명주기가 끝날 때까지 계속 수정되면서 정제되는 행위이다.


• 2. 요구사항은 버전관리되어야 하는 형상의 하나로서 소프트웨어 생명주기의 모든 단계에서 나오는 다른 산출물(형상)과 마찬가지로 똑같은 방식으로 관리되어야 한다.


• 3. 회사와 프로젝트의 종류에 따라 다르게 적용되어야 한다.

(***필자주석) 여기에 매우 심오한 문장이 들어 있다. 1번에서 생명주기가 끝날 때까지 계속 수정된다는 얘기인데 이 말을 잘못 이해하면 그야말로 주먹구구식으로 개발하면서 SWEBOK을 따라 했다고 우겨댈 수 있는 위험한 문장이다. 이 말은 폭포수 모델(Waterfall Model)을 극단적으로 해석해서 한 번 적으면 절대로 변하지 않는다는 극단론자들에 대한 조언 정도로 받아들이면 될 것이다. 즉 한 번 적힌 요구사항은 변하지 않는다는 이상적인 폭포수 모델은 이 세상에 존재하지 않는다고 보는 것이 옳다. 그렇더라도 국내에서는 "요구사항은 절대 변하면 안 된다" 라고 해석하는 것이 옳다. 국내에서 그런 기준에서 수행해도 실리콘밸리에서 "자주 변할 수 있다" 라는 기준에서 작성할 때보다도 더 많은 양이 변하게 될 것이다. "변한다" 는 문장에서 국내와 실리콘밸리의 기준이 다르기 때문이다. "SWEBOK에서 요구사항이 변경될 수 있다고 했다" 라고 주장한다면 국내에서는 작성하다 만 문서가 난무할 것이고 소프트웨어공학과는 전혀 상관없는 행위가 될 것이다.

2번은 형상관리라는 용어를 소스코드의 버전관리 정도의 좁은 의미로 잘못 사용하는 경우를 국내에서 많이 봤는데 형상은 이 세상의 모든 실체는 형상이다. 여기서는 요구사항 한개 한개가 형상이고 소스코드는 파일 하나 하나가 형상이고 테스트 케이스도 형상이고 SRS 문서 전체도 하나로서의 형상이다. 이런 모든 형상은 베이스라인이라고 하는 어떤 기준선에 따라서 독립된 세트로 관리를 하는 것이 형상관리이다. 나중에 형상관리 KA 꼭지에서 나오겠지만 형상관리도 다 한다고 하지만 진정으로 정교하게 형상관리를 하는 회사는 국내에서 대기업을 포함해서 거의 볼 수 없었다.

3번은 필자에게 가장 많이 들어오는 요청인 "샘플과 템플릿을 보여주세요" 라는 말이 왜 별로 도움이 안 되는 지를 말해주는 문장이다. 어떤 사람이 시금치를 먹고 건강해 졌다고 내가 따라 하면 안 된다. 원칙에 따라 내 몸에 맞게 적용해야 하는 것이 소프트웨어 공학의 기본이고 모든 템플릿은 시작일 뿐이고 원칙을 이해 못한 상태에서는 피해만 준다. 샘플 역시 마찬가지이다. 건강의 원칙을 모르는 상태에서 시금치를 먹는 것은 득보다는 실이 많을 것이다. 더 이상 필자에게 템플릿이나 샘플을 달라는 요청이 없는 시대가 빨리 오기를 기대해 본다. 어차피 템플릿은 인터넷에 많고 다 동일한 내용을 포함하고 있다.

요구사항의 후반부 꼭지인 Elicitation(도출), Analysis (분석), Specification (명시), Validation (검증)에 있어서 프로젝트의 중요에 따라 모두 다른 모양으로 설정되고 수행된다. 또 마케팅 부서의 요구사항이나 구현가능성에 대한 정보를 요구사항 프로세스에 제공한다.

(***필자주석) 필자가 가장 많이 받는 질문 중의 하나가 "코딩을 해 보기 전에는 기능이 가능한 건지 알 수가 없다" 이다 . 이럴 때는 먼저 프로토타입을 만들어 보는 것이다. 그렇다고 모든 것을 만들어 보면 절대 안 된다. 경영자가 빨리 결정하기 위해서는 일단 그럴 시간이 없다. 결국 심각한 기능의 경우에는 미리 검증해 볼 수도 있지만 프로젝트는 어느 정도의 리스크를 가지고 시작할 수 밖에 없는 것이 현실이다. 그래서 리스크관리가 프로젝트 관리에서 필수적인 행위이다. 사실이 이런데도 프로젝트를 수행하면서 리스크관리를 전혀 하지 않는 경우도 많이 보았다. 리스크는 어느 프로젝트이든 존재하는데 존재자체를 인지하지 못하고 있다는 것은 리스크가 매우 크다는 것을 의미한다.

2.2 Process Actors (프로세스 행위자)
행위자는 요구사항 프로세스에 참여하는 모든 이해관계자들이다. 이 프로세스는 근본적으로 상호규제적인 특성을 가진 프로세스이기 때문에 이해관계자(Stakeholder)들과 소프트웨어 개발자들 사이에 조율을 필요로 한다. 요구사항 분석전문가(Requirements Specialist) 뿐만이 아니라 관련하는 많은 사람들이 소프트웨어에 대해 작건 크건 어떤 부분에 대해 주장할 권리가 있다. 이런 이해관계자들의 종류는 프로젝트에 따라 다르지만 사용자와 고객(사용자와 항상 같지 않음)은 항상 포함된다. 일반적으로 다음과 같은 이해관계자들이 있다.

• 1. Users (사용자) - 소프트웨어를 직접 사용하는 그룹인데 그 중에서도 다양한 역할이 있다.


• 2. Customers (고객) - 소프트웨어의 개발을 요청하거나 타겟 시장을 대표하는 사람들이다.


• 3. Market Analysts (시장분석가) - 일반 다수 대중을 목표로 하는 시장에서는 요청하는 고객이 없고 회사의 마케팅 조직이 고객을 대신해서 시장의 요구를 만들어 낸다


• 4. Regulators (규제기관) - 금융이나 대중교통과 같은 분야의 소프트웨어는 규제의 대상이 되고 규제기관의 요구를 준수해야 한다.


• 5. Software Engineers (개발자) - 개발자들은 당연히 소프트웨어를 효율적으로 개발하기 위해 과거의 컴포넌트를 재사용한다든지 하는 효율성의 이해관계가 있다. 어떤 프로젝트의 경우에는 개발자들의 재사용 요구사항이 다른 고객의 요구사항들보다 더 비중이 클 수도 있다. 또 어떤 특수한 요구사항의 경우에는 개발자들의 기술력에 따라 개발비용이나 출시일정에 큰 영향을 줄 수도 있다. 이런 모든 다양한 요구사항이 식별되어야 한다.

모든 이해관계자들의 요구사항을 만족시키는 것은 불가능하다. 그렇기 때문에 이들 사이에서 조율을 해야 하는 것이 개발자의 역할이다. 예산, 기술력, 정부규제등 모든 제약조건 아래서 모든 핵심 이해관계자들 에게 수용 가능한 균형 잡힌 결론을 이끌어 내야 하는 것이다. 이를 위한 전제 조건은 모든 이해관계자가 식별되어야 하고 각 이해 관계자들의 "관심이해사항"이 분석되어야 하고 그에 따른 요구사항이 도출되어야 한다.

(***필자주석) SWEBOK 저자들은 "모든 이해관계자들의 요구사항을 만족시키는 것은 불가능하다" 라는 문장에서 "will not be possible" 이라고 했다. 가능한 경우가 있다면 "may not be possible" 이라고 해야 할 텐데 모든 이해관계자들이 모두 만족하는 경우는 없다는 것을 의미하고 필자의 경험으로 봐서도 100% 공감한다. 필자의 책에서도 말했듯이 "모든 고객을 만족시키려고 하는 것은 100% 실패하는 방법이다" 라고 빌 크로스비도 말했다. 상용제품의 경우에는 모든 사람들을 만족시키겠다는 그럴듯한 패러다임에 현혹되어 프로젝트가 진행이 안 되는 경우를 많이 보았다. 반대로 SI 프로젝트의 경우에는 절대 양보하지 않는 상충되는 두 이해관계자들 사이에서 조율에 어려움을 겪는 경우도 많이 보았다. 다 자기 욕심을 조금도 버리지 않으려고 하다가 모두가 손해 보는 시나리오로 가는 경우이다.

하지만 말이 쉽지 조율이라는 것이 보통 어려운 일이 아니고 책으로 가르칠 수 있는 것도 아니고 경험이 필요한 진정한 소프트웨어 공학의 영역이다. 그래서 분석작업, 즉 Software Requirements Specification을 작성하는 일이 어려운 것이고 가장 최고의 개발자만이 할 수 있는 일이다.

이런 어려운 일을 템플릿이나 채우면 된다고 생각한다면 망상에 불과하다.

2.3 Process Support and Management (프로세스 지원과 관리)
이 토픽은 요구사항 프로세스에 필요한 자원의 관리에 대한 영역이다. 프로세스에서 벌어지는 활동과 비용, 인적자원, 교육, 도구와의 연결고리를 만드는 것이 목표이다.

(***필자주석) 역시 간략하게 표현했지만 관리영역인 만큼 행위와 자원을 적절히 연결하고 관리해야 한다. 관리가 어렵다기 보다는 무엇을 관리해야 할지를 도출하는 것이 훨씬 더 어려운 영역이다. 즉 무슨 도구를 사용해야 할 지, 누가 SRS를 작성할 지 등을 결정하는 것부터 시작해서 인간이 결정해야 하는 많은 사항들이 있다.

2.4 Process Quality and Improvement (프로세스 품질과 개선)

이 토픽은 요구사항 프로세스의 품질과 개선에 대한 측정이다. 즉 소프트웨어 개발 비용과 기간 그리고 고객의 만족도의 관점에서 요구사항 프로세스가 해야 하는 핵심 역할을 강조 한다. 프로세스 품질과 개선에 도움이 되게 처음부터 방향을 정해준다. 프로세스 품질과 개선은 뒤에 나오는 Software Quality KA(소프트웨어 품질 지식영역)와 Software Engineering Process(소프트웨어 공학 프로세스)와 밀접하게 연관되어 있다. 다음과 같은 주제를 다룬다.

• - 프로세스 개선과 표준 모델에 제안하는 요구사항 프로세스 적용범위


• - 요구사항 프로세스의 측정과 벤치마킹


• - 개선 계획과 수행


• - 보안관련 개선 계획과 수행

(***필자주석) 프로세스라는 용어가 기본적으로 매우 추상적인 용어라서 구체화 하기 전에는 경험자가 아니면 상상하기가 어렵다. 프로세스 개선이라고 하는 행위는 CMMI나 SPICE와 같이 한국 업체들이 한 때 열심히 적용하려고 했던 분야이다. 프로세스에 관한 수행은 먼저 프로세스의 각 단계에 해당되는 행위를 충분히 수행할 수 있는 수준이 되었을 때 전체적인 프로세스를 개선한다든지 하는 의미가 있다. 각 단계도 제대로 못하는 상황에서는 프로세스가 도움보다는 피해를 준다. SWEBOK의 저자들은 독자들이 어느 정도 수준에 있다고 가정하고 프로세스에 대한 토픽을 얘기할 지 모르나 필자가 보는 국내 소프트웨어 회사에서는 먼저 SRS를 어느 정도 작성할 수 있는 능력이 있고 나서 프로세스에 대한 고려를 해보는 것이 좋다.

즉 내용이 중요한가 프로세스가 중요한가에 대한 이슈인데 예를 들면 음식을 만들지도 못하는데 담을 그릇을 걱정할 필요는 없다. 요리학원도 다니고 음식을 만들 수 있는 상태가 되면 음식에 맞는 그릇을 사면 된다. 그런 면에서 SWEBOK은 각 수준의 사람들이 각 수준에서 이해할 수 있는 용어들이 있고 또 받아드려야 하는 행위들이 있다. 수준이 향상됨에 따라 다시 읽게 되면 공감하는 부분이 계속 있을 것이다.

3. Requirement Elicitation (요구사항 도출) - 다음 Post에서 다룬다

4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)