소프트웨어 공학: 요구사항 추출 및 분석

 

요구사항 추출 및 분석은 소프트웨어 공학에서 아주 중요한 활동입니다.

하지만 요구사항 추출 및 분석에 어떤 방법이 사용되는지 정리된 내용이 많이 부족합니다.

이번 포스팅에서는 요구사항 추출 및 분석 방법에 대해 살펴 보겠습니다.

 

 

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

 

요구사항 추출 및 분석 (Requirements Elicitation and Analysis)

요구 사항 추출 및 분석은 소프트웨어 엔지니어들이 고객 및 시스템 최종 사용자와 협력하여 애플리케이션 도메인, 시스템이 제공해야 하는 서비스, 시스템의 요구 성능, 하드웨어 제약 조건 등을 파악하는 활동입니다.

 

요구 사항 추출 및 분석에는 조직 내에서 다양한 사람들이 참여할 수 있습니다.

시스템 이해관계자는 시스템 요구 사항에 직간접적으로 영향을 미치는 모든 사람을 의미합니다. 여기에는 시스템과 상호작용할 최종 사용자뿐만 아니라 시스템에 영향을 받는 조직의 모든 사람이 포함됩니다. 다른 이해관계자들로는 관련 시스템을 개발하거나 유지보수하는 엔지니어, 비즈니스 관리자, 도메인 전문가, 노동 조합 대표 등이 있을 수 있습니다.

그림 4.13 요구사항 추출 및 분석 프로세스

 

그림 4.13은 요구 사항 추출 및 분석 프로세스의 모델을 보여줍니다. 각 조직은 직원들의 전문성, 개발 중인 시스템의 유형, 사용되는 표준 등과 같은 지역적 요소에 따라 이 일반 모델의 자체 버전을 가지게 됩니다.

 

프로세스 활동은 다음과 같습니다:

1. 요구 사항 발견: 이는 시스템의 이해관계자와 상호작용하여 그들의 요구 사항을 발견하는 과정입니다. 이 활동 중에 이해관계자로부터의 도메인 요구 사항과 문서화된 내용도 발견됩니다. 요구 사항 발견에는 여러 가지 보완적인 기법이 사용될 수 있습니다.
2. 요구 사항 분류 및 조직화: 이 활동에서는 구조화되지 않은 요구 사항을 관련된 요구 사항으로 그룹화하고 이를 일관된 클러스터로 조직화합니다. 요구 사항을 그룹화하는 가장 일반적인 방법은 시스템 아키텍처 모델을 사용하여 하위 시스템을 식별하고 각 하위 시스템에 요구 사항을 연결하는 것입니다.
3. 요구 사항 우선순위 설정 및 협상: 여러 이해관계자가 참여할 경우, 요구 사항이 충돌할 가능성이 큽니다. 이 활동은 요구 사항의 우선순위를 정하고 협상을 통해 요구 사항 충돌을 해결하는 데 중점을 둡니다.
4. 요구 사항 명세: 요구 사항이 문서화되고 다음 반복 주기에 입력됩니다. 이 단계에서 공식적이거나 비공식적인 요구 사항 문서가 생성될 수 있습니다.

그림 4.13에서 알 수 있듯이, 요구 사항 추출 및 분석은 각 활동에서 다른 활동으로 지속적인 피드백이 발생하는 반복적인 과정입니다. 이 과정의 사이클은 요구 사항 발견에서 시작하여 요구 사항 문서화로 끝납니다. 분석가의 요구 사항에 대한 이해는 각 사이클이 반복될 때마다 향상됩니다.

 

1. 요구 사항 발견 (Requirements Discovery)

요구 사항 발견(때로는 요구 사항 추출이라고도 함)은 필요한 시스템과 기존 시스템에 대한 정보를 수집하고 이 정보에서 사용자 및 시스템 요구 사항을 추출하는 과정입니다. 요구 사항 발견 단계에서의 정보 출처로는 문서화, 시스템 이해관계자, 유사 시스템의 명세서 등이 포함됩니다. 이해관계자와의 인터뷰와 관찰을 통해 상호작용하며, 시나리오와 프로토타입을 사용하여 이해관계자가 시스템이 어떻게 될지 이해하도록 도울 수 있습니다.

 

예를 들어, 정신 건강 관리 환자 정보 시스템의 시스템 이해관계자는 다음과 같습니다:

 

• 환자: 시스템에 정보가 기록되는 사람들.

• 의사: 환자를 평가하고 치료하는 책임이 있는 사람들.

• 간호사: 의사와의 상담을 조정하고 일부 치료를 담당하는 사람들.

• 의료 접수 직원: 환자의 예약을 관리하는 사람들.

• IT 직원: 시스템 설치 및 유지보수를 담당하는 사람들.

• 의료 윤리 관리자: 시스템이 환자 치료를 위한 윤리 지침을 준수하는지 확인하는 사람.

• 의료 관리자: 시스템에서 관리 정보를 얻는 사람들.

• 의료 기록 직원: 시스템 정보를 유지 관리하고 보존하며 기록 유지 절차가 적절히 실행되었는지 확인하는 사람들.

 

요구 사항은 시스템 이해관계자 외에도 애플리케이션 도메인 및 지정된 시스템과 상호작용하는 다른 시스템으로부터도 올 수 있습니다. 이러한 모든 요소는 요구 사항 추출 과정에서 고려되어야 합니다.

 

2. 인터뷰 (Interviewing)

공식적 또는 비공식적 인터뷰는 대부분의 요구공학 프로세스의 일부입니다. 이 인터뷰를 통해 요구공학팀은 현재 사용 중인 시스템과 개발 중인 시스템에 대해 이해관계자에게 질문합니다. 요구 사항은 이러한 질문에 대한 답변에서 도출됩니다.

 

인터뷰는 두 가지 유형으로 나눌 수 있습니다:

 

1. 폐쇄형 인터뷰: 이해관계자가 미리 정의된 질문 세트에 답변하는 방식.

2. 개방형 인터뷰: 사전 정의된 의제가 없으며, 요구공학팀이 시스템 이해관계자와 다양한 문제를 탐색하여 그들의 요구를 더 잘 이해하게 되는 방식.

 

실제 인터뷰는 대부분 이 두 가지를 혼합한 형태로 진행됩니다. 특정 질문에 대한 답변을 얻어야 할 수 있지만, 이들은 대개 덜 구조화된 방식으로 논의되는 다른 문제로 이어집니다.

 

인터뷰는 이해관계자가 하는 일과 그들이 새 시스템과 상호작용하는 방법, 현재 시스템에서 겪는 어려움을 이해하는 데 유용합니다. 그러나 인터뷰만으로는 애플리케이션 도메인에서 요구 사항을 도출하기 어려울 수 있습니다.

 

3. 시나리오 (Scenarios)

사람들은 일반적으로 추상적인 설명보다는 실제 사례와 관련된 내용에 더 쉽게 공감합니다. 그들은 소프트웨어 시스템과 상호작용할 방법에 대한 시나리오를 이해하고 비판할 수 있습니다. 요구공학은 이러한 논의를 통해 얻은 정보를 바탕으로 실제 시스템 요구 사항을 공식화할 수 있습니다.

 

시나리오는 예제 상호작용 세션의 설명입니다. 각 시나리오는 보통 하나 또는 소수의 가능한 상호작용을 다룹니다. 다양한 형태의 시나리오가 개발되며, 이들은 시스템에 대한 다른 수준의 세부 정보를 제공합니다.

 

예를 들어, 아래 표는 MHC-PMS를 사용하여 새로운 환자 데이터를 입력하는 간단한 텍스트 시나리오입니다. 새로운 환자가 클리닉을 방문하면, 의료 접수원이 새 기록을 생성하고 개인 정보를 추가합니다. 간호사가 환자를 인터뷰하고 병력을 수집한 후, 의사가 초기 상담을 진행하여 진단을 내리고 치료 과정을 추천할 수 있습니다. 이 시나리오는 병력이 수집될 때 발생하는 상황을 보여줍니다.

