요구사항 관리

요구사항 관리

요구사항 관리는 소프트웨어 개발 프로세스에서 요구사항을 수집, 문서화, 분석, 추적, 검증 및 관리하는 프로세스입니다. 이는 소프트웨어 개발의 초기부터 마지막까지 지속적으로 이루어지며, 소프트웨어의 품질과 성과에 중요한 영향을 미칩니다.

요구사항 관리는 다음과 같은 주요 활동을 포함합니다:

1. 요구사항 식별 (Requirements Identification):
   • 이해관계자와의 소통을 통해 시스템 또는 소프트웨어에 대한 요구사항을 식별합니다. 이를 위해 다양한 기법이 사용될 수 있으며, 이를 통해 요구사항이나 변경 요청을 도출합니다.
2. 요구사항 문서화 (Requirements Documentation):
   • 수집된 요구사항을 명확하게 문서화하여 요구사항 명세서를 작성합니다. 요구사항 명세서는 이해관계자들 간에 요구사항을 이해하고 공유하는 데 사용됩니다.
3. 요구사항 분석 (Requirements Analysis):
   • 수집된 요구사항을 분석하여 모순되거나 불완전한 부분을 식별하고 명확한 이해관계자의 요구사항을 도출합니다.
4. 요구사항 추적 (Requirements Traceability):
   • 요구사항이 변경될 경우, 해당 변경 사항을 추적하고 요구사항 간의 관계를 관리합니다. 이를 통해 요구사항 변경이 프로젝트 일정 및 예산에 미치는 영향을 파악할 수 있습니다.
5. 요구사항 검증 (Requirements Validation):
   • 명세된 요구사항이 시스템이나 소프트웨어의 요구사항을 충족시키는지를 확인하는 과정을 수행합니다. 이를 통해 시스템이나 소프트웨어가 이해관계자의 요구를 만족시키고 있는지를 확인할 수 있습니다

 

SDLC 요구 사항 관리의 개념

소프트웨어 개발 생명주기(SDLC)에서 요구사항 관리는 중요한 부분을 차지하며, 다음과 같은 절차를 따릅니다:

1. 요구사항 식별 (Requirements Identification):
   • 이해관계자와의 회의, 인터뷰, 설문조사 등을 통해 시스템 또는 소프트웨어에 대한 요구사항을 수집합니다.
   • 요구사항은 기능적 요구사항과 비기능적 요구사항으로 나뉘며, 이를 통해 시스템이나 소프트웨어가 가져야 할 기능과 제약사항을 명확히 합니다.
2. 요구사항 분석 (Requirements Analysis):
   • 수집된 요구사항을 분석하여 모순되거나 불완전한 부분을 식별하고, 이를 해결하기 위한 조치를 취합니다.
   • 요구사항의 우선순위를 결정하고, 필요한 경우 요구사항을 세부화하여 명세합니다.
3. 요구사항 문서화 (Requirements Documentation):
   • 분석된 요구사항을 명세서로 문서화하여 요구사항 명세서를 작성합니다.
   • 요구사항 명세서에는 요구사항의 상세한 설명, 우선순위, 변경 이력 등이 포함됩니다.
4. 요구사항 검증 (Requirements Validation):
   • 명세된 요구사항이 시스템이나 소프트웨어의 요구사항을 충족시키는지를 검증합니다.
   • 이를 위해 다양한 검증 기법이 사용될 수 있으며, 이를 통해 요구사항이 완전하고 일관성 있으며 정확하게 이해되었는지를 확인합니다.
5. 요구사항 관리 (Requirements Management):
   • 요구사항이 변경될 경우, 해당 변경 사항을 추적하고 관리하는 프로세스를 설정합니다.
   • 변경 관리 및 버전 관리를 통해 요구사항의 변경에 따라 프로젝트 일정 및 예산을 조정할 수 있도록 합니다.

 

CMMI(통합 성숙도 모델 통합)

CMMI(통합 성숙도 모델 통합)는 조직의 프로세스 향상 및 성숙도를 평가하고 향상시키기 위한 프레임워크입니다. 소프트웨어 및 시스템 개발 프로세스의 성숙도를 다섯 가지 수준으로 평가하고 개선하는데 사용됩니다.

CMMI는 두 가지 주요 모델을 포함하고 있습니다: CMMI-DEV(개발) 및 CMMI-SVC(서비스).

CMMI-DEV는 소프트웨어 및 시스템 개발 조직의 프로세스를 평가하고 개선하는데 사용됩니다. 이 모델은 소프트웨어 및 시스템 개발 프로세스를 개선하기 위한 최적의 실천 방법을 제공합니다.

CMMI-SVC는 서비스 제공 조직의 프로세스를 평가하고 개선하는데 사용됩니다. 이 모델은 서비스 프로세스의 성숙도를 다섯 가지 수준으로 평가하고 개선하는데 도움이 됩니다.

