요구사항 공학(Requirements Engineering) 프로세스

요구사항 공학 프로세스 (Requirements Engineering Processes)

 

 

소프트웨어 개발에서 요구사항 공학(Requirements Engineering, RE)은 시스템이 제공해야 할 서비스와 그 운영 및 개발에 대한 제약 조건을 정의하고 관리하는 중요한 과정입니다. RE 프로세스는 애플리케이션 도메인, 적용되는 소프트웨어 개발 프로세스, 요구사항을 개발하는 사람이나 조직에 따라 다양하게 변형될 수 있습니다. 그러나 모든 RE 프로세스에는 공통적으로 네 가지 주요 활동이 포함됩니다:

1. 요구사항 도출 및 분석 (Requirements Elicitation and Analysis)
2. 요구사항 명세 (Requirements Specification)
3. 요구사항 검증 (Requirements Validation)
4. 요구사항 변경 관리 (Requirements Change Management)

실제로, RE는 이러한 프로세스들이 반복적으로 수행되고 서로 교차하면서 이루어지는 반복적(iterative) 활동입니다.

---

1. 요구사항 도출 및 분석 (Requirements Elicitation and Analysis)

요구사항 도출 및 분석은 시스템의 이해관계자들과 협력하여 시스템이 제공해야 할 서비스, 시스템 성능, 하드웨어 제약 사항, 다른 시스템과의 연동 등을 파악하는 과정입니다. 이를 통해 시스템이 해결해야 할 문제와 필요한 기능을 명확히 합니다.

---

주요 내용:

• 요구사항 도출 (Requirements Elicitation or Requirements Discovery):
  • 소프트웨어 엔지니어가 다양한 시스템 이해관계자들과 협력하여 애플리케이션 도메인, 시스템이 제공해야 할 서비스, 요구되는 시스템 성능, 하드웨어 제약, 기타 시스템 등을 파악합니다.
• 요구사항 분석 (Requirements Analysis):
  • 수집된 요구사항을 분석하여 시스템 요구사항으로 구체화합니다. 이는 사용자 요구사항을 시스템 요구사항으로 변환하는 과정으로, 구조적 분석(SASD)이나 객체 지향 분석(OOAD) 등의 모델을 활용합니다.

---

요구사항 도출의 어려움:

• 이해관계자들이 실제로 원하는 것을 모를 때: 이해관계자들이 자신의 요구를 명확히 표현하지 못하거나, 요구사항이 모호할 수 있습니다.
• 이해관계자들이 자신의 용어로 요구사항을 표현할 때: 기술적 용어가 아닌 비즈니스 용어로 요구사항을 표현할 경우, 이를 정확히 해석하고 기술적 요구사항으로 변환하는 것이 어렵습니다.
• 이해관계자 간 요구사항 충돌: 다양한 이해관계자들이 서로 다른 요구사항을 가질 경우, 이를 조정하고 우선순위를 정하는 것이 필요합니다.
• 조직적 및 정치적 요인: 조직 내 권력 구조나 정치적 요인이 요구사항에 영향을 미칠 수 있습니다.
• 요구사항의 변화: 분석 과정 중에 새로운 이해관계자가 등장하거나 비즈니스 환경이 변화하면서 요구사항이 변경될 수 있습니다.

---

요구사항 도출 활동:

 

1. 요구사항 발견 (Requirements Discovery):
   • 이해관계자들과의 상호작용을 통해 요구사항을 발견합니다.
   • 도메인 요구사항도 이 단계에서 발견됩니다.
2. 요구사항 분류 및 조직 (Requirements Classification and Organization):
   • 관련된 요구사항을 그룹화하고 응집된 클러스터로 조직합니다.
3. 우선순위 지정 및 협상 (Prioritization and Negotiation):
   • 요구사항의 우선순위를 정하고, 요구사항 간의 충돌을 해결합니다.
4. 요구사항 명세 (Requirements Specification):
   • 요구사항을 문서화하여 다음 단계의 스파이럴(Spiral) 모델로 입력합니다.

---

요구사항 발견 기법:

 

1. 요구사항 워크숍 (Requirements Workshop)
2. 브레인스토밍 (Brainstorming)
3. 스토리보드 (Storyboards) 또는 유스케이스 시나리오 (Use-Case Scenario)
4. 인터뷰 (Interviews)
5. 설문지 (Questionnaires)
6. 역할 놀이 (Role Playing)
7. 프로토타입 (Prototypes)
8. 고객 요구사항 검토 (Customer Requirement Specification Review)

