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