2강. 요구사항 확인 — 요구분석기법·요구공학·애자일 | 정보처리기사 필기 완전정복 50강 · 중급 — 누구나패스

🎯 이 강의 학습 목표

이 강을 마치면 요구사항을 기능·비기능으로 나누고, 요구공학 활동(도출 → 분석 → 명세 → 확인)과 각 단계의 기법을 짝지어 설명할 수 있습니다. 또 애자일 선언의 네 가치, 스크럼의 책임·이벤트·산출물, XP의 가치와 실천법을 구별하고, 스프린트 속도로 남은 일정을 계산할 수 있습니다.

출제기준 위치: [소프트웨어 개발 › 1. 요구사항 확인 › 1. 요구사항 확인 › 1. 요구분석기법 · 3. 애자일(Agile)], [같은 항목 › 2. 분석모델 확인 › 3. 요구사항 관리 도구]. 요구공학은 「4. 인터페이스 설계 › 요구공학」과 「5. 소프트웨어개발 방법론 활용 › 요구공학 방법론」에도 다시 나오므로 여기서 기본 틀을 확실히 잡아 둡니다. UML과 분석 모델링 기법은 3강에서 이어집니다.

💡 요구사항이란 무엇이고 왜 따로 관리하는가

요구사항은 소프트웨어가 해결해야 할 문제와 지켜야 할 조건을 이해관계자가 합의한 형태로 적은 것입니다. 개발 후반에 요구사항 오류가 발견되면 설계·코드·테스트를 모두 되돌려야 하므로, 초기에 정확히 잡을수록 비용이 줄어듭니다. 이 때문에 요구사항을 체계적으로 다루는 활동 전체를 요구공학(Requirements Engineering)이라는 별도 분야로 다룹니다.

시험에서 가장 먼저 묻는 분류는 기능 요구사항과 비기능 요구사항입니다. 기능 요구사항은 시스템이 「무엇을 하는가」입니다. 회원 가입, 주문 취소, 월별 매출 보고서 출력처럼 입력·처리·출력으로 표현됩니다. 비기능 요구사항은 그 기능을 「얼마나 잘, 어떤 제약 아래에서」 하는가입니다. 응답 시간 2초 이내(성능), 연중 가동률(가용성), 개인정보 암호화(보안), 특정 DBMS 사용(제약 사항), 처음 쓰는 사람도 10분 안에 주문 완료(사용성) 같은 것이 여기에 속합니다.

판별 요령은 문장에서 동사를 지웠을 때 남는 것을 보는 것입니다. 「사용자는 비밀번호를 재설정할 수 있다」는 기능이지만 「비밀번호 재설정 메일은 5분 안에 도착해야 한다」는 시간 조건이 핵심이므로 비기능입니다. 같은 기능을 두고도 문장이 무엇을 요구하는지에 따라 분류가 달라집니다.

관점에 따라 사용자 요구사항(고객이 이해하는 언어로 쓴 상위 요구)과 시스템 요구사항(개발자가 구현할 수 있도록 상세화한 요구)으로 나누기도 합니다. 사용자 요구사항 하나가 여러 시스템 요구사항으로 쪼개지는 관계입니다.

💡 요구공학 프로세스와 요구분석기법

요구공학 활동은 보통 네 단계로 설명합니다. 순서 자체가 시험에 나오므로 「도출 → 분석 → 명세 → 확인」을 정확히 외워 두세요. 그리고 네 단계 전체에 걸쳐 변경과 추적을 다루는 요구사항 관리가 이어집니다.

단계	하는 일	대표 기법
도출(Elicitation)	이해관계자에게서 요구를 끌어냄	인터뷰, 설문, 브레인스토밍, 워크숍(JAD), 관찰, 프로토타이핑, 유스케이스·시나리오, 사용자 스토리
분석(Analysis)	충돌·누락·모호함을 찾아 정제하고 범위를 정함	요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석
명세(Specification)	합의한 요구를 문서·모델로 기록	비정형 명세(자연어·다이어그램), 정형 명세(Z, VDM 같은 수학 기반 언어)
확인(Validation)	명세가 이해관계자의 실제 의도와 맞는지 점검	검토(리뷰·워크스루·인스펙션), 프로토타입 시연, 모델 검증, 인수 테스트 기준 정의

