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