요구사항 도출의 어려움

요구사항 도출의 일반적 어려움

소프트웨어 공학에서 요구사항 도출은 사용자의 요구와 기대를 수집하고 문서화하는 과정으로, 다양한 요소들로 인해 어려울 수 있다.

요구사항 도출에서의 일반적인 어려움은 다음과 같다.

 

1. 불명확하고 변경되는 요구사항: 요구사항이 명확하게 정의되지 않거나 모호하거나 일관성이 없거나 시간에 따라 변경될 경우, 엔지니어가 사용자나 이해관계자들의 실제 요구를 이해하고 도출하기 어려울 수 있다. 

 

2. 다양한 이해관계자관리: 다양한 이해관계자들이 서로 다른 목표와 우선순위를 가지고 있을 경우, 서로 상충하는 요구사항을 조화시키고 우선순위를 정하는 것이 어려울 수 있다.

3. 의사소통 및 언어 장벽: 이해관계자와 엔지니어 간의 의사소통 불일치나 언어 장벽으로 인해 요구사항이 오해되거나 잘못 해석될 수 있어 정확하고 완전한 요구사항을 수집하는 데 어려움이 있을 수 있다.

4. 도메인 복잡성: 개발 중인 소프트웨어 시스템이 금융, 의료, 항공우주 등과 같이 복잡한 도메인에서 작동하는 경우, 도메인의 복잡성을 이해하고 요구사항을 정확하게 도출하는 것이 어려울 수 있다.

5. 변화하는 기술 환경: 기술 트렌드와 혁신이 빠르게 변화하며, 요구사항을 최신 기술 환경에 맞추고 이에 대응하는 것이 어려울 수 있다.

6. 예산 및 시간 제약: 제한된 예산과 제한된 시간이 요구사항 도출 노력에 영향을 미칠 수 있으며, 철저한 요구사항 분석과 검증을 수행하는 데에 시간과 자원의 제한이 있을 수 있다.

7. 사용자 참여 부족: 최종 사용자나 이해관계자들의 참여가 부족한 경우, 불완전하거나 부정확한 요구사항이도출될 수 있으며, 이에 따른 수정 및 보완이 어려울 수 있다.

8. 기존 시스템과의 통합: 기존 시스템과의 통합을 고려해야 하는 경우, 기존 시스템의 복잡성, 제약사항, 데이터 호환성 등을 고려하여 요구사항을 수집하는 것이 어려울 수 있다.

9. 변경 관리: 요구사항이 프로젝트 진행 중에 변경될 수 있으며, 이에 대한 변경 관리가 필요하다. 요구사항 변경의 파급효과와 우선순위를 정하는 것이 어려울 수 있다.

10. 완전한 요구사항 수집: 모든 요구사항을 완전하게 수집하는 것이 어려울 수 있다. 사용자의 요구사항을 모두 파악하고, 개발자가 이를 충족시키는 것은 어려운 작업일 수 있다.

요구사항 도출의 어려움은 소프트웨어 개발 프로세스의 초기 단계에서 중요한 문제로 작용할 수 있다. 따라서 요구사항 도출 단계에서의 어려움에 대비하고, 적절한 방법과 기술을 활용하여 요구사항을 정확하게 수집하고 관리하는 것이 중요하다.

 

요구사항 도출 단계의 고려 사항

요구사항 도출은 요구사항 공학 프로세스의 첫 번째 단계로, 분석가가 문제 영역에 대한 지식을 습득하고, 이를 토대로 소프트웨어의 공식적 명세를 생성하는 데 도움을 준다. 이 과정에서 다양한 문제와 어려움에 직면할 수 있다.

 

1. 크고(large) 복잡한(complex) 시스템 요구사항을 이해하는 것은 어렵다.

'large'라는 단어는 두 가지 측면으로 나타난다.
 - 사용자 수가 많아 보안 등의 제약이 크다.
 - 구현해야 할 기능 이 많다.

 

2. 시스템의 경계 미정: 정의된 구현 요구 사항 그룹이 없을 수 있다. 고객이 중요한 기능 외에 관련 없는 기능이나 불필요한 기능을 계속해서 포함할 수 있어 구현 비용이 매우 증가하여 결정된 예산을 초과할 수 있다.

 

3. 고객/이해 관계자들의 요구가 명확하지 않음: 때로 고객 자신이 소프트웨어에서 확인하고자 하는 모든 기능 목록에 대해 확신을 갖지 못할 수도 있다. 이러한 문제는 고객이 자신의 요구사항에 대해 매우 기본적인 개념을 가지고 있지만 구현 부분에 대해 계획을 많이 세우지 않은 경우에 발생할 수 있다. 

 

4. 상충하는 요구 사항이 존재함: 프로젝트의 서로 다른 이해 관계자가 서로 다른 구현을 요구할 수 있다. 또한 단일 이해 관계자가 때로는 상반되는 두 가지 요구 사항을 요청할 수도 있다.

 

5. 요구 사항 변경으로 인한 문제: 고객의 지속적인 인터뷰나 검토에서 초기에 정의된 요구 사항의 변경을 요구 할 수 있다. 일부 요구 사항을 수용하는 것은 쉽지만, 이러한 변경되는 요구 사항을 처리하는 것은 종종 어려울 수 있다.

 

