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

SWEBOK 해설 Software Requirements #8

(***필자주석) 앞 포스트에서 인수테스트라는 얘기를 했다. 인수테스트를 작성해야 한다는 것은 소프트웨어 공학에서 많이 들었기 때문에 반론의 여지가 없겠지만 언제 작성하는지가 핵심이다. 지금까지 한국의 소프트웨어 회사에서 한번도 본 적이 없는 것이 인수테스트를 가지고 계약하는 것이다. 계약 시에 인수테스트를 충분히 적을 만큼 요구사항이 자세히 나와 있지도 않거니와 설령 나와 있다고 해도 계약을 위해 인수테스트를 작성한다는 생각을 하지 않을 것이다. 인수테스트를 어느 시점에 작성할 수 있는 역량과 현실에서 언제 작성하는가의 이슈는 다르다. SRS 와 함께 완성할 수 있는 역량이 있다면 언제든지 원하는 시점에 완성할 수 있다. 필자가 실리콘밸리에서 록히드와 계약을 하고 개발을 해주었을 때 SRS보다 더 중요한 것이 인수테스트였다. SRS의 내용은 다르게 해석할 여지가 조금 남아 있지만 인수테스트는 100% 통과해야지만 계약을 준수하는 것이다. 하나라도 통과하지 못하면 계약위반이다. 반대로 인수테스트만 통과하면 계약은 종료된다.

물론 실리콘밸리의 회사가 모든 계약에서 이렇게 하는 것은 물론 아니다. 하지만 그렇게 해야 될 때는 그렇게 한다. 할 수 있는 역량은 있지만 필요에 따라 하기도 하고 안하기도 한다. SRS를 잘 적을 수 있어야만 가능하다. 특히 국방부나 원자력발전소와 같이 대규모의 정교하고 안정된 소프트웨어를 개발할 때 중요해진다. 국내에서는 거의 모든 대규모의 프로젝트가 지연된다. 대규모 프로젝트일수록 인수테스트가 중요해지는데 SRS도 정확하지 않은 상태에서 계약시에 인수테스트를 작성한다는 것은 불가능하다.

역량과 이론과 현실의 삼각 관계에서 어떤 선택을 해야 하는가는 항상 어려운 이슈이다. 무모한 동키호테가 될 수도 있고 이론의 늪 속에 빠져 버릴 수도 있다. 하여튼 이론에서는 인수테스트가 SRS 같이 나와야 하지만 여러 가지 이유로 그렇지 않은 경우가 훨씬 많다. 이 쪽지의 주제가 바로 이론과 다를 수 있는 현실적인 고려사항이다. 현실에서는 고려해야 사항들도 이론과 마찬가지로 중요하다.

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

이 전체 챕터의 제목인 "요구사항 지식영역"에서 지금까지 진행한 소제목들이 순서적으로 진행하는 것처럼 보이지만 그것은 편의상 단순하게 나열한 순서일 뿐이다. 요구사항은 전체 소프트웨어 생명주기에 관계된다. 미래에 개발될 제품을 위한 요구사항을 위한 변경 관리와 이미 개발된 제품에 대한 요구사항의 유지의 두 가지가 소프트웨어 공학 프로세스의 성공의 핵심이다.

모든 회사가 요구사항을 작성하고 유지하는 문화를 가지고 있는 것은 아니다. 특히 제품에 목숨을 걸고 한정된 자원 밖에 없는 역동적인 신생기업의 경우 이런 문서작업을 불필요한 오버헤드라고 생각하는 것이 통상적이다. 하지만 이런 회사들이 성장하고 고객이 늘고 제품이 진화함에 따라 과거의 요구사항에 대한 내용을 파악함으로써 미래를 위한 변경에 따른 영향과 파급효과를 이해할 수 있다. 그래서 요구사항문서와 변경관리는 성공적인 요구사항 관리 프로세스에서 핵심적인 역할을 한다.

(***필자주석) 요구사항의 문서가 없이 제품만 가지고 있는 경우는 사상누각과 같다. 더 이상 발전할 수가 없고 기존 제품만 유지보수 하는 것이 최선의 결과이다. 마치 빌딩을 지었는데 설계문서가 없는 것과 같다. 과거의 기억을 되살리면서 겨우 유지보수는 하겠지만 더 큰 빌딩을 지으라고 하면 머리의 기억만으로 지금까지 겪었던 경험과 시행착오를 기억할 수는 없다. 또 인력이 변경되면서 그런 과거의 배움은 사라지고 결과물만 남아있다. 새 제품을 개발하면서 적어도 과거에 개발할 때 결정한 사항이나 기술의 선택에 대한 배경이나 이론을 문서 없이 기억하기는 어렵다. 실제로 개발할 때 보면 복잡한 이슈의 경우 며칠 전에 정한 결정사항도 결과만 기억하지 결정에 이른 복잡한 과정은 기억하지 못하는 경우도 많다. 1,2년이 지나서 비슷한 상황이 생겼을 때 시행착오를 하지 않으려면 과거의 정보는 필수이다. 기억에 의존해서 소프트웨어를 장기간 개발하려고 한다면 소프트웨어를 너무 쉽게 생각한 것이거나 동호회 수준의 제품을 개발을 하고 있는 것이다.

