요구공학 프로세스

요구공학 프로세스

요구공학은 소프트웨어 시스템에 대한 이해 관계자의 요구와 기대를 식별, 도출, 분석, 명세, 검증 및 관리하는 프로세스다.

요구공학 프로세스는 다음과 같은 단계를 반복 프로세스다.

요구사항 도출

요구 사항 도출은 최종 사용자, 고객 및 기타 관련 당사자를 포함한 다양한 이해 관계자로부터 요구 사항을 수집하는 프로세스다. 이 프로세스에는 인터뷰, 설문 조사, 브레인스토밍 세션 및 포커스 그룹과 같은 다양한 기법을 사용하여 이해 관계자의 요구와 기대를 식별한다. 요구 사항 도출의 목표는 시스템 요구 사항을 포괄적이고 정확하게 이해하여 최종 제품이 이해 관계자의 요구와 기대를 충족하는지 확인하는 것이다. 효과적인 요구사항 도출은 소프트웨어 개발 프로젝트의 성공에 매우 중요하다. 개발 중인 시스템이 관련성 있고 사용 가능하며 사용자에게 가치가 있음을 보장하기 때문이다.

 

요구 사항 도출에 사용되는 다음과 같은 기법들이 있다.

 

1. 인터뷰: 이해관계자와의 일대일 세션을 통해 그들의 필요와 기대에 대한 정보를 수집.
2. 설문조사 및 설문지: 이해관계자의 의견과 피드백을 수집하기 위해 이해관계자에게 하는 질문 및 설문.
3. 관찰: 현재 시스템이나 환경을 활용하여 이해관계자를 직접 관찰하여 요구 사항을 식별.
4. 워크숍: 요구 사항 식별 및 우선순위 지정 위해 이해 관계자 간의 브레인스토밍 및 협업을 하는 그룹 세션.
5. 프로토타이핑: 이해 관계자로부터 피드백 수집하기 위해 시스템의 작업 모델 또는 프로토타입 제작.
6. 문서 분석: 사용자 매뉴얼, 기술 문서 등 기존 문서를 분석하여 요구 사항을 파악.
7. 포커스 그룹: 시스템에 대한 요구 사항과 의견을 논의하기 위해 이해 관계자와 그룹 세션.
8. 유저 스토리: 최종 사용자의 관점에서 특정 요구 사항을 설명하는 짧은 설명.
9. 유스 케이스: 액터 또는 사용자의 관점에서 시스템 동작에 대한 설명.

요구 사항 추출 기법의 선택은 이해 관계자의 가용성, 시스템의 복잡성, 프로젝트의 일정 및 예산과 같은 다양한 요인에 따라 달라진다. 기법을 조합해 사용하여 모든 이해 관계자의 요구와 기대를 포착할 수도 있다.

 

요구사항 분석

정식 소프트웨어 요구 사항 모델을 생성하는 데 사용된다. 기능적 요구사항뿐만 아니라 비기능적 요구사항 및 제약조건을 포함한 모든 요구사항은 이러한 모델에 의해 전체적으로 명시된다. 분석을 진행하는 동안 문제에 대한 추가 지식이 필요할 수 있고, 이는 요구사항 도출 과정을 다시 진행해야 할 수 있다. 

 

요구 사항 분석  에는 다음과 같은 다양한 기법이 사용된다.

1. 비즈니스 프로세스 모델링: 다이어그램과 모델을 만들어 시스템의 프로세스와 워크플로를 표현.
2. 데이터 흐름 다이어그램(DFD): 시스템을 통한 데이터 흐름을 보여주는 다이어그램.
3. 엔터티 관계 다이어그램(ERD): 시스템의 서로 다른 데이터 엔터티 간의 관계를 표현하는 다이어그램.
4. 기능 분해: 시스템의 기능을 더 작고 관리하기 쉬운 구성 요소로 분해.
5. 유스케이스 모델링: 사용자 관점에서 시스템의 동작을 설명.
6. 시나리오 및 스토리보드: 다양한 상황에서 시스템이 어떻게 사용되는지에 대한 시나리오 및 시각적 표현.
7. 프로토타이핑: 요구 사항을 검증하고 개선하기 위해 시스템의 작업 모델 또는 프로토타입을 제작.

 

