396.20 사용자 요구사항 분석과 임무 명세

1. 사용자 요구사항 분석의 정의

사용자 요구사항 분석(User Requirements Analysis)이란 임무를 의뢰하는 사용자(운영자, 고객, 시스템 관리자 등)로부터 임무의 목적, 범위, 제약 조건, 기대 결과를 체계적으로 수집하고, 이를 로봇 시스템이 이해하고 처리할 수 있는 형식적 명세(Formal Specification)로 변환하는 과정이다. 이 과정은 임무 생애 주기에서 가장 초기 단계에 해당하며, 이후의 모든 임무 관리 활동의 기반을 형성한다.

사용자 요구사항 분석의 핵심 과제는 인간이 자연어 또는 비형식적 표현으로 전달하는 의도(Intent)를 로봇 시스템이 처리할 수 있는 구조화된 명세(Structured Specification)로 정확하게 변환하는 것이다. 이 변환 과정에서 발생하는 의미적 손실(Semantic Loss)을 최소화하는 것이 핵심 설계 목표이다.

2. 요구사항의 분류 체계

로봇 임무 관리에서 사용자 요구사항은 다음과 같이 분류된다.

2.1 기능적 요구사항(Functional Requirements)

기능적 요구사항은 로봇 시스템이 수행해야 하는 구체적인 동작이나 기능을 정의한다. 형식적으로, 기능적 요구사항 집합 $\mathcal{F}$ 는 다음과 같이 표현된다.

$\mathcal{F} = \{f_1, f_2, \ldots, f_n\}, \quad f_i = (\text{input}_i, \text{output}_i, \text{function}_i)$

여기서 각 $f_i$ 는 입력 조건, 기대 출력, 수행 기능의 삼중쌍(Triple)이다. 기능적 요구사항의 예시는 다음과 같다.

특정 지점으로의 이동(Navigation to Waypoint)
특정 객체의 탐지 및 식별(Object Detection and Identification)
화물의 집화 및 배송(Pick-and-Place, Delivery)
환경 데이터의 수집 및 전송(Environmental Sensing and Reporting)

2.2 비기능적 요구사항(Non-Functional Requirements)

비기능적 요구사항은 시스템의 품질 속성(Quality Attribute)에 관한 제약을 정의한다. 주요 비기능적 요구사항 유형은 다음과 같다.

유형	설명	정량적 표현
시간 제약(Time Constraint)	임무 완수 기한	$T_{\text{mission}} \leq T_{\text{deadline}}$
안전 제약(Safety Constraint)	충돌 확률 상한	$P_{\text{collision}} \leq \epsilon_{\text{safe}}$
정확도 제약(Accuracy Constraint)	위치 결정 오차	$\vert\vert \mathbf{p}_{\text{actual}} - \mathbf{p}_{\text{target}} \vert\vert \leq \delta_{\text{pos}}$
에너지 제약(Energy Constraint)	최대 에너지 소비	$E_{\text{consumed}} \leq E_{\text{budget}}$
통신 제약(Communication Constraint)	최소 보고 빈도	$f_{\text{report}} \geq f_{\text{min}}$
환경 제약(Environmental Constraint)	작업 가능 기상 조건	$v_{\text{wind}} \leq v_{\text{max}}$

2.3 도메인 제약(Domain Constraints)

도메인 제약은 특정 응용 분야에서 부과되는 규제, 법규, 운용 규정 등에 의한 제약이다. 예를 들어, 무인 항공 시스템의 경우 비행 고도 제한, 비행 금지 구역, 운용 시간 제한 등이 해당한다.

$\mathcal{D}_{\text{constraint}} = \{d_1, d_2, \ldots, d_p\}$

3. 요구사항 수집 방법론

3.1 구조화 인터뷰(Structured Interview)

사용자와의 체계적인 대화를 통하여 임무 요구사항을 수집하는 방법이다. 사전에 준비된 질문 목록에 따라 다음과 같은 항목을 순차적으로 확인한다.

임무의 목적과 최종 목표
작업 환경의 특성(실내/실외, 구조화/비구조화)
시간적 제약과 우선순위
안전 관련 고려 사항
사용 가능한 로봇과 자원
기대하는 결과물과 보고서 형식

3.2 시나리오 기반 분석(Scenario-Based Analysis)

사용자와 함께 임무 수행의 구체적인 시나리오를 작성하고, 이를 통하여 요구사항을 도출하는 방법이다. 시나리오 $\mathcal{S}_k$ 는 다음과 같은 요소로 구성된다.

$\mathcal{S}_k = (\text{context}_k, \text{trigger}_k, \text{actions}_k, \text{outcome}_k, \text{exceptions}_k)$

