PE Notes · 사업관리
요구사항 수집 기법
인터뷰·워크숍·프로토타입·관찰·문서 분석을 PM 도구로 정리하고, 기능·비기능과 추적 매트릭스로 범위의 입구를 닫습니다.
나중에 고치면 값이 뛰는 쪽은 대개 코드가 아니라 빠뜨린 요구입니다. 범위 영역의 요구 수집은 의 필요·기대·제약을 식별해 문서화하는 프로세스입니다. 여기서 모인 문장이 와 일정·원가의 입구가 됩니다. 기법은 도구와 기법(T&T)으로 묶습니다.
다섯 축의 T&T
인터뷰는 1:1 또는 소그룹으로 맥락을 깊게 팝니다. 전문가 판단이 같은 자리에 붙습니다. 워크숍(퍼실리테이션)은 개발과 사용자가 한 방에 앉아 충돌을 그 자리에서 맞춥니다. 공동 설계 워크숍이 대표입니다. 브레인스토밍은 발산이고, 투표·다수결은 우선순위를 닫습니다.
은 글로 안 잡히는 화면·흐름을 만져 보게 합니다. 애자일 가 시장 가설을 시험한다면, 여기 프로토타입은 범위 합의용입니다. 관찰(직무 그림자)은 사용자가 말하는 일과 실제 클릭이 다를 때 씁니다. 문서 분석은 계약, 규정, 레거시 매뉴얼, 이전 결함 목록을 훑습니다. 설문은 다수 정량, 벤치마크는 유사 사례입니다.
친화도법과 마인드맵은 아이디어를 묶고 계층을 그립니다. 맥락 다이어그램은 시스템 경계와 바깥 액터를 한 장에 올립니다. 기법을 많이 적는 것보다, 이해관계자 수·모호함·규제 밀도에 맞춰 고르는 쪽이 답입니다.
| 기법 | 잘 맞는 때 | 한계 |
|---|---|---|
| 인터뷰 | 깊은 맥락, 소수 핵심 | 시간, 개인 편향 |
| 워크숍 | 충돌 조정, 공동 합의 | 진행 실패 시 소음 |
| 프로토타입 | UI·흐름 모호 | 껍데기를 완성으로 오해 |
| 관찰 | 말과 현업이 다름 | 피관찰 효과 |
| 문서 분석 | 규제·계약·레거시 | 낡은 문서 |
유형과 기능·비기능
비즈니스 요구는 조직이 이 일을 하는 이유입니다. 이해관계자 요구는 그룹별 필요입니다. 솔루션 요구는 기능과 비기능입니다. 전환 요구는 지금에서 앞으로 옮기는 데이터·교육·병행입니다. 프로젝트 요구는 일정·보고 같은 수행 조건이고, 품질 요구는 수락 숫자입니다.
기능은 시스템이 해야 할 일입니다. 로그인, 결제, 조회입니다. 나 사용자 스토리로 적습니다. 비기능은 어떻게 해야 하는가입니다. 응답 2초, 가용성 99.9%, 개인정보 암호화입니다. 기능 시험만 통과하고 부하·보안이 비면 인수가 멈춥니다.
| 비교축 | 기능 | 비기능 |
|---|---|---|
| 질문 | 무엇을 하는가 | 얼마나·어떻게 |
| 표현 | 유스케이스, 스토리 | 성능·보안·가용성 |
| 검증 | 기능 시험 | 성능·보안·운영 시험 |
추적과 범위로
추적 매트릭스(RTM)는 요구 ID를 설계·모듈·시험 케이스에 한 줄로 잇습니다. 빠짐과 변경 영향이 보입니다. 수집 산출은 요구 문서와 이 표입니다. 다음 칸이 범위 기술서와 WBS입니다. 표가 없으면 확인 프로세스에서 “이게 그 요구의 인도물인가”를 말로 합니다.
공공은 RFP와 과업을 문서 분석의 바닥으로 두고, 인터뷰와 워크숍으로 해석 차이를 줄입니다. 스타트업은 스토리 맵 워크숍과 얇은 프로토타입이 더 빠릅니다. 기법을 나열한 뒤 “지금 모호한 축에 무엇을 썼는가”를 한 줄 붙입니다.
답안은 인터뷰·워크숍·프로토타입·관찰·문서 분석, 기능≠비기능, RTM, WBS 입구를 한 장에 닫습니다.