출제기준의 세부항목 「요구분석기법」은 위 표의 분석 단계 기법을 가리킵니다. 각각의 뜻은 다음과 같습니다.

요구사항 분류: 기능/비기능, 제품/프로세스, 우선순위, 변경 가능성 등 기준으로 나눠 다루기 쉽게 만듭니다.
개념 모델링: 실세계 문제를 유스케이스 다이어그램, 데이터 흐름도, 클래스 다이어그램 같은 모델로 표현합니다. 모델 표기는 3강의 주제입니다.
요구사항 할당: 아키텍처 구성요소를 정하고 각 요구사항을 어느 구성요소가 맡을지 배정합니다. 할당 과정에서 새 요구사항이 드러나기도 합니다.
요구사항 협상: 이해관계자 사이에 충돌하는 요구를 조정합니다. 보통 우선순위를 매겨 절충합니다.
정형 분석: 수학적으로 정의된 명세 언어로 요구를 기술해 모순과 누락을 논리적으로 검사합니다.

명세 방식의 차이도 자주 나옵니다. 정형 명세는 표현이 엄밀해 모호성이 없고 검증 도구를 쓸 수 있지만, 작성과 이해가 어렵습니다. 비정형 명세는 누구나 읽을 수 있지만 같은 문장을 사람마다 다르게 해석할 위험이 있습니다.

검증(Verification)과 확인(Validation)도 구분해야 합니다. 검증은 「제품을 올바르게 만들고 있는가」, 즉 명세·설계대로 만들었는지 보는 것이고, 확인은 「올바른 제품을 만들고 있는가」, 즉 사용자가 실제로 원하던 것인지 보는 것입니다. 요구공학 마지막 단계는 사용자의 의도와 맞는지를 보므로 확인(Validation)입니다.

💡 요구사항 관리 도구와 추적성

요구사항은 프로젝트 내내 바뀝니다. 변경 요청을 접수하고 영향도를 분석해 승인·반려하고, 바뀐 버전을 기록하는 일을 체계적으로 하려면 도구가 필요합니다. 요구사항 관리 도구가 공통으로 제공하는 기능은 요구사항 저장과 식별자 부여, 속성(우선순위·상태·담당자) 관리, 변경 이력과 버전 관리, 그리고 추적성(Traceability) 관리입니다.

추적성은 요구사항이 설계 요소, 코드, 테스트 케이스와 어떻게 연결되는지 양방향으로 따라갈 수 있는 성질입니다. 이를 표로 정리한 것을 요구사항 추적 매트릭스(RTM)라고 합니다. 요구사항 R-07이 바뀌면 RTM에서 연결된 설계 문서와 테스트 케이스를 바로 찾아 영향 범위를 알 수 있고, 반대로 어떤 요구사항에도 연결되지 않은 코드는 불필요한 기능(gold plating)일 가능성을 의심할 수 있습니다. 이슈 트래커형 협업 도구나 전용 요구사항 관리 도구 모두 이 기능을 중심으로 만들어져 있습니다.

💡 애자일 — 선언, 스크럼, XP

애자일은 긴 계획과 문서를 먼저 확정하는 대신, 짧은 주기로 동작하는 소프트웨어를 만들어 피드백을 받으며 요구 변화를 흡수하는 접근입니다. 2001년 발표된 애자일 소프트웨어 개발 선언은 네 가지 가치를 내세웁니다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

선언문은 왼쪽 항목도 가치가 있지만 오른쪽에 더 높은 가치를 둔다고 명시합니다. 「애자일은 문서와 계획을 하지 않는다」는 선지는 이 문장 때문에 틀립니다. 선언문에는 이를 뒷받침하는 12가지 원칙이 함께 실려 있습니다.

스크럼(Scrum)은 가장 널리 쓰이는 애자일 프레임워크입니다. 2020년 11월판 스크럼 가이드 기준으로 정리하면 다음과 같습니다.

