SWEBOK - 소프트웨어 요구사항 #7

SWEBOK 해설 Software Requirements #7

(***필자주석) 지금까지 요구사항의 도출, 분석을 지나 명시(Specification) 했다. 이제는 내가 명시한 것이 맞는 것인지를 어떻게 증명하는 검증단계에 왔다. 여기서 대충 넘어가면 재앙이 벌어진다. 바로 소프트웨어공학의 1:10:100 법칙에 따른 피해가 벌어진다. 이 단계를 게을리 하면 잘못된 정보를 가지고 다음 단계인 설계를 열심히 하게 된다. 잘못 명시된 요구사항을 설계 단계에서 발견하면 그나마 다행히도 10배의 피해만 입게 된다. 즉 오류를 수정하는 데 들어가는 비용이 10배가 든다. 그 다음 단계인 코딩 단계에서 발견되면 100배의 비용이 들어 간다. 테스트 단계에서 발견되면 1000배의 비용이 들어간다.

쉽게 이해하려면 건축을 생각하면 된다. 건물을 설계단계의 종이에서 고칠 때와 다 만들어 놓고 고칠 때를 상상해 보면 된다. 이론으로 아는 사람은 많지만 실제 벌어지는 국내 프로젝트에서는 똑같은 시행착오를 지금까지 일이십년을 반복해 오고 있다. 그 이유에는 수십가지가 있지만 모두 다 잘못된 핑계에 불과하다. 필자의 책에서도 누누이 얘기하지만 고쳐지지는 않는다. 유일하게 키움증권의 차세대 프로젝트가 제대로 된 SRS를 작성하고 필자가 아는 한 국내에서 처음으로 제 일정에 완성한 프로젝트였다. 필자의 주장을 증명한 케이스이기도 하다. 이에 관해 지디넷(zdnet)에 실린 기사이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140728162641&type=xml

지금까지의 국내 관행대로 똑같은 방법으로 진행한 프로젝트는 모두 일정연기라는 똑같은 결과를 가져왔고 필자의 주장대로 수행한 유일한 프로젝트는 성공했다. 사실은 필자의 주장이 아니라 IEEE의 전문가들 혹은 실리콘밸리의 회사들의 평범한 관행일 뿐이다. 기본을 무시하고는 어떤 것도 잘 될 수는 없다는 것을 보여준다. 건축, 자동차, 전자, 소프트웨어나 모두 다 같다.

앞 단계의 명시단계에서 오류를 범했더라도 아직도 늦지 않았다. 아직은 종이 서류에 불과하고 공사는 시작하지 않았으니 피해 없이 고칠 수 있는 마지막 기회다.

1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)

작성된 요구사항 문서(SRS)는 검증(Validation)과 테스트(Verification)을 해야 한다. 즉 작성한 소프트웨어 엔지니어가 요구사항을 제대로 이해했다는 것을 검증해야 한다. 더 나아가 문서가 회사의 표준에 맞게 작성되어 있고, 이해할 수 있고, 일관성 있고, 완성도 있게 작성되었다는 것을 검증하는 것도 중요하다. 회사의 표준 용어가 외부의 표준 용어와 다르게 사용된다면 그 두 용어 사이의 매핑 테이블을 만들어야 한다. 이런 점에서 누구나 다 이해하는 표준인 공식적인 표기법(Formal Notation)의 방식을 이용해서 작성했다면 매핑 테이블 같은 것을 만들지 않아도 되는 장점이 있다. 고객과 개발자 등을 포함한 모든 이해관계자들이 문서를 검토해야 한다. 이 문서는 소프트웨어 생명주기에 나오는 모든 산출물(설계문서, 소스코드등) 과 동일한 수준으로 그리고 동일한 방법으로 형상관리를 해야 한다. 요구사항관리도구를 이용해서 요구사항 문서를 만드는 경우에도 마찬가지의 형상관리를 해야 한다.

