소프트웨어 공학/요구사항 공학

[EU2] Fundamental Principles of Requirements Engineering

청담동누룽이 2023. 2. 10. 13:32

Goal: Know and understand the principles of RE

Duration: 1 hour 30 minutes

Terms: Context, requirement, Requirements Engineering (RE), stakeholder, shared understanding, validation

Educational objectives:

EO 2.1.1: Enumerate the principles of RE (L1)

EO 2.2.1: Remember the terms associated with the principles (L1)

EO 2.2.2: Explain the principles and the reasons why they are important (L2)

EU 2.1 Overview of Principles (L1)

RE는 RE의 모든 작업, 활동 및 관행에 적용되는 일련의 기본 원칙에 의해 관리된다. 다음의 9가지 원칙은 이 강의계획서의 후속 장에서 제시된 관행의 기초를 형성한다.

  1. 가치 지향(Value-orientation): 요구사항은 목적을 위한 수단이지 그 자체가 목적이 아니다
  2. 이해관계자(Stakeholders): RE는 이해관계자의 욕구와 요구를 충족시키는 것이다
  3. 공유된 이해(Shared understanding): 공통 기반 없이 성공적인 시스템 개발은 불가능합니다
  4. 맥락(Context): 시스템을 분리하여 이해할 수 없음
  5. 문제 – 요구 사항 – 솔루션(Problem – Requirement – Solution): 필연적으로 얽힌 3중창
  6. 검증(Validation): 검증되지 않은 요구 사항은 무용지물입니다
  7. 진화(Evolution): 요구사항 변경은 우연이 아니라 일반적인 경우입니다
  8. 혁신(1Innovation): 같은 것이 더 많으면 충분하지 않다
  9. 체계적이고 규율 있는 업무(Systematic and disciplined work): RE 없이는 지낼 수 없다

EU 2.2 The Principles Explained (L2)

Principle 1 – Value-orientation: Requirements are a means to an end, not an end in itself

요구사항의 가치는 요구사항을 도출, 문서화, 검증 및 관리하는 비용을 뺀 편익과 같다. 요구사항의 효익은 요구사항이 다음에 기여하는 정도이다:

  • 이해관계자의 욕구와 요구를 충족시키는 시스템을 구축합니다.
  • 시스템 개발 시 고장의 위험과 비용이 많이 드는 재작업을 줄입니다.

Principle 2 – Stakeholders: RE is about satisfying the stakeholders’ desires and needs

RE는 이해관계자의 욕구와 요구를 이해하는 것이므로, 이해관계자를 적절히 처리하는 것이 RE의 핵심과제이다. 모든 이해관계자는 구축될 시스템의 맥락에서(예: 사용자, 클라이언트, 고객, 운영자 또는 규제자) 역할을 가집니다. 이해관계자는 동시에 둘 이상의 역할을 가질 수도 있습니다. 너무 많은 개인이 있는 이해관계자 역할의 경우, 또는 개인이 알려지지 않은 경우, **페르소나(personas)**로 알려진 허구의 전형적인 묘사는 대체물로 정의될 수 있다. 최종 사용자나 고객의 요구사항만을 고려하는 것만으로는 충분하지 않습니다. 이렇게 하면 다른 이해관계자의 중요한 요구사항을 놓칠 수 있습니다. 사용 중인 시스템에 대한 피드백을 제공하는 사용자도 이해관계자로 간주해야 한다.

이해관계자는 서로 다른 요구사항과 관점을 가질 수 있으며, 이로 인해 요구사항이 상충될 수 있다. 이러한 갈등을 파악하고 해결하는 것이 RE의 과제이다.

관련 이해관계자 역할에 적합한 사람을 참여시키는 것은 성공적인 RE를 위해 매우 중요하다. 이해관계자를 식별, 우선순위 지정 및 협력하는 관행은 EU 3.5에 설명되어 있다.

Principle 3 – Shared understanding: Successful systems development is impossible without a common basis