여기서 $\text{context}$ 는 시나리오의 배경 조건, $\text{trigger}$ 는 임무 시작을 유발하는 이벤트, $\text{actions}$ 는 수행되는 행동 시퀀스, $\text{outcome}$ 은 기대 결과, $\text{exceptions}$ 는 예외 상황과 대응 방안이다.

3.3 유스 케이스 모델링(Use Case Modeling)

통합 모델링 언어(UML, Unified Modeling Language)의 유스 케이스 다이어그램을 활용하여 시스템과 사용자(Actor) 간의 상호 작용을 모델링한다. 각 유스 케이스는 하나의 임무 시나리오를 나타내며, 포함(Include) 및 확장(Extend) 관계를 통하여 임무 간의 수학적 관계를 표현한다.

4. 요구사항에서 임무 명세로의 변환

4.1 임무 명세의 정의

임무 명세(Mission Specification)는 사용자 요구사항을 로봇 시스템이 처리할 수 있는 형식적 표현으로 변환한 결과물이다. 임무 명세 $\mathcal{M}$ 은 다음과 같은 튜플로 정의된다.

$\mathcal{M} = (G, \Phi, \mathcal{C}, \mathcal{R}, \mathcal{E}, \mathcal{Q})$

여기서:

$G = \{g_1, g_2, \ldots, g_n\}$ : 임무 목표 집합
$\Phi = \{\phi_1, \phi_2, \ldots, \phi_m\}$ : 제약 조건 집합
$\mathcal{C}$ : 임무 컨텍스트(환경 정보, 초기 조건)
$\mathcal{R}$ : 가용 자원 명세
$\mathcal{E}$ : 환경 모델
$\mathcal{Q}$ : 품질 속성(비기능적 요구사항)

4.2 목표의 형식화

사용자가 자연어로 표현한 임무 목표를 형식 논리(Formal Logic)로 변환한다. 목표 $g_i$ 는 시간 논리(Temporal Logic)를 활용하여 다음과 같이 표현될 수 있다.

도달 목표(Reachability Goal): 특정 상태에 최종적으로 도달해야 하는 목표이다.

$\Diamond \phi_{\text{target}}$

“결국(Eventually) 목표 조건 $\phi_{\text{target}}$ 이 참이 되어야 한다.”

유지 목표(Maintenance Goal): 전체 임무 기간 동안 특정 조건이 유지되어야 하는 목표이다.

$\Box \phi_{\text{invariant}}$

“항상(Always) 불변 조건 $\phi_{\text{invariant}}$ 가 참이어야 한다.”

순서 목표(Sequencing Goal): 특정 조건이 지정된 순서로 달성되어야 하는 목표이다.

$\Diamond (\phi_1 \wedge \Diamond (\phi_2 \wedge \Diamond \phi_3))$

“ $\phi_1$ 이 먼저 달성되고, 이후 $\phi_2$ 가, 마지막으로 $\phi_3$ 가 달성되어야 한다.”

4.3 제약 조건의 형식화

사용자가 명시한 제약 조건을 수학적 부등식 또는 논리식으로 변환한다. 제약 조건의 형식화 예시는 다음과 같다.

시간 제약:

$t_{\text{completion}}(g_i) - t_{\text{start}} \leq T_{\text{deadline}}(g_i)$

공간 제약:

$\mathbf{p}(t) \in \mathcal{W}_{\text{allowed}} \setminus \mathcal{W}_{\text{forbidden}}, \quad \forall t$

여기서 $\mathcal{W}_{\text{allowed}}$ 는 허용된 작업 공간, $\mathcal{W}_{\text{forbidden}}$ 은 금지 구역이다.

자원 제약:

$\sum_{i=1}^{n} r_j(\tau_i) \leq R_j^{\text{total}}, \quad \forall j$

여기서 $r_j(\tau_i)$ 는 과업 $\tau_i$ 의 자원 $j$ 소비량, $R_j^{\text{total}}$ 은 자원 $j$ 의 총 보유량이다.

5. 요구사항 검증(Requirements Validation)

5.1 완전성 검증(Completeness Validation)

수집된 요구사항이 임무 수행에 필요한 모든 정보를 포함하고 있는지를 검증한다. 완전성 검증 체크리스트는 다음 항목을 포함한다.

모든 임무 목표가 명시되었는가?
각 목표의 성공 기준(Success Criteria)이 정의되었는가?
필요한 모든 제약 조건이 식별되었는가?
환경 조건의 가정이 문서화되었는가?
예외 상황에 대한 대응 방안이 포함되었는가?