7.1 Iterative Nature of the Requirements Process (요구사항 프로세스의 반복적인 특성)

경쟁적이고 시장 주도의 소프트웨어 영역에서는 점점 더 신속한 개발에 대한 압박이 크다. 더군다나 이미 개발되어 있는 아키텍처(구조) 위에서 업그레이드도 해야 하고 새 제품도 만들어야 하고 기존 제품도 유지해야 하는 동시에 벌어지는 다양한 일이 있다. 그래서 요구사항을 도출하고, 기준선(Baseline)을 긋고, 개발팀에게 넘기는 이론적인 순서로 차례로 수행한다는 것은 현실의 요구사항 프로세스에서는 거의 불가능하다. 그래서 대규모 소프트웨어 프로젝트에서 실제 요구사항이 처음에 완벽하게 이해되고 명시된다는 것은 신화적인 얘기이다.

대신에 요구사항은 설계가 가능할 만한 수준의 품질과 상세도로 반복적인 작업을 통해 정리되어 간다. 어떤 프로젝트에서는 모든 특성을 이해하기 전에라도 기준선을 긋고 개발을 하기도 한다. 물론 잘못된 요구사항이 나중에 발견되면 엄청난 피해를 입는 리스크가 있다. 하지만 소프트웨어 엔지니어들은 프로젝트 관리에 의한 일정을 따라야 하는 제약하에서 움직인다. 그런 환경하에서 주어진 자원으로 작성할 수 있는 최고 품질의 요구사항을 만들어야 한다. 예를 들어 요구사항에 대한 어떤 가정도 분명한 근거가 있어야 하고 알려진 문제에 대해서도 확실히 해결할 수 있다는 근거하에서 가정을 해야 한다.

(***필자주석) SRS를 작성하는 과정에서 가장 어려운 부분이 바로 Assumptions and Dependencies (가정과 의존) 부분이다. 통상적인 국내 개발에서 보면 엄청나게 많은 가정을 가지고 프로젝트를 시작한다. 만약에 가정을 모두 미리 해결할 수만 있다면 프로젝트는 주어진 일정에 정확하게 끝나야 한다. 일정이 지연되는 이유는 알건 모르건 어떤 가정이 생각대로 진행되지 않았기 때문이다. 가정에는 기술적인 이슈도 있지만 인사관리의 이슈도 있고 외주 회사나 플랫폼과 같은 타 회사의 일정에 관계되기도 한다. 그런 경우 가정과 함께 의존성도 생긴다. 이 수 많은 가정을 얼마나 잘 인식하고 도출해 내는 것이 첫번째 필요한 역량이고 그 다음에 어떤 가정을 언제 해결하는가 하는 것을 결정하는 것이 두번째 중요한 이슈이다. 대부분의 국내 회사에서는 거의 희망에 가까운 가정을 하고 해결 계획도 부족한 상태에서 프로젝트에 뛰어든다. 수 많은 가정이 깨어지면서 프로젝트는 아수라장이 된다. 사실은 많은 가정은 아예 초기에 인식조차도 못한다. 이런 상황에서 프로젝트가 제 일정에 끝날 확률은 거의 없다. 프로젝트의 리스크 관점에서는 기능요구사항보다도 훨씬 더 중요하다. 기능요구사항보다 중요한 것이 비기능요구사항이고 그보다 더 중요한 부분이 바로 "가정과 의존" 부분이다. 가정을 모두 해결하고 프로젝트에 들어가는 것은 현실적으로 불가능하다. 그래서 어떤 가정은 해결하고 어떤 가정은 리스크를 택하게 되는데 여기서 인간의 지혜와 경험으로 인한 현명한 결정이 핵심이다. 이 부분이 경험의 차이가 가장 큰 부분이다.

이런 반복적인 모델로 개발하기로 한 프로젝트에서는 요구사항 분석가는 현재 반복주기에 필요한 요구사항의 기준선을 긋고 그 기준선에 기반해서 개발팀은 설계와 구현을 함과 동시에 요구사항 분석가는 다음 반복주기를 위한 요구사항의 기준선을 긋기 위해 분석 작업을 한다. 이 개발모델은 고객에게 제품을 빨리 제공함과 동시에 재작업을 최소화하는 방법이다.