CMMI 모델은 성숙도 수준 및 프로세스 영역에 대한 다양한 지침과 평가 기준을 제공합니다. 조직은 자체 프로세스와 CMMI 모델 간의 차이를 식별하고 프로세스를 개선하기 위한 계획을 수립할 수 있습니다. CMMI 평가는 조직의 프로세스 향상을 위한 중요한 지침을 제공하며, 효율적인 프로세스를 개발하고 유지하는데 도움이 됩니다.

 

CMMI(Capability Maturity Model Integration)는 소프트웨어 및 시스템 개발 조직의 성숙도를 다섯 가지 수준으로 평가합니다. 다음은 CMMI의 다섯 가지 성숙도 수준입니다:

1. Initial (초기 수준):
   • 프로세스가 무질서하고 비예측적인 상태입니다. 프로젝트는 주로 개별 노력에 의존하며, 프로세스의 일관성이 부족합니다.
2. Managed (관리된 수준):
   • 프로세스를 관리하기 시작하는 단계입니다. 프로세스의 일관성과 예측 가능성을 향상시키기 위한 노력이 이루어집니다. 기본 프로세스를 문서화하고 관리하는데 초점이 있습니다.
3. Defined (정의된 수준):
   • 프로세스가 프로젝트 간에 일관되게 정의되고 관리되는 단계입니다. 프로세스의 성과를 지속적으로 측정하고 향상시키는데 초점이 있습니다.
4. Quantitatively Managed (정량화된 관리 수준):
   • 정량적인 데이터를 사용하여 프로세스를 지속적으로 관리하는 단계입니다. 프로세스 성과에 대한 측정 및 분석을 통해 품질을 개선하는 것에 중점을 둡니다.
5. Optimizing (최적화된 수준):
   • 프로세스를 지속적으로 향상시키기 위한 단계입니다. 조직은 프로세스를 지속적으로 분석하고 개선하기 위한 노력을 기울입니다. 혁신과 학습을 촉진하며, 조직의 능력을 지속적으로 향상시킵니다.

 

요구사항 관리 프로세스

1. 요구사항 협상 (Requirements Negotiation):
   • 이해관계자들 간의 요구사항을 조율하고 협상하는 과정입니다. 프로젝트 이해관계자들 간에 충돌하는 요구사항이 있을 수 있으며, 이를 협상하여 모든 이해관계자의 요구를 조율해야 합니다.
2. 요구사항 베이스라인(기준선) 설정 (Requirements Baseline):
   • 요구사항 베이스라인은 프로젝트의 기본적인 요구사항을 문서화하고 승인하는 것을 의미합니다. 이는 프로젝트의 범위를 정의하고 변경 관리의 기준이 됩니다.
3. 요구사항 변경관리 (Requirements Change Management):
   • 요구사항이 변경될 경우, 이를 관리하고 추적하는 프로세스를 설정합니다. 변경 요청을 식별하고 검토하여 승인 또는 거부하고, 승인된 변경 사항을 추적하고 관리합니다.
4. 요구사항 확인 및 검증 (Requirements Verification and Validation):
   • 요구사항이 시스템 또는 소프트웨어의 기능과 제약사항을 충족시키는지 확인하고 검증하는 프로세스입니다.
   • 요구사항 확인은 시스템이 요구사항을 올바르게 구현하고 있는지를 확인하는 것을 의미합니다.
   • 요구사항 검증은 시스템 또는 소프트웨어가 실제 사용 환경에서 요구사항을 충족시키는지를 확인하는 것을 의미합니다.

 

인수 테스트(Acceptance Testing)는 소프트웨어 개발의 마지막 단계로, 개발된 소프트웨어가 최종 사용자 또는 고객의 요구사항을 충족시키는지를 검증하는 프로세스입니다. 이는 고객 또는 최종 사용자가 소프트웨어를 수락하고 사용할 준비가 되었는지를 확인하기 위해 수행됩니다.

인수 테스트는 크게 알파 테스트(Alpha Testing)와 베타 테스트(Beta Testing)로 나뉩니다:

1. 알파 테스트(Alpha Testing):
   • 소프트웨어 개발 과정 중 내부에서 진행되는 테스트로, 개발자나 테스터들이 소프트웨어를 실제로 사용하고 테스트하는 것을 의미합니다.
   • 알파 테스트는 소프트웨어의 초기 버전을 검증하고, 기능적인 결함을 식별하여 수정하는 데 사용됩니다. 이는 내부 직원들이나 개발팀 내에서 진행되는 것이 일반적입니다.
2. 베타 테스트(Beta Testing):
   • 알파 테스트 이후에 공개 베타 테스트 버전으로 소프트웨어를 배포하고, 실제 사용자들이 소프트웨어를 사용하고 테스트하는 것을 의미합니다.
   • 베타 테스트는 소프트웨어가 실제 환경에서 어떻게 작동하는지를 평가하고, 사용자들의 피드백을 수집하여 최종 제품을 개선하는 데 사용됩니다.