완전성 지수 $\mathcal{I}_{\text{comp}}$ 는 다음과 같이 산출된다.

$\mathcal{I}_{\text{comp}} = \frac{N_{\text{specified}}}{N_{\text{required}}}$

여기서 $N_{\text{specified}}$ 는 명세된 요구사항 수, $N_{\text{required}}$ 는 필요한 총 요구사항 수이다.

5.2 일관성 검증(Consistency Validation)

요구사항들 간에 모순이 없는지를 검증한다. 두 제약 조건 $\phi_i$ 와 $\phi_j$ 의 일관성은 다음과 같이 판정된다.

$\text{consistent}(\phi_i, \phi_j) = \neg(\phi_i \wedge \phi_j \equiv \bot)$

즉, 두 제약 조건이 동시에 만족될 수 없는 경우 비일관(Inconsistent)으로 판정된다. 비일관성이 발견된 경우, 사용자와의 협의를 통하여 우선순위를 결정하고 제약을 완화(Relaxation)하거나 수정한다.

5.3 실현 가능성 검증(Feasibility Validation)

명세된 요구사항이 현재 가용한 로봇 시스템의 역량 내에서 실현 가능한지를 검증한다. 실현 가능성은 로봇의 역량 모델(Capability Model) $\mathcal{C}_{\text{robot}}$ 과 요구사항 $\mathcal{M}$ 의 비교를 통하여 판정된다.

$\text{feasible}(\mathcal{M}) = \bigwedge_{i=1}^{n} \left( \text{required}_i(\mathcal{M}) \leq \text{capability}_i(\mathcal{C}_{\text{robot}}) \right)$

실현 불가능한 요구사항이 발견된 경우, 요구사항의 수정, 추가 자원의 확보, 또는 임무 범위의 축소를 통하여 해결한다.

6. 임무 명세의 품질 평가

임무 명세의 품질은 다음과 같은 속성으로 평가된다.

속성	의미	평가 기준
명확성(Clarity)	해석의 모호성 배제	형식 논리로 완전 변환 가능
추적 가능성(Traceability)	사용자 요구와의 연결	모든 명세 항목이 요구사항에 역추적 가능
수정 가능성(Modifiability)	변경의 용이성	단일 항목 수정 시 영향 범위 최소
검증 가능성(Verifiability)	달성 여부의 확인 가능성	각 목표에 측정 가능한 판정 기준 존재

7. 요구사항-명세 추적 행렬(Requirements Traceability Matrix)

사용자 요구사항과 임무 명세 항목 간의 대응 관계를 체계적으로 관리하기 위하여 추적 행렬(Traceability Matrix) $\mathbf{T}$ 를 구성한다.

$\mathbf{T}_{ij} = \begin{cases} 1 & \text{if 요구사항 } r_i \text{가 명세 항목 } m_j \text{에 의해 충족} \\ 0 & \text{otherwise} \end{cases}$

추적 행렬을 통하여 다음을 확인할 수 있다.

미충족 요구사항: $\sum_j \mathbf{T}_{ij} = 0$ 인 행 $i$ 는 대응하는 명세가 없는 요구사항이다.
근거 없는 명세: $\sum_i \mathbf{T}_{ij} = 0$ 인 열 $j$ 는 사용자 요구에 근거하지 않는 명세 항목이다.
변경 영향 분석: 특정 요구사항이 변경될 경우 영향을 받는 명세 항목을 즉시 파악할 수 있다.

8. 반복적 요구사항 정제

사용자 요구사항 분석과 임무 명세는 일회성 활동이 아니라, 반복적 정제(Iterative Refinement) 과정을 통하여 점진적으로 완성된다. 각 반복 $k$ 마다 명세의 품질 지수 $Q^{(k)}$ 가 향상된다.

$Q^{(k+1)} = Q^{(k)} + \Delta Q(\text{feedback}^{(k)})$

여기서 $\Delta Q$ 는 사용자 피드백에 의한 품질 개선분이다. 반복은 $Q^{(k)} \geq Q_{\text{threshold}}$ 가 될 때까지 계속된다.

9. 참고 문헌

Sommerville, I. (2015). Software Engineering. 10th Edition. Pearson.
Nuseibeh, B., & Easterbrook, S. (2000). “Requirements engineering: A roadmap.” In Proceedings of the Conference on the Future of Software Engineering (pp. 35–46). ACM.
Ghallab, M., Nau, D., & Traverso, P. (2016). Automated Planning and Acting. Cambridge University Press.
Pnueli, A. (1977). “The temporal logic of programs.” In 18th Annual Symposium on Foundations of Computer Science (pp. 46–57). IEEE.
Kotonya, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. Wiley.

v0.1.0