SWEBOK 해설 - Software Requirements #2
1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
1.1 Definition of a Software Requirements (소프트웨어 요구사항의 정의)
기본적으로 Software Requirements는 현실에서 어떤 문제를 해결하기 위해 묘사되는 특성(Property)이다. 해결하려고 하는 문제는 기업의 비지니스 프로세스일 수도 있고, 기존 제품의 개선일 수도 있고, 기구의 컨트롤 시스템일 수도 있고 수 많은 문제들이 있다. 인간 사용자나 비지니스 프로세스나 기구나 대체적으로 동작하는 방식은 복잡하다. 요구사항이라는 것은 소프트웨어가 동작하는 방식에 연관되어 있는 다양한 수준의 사람들이 요구하는 모든 기능들이 고려되는 복잡한 집합체이다.
(***필자주석) 모든 이해관계자들이 요구하는 기능을 다 집어넣는 다는 것은 가장 나쁜 요구사항 작성법이다. 바로 Kitchen Sink라고 말하는 쓰레기 통이다. 요구사항 작성이 어려운 것은 이 모든 이해 관계자들을 조율해서 가장 현실적인 제품을 만들어 내는 것이다.
Software Requirements의 필연적인 특성은 기능으로서나 혹은 시스템에 부과되는 비기능요구사항으로서나 각각 하나씩 독립적으로 검증될 수 있어야 한다는 것이다. 이런 검증은 매우 어렵거나 많은 비용이 들 가능성이 있다. 예를 들어 Call Center의 요구사항을 테스트하기 위해서는 시뮬레이션 프로그램을 개발해야 할지도 모른다. 소프트웨어 요구사항 작성자나 테스트계획이나 품질검증부서는 현실적으로 가능한 자원의 한도 내에서 모든 요구사항이 검증될 수 있다는 것을 보장해야 한다.
또 요구사항은 제한적인 자원과 프로젝트의 트레이드오프를 선택할 수 있도록 우선순위를 명시해야 하는 특성을 가지고 있다.
(***필자주석) 요구사항 작성시 우선순위의 명시는 필수이다. 보통 저지르는 실수는 전부 다 중요하다고 적은 것이다. 그렇게 하려면 적을 필요도 없다. 항상 일정과 자원과 기능의 상충되는 목표를 조율하기 위해서는 모든 기능의 우선순위를 적절히 배분해서 명시해야 한다. 그래서 여러 이해관계자들 사이에서 조율이 필요하다. Kitchen Sink는 최악의 요구사항이라는 것을 인식해 놓기 바란다. 버릴 고객은 과감히 버려야 한다.
1.2 Product and Process Requirements (제품요구사항과 프로세스 요구사항)
제품요구사항은 개발하려고 하는 소프트웨어 제품의 기능이나 제약에 관한 것이다. 반면에 프로세스 요구사항은 소프트웨어를 개발하는 과정에서 부과되는 제약사항들이다. 예를 들어 "이 소프트웨어는 RUP 프로세스 방식을 이용해서 개발할 것이다" 와 같은 것들이다. 혹은 Java를 이용한다와 같은 것들이다.
어떤 소프트웨어는 암묵적인 프로세스 요구사항을 가지고 있다. 예를 들어 테스팅의 경우 특수한 테스팅 기계가 필요할 수도 있고 국방부 프로젝트와 같이 공식적인 문서작성 방식을 따라야 하는 경우도 있다. 프로세스 요구사항은 개발조직에서 자체적으로 설정할 수도 있고, 고객이 설정할 수도 있고 안전검증기관과 같이 국가기관에서 설정할 수도 있듯이 다양한 요구자가 있다.
1.3 Functional and Nonfunctional Requirements (기능요구사항과 비기능요구사항)
기능요구사항은 소프트웨어가 실행하는 기능(Function)을 묘사한다. 보통 기능(Capability) 혹은 특성(Feature) 이라고 알려져 있다. 테스팅 관점에서는 제품 동작을 검증하기 위해서 유한한 테스팅 단계에 의해 검증이 가능한 단위를 의미한다.
(***필자주석) 테스트 케이스의 설명으로 요구사항을 정의할 수 있다는 것이 바로 Agile 방법론 중의 하나이다. 어차피 요구사항과 테스트 케이스가 일대일 매핑이 가능하다면 같은 기능을 두 번 명시하는 것은 중복이라고 할 수 있다. 즉 테스트의 자세한 설명으로 내가 무엇을 개발할지 확실히 알 수 있는 제품이라면 당연히 요구사항을 추가로 적을 필요는 없다. 하지만 그런 제품은 많지 않다는 것이다. 예를 들어 사용자의 관점에서 테스트를 할 수 있는 홈페이지 같은 것들은 숨어있는 로직이 별로 없기 때문에 테스트 케이스를 작성하나 요구사항을 작성하나 큰 차이가 없다. 이럴 경우는 선택의 문제라고 할 수 있다. 정상적인 경우는 요구사항은 요구사항 방식으로 적는 것이 99%의 경우에 해당한다고 보면 된다. 또 요구사항 대신에 테스트 케이스를 적는다고 하더라도 요구사항 작성역량이 있는 상태에서 결정하는 것이 옳다. 기본도 되어 있지 않은 상태에서 테스트 케이스로 요구사항을 대신한다는 것은 매우 위험한 일이다.
비기능요구사항은 제품에 기능 외에 제약사항이 있다는 것을 의미한다. 용어로는 제약요구사항 (Constraint Requirements) 혹은 특성요구사항 (Quality Requirements)이라고 한다. 더 자세하게 나누면 성능요구사항 (Performance Requirements), 유지보수요구사항 (Maintainability Requirements), 안전요구사항(Safety Requirements), 상호운영성성요구사항 (Interoperability Requirements) 등 많은 비기능적인 요구사항들을 의미한다.
(***필자주석) 현실적으로 이 비기능요구사항이 기능요구사항에 비해 작성하기 훨씬 어려운 부분이다. 난이도로 볼 때 10배 이상 어렵다고 볼 수 있다. 그만큼 기능요구사항을 적을 때 보다 훨씬 더 많은 경험이 필요한 분야이다. 템플릿에도 자세한 설명이 나와 있지도 않고 가르쳐 줄 수도 없다. 원칙을 이해하고 상상력을 동원해 적어야 하는 부분이다. 제품의 심각한 문제는 주로 이 비기능요구사항의 부족함에서 생긴다. 소프트웨어 개발에서의 큰 소송은 발주자와 개발자의 커뮤니케이션의 오해에서 생기는데 기능요구사항보다는 비기능요구사항에서 문제가 될 확률이 훨씬 높다. 이 문제는 교육이나 강의로 가르쳐 줄 수 있는 문제가 아니고 같이 일하면서 경험을 쌓으면서 커가는 역량이다.
1.4 Emergent Properties (출현특성)
이 특성은 어느 하나의 컴포넌트에서 나오는 요구사항이 아닌 여러 개의 컴포넌트의 상호작용에 의해 출현되는 요구사항이다. 예를 들어 Call Center에서 얼마나 많은 전화를 응대할 수 있는가 하는 것은 전화 중계기, 전산 시스템, 그리고 전화응대 직원이 현실 상황에서 어떻게 상호작용하는 것에 의해서 결정된다. 이 출현특성은 시스템 아키텍처에서 매우 중요하게 고려되는 요소이다.
(***필자주석) 순수 소프트웨어만을 개발하는 경우라면 소프트웨어 아키텍처만 걱정하면 되겠지만 많은 소프트웨어는 하드웨어 시스템과 같이 연관되어 있다. 그게 소프트웨어 역사에서의 최초 사용도이기도 했다. 바로 임베디드 시스템이다. 그러므로 소프트웨어 요구사항을 작성한다고 하면 많은 경우에 시스템 요구사항과 시스템 아키텍처가 상위수준에서 우선적으로 명시되게 되어 있다. 앞으로도 이 차이점에 대해 뒷부분 여기저기서 나오겠지만 일단은 생각하는 방식과 작성하는 방식은 하드웨어나 소프트웨어나 동일하다는 것을 인식해 놓기 바란다.
1.5 Quantifiable Requirements (정량적인 요구사항)
소프트웨어 요구사항은 명확하게 (Clearly) 그리고 애매모호하지 않게(Unambiguously) 명시되어야 한다. 그리고 가능한 한 정량적으로 명시되어야 한다. "대충" 그리고 "검증할 수 없게" 적는 것은 피해야 한다. 사람마다 다르게 해석되는 대표적인 용어의 예가 "신뢰할 만한" 그리고 "사용자에게 친숙한" 과 같은 용어이다. 정량적인 요구사항은 특히 비기능요구사항의 경우에 중요하다. Call Center의 경우에 정량적으로 비기능요구사항을 명시한 예를 보면 "시간당 처리량(Throughput)이 현재보다 20% 증가해야 하고 치명적인 오류는 시간당 1 * 10**(-8) 보다 작게 발생해야 한다"이다. 이 상위수준의 정량적 요구사항에 따라서 하위 컴포넌트에게 많은 자세한 요구사항이 생겨날테고 또 시스템 어키텍처에 많은 제약을 가하게 될 것이다.
(***필자주석) 정량적으로 적는다는 것이 생각보다는 훨씬 어렵다. 잘 적을 수 있다면 이미 글로벌 분석가 수준이다. 대부분의 초보자들의 핑계는 해보지 않고 어떻게 숫자를 얘기할 수 있느냐고 한다. 해보지 않고도 알 수 있는 방법은 과거의 경험으로 유추하거나 현재의 환경에서 미래를 시뮬레이션 해서 상상해야 하는 매우 어려운 지식산업의 영역이다. 그리고 통찰력도 필요하다. 이 부분을 잘 명시할 수 없다면 외국에서는 계약이 성립되지도 않거니와 운이 좋아 계약을 했다고 해도 100% 소송의 대상이다. 계약의 기쁨이 악몽으로 변하는 지름길이기도 하다. 국내 소프트웨어 SI 업체와의 계약을 보면 이 부분이 매우 취약하다.
1.6 System Requirements and Software Requirements (시스템요구사항과 소프트웨어요구사항)
"시스템"은 International Council on Software and Systems Engineering(INCOSE)에서 다음과 같이 정의된다.
시스템은 원하는 목적을 위해 상호작용해야 하는 모든 요소들의 집합이다. 즉 하드웨어, 소프트웨어, 펌웨어, 사람, 데이터 정보, 조작기술, 시설, 서비스 등 모든 지원시설이다.
시스템요구사항은 시스템 전체에게 부과되는 요구사항이다. 소프트웨어를 포함하는 시스템에서는 당연히 시스템요구사항으로부터 소프트웨어요구사항이 파생되어 나오게 된다. 한편으로는 사용자요구사항(User Requirements)은 고객이나 최종 사용자의 입장에서 정의된다. 반면에 시스템요구사항은 사용자요구사항과 같이 사용자의 관점에서만 본 시스템이 아닌 정부의 규제 조항이나 안전요구사항과 같은 모든 요구사항을 의미한다.
(***필자주석) 시스템요구사항과 소프트웨어 요구사항은 앞으로도 계속 혼란을 가져오는 이슈이므로 조금이라도 빨리 확실한 이해를 해 두는 것이 중요하다. 근본적으로 생각하는 방식은 같지만 생각할 대상이 시스템에서는 광범위하므로 소프트웨어 만의 경험으로는 작성하기 어려운 것은 사실이다. 산업 도메인 지식도 있어야 하고 하드웨어나 경우에 따라 펌웨어에 대한 기본 이해는 하고 있어야 한다.
2. Requirement Process (요구사항 프로세스) - 다음 Post에서 다룬다
댓글 없음:
댓글 쓰기