RE는 이해관계자, 요구사항 엔지니어 및 개발자와 관련된 당사자 간 및 당사자 간의 공유 이해를 생성, 육성 및 확보합니다. 공유 이해에는 두 가지 형태가 있다:

  • 명시적 공유 이해(문서화되고 합의된 요구사항에 의해 달성됨)
  • 암묵적 공유 이해(요구, 비전, 맥락에 대한 공유 지식 기반 등)

도메인 지식, 이전의 성공적인 협업, 공유된 문화와 가치, 상호 신뢰는 공유된 이해를 가능하게 하는 요소인 반면, 지리적 거리, 아웃소싱 또는 이직률이 높은 대규모 팀은 장애물이다.

공유 이해를 달성하기 위한 검증된 관행에는 용어집 작성(EU 3.5), 프로토타입 작성(EU 3.7) 또는 기존 시스템을 참조 지점으로 사용하는 것이 포함됩니다. 공유 이해를 평가하기 위한 실천요강에는 예상 결과의 예, 프로토타입 탐색 또는 요구사항 구현 비용 추정이 포함된다. 오해의 영향을 줄이기 위한 가장 중요한 관행은 피드백 루프가 짧은 프로세스(EU5)를 사용하는 것이다.

Principle 4 – Context: Systems cannot be understood in isolation

시스템은 **컨텍스트(context, 맥락)**에 내장되어 있습니다. 그 맥락을 이해하지 않고서는 시스템을 제대로 지정하는 것이 불가능하다. RE에서, **시스템의 컨텍스트(system boundary)**는 시스템과 시스템의 요구사항을 이해하는 데 관련된 시스템 환경의 일부이다. 시스템 경계는 시스템과 주변 컨텍스트 사이의 경계입니다. 처음에는 시스템 경계가 명확하지 않은 경우가 많으며 시간이 지남에 따라 변경될 수도 있습니다.

시스템 경계를 명확히 하고 시스템과 시스템이 상호 작용하는 컨텍스트 요소 사이의 외부 인터페이스를 정의하는 것은 진정한 RE 작업입니다. 동시에, 시스템의 범위, 즉 시스템을 개발할 때 형성되고 설계될 수 있는 것들의 범위가 결정될 필요가 있다. 우리는 또한 시스템 환경의 RE 관련 부분을 나머지 세계와 분리하는 소위 **맥락 경계(context boundary)**를 고려할 필요가 있다.

시스템을 지정할 때 시스템 경계 내의 요구 사항만 고려하는 것으로는 충분하지 않습니다. RE는 또한 다음을 고려해야 한다:

  • 시스템 요구사항에 영향을 미칠 수 있는 컨텍스트의 변경사항.
  • 시스템과 관련된 실제 요구사항(및 이러한 요구사항을 시스템 요구사항에 매핑하는 방법).
  • 시스템을 작동시키고 실제 요구사항을 충족하기 위해 유지해야 하는 컨텍스트 가정

Principle 5 – Problem – Requirement – Solution: An inevitably intertwined triple

이해관계자들이 상황에 만족하지 못할 때 문제가 발생한다. 요구사항은 이해관계자가 문제를 제거하거나 단순화하기 위해 필요한 것을 포착합니다. 이러한 요구 사항을 충족하는 사회 기술 시스템이 해결책을 구성한다.

문제, 요구 사항 및 해결 방법이 반드시 이 순서로 발생하는 것은 아닙니다. 솔루션 아이디어는 요구사항으로 해결하고 실제 솔루션에서 구현해야 하는 사용자 요구사항을 생성할 수 있습니다. 이는 혁신할 때 일반적으로 해당됩니다.

  • 문제, 요구 사항 및 해결책은 밀접하게 얽혀 있습니다. 이들은 단독으로 해결될 수 없습니다.
  • 그럼에도 불구하고 요구사항 엔지니어는 생각, 의사소통 및 문서화 시 문제, 요구사항 및 솔루션을 가능한 한 서로 분리하는 것을 목표로 합니다. 이러한 관심사의 분리는 RE 작업을 더 쉽게 처리할 수 있게 한다.

Principle 6 – Validation: Non-validated requirements are useless

