요구사항 공학(Requirements Engineering) 특성과 유형

요구사항 공학 (Requirements Engineering)

요구사항 공학은 고객이 시스템에서 필요로 하는 서비스와 시스템이 작동하거나 개발되는 과정에서의 제약을 정의하는 과정입니다. 이 과정에서 생성된 시스템 요구사항은 시스템 서비스와 제약 사항에 대한 설명입니다.

• 요구사항(Requirements):
  • 서비스나 시스템 제약에 대한 추상적인 고수준 설명부터 수학적으로 정밀한 기능 명세까지 다양할 수 있습니다.
  • 서비스의 설명은 기능적 요구사항(Functional Requirements, FR)으로 나타나고, 시스템 제약은 비기능적 요구사항(Non-Functional Requirements, NFR)으로 표현됩니다. ex) 카메라 셔터 소리, 보안문제 등등

---

요구사항의 유형

1. 사용자 요구사항(User Requirements):
   • 시스템이 제공하는 서비스와 운영 제약을 자연어와 다이어그램으로 설명한 내용.
   • 이해관계자(Stakeholders)로부터 도출되고 발견됨.
   • 고객을 위한 요구사항.
2. 시스템 요구사항(System Requirements):
   • 시스템의 기능, 서비스, 운영 제약을 상세하게 설명한 구조화된 문서.
   • 개발자들이 구현할 내용을 명시함.

---

User and System Requirements

user도 stakeholder랑 같은 의미에서 쓰이고 있습니다.

---

시스템 이해관계자(System Stakeholders)

이해관계자는 시스템에 영향을 받거나 시스템에 관여하는 모든 사람 또는 조직입니다. ex) 주주, 법, 나라

일반적인 이해관계자 유형은 다음과 같습니다:

• 사용자(User): 새로운 시스템의 기능과 특성에 관심.
• 디자이너(Designer): 완벽한 시스템을 구축하거나 기존 코드를 재사용하려 함.
• 시스템 분석가(System Analyst): 요구사항이 정확한지 확인하는 데 중점.
• 트레이닝 및 사용자 지원(Training and User Support): 시스템이 사용하기 쉽고 관리하기 쉬운지 확인.
• 비즈니스 분석가(Business Analyst): 경쟁사보다 더 나은 시스템을 만드는지 확인.
• 기술 저자(Technical Author): 사용자 매뉴얼과 기타 문서를 작성.
• 프로젝트 매니저(Project Manager): 예산 내에서, 시간 내에 프로젝트를 완료하고 모든 목표를 달성하는 것을 목표로 함.
• 고객(Customer): 투자한 비용 대비 최고의 가치를 원함.

---

애자일 방법론과 요구사항 (Agile Methods and Requirements)

• 애자일 방법론에서는 시스템 요구사항을 상세하게 문서화하는 것이 시간 낭비라고 주장하는 경우가 많습니다. 이는 요구사항이 빠르게 변하기 때문입니다.
• 애자일 방법은 incremental한 요구공학을 이용하고 있고, 사용자 스토리(User Stories) 형식으로 요구사항을 표현하며, 이는 비즈니스 시스템에서는 실용적일 수 있지만, 사전 분석이 필요한 시스템이나 여러 팀이 개발하는 시스템에서는 문제가 될 수 있습니다.

---

기능적 요구사항(FR)과 비기능적 요구사항(NFR)

기능적 요구사항(Functional Requirements):

• 시스템이 제공해야 할 서비스에 대한 설명.
• 특정 입력에 대한 시스템의 반응 및 특정 상황에서 시스템이 어떻게 행동해야 하는지 기술.
• 시스템이 하지 말아야 할 내용을 명시할 수도 있음.

비기능적 요구사항(Non-Functional Requirements):

• 시스템에서 제공하는 서비스나 기능에 대한 제약 조건(Constraint)을 명시함.
• 시간 제약(Quality), 개발 과정에서의 제약, 표준 준수 등이 포함.
• 시스템의 전체적인 속성에 적용되며, 개별 기능보다는 시스템 전체에 영향을 미침.