---

요구사항 분석 모델:

• 구조적 분석(SASD):
  • 데이터 흐름도(DFD, Data Flow Diagram)
  • 유한 상태 기계(FSM, Finite State Machine)
  • 엔터티-관계 다이어그램(ERD, Entity-Relationship Diagram)
• 객체 지향 분석(OOAD):
  • 유스케이스(Use Cases)
  • 시스템 시퀀스 다이어그램(SSD, System Sequence Diagram)
  • 도메인 모델(Domain Model)
  •  

---

2. 요구사항 명세 (Requirements Specification)

요구사항 명세는 사용자와 시스템의 요구사항을 요구사항 문서에 기록하는 과정입니다. 이 문서는 비기술 배경을 가진 최종 사용자와 고객이 이해할 수 있도록 작성되어야 합니다. 시스템 요구사항은 더 상세한 기술 정보를 포함할 수 있습니다.

주요 내용:

• 사용자 요구사항(User Requirements):
  • 최종 사용자와 고객이 이해할 수 있도록 작성됩니다.
  • 시스템이 수행해야 할 기능과 서비스에 중점을 둡니다.
• 시스템 요구사항(System Requirements):
  • 더 기술적이고 상세한 요구사항을 포함합니다.
  • 시스템의 내부 동작과 구조에 대한 설명을 포함할 수 있습니다.
• 계약의 일부:
  • 요구사항은 시스템 개발을 위한 계약의 일부가 될 수 있습니다.
  • 요구사항은 시스템이 무엇을 해야 하는지 명시하고, 설계는 그것을 어떻게 수행할지를 설명합니다.
• 요구사항과 설계의 분리:
  • 요구사항은 시스템이 수행해야 할 작업을 정의하고, 설계는 이를 구현하는 방법을 설명합니다.
  • 실제로는 요구사항과 설계가 분리되지 않고 함께 진행되는 경우가 많습니다.

---

소프트웨어 요구사항 문서(SRS, Software Requirements Specification):

• 정의: SRS는 시스템 개발자에게 요구되는 사항을 공식적으로 명시한 문서입니다.
• 포함 내용:
  • 사용자 요구사항과 시스템 요구사항의 정의
  • 시스템이 수행해야 할 기능 (What)
  • 시스템이 이를 수행하는 방법 (How)은 포함되지 않아야 합니다.
• 사용자:
  • 요구사항 문서는 개발자뿐만 아니라, 고객과 이해관계자에게도 중요한 참조 자료가 됩니다.

---

좋은 SRS의 특성들

---

SRS의 구성 요소:

1. 기능성(Functionality):
   • 소프트웨어가 수행해야 할 작업은 무엇인가?
2. 외부 인터페이스(External Interfaces):
   • 소프트웨어가 사람, 하드웨어, 다른 소프트웨어와 어떻게 상호작용하는가?
   • 이러한 외부 엔터티에 대한 가정은 무엇인가?
3. 필요한 성능(Required Performance):
   • 소프트웨어 기능의 속도, 가용성, 응답 시간, 복구 시간 등은 어떻게 되는가?
4. 품질 속성(Quality Attributes):
   • 이식성, 정확성, 유지보수성, 보안성 등은 어떻게 되는가?
5. 설계 제약(Design Constraints):
   • 구현에 필요한 표준, 사용 언어, 데이터베이스 무결성 정책, 자원 제한, 운영 환경 등은 무엇인가?

---

흔한 SRS 실수들

---

요구사항 문서의 변동성:

• 시스템 유형 및 개발 접근 방식에 따라 다름:
  • incremental하게 개발되는 시스템은 요구사항 문서에 덜 상세한 내용을 포함할 수 있습니다.
• 표준화된 요구사항 문서:
  • IEEE 표준 830-1998과 같은 요구사항 문서 표준이 존재합니다.
  • 주로 대규모 시스템 공학 프로젝트에 적용됩니다.

SRS 템플릿:

• IEEE Std 830-1998:
  • 소프트웨어 요구사항 명세를 작성하기 위한 표준 템플릿입니다.

 

---

3. 요구사항 검증 (Requirements Validation)

