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 (도구)
댓글 없음:
댓글 쓰기