요구사항 추출

요구사항 추출

요구 사항 추출은 경영자, 최종 사용자 및 기술 전문가와 같은 다양한 이해 관계자로부터 소프트웨어 시스템의 요구 사항과 요구 사항을 수집하고 정의하는 중요한 프로세스다.

고객의 기대치를 명확하고 포괄적으로 이해하기 위해 요구 사항을 식별, 수집, 분석 및 개선하는 작업을 수행한다. 이 프로세스는 일반적으로 설계 및 개발 단계를 위한 견고한 기반을 구축하기 위해 소프트웨어 개발 프로젝트 초기에 수행된다. 요구사항 추출의 결과는 소프트웨어 개발 팀의 기본 원칙 역할을 하는 명확하고 간결하며 잘 정의된 요구사항 명세서다.

 

요구사항 추출은 소프트웨어 개발에서 가장 어렵고 오류가 발생하기 쉬운 작업 중 하나다. 사용자의 진정한 요구 사항을 명확하게 이해하려면 고객과 개발자 간의 효과적인 커뮤니케이션과 협업이 필요하다.

소프트웨어 개발 팀이 사용자의 기대에 부합하는 요구 사항을 정확하게 식별하고 수집하기 위해서는 고객과 개발자 간의 강력한 파트너십이 요구되며 이는 성공적인 요구 사항 추출에 필수 적이다.

사용자의 요구 사항을 충족하고 가치를 제공하는 소프트웨어를 개발하려면 사용자의 실제 요구 사항을 이해하는 것이 중요하다.

 

요구사항 추출 주요 활동

-  시스템이 적용될 광범위한 도메인 또는 컨텍스트 이해.

-  시스템이 구현될 고객이 직면한 특정 문제(Pain-Point)를 철저히 이해.

-  외부 요구 사항과 시스템의 상호 작용.

-  사용자 요구에 대한 상세 조사.

- 시스템 개발을 위한 제약 조건 정의.

 

요구사항 추출 방법

요구사항 추출에 활용 되는 몇 가지  방법

- 인터뷰
- 브레인스토밍 세션
- FAST(Facilitated Application Specification Technique)
- 품질 기능 전개(QFD: Quality Function Deployment)
- 유즈 케이스(Use Case) 접근법

 

사용된 추출 기법의 효율성은 관련된 분석가, 개발자, 사용자 및 고객의 경험과 전문 지식에 따라 달라진다.

 

1. 인터뷰

인터뷰를 실시하는 목적은 소프트웨어에 대한 고객의 기대를 이해하는 것이다. 
모든 이해관계자를 인터뷰하는 것은 불가능하기 때문에 그룹의 대표자들을 그들의 전문성과 신뢰도에 근거하여 선발한다.

 

인터뷰 방식에는 자유로운 방식과 좀 더 체계적인 방법이 있다.

자유로운 인터뷰는 미리 정해진 의제가 없다. 문제에 대한 포괄적인 이해를 얻기 위해 자유로운 질문을 한다.

체계적인 인터뷰는 질문을 미리 정의해 준비한다. 때로는 공식 설문지를 통해 인터뷰를 진행하기도 한다.

 

인터뷰는 일반적으로 다음과 같이 진행한다.

• 계획: 인터뷰의 목적과 범위를 정의하고, 인터뷰할 이해관계자를 식별하고, 인터뷰 형식(예: 자유로운, 체계적인) 및 물류(예: 위치, 기간, 참가자)를 결정한다.
• 준비: 추출 프로세스의 목표와 이해관계자의 특정 지식 및 전문성을 기반으로 인터뷰 중에 다룰 질문 또는 주제 목록을 개발한다. 인터뷰 가이드, 설문지 또는 프로토타입과 같은 필요한 자료를 준비한다.
• 인터뷰 수행: 미리 결정된 형식에 따라 선정된 이해 관계자와 인터뷰를 수행하고 관련 질문을 하여 개발 중인 소프트웨어 또는 시스템과 관련된 요구, 기대, 선호도 및 제약 조건에 대한 정보를 수집한다. 적극적으로 경청하고, 메모하고, 이해 관계자가 통찰력, 우려 및 아이디어를 공유하도록 격려한다. 
• 녹음 및 문서화: 허용되는 경우 인터뷰를 녹음하거나 인터뷰 도중 및 인터뷰 후에 얻은 정보를 추출하기 위해 자세한 메모를 작성한다. 질문에 대한 응답, 관찰, 이해 관계자가 제공한 추가 통찰력 또는 피드백을 포함하여 인터뷰 결과를 문서화한다.
• 분석: 인터뷰에서 수집된 데이터를 분석하고 일반적인 패턴, 경향 및 주제를 식별하고 수집된 요구 사항 또는 통찰력을 분류한다. 이 분석을 사용하여 요구 사항을 더욱 구체화하고 우선순위를 지정하고 추가 설명이 필요할 수 있는 차이 또는 불일치를 식별한다. 
• 확인 및 검증: 정확성, 완전성 및 관련성을 보장하기 위해 이해 관계자와 함께 수집된 요구 사항을 검증한다. 모호하거나 불명확한 요구 사항에 대한 피드백과 설명을 구하여 요구 사항이 이해 관계자의 요구와 기대를 정확하게 반영하도록 한다.