요구사항 검증은 시스템이 실제로 고객이 원하는 것을 정의하고 있는지, 요구사항이 정확하고 일관되며 완전한지를 확인하는 과정입니다. 요구사항 오류는 수정 비용이 매우 높기 때문에, 초기 단계에서 이를 발견하고 수정하는 것이 중요합니다.

주요 내용:

• 검증의 목적:
  • 시스템이 고객의 요구를 충족하는지 확인합니다.
  • 요구사항이 상호 일관되고, 완전하며, 현실적이고, 검증 가능한지를 평가합니다.
• 요구사항 오류 수정 비용:
  • 요구사항 오류를 시스템 전달 후에 수정하는 비용은 구현 오류 수정 비용의 최대 100배까지 증가할 수 있습니다.
• 요구사항 검증 기준:
  1. 타당성(Validity):
     • 시스템이 고객의 요구를 가장 잘 지원하는 기능을 제공하는가?
  2. 일관성(Consistency):
     • 요구사항 간에 충돌이 없는가?
  3. 완전성(Completeness):
     • 고객이 요구하는 모든 기능이 포함되어 있는가?
  4. 현실성(Realism):
     • 주어진 예산과 기술로 요구사항을 구현할 수 있는가?
  5. 검증 가능성(Verifiability):
     • 요구사항이 검증 가능한가?

---

요구사항 검증 기법:

1. 요구사항 리뷰 (Requirements Reviews):
   • 요구사항을 체계적으로 수동으로 분석하여 검토합니다.
2. 프로토타이핑 (Prototyping):
   • 시스템의 실행 가능한 모델을 사용하여 요구사항을 확인합니다.
3. 테스트 케이스 생성 (Test-Case Generation):
   • 요구사항의 테스트 가능성을 확인하기 위해 테스트 케이스를 개발합니다.

---

V-Model of Software V&V

V-Model은 소프트웨어 개발과 검증 과정을 V자 형태로 시각화한 모델로, 개발 단계와 이에 상응하는 테스트 단계를 병행하여 진행합니다. 이는 각 개발 단계에서 발생할 수 있는 오류를 조기에 발견하고 수정할 수 있게 도와줍니다.

 

---

4. 요구사항 변경 관리 (Requirements Change Management)

요구사항 변경 관리는 요구사항 공학 과정과 시스템 개발, 심지어 시스템 전달 후에도 변화하는 요구사항을 관리하는 과정입니다. 이는 요구사항 변경의 영향을 평가하고, 변경을 수용할지 여부를 결정하는 공식적인 프로세스를 필요로 합니다.

주요 내용:

• 요구사항 추적 및 관리:
  • 개별 요구사항을 추적하고, 의존 관계를 유지하여 요구사항 변경의 영향을 평가할 수 있어야 합니다.
• 변경 제안 프로세스:
  • 변경 제안을 공식화하고, 이를 시스템 요구사항과 연결하는 프로세스를 수립합니다.
• 변경 수용 결정:
  • 요구사항 변경을 수용할지 여부를 결정합니다.
• 요구사항 변경 관리 도구:
  • 요구사항부터 코드 및 테스트 케이스까지의 추적성을 유지하는 도구가 필요합니다.
  • CTIP (Continuous Testing and Integration Platform)과 같은 도구가 유용합니다.

 

---

요약

요구사항 공학 프로세스는 소프트웨어 개발의 성공을 좌우하는 핵심 요소로, 다음과 같은 네 가지 주요 활동으로 구성됩니다:

1. 요구사항 도출 및 분석 (Requirements Elicitation and Analysis):
   • 이해관계자와의 협력을 통해 시스템 요구사항을 파악하고 분석합니다.
2. 요구사항 명세 (Requirements Specification):
   • 사용자 요구사항과 시스템 요구사항을 문서화하여 명확히 정의합니다.
3. 요구사항 검증 (Requirements Validation):
   • 요구사항이 정확하고 일관되며 완전한지를 확인하여 오류를 사전에 방지합니다.
4. 요구사항 변경 관리 (Requirements Change Management):
   • 변화하는 요구사항을 체계적으로 관리하여 시스템 개발의 유연성과 일관성을 유지합니다.

이러한 활동들은 반복적이고 상호 교차하면서 수행되며, 조직의 목표에 따라 프로세스 개선과 성숙도 모델(CMMI 등)을 통해 지속적으로 향상될 수 있습니다. 효과적인 요구사항 공학은 고품질 소프트웨어 개발과 고객 만족을 달성하는 데 필수적인 요소입니다.