시스템 전체에 영향을 미치는것은 NFR이다!

 

도메인 요구사항 (Domain Requirements)

 

시스템이 작동하는 도메인에서 발생하는 제약 사항(Constraint)으로 도메인에 익숙한 사람만 알 수 있는 FR, NFR이다.

---

기능 요구 사항 (Functional Requirements)

기능 요구 사항은 소프트웨어의 기능이나 시스템 서비스를 설명하는 데 필요한 요소로, 소프트웨어의 유형, 예상 사용자 및 소프트웨어가 사용되는 시스템 유형에 따라 달라집니다.

• 기능 사용자 요구 사항 (Functional User Requirements): 시스템이 수행해야 할 작업에 대한 고수준의 진술을 포함할 수 있습니다. 예를 들어, "사용자는 모든 클리닉의 예약 목록을 검색할 수 있어야 한다." (A user shall be able to search the appointments lists for all clinics.)
• 기능 시스템 요구 사항 (Functional System Requirements): 시스템 서비스(사용자 요구 사항)를 자세히 설명해야 합니다. 예를 들어, "시스템은 각 클리닉마다 매일 해당 날의 예약에 참석할 예정인 환자 목록을 생성해야 한다." (The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.)

---

요구사항의 모호성 (Requirements Imprecision)

• 요구사항이 명확하지 않으면 개발자와 사용자가 다르게 해석할 수 있습니다.
• 예를 들어, "사용자는 모든 클리닉의 예약 목록을 검색할 수 있어야 한다"는 요구사항에서 '검색'이라는 용어는 모호할 수 있습니다.
  • 사용자 의도: 모든 클리닉에서 환자 이름을 검색.
  • 개발자 해석: 개별 클리닉에서 환자 이름을 검색.

---

요구사항의 완전성과 일관성 (Requirements Completeness and Consistency C&C)

• 완전성(Complete): 모든 필요한 기능에 대한 설명이 포함되어 있어야 함.
• 일관성(Consistent): 시스템 기능에 대한 설명에 충돌이나 모순이 없어야 함.
• 그러나 실제로 완전하고 일관된 요구사항 문서를 만드는 것은 불가능함.

---

비기능적 요구사항 (Non-Functional Requirements)

• 시스템 속성 및 제약 사항을 정의.
  • 신뢰성, 응답 시간, 저장 용량 등.
• 품질 속성 요구사항(Quality Attribute Requirements): 특정 통합 개발 환경(IDE), 프로그래밍 언어, 개발 방법론, 표준 준수 등과 같은 제약 사항.
• 비기능적 요구사항은 기능적 요구사항보다 더 중요할 수 있으며, 충족되지 않으면 시스템이 무용지물이 될 수 있음.
• 비기능적 요구사항은 시스템의 전체 아키텍처에 영향을 미칠 수 있으며, 시스템 서비스에 대한 추가적인 기능적 요구사항을 생성할 수 있음.

---

Types of Non-Functional Requirements

---

비기능적 요구사항 분류 (Non-functional Classifications)

1. 제품 요구사항(Product Requirements): 제공된 제품이 특정 방식으로 동작해야 함.
   • 예: 실행 속도, 신뢰성.
   • 예시: "Mentcare 시스템은 정상 근무 시간 동안 모든 클리닉에서 사용 가능해야 하며, 다운타임은 하루에 5초를 넘지 않아야 한다."
2. 조직 요구사항(Organizational Requirements): 조직의 정책 및 절차의 결과로 발생하는 요구사항.
   • 예: 프로세스 표준, 구현 요구사항.
   • 예시: "Mentcare 시스템의 사용자는 건강 당국의 신분증을 사용하여 인증해야 한다."
3. 외부 요구사항(External Requirements): 시스템과 개발 과정 외부에서 발생하는 요구사항.
   • 예: 상호 운용성 요구사항, 법적 요구사항.
   • 예시: "시스템은 HStan-03-2006-priv에 명시된 환자 프라이버시 규정을 구현해야 한다."

---

품질 속성 (Quality Attributes)

 

