요구공학 (Requirements Engineering) - 2

문제 및 해결 공간

제조업체 요건 사양과 공급업체 시스템 사양 사이에는 명확한 경계가 없습니다.
독일어에서는 Lastenheft(문자 그대로 "수요 책자")와 Pflichtenheft("의무 책자") 사이에 명확한 구별이 있습니다. 
고객은 자신이 원하는 것(고객의 요구)을 정의하는 첫 번째 문서를 제공하고, 계약자는 시스템을 구축하는 방법(계약자의 의무)을 설명하는 두 번째 문서를 제공합니다.
얼핏 보면, 이 문서들의 영문 상대는 사용자 요구사항 사양과 시스템 요구사항 사양입니다. 사용자 요구사항 문서에는 문제가 무엇인지 나와 있는 반면, 시스템 요구사항 문서에는 해결책이 설명되어 있어야 합니다. 
그러나 현실에서는 고객의 요구가 문제 공간에만 국한되지 않기 때문에 일이 쉽지 않습니다. 
특히 자동차 분야에서는 고객 설명이 문제 영역을 벗어나야 하는 몇 가지 타당한 이유가 있습니다.
■ 시스템은 일반적으로 서로 다른 공급업체가 제공하는 서브시스템과 구성요소로 나뉩니다. DaimlerChrysler는 여러 공급업체의 구성 요소가 함께 작동하여 전체 솔루션의 일부를 지정해야 합니다.
■ 소프트웨어와 하드웨어를 분리하려고 하면 작업이 더욱 어려워집니다. 단일 구성요소를 하드웨어 문제와 소프트웨어 문제의 두 가지 대화형 "문제"로 지정해야 합니다.
■ 많은 상황에서 DaimlerChrysler의 최초 출시 전략에서는 구체적인 알고리즘일 수 있는 특정 사양 문서 기능을 최대한 상세하게 정의해야 합니다. 종종 DaimlerChrysler는 문제 대신 솔루션을 지정하여 미래 표준을 설정해야 합니다.
경우에 따라 RE 전문가와 도메인 엔지니어가 주어진 요구사항이 고객 요구 문서의 일부가 되어야 하는지 여부를 결정하는 것도 어려울 수 있습니다.

 

이중화

이중화는 우수한 엔지니어의 문제를 야기하며, 이로 인한 시스템도 문제가 될 수 있습니다. 
자동차 전기 시스템 개발과 같은 대규모 프로젝트에서는 엔지니어들이 촉박한 마감 기한에 따라 수백 장의 긴 사양과 관련 문서(각각 최대 페이지)를 동시에 작성합니다. 
이 문서들이 일반적으로 중복 정보를 포함하고 있다는 것은 놀라운 일이 아니다. 게다가, 그러한 문서들 사이의 의존성은 복잡하고, 시간이 부족하고, 문서와 관련된 인원의 수 또한 부족하기 때문에 부분적으로 불투명하다. 
단점은 다음과 같습니다. 이러한 중복의 형태는 불일치와 이중 작업으로 이어집니다. 최악의 경우, 규격 문서는 유효하지 않은 전제에서 파생됩니다.
오랜 세월 동안 문서 구조가 발전하고 수용되는 경우가 많았기 때문에 이것은 성가신 문제입니다. 
또한 문서 구조는 일반적으로 조직 구조와 전체 자동차 비즈니스 구조를 반영합니다. 
따라서 중복을 제거하기 위해 문서 구조를 변경하는 것은 어렵고, 노력과 결과 사이에 부정적인 균형이 생기는 경우가 많습니다.
우리의 경험상, 프로젝트 중복에 대한 개요를 얻는 것은 중요한 단계입니다. 
이를 통해 엔지니어는 다른 곳에서 사용되거나 정교하게 다듬어진 문서 부분을 파악할 수 있습니다.

그런 다음 필요한 경우 동기화를 결정할 수 있습니다.

 