요구사항 명세

요구 사항 명세는 분석 단계에서 식별된 요구 사항을 명확하고 모호하지 않게 설명하는 공식 문서를 작성하는 프로세스다. 이해 관계자의 요구와 기대를 정확하게 포함하는 구조화되고 조직화된 문서를 생성한다.

요구 사항 명세 단계에서 요구 사항은 상대적 중요도에 따라 우선순위 지정 통해 관리 가능한 그룹 또는 범주로 구성한다. 이를 통해 개발 팀은 가장 중요한 요구 사항에 먼저 집중할 수 있고 최종 제품의 품질과 적시에 개선할 수 있다.

이 단계에서 생성된 문서는 소프트웨어 설계 및 개발은 물론 테스트 및 검증의 기초 역할을 한다. 소프트웨어 개발 프로세스에 관련된 모든 이해당사자가 요구 사항을 명확하고 일관되게 이해하도록 하여 오해, 오류 및 충돌을 최소화한다. 궁극적으로 요구 사항 명세의 목표는 이해 관계자의 요구와 기대를 정확하게 반영하고 고품질 소프트웨어 시스템 개발을 위한 청사진 역할을 하는 문서를 작성하는 것이다.

일반적으로 요구사항에는 다음과 같은 몇 가지 유형이 있다.

• 기능 요구사항 - 소프트웨어 시스템이 수행해야 하는 작업. 입력 유효성 검사, 데이터 저장소 및 사용자 인터페이스와 같은 시스템이 제공해야 하는 기능.
• 비기능 요구사항 - 소프트웨어 시스템의 성능, 신뢰성, 사용성 및 보안과 같은 시스템의 품질 속성.
• 제약 사항: 소프트웨어 시스템을 개발할 때 고려해야 하는 모든 제한 사항 또는 제약 사항.
• 인수 기준: 소프트웨어 시스템의 개발 완료를 판단 위해 충족해야 하는 조건.

요구사항을 명확하게 하기 위해 요구사항은 자연어로 작성되어야 하며 기술적인 전문 용어를 피하고 문서 전반에 걸쳐 일관된 형식을 사용해야 한다. 요구사항을 효과적으로 전달하기 위해 다이어그램, 모델 및 기타 시각적 보조 도구를 사용하는 것도 중요하다.

 

요구사항 확인 및 검증

확인(Verification) 

확인은 소프트웨어 시스템 또는 모듈을 평가해 해당 요구 사항 및 기준을 충족하는지 확인하는 것이다.

소프트웨어 설계, 코드 및 문서를 검토하고 분석하여 의도한 기능을 올바르게 구현하고 예상대로 작동하는지 확인하는 것을 말한다. 

 

검증(Validation)

검증은 고객 요구사항에 부합하는 소프트웨어가 개발되었는지 확인하는 것이다. 만약 요구사항이 검증되지 않으면, 요구사항 정의에서의 오류가 후속 단계에 전파되어 많은 수정과 재작업이 필요해질 수 있다. 따라서 검증은 소프트웨어 개발 과정에서 고객 요구사항을 충족시키는 것이 목표다.

 

검증 단계에서는 다음과 같은 내용을 확인해야 한다.

- 모든 요구사항은 다른 요구사항과 모순이 없어야 한다, 즉 두 요구사항이 서로 충돌하지 않아야 한다.

- 요구사항은 모든 면에서 완전해야 한다.

- 요구사항은 실질적으로 달성 가능해야 한다.

이를 위해 사용되는 방법으로는 리뷰, 버디 체크, 테스트 케이스 등이 있다.

 

요구사항 확인 및 검증(V&V)은 소프트웨어 시스템의 요구사항이 완전하고 일관성 있으며 정확하며 이해관계자들의 요구와 기대를 충족하는지 확인하는 과정이다. V&V의 목표는 소프트웨어 시스템이 요구사항을 충족하고 제때에 예산 내에 필요한 품질로 개발되도록 보장하는 것이다.

 