품질 속성(Quality Attributes)은 시스템의 측정 가능하거나 테스트 가능한 속성을 의미하며, 시스템이 이해관계자의 요구를 얼마나 잘 충족시키는지를 나타냅니다.

• 예시: 가용성(Availability), 구성 가능성(Configurability), 수정 가능성(Modifiability), 성능(Performance), 신뢰성(Reliability), 재사용성(Reusability), 보안(Security), 이식성(Portability), 유지보수성(Maintainability), 효율성(Efficiency), 사용성(Usability) 등.
• Emergent Properties: 소프트웨어를 독립적으로 측정하는 것이 아니라, 소프트웨어와 그 응용 도메인(Application Domain) 간의 관계를 측정함.
• 환경 의존성: 소프트웨어를 특정 환경에 배치해야만 품질을 측정할 수 있으며, 품질은 환경에 따라 달라질 수 있음.
• 목적 적합성(Fitness to Purpose): 소프트웨어 품질은 이해관계자의 목적에 얼마나 부합하는지에 초점을 맞춤.
  • "필요한 것을 잘 수행하는가?"
  • "사용자가 필요로 하는 방식으로 수행하는가?"
  • "충분히 신뢰성 있게? 충분히 빠르게? 충분히 안전하게? 충분히 보안적으로 수행하는가?"
  • "비용이 적절한가? 사용자가 필요로 할 때 준비가 되어 있는가?"
  • "요구사항이 변화할 때 쉽게 변경할 수 있는가?"

품질 속성 분류 (Taxonomies of Quality Attributes)

품질 속성은 다양한 방법으로 분류될 수 있으며, 일반적으로 다음과 같은 접미사를 사용하여 구분합니다:

1. -ilities
   • 정의: 다양한 품질 속성을 포함하는 접미사.
   • 예시: 이해 가능성(Understandability), 사용성(Usability), 수정 가능성(Modifiability), 상호 운용성(Interoperability), 신뢰성(Reliability), 이식성(Portability), 유지보수성(Maintainability), 확장성(Scalability), 구성 가능성(Configurability), 맞춤화(Customizability), 적응성(Adaptability), 변동성(Variability), 변동성(Volatility), 추적 가능성(Traceability) 등.
2. -ities
   • 정의: 특정 품질 속성을 나타내는 접미사.
   • 예시: 보안(Security), 단순성(Simplicity), 명확성(Clarity), 보편성(Ubiquity), 무결성(Integrity), 모듈성(Modularity) 등.
3. -ness
   • 정의: 품질의 상태나 특성을 나타내는 접미사.
   • 예시: 사용자 친화성(User-friendliness), 견고성(Robustness), 시의성(Timeliness), 응답성(Responsiveness), 정확성(Correctness), 완전성(Completeness), 간결성(Conciseness), 응집력(Cohesiveness) 등.
4. 기타 (Others)
   • 정의: 위의 분류에 속하지 않는 다양한 품질 속성.
   • 예시: 성능(Performance), 효율성(Efficiency), 정확도(Accuracy), 정밀도(Precision), 비용(Cost), 개발 시간(Development Time), 낮은 결합도(Low Coupling) 등.

---

ISO/IEC 25010

ISO/IEC 25010:2011은 시스템 및 소프트웨어 공학 - 시스템 및 소프트웨어 품질 요구사항 및 평가 (SQuaRE: Systems and software Quality Requirements and Evaluation) - 시스템 및 소프트웨어 품질 모델을 정의한 국제 표준입니다.

• 목적: 시스템 및 소프트웨어의 품질을 평가하고, 품질 요구사항을 정의하는 데 사용됨.
• 구성 요소:
  • 품질 모델(Quality Model): 다양한 품질 속성을 체계적으로 분류하고 정의함.
  • 품질 측정 방법(Quality Measurement Methods): 품질 속성을 측정하고 평가하는 방법을 제공함.

---

목표와 요구사항 (Goals and Requirements)

