작업 요구사항 분석
📌 개요
- 작업 요구사항 분석 = 로봇이 수행할 작업(Task)을 요구공학 절차로 파악·명세하는 활동
- 한 문장("커피를 나른다") 뒤에 숨은 요구 다수 — 몇 잔·얼마나 빨리·흘리면 어떻게?
- 출제 포인트: 요구공학 4단계(도출→분석→명세→검증) · 기능/비기능 구분 · 좋은 요구사항 특성 · 작업 분해
- 환경·사용자 관점은 로봇 작업환경 분석·사용자 특성의 분석 참조 — 이 노트는 작업 그 자체에 집중
📖 핵심 개념
요구공학(Requirements Engineering) 4단계 (시험 단골)
- 도출(Elicitation): 이해관계자에게서 요구를 끌어냄 — 인터뷰, 현장 관찰, 기존 작업 방식 분석, 시나리오 워크숍. 고객은 요구를 완결된 형태로 말해 주지 않는다 — "빨리"가 몇 초인지 파고들어야 한다
- 분석(Analysis): 수집된 요구의 충돌 해결·우선순위화·실현성 검토 — "정밀하게"와 "빠르게"는 충돌한다(트레이드오프). 우선순위 기법으로 MoSCoW(Must/Should/Could/Won't) 등을 사용
- 명세(Specification): 합의된 요구를 문서(요구사항 명세서, SRS)로 작성 — 이후 설계·시험의 기준
- 검증(Validation): 명세가 이해관계자의 진짜 의도와 일치하는지 확인 — 검토 회의, 프로토타입 시연 (→ 검토 기법)
기능 요구와 비기능 요구 (시험 단골)
- 기능 요구(Functional): 시스템이 무엇을 하는가 — "테이블 번호를 지정하면 음료를 배달한다", "장애물을 만나면 회피한다"
- 비기능 요구(Non-functional): 얼마나 잘 하는가 — 성능(사이클 타임), 신뢰성(성공률), 안전성, 사용성, 유지보수성. 아키텍처를 결정하는 것은 주로 비기능 요구다 (→ 아키텍처 드라이버)
작업 분해 (Task Decomposition)
큰 작업을 계층적으로 하위 작업으로 분해해야 요구가 구체화된다 (→ HTA).
- "음료 서빙" → 주문 접수 / 픽업 / 이동 / 전달 / 복귀
- 각 하위 작업마다 입력·출력·성공 조건·실패 시 대응을 정의
- 분해 결과는 작업 시나리오와 태스크 플래닝의 골격이 된다
좋은 요구사항의 특성 (시험 단골)
| 특성 | 의미 | 나쁜 예 → 좋은 예 |
|---|---|---|
| 명확성(비모호) | 누가 읽어도 한 가지 해석 | "빨리 배달" → "주문 후 5분 이내 배달" |
| 검증 가능성 | 시험으로 충족 여부 판정 가능 | "사용하기 편해야" → "신규 사용자가 교육 없이 3분 내 주문 완료" |
| 완전성 | 필요한 요구가 빠짐없이 | 정상 흐름만 → 예외·실패 대응 포함 |
| 일관성 | 요구끼리 모순 없음 | 속도 요구와 안전 요구의 충돌 해결 |
| 추적 가능성 | 출처와 반영처를 추적 | 요구 ↔ 설계 ↔ 시험 케이스 연결 (→ 추적표) |
작업 요구사항 분석의 산출물
- 작업 목록과 분해 구조: 무엇을 하는가의 트리
- 작업별 요구 명세: 기능 + 성능·조건(빈도, 물체 크기·무게 범위, 허용 실패율)
- 제약사항: 예산, 기존 설비 연동(→ 주변장치 인터페이스 분석), 법규·안전 기준
- 이 산출물이 로봇 성능 분석(할 수 있는가)과 작업지능 소프트웨어 목표사양(얼마나 잘할 것인가)의 입력이 된다
📊 다이어그램 · 수식
요구공학 4단계
flowchart LR
E["① 도출
인터뷰·관찰·시나리오"] --> A["② 분석
충돌 해결·우선순위"] --> S["③ 명세
SRS 작성"] --> V["④ 검증
검토·프로토타입"]
V -- 의도 불일치 발견 시 --> E작업 분해의 예 — 서빙 작업
flowchart TD
T["음료 서빙 작업"] --> T1["주문 접수"] & T2["픽업"] & T3["이동"] & T4["전달"] & T5["복귀"]
T3 --> R1["요구: 5분 내 도착"] & R2["요구: 흘림 없음(가감속 제한)"] & R3["실패 대응: 경로 막힘 시 재계획"]🎯 핵심 요약 · 암기 포인트
✏️ 예상문제
1. 요구공학의 단계를 순서대로 옳게 나열한 것은?
① 명세 → 도출 → 분석 → 검증 ② 도출 → 분석 → 명세 → 검증 ③ 분석 → 검증 → 도출 → 명세 ④ 검증 → 명세 → 분석 → 도출
정답 및 해설
정답: ② 이해관계자에게서 요구를 끌어내고(도출), 충돌을 정리해(분석), 문서로 확정하고(명세), 진짜 의도와 맞는지 확인(검증)하는 순서다. 검증에서 불일치가 발견되면 앞 단계로 되돌아가는 반복 과정이다.
2. 다음 중 비기능 요구사항에 해당하는 것은?
① 테이블 번호를 지정하면 음료를 배달한다 ② 장애물을 만나면 회피 경로를 생성한다 ③ 배달 작업의 성공률이 99% 이상이어야 한다 ④ 충전 스테이션에 자동 도킹한다
정답 및 해설
정답: ③ ①②④는 시스템이 "무엇을 하는가"(기능)이고, ③은 그 기능을 "얼마나 잘 하는가"(신뢰성 — 비기능)다. 성능·신뢰성·안전성 같은 비기능 요구가 아키텍처를 결정한다.
3. "로봇은 사용하기 편해야 한다"라는 요구사항의 가장 큰 문제는?
① 기능 요구라는 점 ② 모호하여 검증(시험)이 불가능하다는 점 ③ 우선순위가 낮다는 점 ④ 작업 분해가 이미 완료되었다는 점
정답 및 해설
정답: ② "편하다"는 사람마다 해석이 달라 충족 여부를 판정할 수 없다. "신규 사용자가 교육 없이 3분 내 주문을 완료한다"처럼 측정 가능한 형태로 다시 써야 한다 — 명확성과 검증 가능성은 좋은 요구사항의 핵심 특성이다.
4. 요구 분석 단계에서 수행하는 활동으로 가장 거리가 먼 것은?
① 요구 간 충돌(정밀 vs 속도)의 조정 ② MoSCoW 등으로 우선순위 부여 ③ 실현 가능성 검토 ④ 소스 코드 구현
정답 및 해설
정답: ④ 분석은 요구를 정리·조정하는 단계로 구현과는 거리가 멀다. 코드는 명세·설계가 끝난 뒤의 일이며, 요구 단계의 산출물은 문서(SRS)다.
5. 작업 분해(task decomposition)에 대한 설명으로 옳지 않은 것은?
① 큰 작업을 계층적으로 하위 작업으로 나눈다 ② 하위 작업마다 입력·출력·성공 조건을 정의한다 ③ 분해 결과는 작업 시나리오와 태스크 플래닝의 골격이 된다 ④ 정상 흐름만 분해하면 되고 실패 대응은 정의할 필요가 없다
정답 및 해설
정답: ④ 로봇 작업 요구의 절반은 예외·실패 대응이다(완전성). 하위 작업마다 실패 시 대응(재시도·재계획·안전 정지)을 함께 정의해야 시나리오와 설계로 이어질 수 있다.
🔗 관련 노트
- 로봇 성능 분석 — 요구를 로봇이 감당할 수 있는가
- 작업지능 소프트웨어 목표사양 — 요구의 정량 사양화
- 로봇 작업 시나리오 작성 — 요구가 구체화된 시나리오
- 로봇 작업환경 분석 · 사용자 특성의 분석 — 환경·사용자 관점의 분석
- 로봇 시스템 평가절차 — 요구↔시험의 추적성
- _MOC 지능소프트웨어