요구사항 개발과 도출 기법
요구사항 개발의 네 활동과 인터뷰·설문·워크숍·프로토타이핑 등 주요 도출 기법을 비교한다.
요구사항 개발의 네 활동
요구사항 개발 흐름도
| 활동 | 핵심 질문 | 대표 결과 |
|---|---|---|
| 도출(Elicitation) | 누구에게서 무엇을 알아내야 하는가? | 후보 요구사항, 업무 규칙, 용어, 문제점 |
| 분석(Analysis) | 요구가 타당하고 일관되며 실현 가능한가? | 분류·우선순위·모델·충돌 해결 결과 |
| 명세(Specification) | 합의한 요구를 어떻게 명확히 기록할 것인가? | 요구사항 명세서, 모델, 시나리오 |
| 확인(Validation) | 기록된 요구가 실제 필요와 맞는가? | 검토 결과, 수정·승인 사항 |
실제 수행은 일방향이 아니다. 분석 중 누락이 발견되면 다시 도출하고, 확인 중 모호성이 발견되면 명세를 수정한다.
도출 준비
도출 기법을 선택하기 전에 다음을 확인한다.
- 시스템의 목적과 범위
- 의사결정자·사용자·운영자·외부 기관 등 이해관계자
- 현행 문서, 법·규정, 화면, 데이터, 장애 기록
- 알고 싶은 정보와 미확인 가정
- 시간·비용·참여 가능성
특정 사용자 한 명의 의견을 전체 요구로 일반화하지 않도록 다양한 출처를 확인한다.
대표 도출 기법
요구사항 도출 기법 비교도
| 기법 | 적합한 상황 | 장점 | 주의점 |
|---|---|---|---|
| 인터뷰 | 깊은 경험·이유 확인 | 추가 질문 가능 | 시간 소요, 응답자 편향 |
| 설문조사 | 많은 사람의 의견 수집 | 빠른 정량 집계 | 복잡한 맥락 파악이 약함 |
| 브레인스토밍 | 짧은 시간에 아이디어 확대 | 다양한 후보 생성 | 평가와 생성을 동시에 하면 위축 가능 |
| 워크숍/JAD | 여러 부서의 충돌·합의 | 공동 이해와 결정 촉진 | 진행자와 의사결정권 필요 |
| 델파이 | 전문가 의견을 익명·반복 수렴 | 권위 영향 완화 | 반복에 시간이 걸림 |
| 관찰 | 말로 설명하기 어려운 실제 업무 | 숨은 절차·예외 발견 | 관찰 효과, 드문 예외 누락 |
| 문서 분석 | 규정·양식·기존 명세 확인 | 공식 규칙과 용어 확보 | 문서와 실제 업무 차이 가능 |
| 프로토타이핑 | 화면·상호작용 요구가 모호함 | 빠른 피드백 | 시제품을 완성품으로 오해 가능 |
| 시나리오/유스케이스 | 사용자 목표와 상호작용 확인 | 정상·대안·예외 흐름 파악 | 내부 구현 설계로 과도하게 내려가지 않음 |
기법은 조합한다
예를 들어 승인 업무를 개선할 때 문서 분석으로 공식 규칙을 찾고, 관찰로 우회 절차를 발견하며, 워크숍으로 부서 간 충돌을 합의하고, 프로토타입으로 화면 요구를 확인할 수 있다.
질문과 기록 방법
좋은 질문은 특정 답을 유도하지 않고 실제 업무·조건·예외를 묻는다.
- 나쁜 질문: “자동 승인이 더 편하지 않습니까?”
- 좋은 질문: “현재 승인이 지연되는 조건은 무엇이며, 예외 처리는 어떻게 합니까?”
기록할 때는 다음을 분리한다.
- 발언·관찰 사실: 실제로 들었거나 본 내용
- 해석: 분석자가 추론한 의미
- 후보 요구사항: 시스템이 제공해야 할 것으로 정리한 내용
- 미결 질문: 추가 확인이 필요한 사항
도출 결과 확인
도출 후에는 누락·중복·충돌·용어 불일치를 점검하고, 출처와 우선순위를 기록한다. 요구사항 관리 도구는 식별자, 상태, 버전, 출처와 변경 이력을 연결하는 데 도움을 주지만, 요구의 타당성을 자동으로 판단해 주지는 않는다.