(***필자주석) 형상관리를 소스코드 관리로 한정해서 생각하는 개발자들이 많지만 사실은 요구사항문서(SRS)가 소스코드만큼 중요하기 때문에 철저한 형상관리(여기서는 버전관리를 의미) 해야 한다. 하지만 대부분의 국내 프로젝트는 SRS는 버전관리를 할 만큼 정확하게 적히지도 않고 소스코드와 내용이 일치되지도 않기 때문에 버전관리를 하나 안하나 의미가 없다. SWEBOK에서 말하는 SRS를 형상관리하라는 말은 글로벌 수준의 회사를 기준으로 말하는 것이고 그렇지 않은 회사는 형상관리 하느라 노력한 대가도 없고 그냥 관리비용만 늘어가니 국내에서는 적당히 형식적으로만 하면 될 것이다. 항상 그렇지만 내용이 충실하면 관리가 중요해 지지만 내용이 부실하면 관리를 해도 의미가 없다. 그냥 형식적인 회사 프로세스에서 형상관리를 요구한다면 역시 형식적으로 흉내만 내면 된다. 그래서 기초가 부족한 상태에서 프로세스를 도입한다고 해야 시간과 비용만 들고 피해만 입는다.

적어도 한 번 이상의 검증을 해야 하고 그 검증을 위한 회의 일정을 공식적으로 미리 정해 놓고 하는 것이 정상이다. 근본적인 목적은 개발자원이 투입되기 전에 문제가 있는 지를 찾아내는 것이다. 다시 말하지만 검증(Validation)은 요구사항문서가 우리가 원하는 소프트웨어를 정확하게 제대로 정의했는지를 조사하는 것이다.

(***필자주석) SRS는 필자의 경험으로 Full Review를 적어도 2번 이상은 해야 한다. 한 번에 통과한다는 것은 기적이다. 아직까지 한 번도 본 적이 없다. 가장 잘 적은 경우의 시나리오는 한 번 검토하고, 검토한 결과에 따라 수정하고, 두 번 째 회의에 모여 모든 이해관계자가 승인해 주는 경우이다. 두 번에 통과하기도 매우 어렵다. 여기서 통과하느냐 마느냐 하는 것도 SRS 내용을 자세히 적었을 때 어려운 것이다. 차라리 내용이 대충 추상적으로 제목 정도만 적혀 있으면 통과하기는 쉽다. 대충 적힌 문서는 시비를 걸기 어렵기 때문이다. 나중에 문제가 생겨서 그렇지 일단 SRS는 통과한다. 나중에 수백 배의 피해를 입는 조삼모사이다. 국내 기준으로 보면 RFP 혹은 기획서 정도의 내용이 적힌 문서가 계약에서 통과된다. 그런 것을 SRS 검증이라고 얘기 할 수는 없다. 결국 진정한 SRS는 한 번도 검증되지 않은 상태에서 설계나 코딩이 벌어지게 되는 것이 국내 현실이다. SWEBOK이 가정한 개발 환경과 실제 국내 환경과는 갭이 크니 그걸 감안해서 잘 해석해야 한다.

6.1 Requirement Review (요구사항 검토)

검증에서 가장 많이 사용되는 방법은 조사(Inspection) 혹은 검토(Review)이다. 여러 명의 검토자 들에게 오류, 잘못된 가정, 불명확한 설명, 비표준적인 내용 등을 찾도록 부탁한다. 검토자 그룹의 멤버가 중요한데 예를 들어 적어도 한 명의 고객대표가 참석해야 한다. 검토하기 쉽도록 체크리스트 같은 가이드가 도움이 되기도 한다. 통상적으로 검토는 시스템 정의서 (System Definition), 시스템 사양서(System Specification), SRS(Software Requirements Specification) 이 완성된 다음에 진행된다.