구분	내용
책임(3)	제품 책임자(Product Owner): 제품 백로그 관리, 가치 극대화 / 스크럼 마스터: 스크럼 이해·실천을 돕고 방해 요소 제거 / 개발자(Developers): 스프린트마다 사용 가능한 증분 생성
이벤트(5)	스프린트(한 달 이하, 다른 이벤트를 담는 그릇) / 스프린트 계획(한 달 스프린트 기준 최대 8시간) / 일일 스크럼(15분) / 스프린트 리뷰(최대 4시간) / 스프린트 회고(최대 3시간)
산출물과 약속	제품 백로그 ↔ 제품 목표 / 스프린트 백로그 ↔ 스프린트 목표 / 증분 ↔ 완료의 정의(Definition of Done)
경험주의 3기둥	투명성, 검사, 적응
가치(5)	확약(Commitment), 집중, 개방성, 존중, 용기

이전 판에서 쓰던 「개발팀」이라는 표현은 2020년판에서 「개발자」로 바뀌었고, 가이드는 스크럼 팀 안에 하위 팀이나 위계를 두지 않는다고 명시합니다. 완료의 정의를 충족하지 못한 백로그 항목은 스프린트 리뷰에 내놓을 수 없고 제품 백로그로 되돌아갑니다.

XP(eXtreme Programming)는 개발 실천법에 초점을 둔 애자일 방법입니다. 가치는 의사소통, 단순성, 피드백, 용기, 존중의 다섯 가지입니다. 대표 실천법으로 짝 프로그래밍, 테스트 주도 개발(테스트를 먼저 작성), 지속적 통합, 리팩터링, 작은 릴리스, 코드 공동 소유, 계획 게임, 고객 상주, 지속 가능한 속도(주 40시간) 등을 듭니다. 스크럼이 일하는 「틀(역할·이벤트)」을 정한다면 XP는 코드를 다루는 「습관」을 정한다고 대비해 두면 선지 구분이 쉬워집니다.

그 밖에 작업 흐름을 칸반 보드로 시각화하고 진행 중 작업(WIP) 수를 제한하는 칸반, 낭비 제거를 핵심으로 하는 린(Lean)도 애자일 계열로 묶입니다. 애자일에서 요구사항은 주로 「〈역할〉로서 나는 〈목표〉를 원한다, 〈이유〉 때문에」 형식의 사용자 스토리로 쓰고, 좋은 스토리의 조건을 INVEST(독립적·협상 가능·가치 있는·추정 가능·작은·테스트 가능)로 요약합니다.

💻 예제로 확인하기 — 속도와 번다운

스크럼 팀은 스프린트마다 완료한 스토리 포인트 합계를 속도(velocity)로 기록하고, 이를 남은 백로그 추정에 씁니다. 스프린트 안에서는 날마다 남은 작업량을 그린 번다운 차트로 진행을 봅니다. 아래 코드는 두 계산을 한 번에 보여 줍니다.

import math

done = [21, 18, 24]              # 지난 세 스프린트에 완료한 스토리 포인트
velocity = sum(done) / len(done)
remaining = 130                  # 제품 백로그에 남은 포인트
print("평균 속도:", velocity)
print("필요 스프린트 수:", math.ceil(remaining / velocity))

# 10일짜리 스프린트, 계획 30포인트의 번다운
plan = 30
burned = [0, 3, 3, 0, 5, 2, 0, 6, 4, 5]   # 날마다 완료한 포인트
left = plan
for day, b in enumerate(burned, 1):
    left -= b
    ideal = plan - plan * day / len(burned)
    print(f"{day:2}일차 남은 {left:2} / 이상선 {ideal:4.1f}")

평균 속도: 21.0
필요 스프린트 수: 7
 1일차 남은 30 / 이상선 27.0
 2일차 남은 27 / 이상선 24.0
 3일차 남은 24 / 이상선 21.0
 4일차 남은 24 / 이상선 18.0
 5일차 남은 19 / 이상선 15.0
 6일차 남은 17 / 이상선 12.0
 7일차 남은 17 / 이상선  9.0
 8일차 남은 11 / 이상선  6.0
 9일차 남은  7 / 이상선  3.0
10일차 남은  2 / 이상선  0.0

