요구사항 정의 — PRD·유저스토리·인수기준 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theorysw-engineering/requirements-prd

TRACK

SW-ENGINEERING

SLA

55분

LEVEL

중급

PHASES

3단계

ENV

local

INCOMING TICKET

“기획자: "다음 스프린트에 '로그인 기능'이랑 '검색 좀 빠르게' 넣기로 했어요. 근데 지난번처럼 만들고 나서 '이게 아닌데' 소리 나오면 안 되니까, 뭘 왜 만드는지랑 어디까지가 완료인지를 문서로 딱 정리해서 개발·QA가 같은 걸 보게 해주세요."”

YOUR ROLE

요구를 글로 정리해 팀을 정렬하는 PO/기획 담당

안 하면 나중에

요구가 말로만 떠다니면, 개발은 짐작으로 만들고 QA는 다른 기준으로 검수한다. "완료"의 정의가 사람마다 달라 재작업과 범위 다툼이 반복된다.

📋상황 브리핑

기획자가 말합니다.

"다음 스프린트에 두 가지를 넣기로 했어요. 하나는 '로그인 기능', 하나는 '검색이 좀 느리니까 빠르게'. 근데 지난번에 이렇게만 적어서 넘겼더니, 개발자는 소셜 로그인만 붙였고 저는 이메일 로그인을 생각했고 QA는 뭘 통과시켜야 완료인지 몰라서 배포 직전에 다 뒤집혔어요. 이번엔 만들기 전에, 뭘 왜 만드는지랑 '여기까지 되면 완료'라는 기준을 문서로 정해서 셋이 같은 걸 보게 해주세요."

요구사항 정의는 "코드를 잘 짜는 일"이 아니라 "무엇을 만들지에 대한 오해를 만들기 전에 없애는 일"이다. 이 Lab은 모호한 한 줄을 유저스토리로 다시 쓰고, 인수기준으로 완료를 검증 가능하게 만들고, 범위·우선순위·가정을 글로 못 박아 요구를 다스린다.

⏱ 55분📊 중급🔧 3단계#requirements#prd#user-story#acceptance-criteria

MISSION

모호한 요구를 유저스토리로 — 누가·왜부터 세운다

한 줄짜리 모호한 요구를 "역할·원함·이유"를 갖춘 유저스토리로 다시 쓰고, 기능 요구와 비기능 요구를 갈라낸다.

인수기준으로 완료 정의 — Given-When-Then

각 유저스토리에 "여기까지 되면 완료"를 Given-When-Then 형식의 검증 가능한 인수기준으로 정의하고, 정상 경로뿐 아니라 예외·경계 케이스까지 덮는다.

범위·우선순위·모호성 제거 — 요구를 글로 다스리기

In/Out 범위와 우선순위(MoSCoW)를 명시하고, 가정·제약·열린 질문을 목록으로 못 박아 스코프 크리프와 각자 다른 가정을 원천 차단한다.

📌 선수 지식

• [이론] sw-engineering/requirements-prd

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES