소프트웨어 공학: 요구사항 확인 및 관리 - 소프트웨어 품질과 변화 대응을 위한 방법

 

요구사항을 추출하고 분석하는 것도 매우 어려운 일이지만,

요구사항을 검증하고 관리하는 것 역시 쉽지 않습니다.

이미 잘 알려진 내용이지만, 가볍게 한번 살펴 보겠습니다.

 

 

이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.

 

 

요구사항 확인 (Requirements Validation)

요구사항 확인은 요구사항이 실제로 고객이 원하는 시스템을 정의하고 있는지 확인하는 과정입니다. 이 과정은 요구사항 분석과 겹치는 부분이 있으며, 요구사항의 문제를 찾는 데 중점을 둡니다. 요구사항 문서에 오류가 있는 경우, 개발 중이나 시스템이 서비스에 들어간 후 문제가 발견되면 광범위한 재작업 비용이 발생할 수 있기 때문에 요구사항 검증은 매우 중요합니다.

요구사항 문제를 수정하기 위한 시스템 변경 비용은 일반적으로 설계나 코딩 오류를 수정하는 비용보다 훨씬 큽니다. 그 이유는 요구사항의 변경이 시스템 설계 및 구현의 변경을 의미하며, 이후 시스템을 다시 테스트해야 하기 때문입니다.

 

요구사항 검증 과정에서는 요구사항 문서에 대해 여러 가지 검토가 이루어져야 합니다. 이러한 검토에는 다음이 포함됩니다:

1. 타당성 검토(Validity checks): 사용자는 특정 기능을 수행하는 시스템이 필요하다고 생각할 수 있습니다. 그러나 추가적인 분석을 통해 추가 또는 다른 기능이 필요하다는 것이 밝혀질 수 있습니다. 시스템은 다양한 이해관계자가 존재하며, 모든 요구사항 세트는 이러한 이해관계자들 간의 타협의 결과입니다.
2. 일관성 검토(Consistency checks): 문서 내의 요구사항은 상충되어서는 안 됩니다. 즉, 모순된 제약 조건이나 동일한 시스템 기능에 대한 서로 다른 설명이 있어서는 안 됩니다.
3. 완전성 검토(Completeness checks): 요구사항 문서에는 시스템 사용자가 의도한 모든 기능과 제약 조건을 정의하는 요구사항이 포함되어야 합니다.
4. 현실성 검토(Realism checks): 기존 기술에 대한 지식을 활용하여 요구사항이 실제로 구현될 수 있는지 확인해야 합니다. 이 검토에서는 시스템 개발 예산과 일정도 고려해야 합니다.
5. 검증 가능성(Verifiability): 고객과 계약자 간의 분쟁 가능성을 줄이기 위해, 시스템 요구사항은 항상 검증 가능하도록 작성되어야 합니다. 이는 각 요구사항에 대해 테스트를 작성하여 전달된 시스템이 명시된 요구사항을 충족하는지 입증할 수 있어야 한다는 것을 의미합니다.

요구사항 확인 기법

요구사항 확인에는 개별적으로 또는 함께 사용할 수 있는 다양한 기법이 있습니다:

 

1. 요구사항 리뷰: 검토 팀이 요구사항을 체계적으로 분석하여 오류와 불일치를 확인합니다.
2. 프로토타이핑: 확인 접근 방식의 하나로, 시스템의 실행 가능한 모델을 최종 사용자와 고객에게 시연합니다. 이들은 이 모델을 실험하여 실제로 필요한 요구를 충족하는지 확인할 수 있습니다.
3. 테스트 케이스 생성: 요구사항은 테스트 가능해야 합니다. 요구사항에 대한 테스트를 확인 과정에서 설계하면 종종 요구사항 문제를 드러냅니다. 테스트 설계가 어렵거나 불가능한 경우, 이는 일반적으로 요구사항이 구현하기 어려울 것임을 의미하며, 이를 재고해야 합니다.