NFR은 시스템의 성능, 신뢰성, 보안, 유지 보수성 등과 같은 특성을 설명합니다. 이러한 요구 사항은 주관적일 수 있고, 정량적인 기준을 정하기 어려운 경우가 많아, 명확하게 정의하기가 어렵습니다. 예를 들어, "시스템은 빠르게 반응해야 한다"라는 요구 사항은 반응 속도의 정확한 기준 없이 제시될 수 있기 때문에, 이를 명확하게 측정하기 어려울 수 있습니다.

 

요구 사항이 모호하거나 불명확하면, 개발자나 테스터가 그 요구 사항을 충족했는지 검증하기 어려워집니다. 예를 들어, "시스템은 사용자가 만족할 수 있는 속도로 작동해야 한다"라는 비기능 요구 사항은 '만족할 수 있는 속도'라는 주관적인 개념을 포함하고 있어, 이를 검증하는 기준이 부족합니다. 따라서 시스템이 요구 사항을 충족하는지 확인하는 것이 매우 복잡해질 수 있습니다.

 

시스템 사용자(예: 고객, 최종 사용자)의 의도를 명확히 전달하는 것은 개발자에게 큰 도움이 됩니다. 목표(Goals)는 시스템이 달성해야 하는 품질 속성이나 기대치를 표현합니다. 예를 들어, "시스템은 사용자가 쉽게 사용할 수 있어야 한다"라는 목표는 사용자가 원하는 경험을 기반으로 하여 개발자가 필요한 기능을 이해하고 구현하는 데 도움을 줄 수 있습니다. 이러한 목표는 비기능 요구 사항을 더 명확하게 정의하는 데 기여하여, 개발팀이 사용자 기대를 충족하는 제품을 만들 수 있도록 합니다.

 

정의

• 목표(Goals):
  • 시스템이 왜 필요한지를 설명하는 일반적인 의도.
  • 예: "사용하기 쉬워야 한다(Ease of Use)".
  • 종종 비기능적 요구사항(NFR: Quality Attributes)과 관련됨.
• 요구사항(Requirements):
  • 목표를 달성하기 위한 구체적인 요구사항.
  • 검증 가능한 비기능적 요구사항(Verifiable Non-Functional Requirement): 객관적으로 테스트할 수 있는 측정 기준을 사용한 진술.

예시

• 품질 요소(Quality Factor): 사용성(Usability)
  • 목표(Goal): "시스템은 의료 직원이 사용하기 쉬워야 하며, 사용자 오류를 최소화할 수 있도록 조직되어야 한다."
  • 검증 가능한 비기능적 요구사항(Verifiable Non-Functional Requirement): "의료 직원은 4시간의 교육 후 모든 시스템 기능을 사용할 수 있어야 한다. 이 교육 후, 경험 많은 사용자가 시스템을 사용하면서 발생하는 평균 오류 수는 시간당 2건을 넘지 않아야 한다."

---

목표 분석 (Goal Analysis)

목표 분석(Goal Analysis)은 시스템이 왜 필요한지를 중심으로 분석하는 과정입니다.

과정

1. 목표의 표현:
   • 시스템 사용자들의 의도를 목표 집합(Set of Stakeholder Goals)으로 표현.
2. 목표 정제(Goal Refinement):
   • 구체적인 요구사항에 도달하기 위해 목표를 정제하고 상세화.
3. 목표 문서화 및 분류:
   • 목표를 문서화하고, 조직화하며, 분류.
4. 목표의 진화(Goal Evolution):
   • 목표를 정제하고, 확장하며, 실행 가능하게 만듦.
5. 목표 계층 구조(Goal Hierarchies):
   • 목표의 정제 및 대안을 보여주는 계층 구조를 작성.
6. 목표 모델링(Goal Modeling):
   • 목표 분석을 시각적으로 표현하는 모델을 작성.

목표 유형

• Hard Goal: 시스템이 반드시 수행해야 할 기능을 설명.
  • 예시: 시스템이 수행해야 할 기능적 요구사항(FR).
• Soft Goal: 완전히 만족시킬 수 없는 목표를 설명.
  • 예시: 품질(Accuracy, Performance, Security 등).

---

목표 상세화 (Goal Elaboration)

