PE Notes · 사업관리
요구공학
도출·분석·명세·검증·관리로 요구를 닫고, 기능·비기능과 추적·변경 통제를 SRS·RTM과 잇습니다.
빠진 한 줄이 후반에 보이면, 값은 코드가 아니라 일정으로 뜁니다. 은 이해관계자의 필요를 도출하고, 충돌을 가르며, 글로 고정한 뒤 시험 가능하게 확인하고, 바뀌면 기준선을 같이 옮기는 일입니다. 올바른 시스템을 올바르게 만들려면, 수집 기법만으로는 부족하고 전 기간의 관리가 붙어야 합니다.
다섯 칸의 흐름
은 인터뷰·워크숍·관찰·문서·으로 말을 꺼냅니다. 분석은 기능과 비기능을 가르고, 우선순위를 매기며, 서로 모순되는 문장을 한자리에서 맞춥니다. 명세는 와 ·스토리로 합의를 남깁니다. 검증은 리뷰와 시제품, 수락 기준으로 “이 문장이 시험 가능한가”를 묻습니다. 관리는 변경과 추적입니다.
수집 기법은 입구입니다. 요구공학은 그 입구 뒤에 명세·검증·기준선을 둡니다. 공공은 와 과업이 문서 분석의 바닥이고, 해석 차이는 워크숍에서 줄입니다.
| 칸 | 하는 일 | 남는 것 |
|---|---|---|
| 도출 | 필요·제약·암묵을 꺼냄 | 요구 목록 초안 |
| 분석 | 분류·우선·충돌 해소 | 합의된 요구 집합 |
| 명세 | 시험 가능한 문장 | SRS, 유스케이스 |
| 검증 | 완전·일관·실현 확인 | 리뷰·시제품 결과 |
| 관리 | 변경·추적 | 이력, 추적표 |
기능·비기능과 문장 품질
기능은 시스템이 해야 할 일입니다. 로그인, 결재, 조회입니다. 비기능은 얼마나·어떻게입니다. 응답, 가용성, 암호, 접근성입니다. 기능만 적고 비기능을 구호로 두면, 인수 시험에서 숫자가 없습니다.
좋은 문장은 빠짐이 없고, 서로 안 싸우며, 모호하지 않고, 시험으로 닫히며, 설계·코드·시험으로 이어집니다. “빠르게”는 요구가 아니고, “피크 1,000 TPS에서 2초”가 요구입니다. 관련 없는 희망은 잘라 냅니다.
| 비교축 | 기능 | 비기능 |
|---|---|---|
| 질문 | 무엇을 하는가 | 얼마나·어떻게 |
| 표현 | 유스케이스, 스토리 | 성능·보안·운영 숫자 |
| 검증 | 기능 시험 | 부하·보안·가용 시험 |
추적과 변경
는 요구 ID를 설계·모듈·시험에 한 줄로 잇습니다. 빠짐과 변경 범위가 표로 보입니다. 변경 요청이 오면 영향부터 보고, 가 승인·기각을 닫습니다. 승인된 뒤에야 을 고칩니다. 옆 자리 합의로 범위를 넓히면 입니다.
요구공학이 전 과정이면, 요구 관리는 그 안의 변경·이력 칸입니다. 개발이 시작된 뒤에도 추적표가 살아 있어야 감리와 인수가 “이 문장의 인도물인가”를 말로 하지 않습니다.
답안은 다섯 칸 이름, 기능≠비기능, 문장 품질, RTM과 CCB를 한 장에 닫습니다.