요구사항 확인에 수반되는 문제를 과소평가해서는 안 됩니다. 궁극적으로, 요구사항 세트가 실제로 사용자의 요구를 충족하는지 입증하기는 어렵습니다. 사용자는 시스템의 운영을 상상하고, 그 시스템이 작업에 어떻게 맞춰질지를 생각해 봐야 합니다. 숙련된 컴퓨터 전문가에게도 이러한 추상적 분석을 수행하는 것은 어려우며, 시스템 사용자에게는 더욱 어려울 수 있습니다. 이로 인해 요구사항 검증 과정에서 모든 요구사항 문제를 찾는 경우는 드뭅니다. 요구사항 문서가 합의된 후에도 누락된 부분과 오해를 수정하기 위해 추가적인 요구사항 변경이 불가피합니다.

 

요구사항 관리 (Requirements Management)

대규모 소프트웨어 시스템의 요구사항은 항상 변화합니다. 그 이유 중 하나는 이러한 시스템이 ’악성 문제(wicked problem)’를 해결하기 위해 개발되기 때문입니다. 이러한 문제는 완전히 정의할 수 없기 때문에, 소프트웨어 요구사항은 불완전할 수밖에 없습니다.

소프트웨어 개발 과정에서 이해관계자의 문제에 대한 이해가 지속적으로 변화하게 되면, 시스템 요구사항도 이러한 변경된 문제를 반영하여 진화해야 합니다.

다음 그림 4.17은 초기 문제에서 요구사항이 생성되고, 여러 이유에 의해 변경이 발생하며, 이를 반영해 변경된 요구사항이 시간 흐름에 따라 필수적으로 발생함을 나타내고 있습니다.

그림 4.17 요구사항 진화(Evolution)

 

요구사항 관리란 시스템 요구사항에 대한 변경을 이해하고 통제하는 과정입니다. 개별 요구사항을 추적하고, 상호 의존적인 요구사항 간의 링크를 유지하여 요구사항 변경의 영향을 평가할 수 있어야 합니다. 요구사항 문서의 초안이 준비되면 공식적인 요구사항 관리 프로세스를 시작해야 하며, 요구사항 추출 과정 동안 변경 관리 계획을 세워야 합니다.

 

1. 요구사항 관리 계획

요구사항 관리 프로세스의 첫 번째 단계는 계획입니다. 계획 단계에서는 요구사항 관리의 세부 사항 수준을 설정합니다. 이 단계에서 결정해야 할 사항은 다음과 같습니다:

 

1. 요구사항 식별: 각 요구사항은 고유하게 식별되어야 하며, 이를 통해 다른 요구사항과 교차 참조하거나 추적 가능성 평가에 사용할 수 있어야 합니다.

2. 변경 관리 프로세스: 변경의 영향을 평가하고 비용을 산정하는 활동 세트를 정의해야 합니다. (그림 4.18은 이러한 변경 관리 흐름을 보여주고 있습니다.

그림 4.18 요구사항 변경 관리

3. 추적 정책: 각 요구사항 간의 관계와 요구사항과 시스템 설계 간의 관계를 정의하는 정책을 마련해야 합니다.

4. 도구 지원: 요구사항 관리는 대량의 정보를 처리해야 하므로, 이를 지원할 소프트웨어 도구를 선택해야 합니다.

 

요구사항 관리 도구는 요구사항 저장, 변경 관리, 추적성 관리에 대한 지원을 제공할 수 있어야 하며, 이를 통해 요구사항 문서를 효율적으로 관리할 수 있습니다.

 

1. 요구사항 저장: 요구사항은 보안이 유지된 관리 데이터 스토어에 저장되어야 하며, 이는 요구사항 엔지니어링 프로세스에 참여하는 모든 사람이 접근할 수 있어야 합니다.

2. 변경 관리: 변경 관리 프로세스는 도구의 적극적인 지원이 있을 경우 더 간단해집니다.

3. 추적성 관리: 추적성 관리를 위한 도구 지원은 관련된 요구사항을 발견하는 데 도움을 줍니다. 일부 도구는 자연어 처리 기술을 사용하여 요구사항 간의 가능한 관계를 발견하는 데 도움을 줍니다.

 

소규모 시스템의 경우, 전문화된 요구사항 관리 도구를 사용할 필요가 없을 수도 있습니다. 워드 프로세서, 스프레드시트, PC 데이터베이스에서 제공하는 기능을 사용하여 요구사항 관리 프로세스를 지원할 수 있습니다. 그러나 대규모 시스템의 경우, 보다 전문화된 도구 지원이 필요합니다. 책의 웹 페이지에 요구사항 관리 도구에 대한 정보 링크를 포함시켰습니다.

 

2. 요구사항 변경 관리

요구사항 변경 관리는 요구사항 문서가 승인된 후 시스템의 요구사항에 대한 모든 제안된 변경 사항에 적용되어야 합니다 (그림 4.18 참조). 변경 관리는 새로운 요구사항을 구현하는 것이 그 구현 비용에 비해 이점이 있는지 결정해야 하므로 필수적입니다. 공식적인 변경 관리 프로세스를 사용하는 장점은 모든 변경 제안이 일관되게 처리되고 요구사항 문서에 대한 변경이 통제된 방식으로 이루어진다는 점입니다.

 

변경 관리 프로세스에는 세 가지 주요 단계가 있습니다:

 

1. 문제 분석 및 변경 명세: 이 과정은 식별된 요구사항 문제 또는 특정 변경 제안에서 시작됩니다. 이 단계에서 문제나 변경 제안을 분석하여 그 타당성을 확인합니다. 이 분석 결과는 변경 요청자에게 피드백되며, 요청자는 이를 바탕으로 더 구체적인 요구사항 변경 제안을 할 수도 있고, 요청을 철회할 수도 있습니다.

2. 변경 분석 및 비용 산정: 제안된 변경의 영향을 추적성 정보와 시스템 요구사항에 대한 일반적인 지식을 사용하여 평가합니다. 변경 작업에 소요되는 비용은 요구사항 문서의 수정과, 필요시, 시스템 설계 및 구현의 수정 측면에서 추정됩니다. 이 분석이 완료되면 요구사항 변경을 진행할지 여부가 결정됩니다.

3. 변경 구현: 요구사항 문서와, 필요시, 시스템 설계 및 구현이 수정됩니다. 요구사항 문서는 광범위한 재작성이나 재구성을 필요로 하지 않도록 체계적으로 구성해야 합니다. 프로그램과 마찬가지로, 문서의 변경 가능성은 외부 참조를 최소화하고 문서 섹션을 가능한 모듈화함으로써 달성됩니다. 이를 통해 개별 섹션을 다른 문서 부분에 영향을 미치지 않고 변경 및 교체할 수 있습니다.

 

새로운 요구사항을 긴급하게 구현해야 하는 경우, 시스템을 변경한 다음 요구사항 문서를 소급적으로 수정하려는 유혹이 있을 수 있습니다. 그러나 이는 거의 대부분의 경우, 요구사항 명세와 시스템 구현 간의 불일치를 초래하므로 피하는 것이 좋습니다. 시스템 변경이 이루어진 후에는 이러한 변경 사항을 요구사항 문서에 포함시키는 것을 잊기 쉽거나, 구현과 일치하지 않는 정보를 요구사항 문서에 추가하게 될 수 있습니다.

 

애자일 개발 프로세스, 예를 들어 익스트림 프로그래밍(Extreme Programming)과 같은 방법은 개발 과정에서 요구사항이 변경되는 상황에 대처하도록 설계되었습니다. 이러한 프로세스에서는 사용자가 요구사항 변경을 제안할 때, 이 변경은 공식적인 변경 관리 프로세스를 거치지 않습니다. 대신 사용자는 해당 변경의 우선순위를 정하고, 우선순위가 높은 경우 다음 반복(iteration)에서 계획된 시스템 기능 중 어떤 것을 제외할지 결정해야 합니다.