요구 사항 도출을 위한 인터뷰 방법은 이해 관계자의 관점에 대한 통찰력을 얻고 요구 사항을 이해하며 가정을 검증하는 데 유용한 기법이다. 소프트웨어 개발 프로세스에서 추가로 사용할 수 있도록 요구 사항을 정확하게 추출하고 문서화하려면 효과적인 의사소통 기술, 적극적인 경청 및 신중한 문서화가 필요하다.

 

2. 브레인스토밍

브레인스토밍은 문제나 과제에 대한 많은 아이디어나 솔루션을 도출하는 데 사용되는 그룹 기술이다. 창의성, 혁신 및 다양한 관점을 장려하기 위해 팀 구성원 간의 개방적이고 자유로운 토론을 진행한다. 브레인스토밍의 목표는 즉각적인 판단이나 평가 없이 광범위한 아이디어를 생성하는 것이며 나중에 이러한 아이디어를 다듬고 추가 고려를 위해 우선순위를 지정할 수 있다. 브레인스토밍은 비즈니스, 혁신, 문제 해결 등 다양한 분야에서 일반적으로 사용된다. 

 

브레인스토밍에 사용할 수 있는 몇 가지 방법이 있다.

• 전통적인 브레인스토밍: 이 방법에서 팀원들은 제약이나 비판 없이 자유롭게 아이디어를 공유한다. 모든 아이디어는 판단 없이 기록되며 품질보다는 양에 중점을 둔다.
• 역방향 브레인스토밍: 이 방법에서 팀은 문제를 생성하거나 악화시키는 방법에 대한 아이디어를 도출하는 데 집중한 다음 아이디어를 뒤집어 잠재적인 솔루션 또는 개선 사항을 식별한다.
• 라운드 로빈 브레인스토밍(Round-Robin Brainstorming): 이 방법에서는 팀원들이 과정 중에 토론이나 평가 없이 구조화된 방식으로 차례로 아이디어를 하나씩 공유한다.
• 명목 그룹 기법: 이 방법에서는 팀원들이 독립적으로 아이디어를 생성한 다음 라운드 로빈 방식으로 공유한다. 그런 다음 팀에서 아이디어를 종합적으로 평가하고 우선순위를 지정한다.
• 마인드 매핑(Mind Mapping): 이 방법은 다이어그램을 사용하여 아이디어를 시각적으로 매핑하고 주요 문제 또는 과제를 중심에 두고 비선형 및 연관 방식으로 아이디어를 분기한다.
• 6가지 생각하는 모자(Six Thinking Hats): 이 방법에서 팀원들은 다양한 관점(예: 창의적, 비판적, 낙관적, 비관적)을 나타내는 다양한 "모자"를 쓰고 이러한 관점에서 아이디어를 도출한다. 
• 조용한 브레인스토밍: 이 방법에서는 팀 구성원이 스티커 메모나 카드에 아이디어를 개별적으로 기록한 다음 브레인스토밍 과정에서 구두 의사소통 없이 토론을 위해 수집 및 구성한다.

 

3. FAST(Facilitated Application Specification Technique)

FAST(Facilitated Application Specification Technique)는 이해 관계자로부터 요구 사항 및 사양을 수집하기 위해 소프트웨어 개발에 사용되는 협업 방식이다. 소프트웨어 응용 프로그램의 원하는 기능과 기능을 정의하기 위해 이해 관계자가 함께 모이는 워크숍이다.

FAST 세션 동안 촉진자는 열린 커뮤니케이션과 협업을 장려하는 구조화된 프로세스를 통해 참가자를 안내한다. 진행자는 참가자가 브레인스토밍, 유스케이스 분석, 순서도나 다이어그램과 같은 시각화 도구와 같은 기술을 사용하여 요구 사항을 식별하고 우선순위를 지정하도록 돕는다.