6. 복잡성을 줄이기 위해 시스템을 적절하게 분할: 프로젝트는 때로는 작은 모듈이나 기능으로 분해하고 이를 별도의 팀이 처리한다. 보다 복잡하고 대규모 프로젝트는 종종 더 많은 분할이 필요하다. 분할된 부분이 서로 겹치지 않고 독립적인지 확인해야 한다.

 

7. 요구 사항의 검증 및 추적: 구현을 시작하기 전에 명시된 요구 사항을 상호 검토하는 것이 매우 중요하다. 또한 전방향 및 후방향 추적이 이루어져야 한다. 예를 들어, 모든 개체 이름은 어디서든 동일해야 한다.

즉 'STUDENT'과 'STUDENTES'이 같은 개체를 나타내는 데 별도의 위치에서 사용되서는 안된다.

 

8. 핵심적인 요구 사항 식별: 어떤 대가를 치르더라도 구현되어야 하는 요구 사항을 식별하는 것은 매우 중요하다. 요구 사항은 우선 순위를 매겨야 하며, 중요한 요구 사항이 가장 높은 우선순위로 먼저 구현될 수 있도록 해야 한다. 

 

9. 요구 사항의 "미결정(TBD: to be determined)" 부분 해결: TBD 요구 사항에는 미래에 해결되어야 할 요구 사항이 포함된다. 이러한 요구 사항의 수를 최소한으로 유지해야 한다.

 

10. 적절한 문서화, 적절한 회의 시간, 예산 제한: 적절한 문서화는 특히 변화하는 요구 사항의 경우 내재적인 이슈이다. 또한 시간 및 예산 제한도 신중하고 체계적으로 처리되어야 한다.

 

요구사항 도출에 있어 어려움을 극복하기 위한 해결책

1. 적절한 문서의 유지.
2. 이해관계자의 관점에서 이해하려고 노력.
3. 이해관계자와의 적절한 의사소통 확립.
4. 이해관계자 측에서 상충되는 요구 사항 파악.
5. 최종 사용자와 체계적이고 통찰력 있는 대화 구축.
6. 적절한 시장 조사 및 경쟁업체 분석 수행.

 

요구사항을 도출하는 장점

소프트웨어 엔지니어링에서 요구사항을 도출하는 이점은 다음과 같습니다:

1. 커뮤니케이션 향상: 요구사항을 도출하면 이해관계자, 개발자 및 사용자 간의 의사소통이 개선되어 사용자의 요구사항을 더 잘 이해하고 최종 제품을 더 성공적으로 만들 수 있다.

2. 재작업 감소: 개발 프로세스 초기에 요구사항을 파악하고 해결함으로써 엔지니어는 나중에 비용이 많이 드는 재작업의 가능성을 줄일 수 있다.

3. 사용자 만족도 향상: 엔지니어는 사용자의 요구를 완벽하게 이해하고 해결함으로써 사용자의 기대를 충족시키고 만족도를 높일 수 있는 소프트웨어를 만들 수 있다.

4. 시스템 품질 향상: 엔지니어는 요구사항과 관련된 위험을 식별하고 완화함으로써 시스템의 전반적인 품질을 개선할 수 있다.

5. 비즈니스 목표와의 연계 개선: 비즈니스 목표에 맞춰 요구사항을 조정함으로써 엔지니어는 소프트웨어가 고객의 전반적인 목표를 지원하는 방식으로 개발되도록 보장할 수 있다.

 

요구사항을 도출하는 단점

1. 시간 소모: 요구사항을 도출하는 것은 시간이 많이 소요되는 프로세스일 수 있으며, 이는 개발 프로세스를 지연시킬 수 있다.

2. 비용: 특히 여러 이해관계자가 참여하는 경우 요구사항을 수집하는 데 비용이 많이 들 수 있다.

3. 요구사항 변경 위험: 요구사항은 시간이 지남에 따라 변경될 수 있으며, 이로 인해 혼란이 발생할 수 있으며 변경된 요구사항에 맞춰 프로젝트를 진행하기 위해 추가 작업이 필요하다.

4. 모든 요구사항을 식별하는 어려움: 특히 복잡한 시스템이나 신기술을 다룰 때 모든 요구사항을 파악하는 것은 어려울 수 있다.

5. 미래 요구사항 예측의 어려움: 향후 요구 사항을 예측하기가 어려울 수 있으며, 이로 인해 소프트웨어가 구식이 되거나 재설계가 필요할 수 있다.

6. 사용자의 변화하는 요구사항을 처리하는 데 어려움: 사용자는 시스템을 사용하기 시작하면서 요구사항 수집 단계에서 예상하지 못한 것이 필요하다는 것을 깨달을 수 있다.

 

요구 공학에는 시스템 범위를 정의하는 문제, 제안된 시스템에 영향을 받는 다양한 커뮤니티 간의 이해 촉진 문제, 수요의 불안정성을 해결하는 문제 등 많은 문제가 있다. 이러한 문제들은 비지속 가능한 요구 사항을 생성하고, 프로그램 개발을 취소하거나, 그렇지 않으면 시스템 개발이 만족스럽지 않거나 받아들일 수 없다고 간주되거나, 고가의 수정 비용이 발생하거나, 변경의 대상이 될 수 있다. 서비스 개선을 통해 요구 공학 프로세스를 개선함으로써 시스템 요구 사항이 향상되고 더 나은 시스템이 개발될 수 있다.