알파 테스트와 베타 테스트는 모두 소프트웨어의 품질을 향상시키고 사용자들의 요구를 반영하는 데 중요한 역할을 합니다. 알파 테스트는 개발 초기에 결함을 식별하고 수정하는 데 도움을 주며, 베타 테스트는 최종 사용자들의 피드백을 수집하여 소프트웨어를 완성하는 데 기여합니다.

 

모델 품질 검증(Model Quality Validation)

모델 품질 검증(Model Quality Validation)은 개발된 모델이나 시스템이 일정한 품질 기준을 충족하는지를 확인하는 과정을 말합니다. 주로 다음과 같은 방법으로 수행됩니다:

1. 정확성 평가: 모델이 실제 시스템이나 현상을 정확하게 반영하는지를 확인합니다. 이를 위해 데이터의 신뢰성과 모델의 예측 정확성을 평가합니다.
2. 일반화 가능성 검증: 모델이 다양한 조건이나 환경에서도 적용 가능한지를 확인합니다. 모델이 특정 상황에만 적용 가능하거나 제한적인 경우에는 이를 개선하거나 보완해야 합니다.
3. 간결성 확인: 모델이 간결하고 명확하게 구성되어 있는지를 평가합니다. 복잡한 모델은 해석이 어려울 수 있으므로, 모델의 간결성은 중요합니다.

정적분석(Static Analysis)은 소프트웨어나 모델의 소스 코드를 분석하여 프로그램의 동작을 이해하고 결함을 찾는 과정을 말합니다. 이는 소스 코드를 실행하지 않고도 프로그램의 오류를 탐지하고 해결할 수 있는 강력한 도구입니다. 정적분석은 다음과 같은 목적으로 사용됩니다:

1. 코드 품질 평가: 코드의 구조와 스타일을 평가하여 코드 품질을 향상시킵니다.
2. 보안 취약점 탐지: 코드에 존재하는 보안 취약점을 식별하고 해결합니다.
3. 성능 최적화: 코드의 성능을 분석하여 최적화할 수 있는 부분을 찾아 개선합니다.

동적분석(Dynamic Analysis)은 소프트웨어나 모델을 실행하고 그 결과를 분석하여 동작을 평가하는 과정을 말합니다. 주로 다음과 같은 목적으로 사용됩니다:

1. 실행 경로 분석: 프로그램이 실제로 어떻게 동작하는지를 이해합니다.
2. 메모리 누수 검사: 프로그램이 메모리를 적절하게 사용하는지 확인합니다.
3. 성능 분석: 프로그램의 실행 시간이나 자원 사용량을 측정하여 성능을 평가합니다.

요구사항 검토(Requirements Review)는 소프트웨어 요구사항 명세서를 분석하여 논리적, 기능적, 비기능적인 측면에서 완전하고 일관성 있는지를 확인하는 과정을 말합니다. 이는 요구사항이 명확하게 정의되어 있고, 이해관계자들의 요구사항을 충족시키는지를 검증하기 위해 수행됩니다. 요구사항 검토는 팀원들 간의 의견을 교환하고 결함을 식별하여 조기에 수정함으로써 소프트웨어의 품질을 향상시키는 데 도움이 됩니다.

 

 

테스트 레벨

소프트웨어 테스트에서는 다양한 테스트 레벨이 존재하며, 각 레벨은 특정한 목적과 범위를 갖습니다. 가장 일반적으로 사용되는 테스트 레벨은 다음과 같습니다:

1. 단위 테스트(Unit Testing):
   • 소프트웨어의 가장 작은 단위인 모듈 또는 함수를 개별적으로 테스트하는 것입니다. 주로 프로그래머가 단위 테스트를 작성하며, 모듈이 의도된 대로 동작하는지를 확인합니다.
2. 통합 테스트(Integration Testing):
   • 단위 테스트된 모듈을 결합하여 상호작용하고 통합된 소프트웨어를 테스트합니다. 모듈 간의 인터페이스와 상호작용을 검증하고, 모듈 간의 결합에 따른 문제를 식별합니다.
3. 시스템 테스트(System Testing):
   • 통합된 시스템 전체를 테스트하여 전반적인 기능과 비기능적 요구사항을 검증합니다. 시스템 테스트는 사용자의 시나리오에 따라 테스트 케이스를 실행하고, 시스템이 사용자 요구를 충족시키는지를 확인합니다.
4. 인수 테스트(Acceptance Testing):
   • 최종 사용자 또는 고객이 시스템을 테스트하고 승인하는 것을 의미합니다. 사용자가 실제로 시스템을 사용하고 요구사항을 충족시키는지를 평가하며, 시스템이 사용자 요구를 충분히 충족하는지 확인합니다.

이러한 테스트 레벨은 소프트웨어 개발 프로세스의 다양한 단계에서 사용됩니다. 단위 테스트와 통합 테스트는 주로 개발 초기에 수행되며, 시스템 테스트와 인수 테스트는 개발이 완료된 후에 진행됩니다. 이러한 다양한 테스트 레벨은 소프트웨어 품질을 보장하고 문제를 조기에 식별하여 수정할 수 있도록 도와줍니다.