항목	내용
초기 가정  (Initial Assumption)	• 환자는 의료 접수원(medical receptionist)과 만나 환자 개인 정보 (이름, 주소 나이 등)을 시스템에 등록했습니다.  • 현재 간호사가 시스템에 로그인 하여 환자의 의료 기록을 수집하고 있습니다.
정상 흐름 (Normal)	1. 환자 검색: • 간호사는 환자의 성(family name)을 기준으로 환자를 검색합니다. • 동일한 성을 가진 환자가 여러 명 있을 경우, 환자의 이름(영어로는 first name)과 생년월일을 사용하여 환자를 식별합니다. 2. 의료 기록 추가: • 간호사는 메뉴 옵션에서 ‘의료 기록 추가’를 선택합니다. • 시스템의 일련의 프롬프트를 따라, 다음과 같은 정보를 입력합니다: • 다른 곳에서 정신 건강 문제로 받은 상담 기록(자유 텍스트 입력) • 기존의 의료 상태(메뉴에서 상태 선택) • 현재 복용 중인 약물(메뉴에서 약물 선택) • 알레르기(자유 텍스트) • 가정 생활(폼 입력)
비정상 흐름 (What can go wrong)	1. 환자 기록이 존재하지 않거나 찾을 수 없는 경우: • 간호사는 새로운 기록을 생성하고, 환자의 개인정보를 기록해야 합니다. 2. 메뉴에 없는 환자의 상태나 약물: • 간호사는 ‘기타’ 옵션을 선택하고, 해당 상태나 약물을 자유 텍스트로 입력해야 합니다. 3. 환자가 의료 기록에 대한 정보를 제공할 수 없거나 제공하지 않으려는 경우: • 간호사는 환자가 정보를 제공할 수 없거나 제공하지 않으려 한다는 내용을 자유롭게 기록해야 합니다. • 시스템은 환자에게 서명을 받기 위한 표준 양식을 인쇄해야 합니다. • 위 표준 양식에는 환자 정보 부족으로 인해 치료가 제한되거나 지연될 수 있음을 명시해야 합니다. • 간호사는 위 양식을 시스템으로부터 출력하여 환자에게 서명을 받아야 합니다.
기타 (Other activities)	다른 직원들이 정보가 입력되는 동안 기록을 조회할 수 있지만, 수정은 불가능 합니다.
완료시 시스템 상태 (System state on completion)	• 사용자는 여전히 시스템에 로그인된 상태입니다. • 환자의 의료 기록이 데이터베이스에 입력되었으며, 세션의 시작 및 종료 시간과 간호사의 정보가 시스템 로그에 추가됩니다.

 

4. 유즈 케이스 (Use Cases)

유즈 케이스는 Objectory 메소드에서 처음 도입된 요구 사항 발견 기법입니다. 유즈 케이스는 현재 통합 모델링 언어(UML)의 기본 요소로 자리잡았습니다. 유즈 케이스는 상호작용에 참여하는 액터(actors)를 식별하고 상호작용의 유형을 명명하는 것으로 시작됩니다. 이후 이 상호작용에 대한 추가 정보를 텍스트 설명 또는 하나 이상의 그래픽 모델(예: UML 순서도 또는 상태도)로 보충합니다.

 

그림 4.15 MHC-PMS에 대한 유즈 케이스

 

유즈 케이스는 시스템 요구 사항에서 설명될 모든 가능한 상호작용을 나타냅니다. 그림 4.15는 환자 정보 시스템의 몇 가지 유즈 케이스를 보여줍니다.

 

시나리오와 유즈 케이스는 시스템과 직접 상호작용하는 이해관계자로부터 요구 사항을 도출하는 데 효과적인 기법입니다. 그러나 이러한 기법은 시스템과의 상호작용에 중점을 두기 때문에 제약 조건이나 고수준의 비즈니스 요구 사항, 비기능적 요구 사항을 도출하는 데는 덜 효과적일 수 있습니다.

 

5. Ethnography

소프트웨어 시스템은 사회적 및 조직적 맥락에서 사용되며, 소프트웨어 시스템 요구 사항은 이러한 맥락에서 파생되거나 제약을 받을 수 있습니다. 이 사회적 및 조직적 요구 사항을 충족시키는 것이 시스템 성공의 중요한 요소일 수 있습니다.

 

Ethnography는 실제 작업을 관찰하여 지원 요구 사항을 도출하는 데 사용될 수 있는 관찰 기법입니다. 분석가는 시스템이 사용될 작업 환경에 몰입하여 일상적인 작업을 관찰하고, 참가자들이 수행하는 실제 작업을 기록합니다.

 

Ethnography는 다음과 같은 두 가지 유형의 요구 사항을 발견하는 데 특히 효과적입니다:

 

1. 사람들의 실제 작업 방식에서 파생된 요구 사항.

2. 협업 및 다른 사람들의 활동 인식에서 파생된 요구 사항.

 

그림 4.16 요구사항 분석에 대한 Ethnography와 Prototyping

 

Ethnography 연구는 종종 다른 요구 사항 도출 기법으로는 놓칠 수 있는 중요한 프로세스 세부 사항을 드러낼 수 있습니다. 그러나 최종 사용자에 중점을 두기 때문에 조직적 요구 사항이나 도메인 요구 사항을 발견하는 데는 항상 적합하지 않을 수 있습니다. 따라서 Ethnography는  요구 사항 도출의 완전한 접근 방식이 아니며, 유즈 케이스 분석과 같은 다른 접근 방식을 보완하는 데 사용되어야 합니다.