결국, 우리는 배치된 시스템이 이해관계자들의 욕구와 요구를 충족하는지 검증해야 한다. 불만족 이해관계자의 위험을 처음부터 통제하기 위해서는 요구사항의 유효성 검사가 RE 중에 이미 시작되어야 한다. 다음 사항을 확인해야 합니다:

  • 이해관계자 간에 요구사항에 대한 합의가 이루어졌으며,
  • 이해관계자의 욕구와 요구사항은 요구사항에 의해 적절히 커버된다.
  • 맥락 가정(위의 원칙 4 참조)은 타당하다.

요구사항을 검증하기 위한 관행은 EU 4.4에서 논의된다.

Principle 7 – Evolution: Changing requirements are no accident, but the normal case

시스템과 그 요구사항은 진화의 영향을 받습니다. 이것은 그들이 끊임없이 변한다는 것을 의미합니다. 시스템에 대한 요구사항 또는 요구사항 집합의 변경 요청은 다음과 같은 경우에 발생할 수 있습니다:

  • 변경된 비즈니스 프로세스
  • 새로운 제품 또는 서비스를 출시하는 경쟁업체
  • 고객이 자신의 우선순위나 의견을 변경합니다
  • 기술의 변화
  • 법령의 변경
  • 새로운 기능 또는 변경된 기능을 요청하는 시스템 사용자의 피드백

또한 요구사항 검증 시 이해관계자의 피드백, 이전에 도출된 요구사항의 결함 감지 또는 변경된 요구사항으로 인해 요구사항이 변경될 수 있다.

결과적으로 요구사항 엔지니어는 두 가지 모순되는 목표를 추구해야합니다 :

  • 변경을 허용하는 요구사항
  • 요구사항을 안정적으로 유지

이를 달성하는 방법에 대한 세부사항은 EU 6.7에서 논의된다.

Principle 8 – Innovation: More of the same is not enough

이해관계자들에게 그들이 원하는 것을 정확히 제공하는 것은 이해관계자들의 요구를 그들이 기대하는 것보다 더 잘 충족시키는 시스템을 구축할 기회를 놓친다. Good RE는 이해관계자들을 만족시키기 위해 노력할 뿐만 아니라, 그들을 행복하게 하거나, 흥분하게 하거나, 안전하다고 느끼게 하기 위해 노력한다. 이것이 궁극적으로 혁신에 관한 것이다.

RE는 혁신적인 시스템을 형성합니다:

  • 흥미로운 새로운 기능과 사용 편의성을 위해 노력함으로써 소규모로 제공됩니다.
  • 파괴적인 새로운 아이디어를 위해 노력함으로써 대규모로.

EU 4.2는 RE에서 혁신을 촉진하기 위한 몇 가지 기술을 논의한다.

Principle 9 – Systematic and disciplined work: We can’t do without in RE

실제 개발 프로세스와 관계없이 요구사항을 체계적으로 도출, 문서화, 검증 및 관리하기 위한 적절한 프로세스와 관행을 채택해야 합니다. 시스템이 임시 방식으로 개발되더라도 RE에 대한 체계적이고 규율된 접근 방식은 결과 시스템의 품질을 향상시킨다.

RE에는 주어진 모든 상황에서 또는 적어도 대부분의 상황에서 잘 작동하는 단일 프로세스 또는 관행이 없습니다. 체계적이고 규율된 작업은 요구사항 엔지니어가 다음을 수행한다는 것을 의미합니다:

  • 주어진 문제, 상황 및 환경에 맞게 프로세스와 관행을 조정합니다.
  • 항상 동일한 프로세스와 일련의 관행을 사용하지 마십시오.
  • 과거의 성공적인 리워크의 프로세스와 관행을 반영 없이 재사용하지 마십시오.

모든 RE 노력에 대해 특정 상황에 가장 적합한 프로세스, 관행 및 작업 제품을 선택해야 합니다. 자세한 내용은 EU 3, EU 4, EU 5 및 EU 6에 자세히 설명되어 있습니다.

 

참고문헌 : CPRE Foundation Level Syllabus Version 3.0