요구 공학 (Requirements Engineering) -3

비기능 요구사항, Acceptance criteria, Test case

엔지니어는 비기능적 요구사항, Acceptace criteria, Test case를 관리하지 못한다.
DaimlerChrysler의 모든 엔지니어는 비기능적 요구사항, Acceptace criteria, Test case의 중요성을 이해하고 있습니다. 
안타깝게도, 적절한 리소스가 있는 프로젝트에서도 실제 사양 문서가 해당 클레임을 충족하는 경우는 거의 없습니다. 기능 요구사항에 대한 합리적 Acceptace criteria, 적합한 Test case를 마련하기 어렵기 때문입니다. 
비기능적 요구사항에 대해서는 더욱 어렵다.
우리의 경험으로 볼 때, 좋은 Acceptace criteria를 작성하는 것은 단순히 연습과 개인적인 경험의 문제입니다. 따라서, Acceptace criteria를 개선하는 최선의 방법은 잘 구조화된 요구사항과 여러 단계의 추상화에서의 설계 결정사항이 상세한 명세서 문서를 이해하는 데 있어 매우 중요합니다. 
비기능적 요건에 대해서, 유지보수성 같은 품질을 상정하는 것은 입증하기 어렵다. 일반적으로 해당 Acceptace criteria와 Test case는 존재하지 않거나 너무나 학술적입니다. 예를 들어 다음의 요구사항은 사실상 무의미합니다.

"유지보수 작업의 90%는 5분 이내에 이루어져야 한다."
이러한 내용은 비기능적 요구사항을 일련의 기능적 요구사항으로 구현할 수 있을 때까지, 단계적으로 개선해야 합니다.

 

변경

변경은 일상적인 프로젝트 생활의 일부이며 그것을 바꿀 방법은 없습니다.
늦거나 전혀 예상치 못한 것을 포함하여 모든 종류의 변화가 프로젝트 중에 일어납니다. 
당신은 변화의 양을 비판할 수 있지만, 우리는 그것이 현명하지는 않습니다. 변화가 정당하고 기술적으로 실현 가능한 한, 변화가 발생할 것입니다. 
따라서, 늦게 변경되거나 예상치 못한 변경 사항을 합리적으로 처리할 수 있는지 확인해야 합니다.
프로젝트에서 발생할 수 있는 변경 사항으로는 시스템, 애플리케이션 및 구성요소 요구사항의 변경, 일정, 공급업체의 변경, 프로세스 및 도구 환경의 변경 등이 있습니다. 
변경의 빈도가 증가하는 주요 이유는 개발 프로젝트의 복잡성, 병렬화 및 시간 제한 때문입니다.
이러한 요인들은 개발자들이 개발 초기에 시스템에 대해 점점 더 많은 가정을 도입하도록 강요합니다. 그런 다음 시스템이 성숙함에 따라 이러한 가정에 이의를 제기하거나 재작업을 하는 경우가 많습니다.
프로젝트 전반에 표준 요구사항을 설정하고 비필수 적용을 최소화함으로써 표준 요구사항 변경을 필수 요구사항으로 제한할 수 있었습니다. 
우리는 또한 변경 제안이 실제 프로젝트 변경보다 훨씬 더 자주 발생한다는 것을 발견할 수 있습니다. (일반적으로 개발 후반기에 증가합니다.)

기술 전문가로서 엔지니어는 변경 제안에 대한 의견을 신속하게 제시해야 합니다. 
요구사항 엔지이너가 적절한 요구사항 관리 체계를 기반으로 하는 경우, 엔지니어는 요구사항과 해당 속성 간의 관계에 대한 문서화를 바탕으로 제안된 변경의 잠재적 영향을 평가할 수 있습니다. 

검토

올바른 사양 검토는 성공적인 제조업체-공급업체 관계를 위해 필수적입니다.
사양이 꾸준히 발전함에 따라 비공식 및 공식 검토가 자주 이루어집니다.
이러한 검토는 규격 품질과 하위 시스템 호환성을 모두 보장하는 데 중요하며 때로는 전체 시스템 호환성과 무결성을 보장하는 유일한 방법을 나타냅니다.
자동차 도메인은 복잡하며, 엔지니어는 일반적으로 여러 개발 단계에서 여러 구성 요소 버전을 담당합니다. 
그런 환경에서는 효과적이고 효율적인 검토를 수립하는 것이 매우 중요합니다.
경험에 비추어 볼 때, 효과적인 요구사항 관리 관행과 적절한 툴 지원은 성공적인 사양 검토의 핵심입니다. 
단일 소스 접근 방식을 사용하면 모든 검토자가 동일한 버전의 검토 산출물을 검토할 수 있습니다. 
역할별 보기 및 속성을 통해 모든 사용자가 각 단계에서 수행해야 할 작업과 수행 방법을 알 수 있습니다. 
검토 회의에서는 온라인으로 결정을 문서화합니다. 우리는 또한 프로젝트 경영진에게 검토 과정을 통제하기 위한 특별한 뷰를 제공합니다. 
마지막으로, 요구사항 관리 툴의 기록 기능을 통해 모든 결정을 추적하고 언제든지 질문할 수 있습니다. 
이와 같은 적절한 요구사항 관리 지원은 검토 프로세스를 상당히 개선하고 용이하게 합니다. 

추적성

추적성은 중요한 특징이지만, 어떤 흔적을 유지할 것인지 결정하는 것이 진짜 중요한 내용입니다.
명확한 추적성을 도입하면 비용을 크게 절감할 수 있지만, 이를 실현하려면 신중한 트레이드오프 분석이 필요합니다.
객체 간에는 다양한 잠재적 링크가 있습니다. 또한 요구사항과 관련 객체 간의 연결은 필수적이지만, 링크를 유지하려면 다음과 같은 작업을 통해 균형을 이루어야 합니다.
추적성의 이점입니다. 이를 위해 엔지니어들이 무엇을 원하고 무엇을 받아들일 수 있는지 알기 때문에 기본적으로 이러한 결정을 엔지니어들에게 맡겨야 한다.
일반적으로 엔지니어들은 처음에는 모든 종류의 흔적을 만들고 유지하기를 간절히 원하지만, 나중에는 그렇게 하는 데 필요한 훈련에 미치지 못합니다. 이러한 관찰을 염두에 두고 명시적 추적의 수를 작게 유지하는 것이 좋습니다.
엄밀히 말하면 객체 관계를 표현하는 방법에는 두 가지가 있습니다.
■ 링크 객체로 표현되는 명시적 링크
■ 텍스트에 통합된 텍스트 참조(예: "SR123" 참조) 또는 규칙(예: "XX장의 12장은 YY 문서의 4장에 해당")과 같은 암시적 링크
요구사항 관리 체계에는 추적할 객체와 암묵적 또는 명시적으로 추적할 것인지에 대한 모든 결정이 포함되므로 프로젝트 시작 중에 이러한 결정을 정확하게 정의해야 합니다.
설계 지침을 사용하면 설정할 링크, 설정 방법 및 업데이트 시기에 대한 규칙을 정의하여 추적성을 마스터할 수 있습니다.