(***필자주석) SWEBOK에서 체크리스트가 있으면 도움이 될지도 모른다고 했는데 이 부분을 잘못 해석하면 체크리스트에 있는 Yes/No 형식의 답을 한다고 생각하면 오산이다. 체크리스트가 제공해 주는 것은 검토를 해야 할 주제를 혹시라도 빼먹지 않도록 하는 것이지 검토 자체를 도와주는 것이 아니다. 예를 들어 "문서의 가독성"을 검토해야 하는데 Yes/No 로 대답한다면 잘못된 것이다. 체크리스트는 올바른 검토를 하기 위해 필요한 가이드이지 체크리스트가 없어서 검토를 못하는 것도 아니고 체크리스트가 있다고 해도 검토를 제대로 하는 것은 더군다나 아니다. 여행 준비물 체크리스트 정도의 의미라고 생각하면 된다. 필자에게 템플릿과 체크리스트를 보여달라고 하는 개발자들이 많은데 검증의 품질과는 거의 관계가 없다는 것을 알기 바란다.

6.2 Prototyping (프로토타이핑)

프로토타이핑은 개발자가 어떻게 사양을 이해했는가를 검증하는 방법이다. 겸사겸사 눈에 잘 보이니 새로운 요구를 추가하기 쉽기도 하다. 요구사항 도출(Elicitation) 때와 마찬가지로 프로토타입이 효율적으로 사용될 수 있는 부분이 있다. 프로토타입의 장점은 개발자가 어떻게 이해했는가를 볼 수 있는 가장 좋은 방법이고 동시에 무엇이 잘못되었는지를 발견하고 의견을 주기에도 적합하다. 동적인 유저인터페이스를 글로 설명하기는 어렵운 반면에 동적인 애니메이션이 훨씬 더 잘 설명할 수 있다. 프로토타입으로 검증된 요구사항이 수정될 가능성은 매우 낮은 것이 장점이다. 안전요구사항이나 중요한 핵심적인 기능들은 프로토타이핑을 해보는 것이 중요하다. 하지만 프로토타이핑의 단점도 있다. 사용자들이 미적인 이슈에 사로 잡혀 진정한 기능을 게을리 볼 수 있는 위험성도 있고 프로토타이핑의 품질이 나쁘다는 데 있다. 그래서 프로토타이핑 보다는 시나리오북 (Flip-chart based mockup) 같은 방식을 선호하기도 한다. 프로토타입은 개발비용이 많이 든다. 그렇더라도 나중에 잘못된 소프트웨어를 개발하는 것보다는 프로토타이핑을 하는 것이 좋을 수도 있다. 만약 프로토타입이 최종 제품과 비슷한 모습을 가지고 있다면 꼭 버릴 필요는 없다.

(***필자주석) SWEBOK에서 프로토타이핑한 결과를 100% 버려야 한다고 주장할 수는 없는 상황이기 때문에 프로토타입을 실제 제품에 사용할 수도 있다고 하지만 필자의 경험으로는 프로토타입은 버리는 것이 옳다. 프로토타입은 가장 신속히 개발해서 SRS를 검증하는 것이 목표이기 때문에 한가하게 아키텍처 생각하고, 주석 달고, 공통코드 추출하고, 에러처리하고, 등등 할 시간이 없다. 그런 코드를 나중에 그대로 써 먹는다는 것은 얻는 것보다 잃는 것이 많다. 물론 프로토타입에 사용한 코드의 일부분을 사용하는 것은 문제가 없지만 프로토타입은 말 그대로 모형이다. 아파트 모델하우스를 고쳐서 실제 살 집을 만들지 않는 것과 같이 프로토타입은 100% 버린다고 생각해라.

6.3 Model Validation (모델 검증)

분석과정 중에 모델 기법을 사용했다면 모델의 품질을 검증하는 것이 필요하다. 예를 들어 객체모델(Object Model)인 경우 정적 분석(Static Analysis)을 통해 객체간에 어떤 데이터가 움직이는 지와 같은 것을 검증할 수 있다. 만약 공식표기법(Formal Notation)이 사용되었다면 공식적인 로직에 기반한 검증방법을 사용하는 것이 가능하다. 이 부분은 Software Engineering Models and Methods KA 와 밀접하게 관련되어 있다.