콘텐츠 프레젠테이션

 
콘텐츠는 우수한 엔지니어에게 고통을 주지 않지만, 콘텐츠 프레젠테이션은 문제를 일으킬 수 있습니다. 
자동차 분야에서는 일반적으로 시스템을 처음부터 새로 만드는 것이 아니라 점진적으로 구축합니다. 새로운 자동차 시리즈는 다양한 적응, 확장 또는 혁신을 통해 기존 자동차 시리즈에서 대부분의 기능을 이어받습니다. 
새 윈드실드 와이퍼는 기본적으로 또 다른 윈드실드 와이퍼입니다.
따라서 이 수준에서는 일반적으로 새로운 구성요소 버전을 개발하는 데 관련된 활동이 거의 수반되지 않기 때문에 공식적인 도출 단계는 없다. 
우수한 엔지니어는 자신의 전문 영역에 대한 프리미어 리그 전문가이며 요구사항 컨텐츠의 미묘함과 함정에 대한 깊은 통찰력을 가지고 있습니다. 
그들에게 콘텐츠와 도메인 지식은 중요한 문제가 아니다.
그러나 콘텐츠 프리젠테이션과 구조화에는 어려움이 따릅니다. 엔지니어들은 종종 비구조적인 방식으로 사양을 설명하여 커뮤니케이션 노력을 증가시킵니다. 
그러나 요구사항 관리 도구에 의해 구현되는 잘 정의된 RMI는 콘텐츠 구조와 프레젠테이션을 개선하는 데 도움이 될 수 있습니다. 
예를 들어, 엔지니어들에게 긴 사양 문단을 원자 요구 사항으로 나누도록 강요할 수 있습니다.
재사용은 또 다른 개선 사항입니다. 오늘날 대부분의 사양 재사용은 효율성과 품질에 영향을 미치는 임시적이고 암시적입니다. 
그러나 이 접근 방식의 가장 큰 문제는 좋은 사양이 도메인에 대한 엔지니어의 고급 전문지식에 전적으로 좌우된다는 것입니다. 
대안으로, 우리는 사양 프로세스의 명시적 단계로서 기존의 사양을 체계적으로 재활용할 것을 제안합니다.
마지막으로, 요구사항 관리 데이터베이스를 도입할 때 기존 문서를 시스템으로 마이그레이션해야 이후 프로젝트에서 재사용할 수 있습니다. 
요구사항 관리 툴이 일부 자동 캡처를 지원하지만, 경험상 마이그레이션 프로세스에는 여전히 상당한 수작업이 필요합니다. 

 

프로세스 문제

NAT의 프로세스 관련 경험
추상적 사양, 비기능적 요구사항, 변경, 사용자 적응 가능한 보기 및 사양 검토와 관련된 당면 과제입니다.
추상 규격 수준 상세 규격은 일반적으로 시스템 분해 트리의 잎만 포함합니다. 
엔지니어들이 저수준의 상세한 부품 사양을 구성하는 시스템 요구 사항을 논의하고 처리하는 것만으로 최신 텔레매틱스 유닛과 같은 복잡한 시스템을 개발할 수는 없습니다. 반대로 복잡한 시스템을 위에서 아래로 여러 계층으로 세분화하여 개발하는 것은 불가피합니다.
RE에 관한 한, 이 견해는 여전히 유효하다. 안타깝게도 오늘날에는 상위 수준의 요구사항과 설계 결정에 대한 체계적인 처리와 문서화가 충분하지 않습니다. 
그러나 엔지니어가 이러한 높은 수준의 요구사항과 근거를 문서화하지 않으면 모래 위에 다음과 같은 세부 요구사항을 작성합니다. 어떤 사람들은 정당화하기 어렵기 때문에 정기적으로 도전을 받을 것입니다. 어떤 사람들은 완전히 불필요하지만 여전히 존재합니다. (이후 정지된 법률 규정에서 2년 전에 파생된 요구사항처럼)
마지막으로, 세부 사양 문서를 이해하기 위해서는 여러 단계의 추상화에서 잘 구조화된 요구사항과 설계 결정이 매우 중요합니다.
목표 트리, 피쳐 목록, 사용 사례, 메시지 시퀀스 차트 및 상태 모델 등 다양한 설명 기법이 있습니다.
문제는 도메인 또는 조직별 모델을 정의하는 것입니다. 이를 위해 자체 연구는 주로 활용 사례에 초점을 맞추고 있습니다.