130 ÷ 21 ≈ 6.19이므로 스프린트는 올림해서 7개가 필요합니다. 번다운에서는 실제 남은 양이 내내 이상선보다 위에 있어 일정이 밀리고 있음이 보이고, 마지막 날 2포인트가 남았습니다. 이 2포인트짜리 항목은 완료의 정의를 충족하지 못했으므로 증분에 포함하지 않고 제품 백로그로 돌려보낸 뒤 다음 스프린트 계획에서 다시 우선순위를 정합니다. 「끝까지 마무리하려고 스프린트 기간을 늘린다」는 선택지는 스프린트 기간을 고정한다는 스크럼 규칙과 맞지 않습니다.

⚠️ 시험에 나오는 함정

기능 vs 비기능: 「~할 수 있다」는 기능, 「~초 안에」「~% 이상」「~를 사용해야 한다」는 비기능(성능·가용성·제약)입니다.
도출 vs 분석: 인터뷰·설문·관찰은 도출 기법, 분류·할당·협상·정형 분석은 분석 기법입니다. 프로토타이핑은 도출과 확인 양쪽에 쓰입니다.
검증 vs 확인: Verification = 명세대로 만들었나, Validation = 사용자가 원한 것인가.
정형 vs 비정형 명세: Z·VDM은 정형, 자연어·다이어그램은 비정형입니다. 정형 명세의 단점은 「작성·이해가 어렵다」입니다.
스크럼 vs XP: 스프린트·일일 스크럼·제품 책임자는 스크럼, 짝 프로그래밍·TDD·리팩터링·코드 공동 소유는 XP입니다. 「용기」와 「존중」은 두 방법의 가치에 모두 들어 있습니다.
스크럼 책임자의 일: 백로그 우선순위는 제품 책임자, 방해 요소 제거·코칭은 스크럼 마스터입니다. 스크럼 마스터는 작업을 지시하는 관리자가 아닙니다.

📝 핵심 요약 — 암기표

키워드	한 줄 정리
요구공학 순서	도출 → 분석 → 명세 → 확인 (+ 전 과정의 요구사항 관리)
요구분석기법	분류, 개념 모델링, 할당, 협상, 정형 분석
추적성	요구 ↔ 설계 ↔ 코드 ↔ 테스트 양방향 연결, RTM
애자일 4가치	개인과 상호작용 / 작동하는 SW / 고객 협력 / 변화 대응
스크럼	책임 3, 이벤트 5, 산출물 3(각 약속 1), 일일 스크럼 15분, 스프린트 한 달 이하
XP 가치	의사소통, 단순성, 피드백, 용기, 존중
속도	스프린트당 완료 포인트, 남은 포인트 ÷ 속도 → 올림

다음 강 「UML과 분석 모델 — 다이어그램·모델링 기법·분석 자동화 도구」에서는 개념 모델링에 쓰는 UML 14종 다이어그램과 관계 표기, 분석 자동화(CASE) 도구를 다룹니다.

📋 실전 문제

다음 중 비기능 요구사항에 해당하는 것은?

① 사용자는 장바구니에 담은 상품을 삭제할 수 있다.
② 관리자는 월별 매출 보고서를 내려받을 수 있다.
③ 검색 결과는 동시 사용자 500명 환경에서 2초 안에 표시되어야 한다.
④ 회원은 주문 내역을 기간별로 조회할 수 있다.
요구공학 프로세스의 순서로 옳은 것은?

① 도출 → 분석 → 명세 → 확인
② 분석 → 도출 → 확인 → 명세
③ 명세 → 도출 → 분석 → 확인
④ 도출 → 명세 → 분석 → 확인
요구사항 분석 단계의 기법이 아닌 것은?

① 요구사항 할당
② 요구사항 협상
③ 개념 모델링
④ 현장 관찰
정형 명세 기법에 대한 설명으로 옳은 것은?

① 자연어로 작성해 누구나 쉽게 이해할 수 있다.
② 수학적 기반의 언어로 기술하므로 모호성이 적고 작성이 상대적으로 어렵다.
③ 다이어그램만으로 요구사항을 표현하는 방식이다.
④ 사용자 스토리를 INVEST 기준으로 점검하는 방식이다.
2020년판 스크럼 가이드에 대한 설명으로 옳지 않은 것은?

① 스크럼 팀의 책임은 제품 책임자, 스크럼 마스터, 개발자로 나뉜다.
② 일일 스크럼은 15분으로 정해져 있다.
③ 스프린트 백로그에 대응하는 약속은 스프린트 목표이다.
④ 스크럼 마스터가 제품 백로그의 우선순위를 최종 결정한다.
XP(eXtreme Programming)의 실천법이 아닌 것은?

