요구사항 개발 프로세스는 소프트웨어 개발을 위한 활동으로,
도출, 분석, 명세, 검증의 순서로 진행
1. 요구사항 도출
- 비즈니스 분석가(business analyst)가 이해관계자(project sponsor, Developer 등)로부터 목표 시스템에 바라는 요구를 식별하는 단계
2. 요구사항 도출 기법
2.1 인터뷰
-
직접 대화를 통하여 요구사항 도출
-
개인이나 소규모 그룹을 대상으로 실시하기 때문에 통제가 수월함
-
친밀감을 형성하고 경청하는 자세가 중요
-
범위에 벗어나지 않기
-
폐쇄적인 질문보다 가능한 개방형 질문
- 폐쇄적 질문(closed question): yes 또는 no와 같이 미리 정해진 해답을 가지는 질문이며 보통 확인을 받을 때 사용
- 개방형 질문(open question): 답이 정해진 게 없으며 상세한 정보를 획득할 때 사용 -
5 whys 기법 활용하여 문제의 보다 근본적인 원인 식별
그림 https://kanbanize.com/lean-management/improvement/5-whys-analysis-tool -
5 whys 기법은 반드시 5번의 질문이 아니라 근본의 원인을 찾을 때까지 질문 가능
2.2 워크숍
- 이해관계자의 협업을 통한 요구사항 도출 및 정의
- 다양한 이해관계자, facilitator, 서기 참여(facilitator가 의견 제시, 원할한 회의 촉진)
- 특정 주제 기반의 의견 공유
- 다양한 이해관계자의 요구사항을 동시에 도출
- 의견 충돌을 해소하고 가능한 한 빨리 합의에 도달
-> 짧은 시간 내에 많은 의견관을 이룰 수 있는 장점이 있음 - 정해진 시간 집약적인 의견 교환 가능
2.3 설문
- 대규모 사용자 그룹의 요구를 이해하기 위한 조사 방법
- 상용 제품에 대한 피드백(일반 대중을 대상)
- 가장 문제가 되는 영역을 파악할 때 사용
- 우선 순위 결정과 같은 정량적인 데이터의 제시가 필요할 때
2.4 브레인스토밍(Brainstorming)
- 짧은 시간에 소수의 그룹(6~8명)이 최대한 많은 아이디어를 이끌어 내기 위한 방법(집단적 창의적 발상 기법)
- 4S 원칙
- 비판 금지(Support)
아이디어를 내놓는 동안 어떤 아이디어라도 절대로 비판하거나 평가하지 않는다.
- 자유 분방(Sily)
우스꽝스러운 발상과 기발한 발상 모두 대환영. 창의적 아이디어가 숨어있다.
- 양산(Speed)
양은 질을 낳는다는 말이 있듯이 아이디어가 많을수록 그 속에 좋은 아이디어가 나타날 확률이 높다.
- 결합과 개선(Synergy)
브레인스토밍에서 나오는 모든 아이디어는 기록하고 여러 아이디어를 결합해서 제3의 아이디어를 이끌어 낼 수 있도록 한다.
2.5 관찰
- 업무 환경에서 사용자의 워크플로우를 관찰하여 현 시스템의 문제점을 식별하고 신규 시스템이 더 나은 워크플로우를 제공하는 방법 파악
- 적극적인 관찰(active observation): 사용자가 업무 중에도 질문을 할 수 있다. 이는 사용자가 어떤 행위를 수행했을 때 그 이유를 바로 이해하는데 도움이 된다.
- 수동적인 관찰(passive observation): 사용자의 업무를 방해하지 않고 조용한 관찰한다.
2.6 문서 분석
- 문서 분석에는 사업계획서, 기술문서, 문제점 보고서, 기존 요구사항 문서 등의 검토가 포함된다.
- 기존 시스템이나 신규 시스템에 대한 정보 습득
- 시스템 교체 프로젝트인 경우 더 이상 필요 없는 기능뿐만 아니라 계속 유지해야하는 기능 식별
- 문제 보고서나 개선 요구서는 시스템이 추후 제공할 아이디어 제공
