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 (도구)