① 스프린트 회고
② 짝 프로그래밍
③ 테스트 주도 개발
④ 코드 공동 소유
요구사항 추적 매트릭스(RTM)를 활용하는 목적으로 가장 적절한 것은?

① 프로젝트 비용을 기능 점수로 산정한다.
② 요구사항 변경 시 연결된 설계·코드·테스트의 영향 범위를 파악한다.
③ 스프린트마다 완료한 스토리 포인트를 기록한다.
④ 화면 간 이동 흐름을 시각화한다.
지난 4개 스프린트의 완료 포인트가 20, 26, 22, 24이고 남은 제품 백로그가 125포인트일 때, 평균 속도로 추정한 필요 스프린트 수는?

① 4
② 5
③ 6
④ 7

✅ 정답과 해설

정답 ③ — 동시 사용자 수와 응답 시간 조건은 성능 요구, 즉 비기능 요구사항입니다. ①·②·④는 시스템이 제공하는 동작(삭제·내려받기·조회)을 정한 기능 요구사항입니다.
정답 ① — 요구를 끌어낸 뒤(도출) 정제하고(분석) 기록한 다음(명세) 사용자 의도와 맞는지 점검합니다(확인). 나머지는 순서가 뒤섞였습니다. 특히 ④처럼 분석 전에 명세하면 충돌·누락이 정리되지 않은 채 문서가 확정됩니다.
정답 ④ — 현장 관찰은 사용자가 실제로 일하는 모습을 보며 요구를 끌어내는 도출 기법입니다. ①·②·③은 분류·정형 분석과 함께 분석 단계의 요구분석기법입니다.
정답 ② — 정형 명세는 Z·VDM처럼 수학 기반 표기로 써서 모호성이 적지만 작성·이해 비용이 큽니다. ①·③은 비정형 명세의 특징이고, ④의 INVEST는 사용자 스토리 품질 점검 기준으로 명세 형식의 분류와 관계가 없습니다.
정답 ④ — 제품 백로그의 관리와 순서 결정은 제품 책임자의 책임입니다. 스크럼 마스터는 팀과 조직이 스크럼을 이해하고 실천하도록 돕고 방해 요소를 없애는 역할입니다. ①·②·③은 2020년판 가이드의 내용과 일치합니다.
정답 ① — 스프린트 회고는 스크럼의 이벤트입니다. ②·③·④는 XP의 대표 실천법입니다. 스크럼과 XP를 함께 쓰는 팀도 많지만, 「어느 방법의 요소인가」를 묻는 문제에서는 출처를 구분해야 합니다.
정답 ② — RTM은 요구사항과 설계·코드·테스트의 연결을 표로 관리해 변경 영향 분석과 누락 확인에 씁니다. ①은 비용 산정 기법(10강), ③은 속도 기록, ④는 화면 흐름도·스토리보드(4강)의 역할입니다.
정답 ③ — 평균 속도는 (20+26+22+24) ÷ 4 = 23입니다. 125 ÷ 23 ≈ 5.43이므로 스프린트는 올림해서 6개가 필요합니다. ② 5는 소수점 아래를 버린 값인데, 5스프린트로는 115포인트밖에 끝내지 못해 10포인트가 남습니다. ①·④는 평균 속도를 잘못 계산했을 때 나오는 값입니다.

📚 참고 자료

애자일 소프트웨어 개발 선언(한국어): https://agilemanifesto.org/iso/ko/manifesto.html · 12가지 원칙: https://agilemanifesto.org/iso/ko/principles.html
The 2020 Scrum Guide (Ken Schwaber, Jeff Sutherland): https://scrumguides.org/scrum-guide.html
Extreme Programming — Values: http://www.extremeprogramming.org/values.html
IEEE Computer Society, SWEBOK Guide V4.0 (Software Requirements 지식 영역): https://www.computer.org/education/bodies-of-knowledge/software-engineering
큐넷 정보처리기사 출제기준(2027.1.1~2029.12.31): https://www.q-net.or.kr/cst006.do?id=cst00601&code=1202

요구사항 확인 — 요구분석기법·요구공학·애자일