(***필자주석) 이 꼭지는 대부분의 독자는 건너 뛰어도 된다고 생각한다. 그 이유는 통상적인 SRS에서는 설계의 상위부분을 다루게 되는데 그럴 경우에 Modeling 기법도 사용하고 Formal Notation도 도입할 수 있는데 국내에서는 SRS 단계에서 그 정도까지 생각하는 경우가 거의 없기 때문에 이 꼭지는 거의 의미가 없다. 모델링은 설계단계에서 수행하는 것이라는 흑백논리의 오류인 것이다. 이 점은 앞 단계에서도 이미 언급되었지만 분석이나 설계단계에서 할 일이 흑백논리로 정해지는 것이 아니고 경우에 따라 원칙을 잘 적용하는 것이 실용주의인 소프트웨어공학을 잘하는 것이다.

6.4 Acceptance Tests (인수 테스트)

소프트웨어 요구사항의 필수적인 단계는 개발이 요구사항에 적힌 그대로 개발이 완료되었냐는 것을 확인하는 것이다. 확인될 수 없는 요구사항은 희망사항(Wishes)에 불과하다. 그러므로 확인하기 위해서 꼭 필요한 일은 어떻게 확인할(Verify) 지를 계획하는 것이다. 대부분의 경우에 인수테스트(Acceptance Test)를 사용한다.

(***필자주석) 확인(Verify)하기 위해서는 확인할 대상이 정확이 명시되어 있어야 한다. 확인할 대상이 대충 적혀 있다면 확인을 아무리 잘한다고 한들 의미가 없다. 그래서 필자가 책에서도 말했지만 세계적인 테스트팀이 와도 SRS가 잘 적혀있지 않다면 소프트웨어 품질이 좋아지지 않는다고 하는 이유이다. 하여튼 일단 테스트를 잘 하는 것은 일부라도 품질을 높이기 위해서는 중요하다. 근래 많이 사용하는 테스트 방법론인 V-Model 혹은 V-testing model을 보면 인수테스트 외에도 많은 종류의 테스트가 있다. 확실한 것은 SRS에 대응되는 테스트는 인수테스트이고 인수테스트가 바로 계약에 사용되는 문서이다. 다른 테스트는 계약에 필요한 것이 아니고 개발을 진행하면서 중간에 필요한 테스트들이다. 고객에게 약속한 최종사양은 인수테스트에서 모두 명시되어야 하고 인수테스트만 통과하면 계약은 종료된다.

인수테스트를 도출하고 설계하는 것이 비기능요구사항 (Nonfunctional Requirements) 의 경우에 매우 어렵다. 검증이 가능하려면 먼저 충분히 분석되고 작은 컴포넌트로 나누어지고 숫자적으로 표현될 수 있어야 한다. Software Testing KA 에서 인수테스트에 관한 추가정보를 얻을 수 있다.

(***필자주석) SRS를 적성할 때 요구사항 종류에는 기능요구사항과 비기능요구사항이 있는데 비기능요구사항은 생각해 내기도 쉽지 않다. 생각해 내기도 어려운 데 테스트 하기도 어렵다. 특히 초보자들은 잘 모르니까 "빨리" "사용하기 용이한" 등 추상적인 용어를 사용하게 된다. 그런 용어는 SRS를 적을 때 절대 사용하면 안 되는 감점요인이다. 그리고 프로젝트 실패 중에서도 큰 실패의 원인은 대부분 비기능요구사항의 부족에서 발생한다. 조금이라도 비기능요구사항의 완성도를 높이기 위해서는 많은 실무 경험이 있어야 한다. 비기능요구사항은 템플릿이나 체크리스트조차 만들기 어렵다. 비싼 상용도구를 사용하더라도 도움이 될 수준까지 자세히 가르쳐 줄 수가 없다. 그러다 보니 국내 대부분의 프로젝트는 아예 비기능요구사항을 적지도 않고 진행하기도 한다. 하여튼 비기능요구사항을 충분히 자세히 적을 수 있다면 이미 글로벌 개발 역량을 가지고 있는 것이다. 즉 SWEBOK을 읽을 것이 아니라 SWEBOK을 작성할 수 있는 수준일 것이다. 그만큼 어려운 것이 비기능요구사항의 작성이다.

7. Practical Considerations (현실적인 고려사항) - 다음 Post에서 다룬다

8. Software Requirements Tools (도구)