• 확인(Verification)은 요구사항이 완전하고 일관성 있으며 정확한지 확인하는 과정이다. 이 과정은 요구사항이 명확하고 테스트 가능하며 오류 및 불일치가 없는지 확인하기 위한 요구사항을 검토한다. 주요 방법으로는 요구사항 문서, 모델 및 다이어그램 검토 및 이해관계자와의 회의와 워크스루등이 있다.
• 검증(Validation)은 요구사항이 이해관계자의 요구와 기대를 충족하는지 확인하는 과정이다. 이 과정은 요구사항이 유효하며 소프트웨어 시스템이 이해관계자의 요구 충족을 보장하기 위한 요구사항 테스트를 수행한다. 주요 방법으로는 시뮬레이션을 통한 소프트웨어 시스템 테스트, 프로토타입 테스트, 최종 소프트웨어 버전으로의 테스트 등이 있다.
• V&V는 소프트웨어 개발 생명주기 전반에 걸쳐 반복적으로 수행된다. 요구사항이 철저하게 검토되고 테스트되도록 이해관계자와 개발팀이 V&V 프로세스에 참여하는 것이 중요하다.

V&V는 일회성 프로세스가 아니며, 소프트웨어 개발 과정 전반 및 유지보수 단계에서도 통합되어 계속 수행되어야 한다.

요구사항 관리

요구 사항 관리는 요구 사항을 분석, 문서화, 추적, 우선 순위 지정 및 동의하고 관련 이해 관계자와의 커뮤니케이션을 통제하는 ​​프로세스다. 이 단계에서는 요구 사항 변화 관리를 수행 한다.

SRS(소프트웨어 요구 사항 설명서)가 가능한 한 유연하여 이후 단계에 최종 사용자가 지정한 요구 사항의 변경 사항이 관리될 수 있도록 하는 것이 중요한다. 요구 사항에 따라 체계적이고 통제되어 소프트웨어를 변경할 수 있게 하는 것은 요구공학 프로세스에서 매우 중요하다.

 

요구 사항 관리는 변경 사항 추적 및 통제를 포함하여 소프트웨어 개발 수명 주기 전체에서 요구 사항을 관리하고 요구 사항이 유효하고 관련성이 있는지 확인하는 프로세스다. 요구 사항 관리의 목표는 개발 중인 소프트웨어 시스템이 이해 관계자의 요구와 기대를 충족하고 시간과 예산 내에서 필요한 품질로 개발되도록 하는 것이다.

 

요구사항 관리와 관련된 주요 활동은 다음과 같다.

• 변경사항 추적 및 통제: 변경의 원인을 파악하고, 변경의 영향을 평가하고, 변경을 승인하거나 거부하는 등 개발 프로세스 전반에 걸쳐 요구사항에 대한 변경사항을 모니터링하고 통제.
• 버전 통제: 여러 버전의 요구사항 문서 및 기타 관련 아티팩트를 추적.
• 추적 관리: 설계, 테스트 및 검증과 같은 개발 프로세스의 다른 항목과 요구사항을 연결해 추적 관리.
• 커뮤니케이션: 요구사항이 모든 이해관계자에게 공유되고 모든 변경사항이나 문제가 적시에 해결되도록 의사소통.
• 모니터링 및 리포팅: 개발 프로세스의 진행 상황을 모니터링하고 요구 사항의 상태를 리포팅.

요구 공학의 장점

- 개발 중인 소프트웨어가 이해 관계자의 요구와 기대를 충족하도록 보장한다.

- 잠재적인 이슈 또는 문제를 개발 프로세스의 초기에 식별할 수 있으므로 중요한 문제가 발생하기 전에 조정할 수 있다.

- 소프트웨어가 비용 효율적이고 효과적인 방식으로 개발되도록 지원

- 개발 팀과 이해 관계자 간의 커뮤니케이션 및 협업을 개선할 수 있다.

 

요구 공학의 단점

- 요구 사항 관리는 특히 요구 사항 수집 프로세스가 제대로 관리되지 않는 경우 시간과 비용이 많이 소요될 수 있다.

- 요구 사항 관리 중에 모든 이해 관계자의 요구와 기대를 고려하는 것은 어려울 수 있다.

- 요구 사항 관리 중에 요구 사항이 명확하고 일관되고 완벽하게 확인하는 것은 어려울 수 있다.
- 요구사항이 변경되면 개발 프로세스가 지연되고 비용이 증가할 수 있다.