FAST는 이해 관계자가 협업 환경에서 자신의 아이디어, 통찰력 및 우려 사항을 제공할 수 있도록 하므로 요구 사항을 수집하는 데 효과적인 방법이다. 다양한 이해 관계자의 기대치를 조정하고, 요구 사항을 명확히 하고, 개발 프로세스 초기에 잠재적인 충돌이나 문제를 식별하는 데 도움이 된다.

FAST(Facilitated Application Specification Technique)의 목표는 요구 사항 수집에 대한 팀 중심 접근 방식을 보장하여 개발자와 고객 간의 기대 격차를 해소하는 것이다.

FAST 세션에서 각 참석자는

- 시스템을 둘러싼 환경의 일부인 개체

- 시스템에서 생성된 개체

- 시스템에서 사용되는 개체

세 가지 범주로 분류되는 개체 목록을 작성한다. 그런 다음 이러한 개별 목록을 결합하고 중복 항목을 제거한 다음 팀을 더 작은 하위 팀으로 나누어 미니 사양을 개발한다.

마지막으로 회의에서 수집한 모든 정보를 사용하여 사양 초안을 작성한다.

 

4. 품질 기능 전개(QFD: Quality Function Deployment)

QFD(Quality Function Deployment) 기법에서 고객 만족이 가장 큰 관심사이기 때문에 고객에게 중요한 요구 사항 식별을 중요하게 생각한다.
3가지 유형의 요구사항을 식별한다. 

 

일반적 요구사항 – 고객과 논의되는 제안된 소프트웨어의 목적과 목표를 나타낸다. 예를 들어 결과 관리 시스템의 경우 일반적인 요구 사항에는 마크 입력, 결과 계산 및 기타 관련 기능과 같은 기능이 포함될 수 있다.

 

예상 요구사항 – 고객이 명시적으로 말할 필요가 없는 암시적이고 명백한 요구 사항이다. 예를 들어 소프트웨어 시스템의 경우 예상 요구 사항에는 무단 액세스로부터 보호, 데이터 보안 보장 및 기타 유사한 기능과 같은 기능이 포함될 수 있다.

 

흥미로운 요구사항 – 고객의 기대를 뛰어넘고 소프트웨어에 존재할 때 높은 수준의 만족을 제공하는 요구 사항이다. 예를 들어 무단 액세스를 감지하는 경우 추가 손상이나 보안 위반을 방지하기 위해 데이터를 자동으로 백업하고 모든 프로세스를 종료하는 기능이 흥미로운 요구 사항일 수 있다. 

 

주요 단계는 다음과 같다.

 

1. 모든 이해 관계자 식별: 프로젝트 또는 제품에 이해관계가 있는 모든 개인, 그룹 또는 단체를 식별하다.

사용자, 개발자, 고객 및 기타 관련 당사자.

2. 고객의 모든 요구 사항 나열: 제품 또는 프로젝트의 고객 또는 최종 사용자로부터 모든 요구 사항과 기대치를 수집한다. 설문 조사, 인터뷰 또는 기타 피드백 수집 수단.
3. 각 요구 사항에 대한 중요도를 나타내는 값 지정: 프로젝트 또는 제품에 대한 중요도 또는 관련성에 따라 각 요구 사항을 평가하고 우선순위를 지정한다.

각 요구 사항에 점수 또는 순위를 지정.
4. 최종 요구 사항 목록 분류: 모든 요구 사항을 평가한 후 세 가지 주요 범주로 분류한다.

• 달성: 프로젝트 또는 제품의 범위 및 제약 조건 내에서 구현 및 달성할 수 있는 요구 사항.
• 연기: 프로젝트 또는 제품의 현재 단계에서 달성할 수 없고 이후 단계 또는 버전으로 연기해야 ​​하는 요구 사항. 이러한 요구 사항은 연기해야 하는 이유를 기술한다.
• 불가능: 기술, 예산 또는 기타 제약으로 인해 달성할 수 없는 요구 사항으로 요구 사항 목록에서 제외한다.

 

5. 유즈 케이스(Use Case) 접근법

이 기법은 텍스트와 이미지를 결합하여 요구 사항에 대한 이해를 높인다. 유스 케이스는 시스템의 기능적 보기를 제공하는 "방법"이 아니라 시스템의 "무엇"을 설명한다. 유스 케이스 디자인의 구성 요소에는 일반적으로 액터, 유스 케이스 및 유스 케이스 다이어그램의 세 가지 주요 요소가 포함된다.

 

ㆍ행위자(Actor) -
행위자는 어떤 방식으로든 시스템과 상호 작용하고 시스템 경계 외부에 존재하는 외부 에이전트다. 행위자는 사람, 기계 또는 기타 개체가 될 수 있다. 일반적으로 유스 케이스 다이어그램에서 막대 그림으로 표시된다. 행위자는 기본 행위자 또는 보조 행위자로 분류할 수 있다.