목표 상세화(Goal Elaboration)는 목표 분석을 더욱 심화하는 과정으로, 목표의 맥락과 운영 방식을 탐구합니다.

과정

1. 질문 탐구:
   • "왜(Why)": 시스템이 필요한 이유를 탐구하여 높은 수준의 목표(High-Level Goals)를 도출.
   • "어떻게(How)": 낮은 수준의 목표(Low-Level Goals)를 도출하여 운영 방식을 탐구.
   • "다른 방법으로 어떻게 할 수 있는가(How else)": 대안을 탐구하여 목표 달성을 위한 다양한 방법을 모색.
2. 목표 간의 관계:
   • 긍정적 관계(+): 한 목표가 다른 목표 달성에 도움을 줌.
   • 부정적 관계(-): 한 목표가 다른 목표 달성을 방해함.
   • 강화 관계(++): 한 목표의 달성이 다른 목표의 달성을 보장함.
   • 파괴 관계(--): 한 목표의 달성이 다른 목표의 달성을 방해함.

---

소프트 목표 (Soft Goals)

정의

소프트 목표(Soft Goals)는 완전히 만족시킬 수 없는 목표를 의미합니다.

• 예시: "시스템은 사용하기 쉬워야 한다(Easy to Use)", "접근성은 안전해야 한다(Secure Access)".
• 다른 용어: 비기능적 요구사항(NFR: Non-Functional Requirements), 품질 속성(Quality Attributes).

특징

• 소프트 목표는 특정한 품질 속성을 통해 간접적으로 달성됩니다.
• 목표를 직접적으로 만족시키는 대신, 이를 지원하는 속성을 통해 간접적으로 달성됨.

예시

• 예시 1: "트레인 시스템은 사용하기 쉬워야 한다."
• 예시 2: "접근성은 안전해야 한다."

---

소프트 목표를 선택 기준으로 사용하기 (Soft Goals as Selection Criteria)

과정

1. 목표 분석(Goal Analysis)을 통해 소프트 목표를 식별하고, 이를 프로젝트의 선택 기준으로 활용.
2. 목표의 관계 파악:
   • 소프트 목표 간의 긍정적, 부정적 관계를 분석하여 프로젝트의 방향성을 설정.
3. 목표의 우선순위 결정:
   • 프로젝트의 핵심 목표를 정의하고, 이를 바탕으로 요구사항을 도출.

예시

• 트레인 시스템의 소프트 목표:
  • "시스템은 사용하기 쉬워야 한다."
  • "시스템은 안전해야 한다."
  • "시스템은 신뢰할 수 있어야 한다."

---

요약

요구사항 공학은 시스템이 제공해야 하는 서비스와 제약 조건을 정의하는 중요한 과정이며, 기능적 요구사항(FR)과 비기능적 요구사항(NFR)으로 구분됩니다.

품질 속성(Quality Attributes)은 시스템의 측정 가능하거나 테스트 가능한 속성으로, 이해관계자의 요구를 얼마나 잘 충족시키는지를 나타냅니다. ISO/IEC 25010 표준은 이러한 품질 속성을 체계적으로 분류하고 정의하는 데 사용됩니다.

목표 분석(Goal Analysis)과 목표 상세화(Goal Elaboration)는 시스템이 왜 필요한지를 중심으로 요구사항을 구체화하는 과정이며, 소프트 목표(Soft Goals)는 완전히 만족시킬 수 없는 목표로, 비기능적 요구사항으로 표현됩니다.

소프트 목표는 프로젝트의 선택 기준으로 활용되며, 품질 속성을 통해 간접적으로 달성됩니다.

요구사항 공학과 품질 속성 관리는 소프트웨어 개발의 성공과 직결되므로, 정확하고 체계적인 접근이 필요합니다. 이를 통해 시스템이 이해관계자의 요구를 충족시키고, 높은 품질을 유지할 수 있도록 할 수 있습니다.

 

 

다음 포스트에서는 이어서 요구사항 공학 프로세스(Requirement Engineering Process)에 대해서 다루겠습니다!