(***필자주석) 대충 보면 이런 방식이 바로 애자일 방식의 개념과 비슷하다. SWEBOK의 저자들이 폭포수 모델을 중심으로 적었을 것이라고 생각한다면 착각이다. 이미 20년 전에도 폭포수 모델의 장단점과 애자일 모델의 필요성에 대한 논쟁도 있었다. 필자도 실리콘밸리의 회사 중 GE와 GTE Government System을 제외하고는 모두 애자일 개념을 사용했다. 물론 그 당시에는 "애자일" 이라는 용어를 사용하지는 않았다. 나중에 만들어진 용어일 뿐이지 그런 행위는 이미 과거 수십 년 전에도 존재하고 있었다. 마치 애자일 방식이 소프트웨어 개발을 잘하는 최신 비법이라고 생각한다면 거대한 착각이다. 소프트웨어 개발의 핵심은 변하지 않았고 그냥 언저리 편법이 건강식품처럼 유행을 타기는 한다. 먼저 정통을 알고 그 다음에 상황에 따라 응용하는 것은 좋지만 정통은 해본 적도 없으면서 편법만 배워서 해결하려고 한다면 100% 실패할 수 밖에 없다.

거의 모든 경우에 요구사항의 이해는 기준선에서 끝나지 않고 설계와 구현단계까지 진화하며 계속된다. 이는 당연히 개발주기의 후반부에서 요구사항의 변경을 초래한다. 소프트웨어 요구사항에서 꼭 이해해야 할 가장 중요한 점은 요구사항의 많은 부분이 변경된다는 것이다. 이유로는 분석 과정에서의 오류도 있지만 많은 경우에 환경의 변화 때문이다. 환경에는 고객의 운영환경, 비지니스 환경, 정부의 규정 변경, 시장의 변화 등이 있다. 무슨 이유든지 간에 요구사항은 변경될 것이라는 것을 인정하고 그 영향을 최소화하도록 불가피하게 준비작업을 해야 한다는 것이다. 변경할 사항은 공식 검토와 승인 프로세스를 따라야 하며 요구사항 추적, 영향력평가, 형상관리와 같은 세심한 관리를 해야 한다. 그래서 요구사항 분석은 생명주기의 전반부에만 한정된 것이 아니라 전체 생명주기에 다 관련된 행위이다. 통상적인 프로젝트에서 소프트웨어 분석 행위는 최초의 도출 과정부터 변경관리의 마지막 단계까지 시간에 따라 계속 진화한다. Top-down 분석과 디자인 모델링의 상위기법과 Bottom-up 구현과 Refactoring 방식의 하위기법의 두 가지 방식이 중간 지점에서 만나도록 해서 두 방식의 좋은 점만을 이용할 수도 있다. 그러나 현실적으로 이런 두 가지 방식의 조합은 소프트웨어 엔지니어들의 경험과 성숙도가 최대한도로 요구되므로 어렵다.

(***필자주석) 앞 쪽에서 필자가 걱정한 것 중의 하나가 SWEBOK이 요구사항이 변할 수 있다고 하는 것이다. 여기서는 한 술 더 떠서 변경 가능성이 아니라 요구사항은 필연적으로 변경된다고 얘기한다. 그럼 변경은 기정사실화 하고 변경이 되기 때문에 요구사항 분석을 대충 하는 것이 좋은가 하는 착각을 하게 된다. 반대로 생각하면 변경이 될 것이기 때문에 그에 대비해서 먼저 분석을 잘해 놓고 나중에 변경 추적, 영향력 분석 등 중요한 이슈들을 분석하고 변경에 대한 대책을 세울 수 있어야 한다. 최초의 SRS가 없다면 변경 시에 더 어려운 일을 당하게 된다. 만약에 요구사항이 전혀 변하지 않고 차라리 문서를 작성하지 않아도 피해가 적다. 결론은 변경이 벌어질 것이기 때문에 SRS를 더 잘 작성해 놓아야 한다.

7.2 Change Management (변경관리)

변경관리는 요구사항 관리의 중심이 되는 토픽이다. 이 토픽은 변경관리의 역할, 프로세스, 변경 내용에 대한 분석 방법에 대한 이슈를 다룬다. Software Configuration Management KA 에서 관련 내용을 다룬다.

7.3 Requirements Attributes (요구사항 속성)

SRS는 요구되는 사양만을 포함하는 것이 아니라 그 외 부수적인 정보들도 포함한다. 부수적인 정보는 요구사항을 관리하고 이해하는 것을 돕는 역할을 한다. 그 중에는 여러 관점에서 본 분류체계(Section 4.1 Requirements Classification), 검증 방법, 관련된 인수테스트계획 등이 있다. 또 각 요구사항이 나온 배경, 요구사항의 근원, 변경 이력 등도 포함된다. 그 중에서도 가장 중요한 속성은 각 요구사항을 식별할 수 있는 고유한 아이디(ID)이다.