• 주요 행위자 – 주요 행위자는 목표를 달성하기 위해 시스템의 지원이 필요하다. 그들은 시스템과의 상호 작용을 시작하고 사용 사례에 직접 관여한다.
• 보조 행위자 – 보조 행위자는 시스템에서 지원이 필요한 행위자다. 이들은 시스템에 서비스 또는 리소스를 제공하고 유스 케이스에 간접적으로 관여한다.
  

ㆍ유스 케이스(Use cases) -
유스 케이스는 액터와 시스템 간의 상호 작용 순서를 설명한다. 액터가 수행하는 작업과 시스템과의 상호 작용을 표현한다. 완전한 유스 케이스 세트는 발생할 수 있는 모든 다양한 시나리오와 상호 작용을 포함하여 액터가 시스템을 사용할 수 있는 모든 가능한 방법을 정의한다.

ㆍ유스 케이스 다이어그램(Use case diagram) –
유스 케이스 다이어그램은 액터와 시스템 간의 상호 작용을 나타내는 그래픽 표현이다. 시스템의 기능적 측면과 액터가 시스템과 상호 작용하는 방식을 시각적으로 표현한다. 유스 케이스 다이어그램에서 액터는 일반적으로 막대 모양으로 표시되고 유스 케이스는 타원으로 표시되며 선은 액터와 유스 케이스 간의 관계를 나타내는 데 사용된다.

 

요구사항 추출의 특징

1. 이해 관계자 참여: 요구 사항 추출에는 고객, 최종 사용자, 프로젝트 후원자 및 주제 전문가와 같은 이해 관계자와 참여하여 그들의 요구 사항과 요구 사항을 이해하는 것이 필요하다.

2. 정보 수집: 요구 사항 추출에는 개발할 시스템, 지원하는 비즈니스 프로세스 및 이를 사용할 최종 사용자에 대한 정보 수집 해야 한다.

3. 요구 사항 우선순위 지정: 요구 사항 추출에는 프로젝트 성공에 대한 중요도에 따라 요구 사항의 우선순위를 지정해야 한다.

4. 요구 사항 문서화: 요구 사항 추출에는 요구 사항을 명확하고 간결한 방식으로 문서화하여 쉽게 이해하고 개발 팀에 전달해야 한다.

5. 검증 및 확인: 요구 사항 추출에는 이해 관계자와 함께 요구 사항을 검증하고 확인하여 요구 사항을 정확하게 나타내는지 확인해야 한다.

6. 반복 프로세스: 요구 사항 추출은 이해 관계자의 피드백을 기반으로 요구 사항을 지속적으로 개선하고 업데이트하는 반복 프로세스다.

7. 커뮤니케이션 및 협업: 요구사항 추출에는 이해관계자, 프로젝트 팀 구성원 및 기타 관련 당사자와의 효과적인 커뮤니케이션 및 협업해 요구사항이 명확하게 이해되고 구현되도록 한다.

8. 유연성: 요구 사항 추출에는 변화하는 요구 사항, 이해 관계자 요구 사항 및 프로젝트 제약 조건에 적응할 수 있는 유연성이 필요하다. 

 

요구사항 추출의 장점

• 고객 요구사항을 명확히 하고 구체화하는 데 도움이 된다.
• 이해 관계자 간의 커뮤니케이션 및 협업을 개선한다.
• 고객의 요구를 충족하는 소프트웨어 시스템을 개발할 가능성을 높인다.
• 오해를 피하고 기대치를 관리하는 데 도움이 된다.
• 개발 주기 초기에 잠재적 위험 및 문제 식별을 지원한다.
• 포괄적이고 정확한 프로젝트 계획의 개발을 촉진한다.
• 소프트웨어 개발 프로세스에 대한 사용자 및 이해 관계자의 신뢰를 높인다.
• 새로운 비즈니스 기회 및 수익원 식별을 지원한다.

요구사항 도출의 단점

• 시간과 비용이 많이 소요될 수 있다.
• 전문적인 기술과 전문성이 필요하다.
• 변화하는 비즈니스 요구 사항 및 요구 사항의 영향을 받을 수 있다.
• 정치적, 조직적 요인의 영향을 받을 수 있다.
• 이해 관계자의 구매 및 약속이 부족할 수 있다.
• 상충되는 우선순위와 상충하는 이해관계의 영향을 받을 수 있다.
• 적절하게 관리되지 않으면 요구사항이 불완전하거나 부정확해질 수 있다.
• 요구 사항이 잘 정의되지 않은 경우 개발 비용이 증가하고 효율성이 감소할 수 있다.