(***필자주석) 결국은 나올 수 있는 것은 다 나온다. 각 요구사항을 추적하려면 당연히 고유한 ID가 있어야 한다. 하지만 이런 행위도 요구사항이 적절한 단위로 세세히 나누어지고 잘 분류되어 있을 때 유용한 것이지 수시로 변하거나 대충 큰 단위로 분류를 해 놓았다면 얻는 것보다 시간 낭비할 가능성이 크다. 결국 기본이 되어 있지 않으면 소프트에어 공학에서 말하는 기법을 무조건 사용하는 것은 혜택보다는 피해가 크다.

7.4 Requirements Tracing (요구사항 추적)

요구사항 추적은 요구사항의 근원이 무엇이고 어느 곳에 영향을 미치는 가를 알게 한다. 특히 요구사항이 변경될 때의 영향도 평가에 필수적이다. 요구사항은 뒤로는 시스템 요구사항과 같이 생성의 근원과 요구한 이해관계자들을 인식할 수 있도록 한다. 반대로 앞으로는 그 요구사항을 만족시키는 설계, 소스코드, 테스트 케이스, 심지어는 사용자 매뉴얼의 어떤 부분과 관련이 있는지 까지 추적할 수 있어야 한다.

요구사항 추적은 통상적으로 복잡한 Directed Acyclic Graph(비순환 방향성 그래프, DAG) (Computing Foundation KA참조) 를 형성한다. 이런 DAG나 추적 매트릭스를 관리하는 행위는 전체 생명주기에서 필수적으로 고려해야 하는 행위이다. 만약에 추적표가 제대로 갱신되지 않는다면 영향도 평가를 신뢰할 수 없다.

(***필자주석) 요구사항 추적이 필요하다고 얘기하지만 현실적으로 국내에서 요구사항 추적을 할 정도로 SRS를 잘 적을 수 있는 회사가 있을 까 궁금하다. 기능요구사항은 비기능요구사항에 비해 상대적으로 쉬운 편이다. 실리콘밸리에서도 제대로 하기 어렵고 그래서 잘 이용하지 않는 것이 요구사항 추적이다. 추적을 하라고 하기도 난감하고 하지 말라고 말하기도 난감하다. 특히 대기업일 경우 소프트웨어 공학의 도입에 따라 비싼 도구를 이용해서 시도를 하기도 하지만 그 신뢰성과 효과는 미지수이다. 추적을 하느냐 안하느냐를 결정하기 전에 먼저 SRS를 제대로 적으면서 수 년의 경험을 한 다음에서야 추적을 시도할 것을 권장한다. 프로세스가 요구하니까 무조건 시도했다가는 시간만 낭비하기 딱 좋은 주제이다.

7.5 Measuring Requirements (요구사항 측정)

소프트웨어의 프로젝트에서 어떤 요구사항이 있으면 Volume("양") 에 관한 개념을 가져야 한다. 이 개념은 개발에 드는 비용, 유지보수에 드는 비용, 변경에 드는 비용의 규모를 측정하는데 필요하다. 또 다른 요구사항과 상대적으로 비교할 필요가 있을 때도 유용하다. Functional Size Measurement (FSM, 기능크기측정)이 Function의 규모를 측정하는 기법이다. 이와 관련된 정보는 Software Engineering Process KA에서 다룬다.

(***필자주석) 어떤 요구사항이 있을 때 개발비용과 일정이 얼마나 걸릴까 하는 것은 경영진과 관리자의 최고 관심사이다. 그러니 이 토픽이 소프트웨어 공학에서 없어질 수가 없다. 하지만 이론적이고 수학적인 방법이 과연 가능할까 하는 회의가 든다. 이론적인 소프트웨어 공학자들이 측정이론을 주장해도 일단 필자는 믿지 않는다. 이 부분은 인간의 고유 영역이라고 본다. 규모를 측정하고 일정을 산정할 때의 가장 큰 변수는 누가 개발하는 것이냐 이다. 모든 개발자들의 역량이 다른데 그 상황에 따라서 산정을 다르게 해야 한다. 개발이 끝난 후에 SLOC(소스코드 라인수)나 Function Point를 이용해서 비교하기도 하지만 난이도를 고려하지도 않고 코딩 스타일에 따라 천차만별이기 때문에 큰 의미를 부여할 수 없다. 그럼에도 불구하고 휴대폰에 들어간 소스코드가 몇백만 라인이다 라는 식으로 말할 때는 대충 규모를 판단하는 데 도움이 된다.

8. Software Requirements Tools (도구) - 다음 Post에서 다룬다