요구사항 도출

<요구사항 개발 프로세스>
- 소프트웨어 개발을 위한 요구사항 개발을 위한 활동
  
  - 도출(Elicitation)
    - 인터뷰, 워크숍 등과 같이 요구사항을 찾아내기 위한 모든 관련 활동
    - 이해관계자 식별
    - 이해관계자로부터 요구사항 도출(수집X)

  - 분석(Analysis)
    - 요구사항을 더욱 자세하고 정확하게 이해
    - 요구사항 상세화 중복 제거 및 일관성 검사 등 품질평가
    - 우선순위
    - 모델링

  - 명세
    - 요구사항을 문서화

  - 검증(Validation)
    - 요구사항이 정확하고 올바르고 빠짐없이 작성 되었는지 확인



<요구사항 도출>
- 비지니스 분석가(business analyst)가 이해관계자로부터 목표 시스탬에 바라는 요구는 식별하는 단계
  - Scope and status : Project Management
  - Project Sponsor : Business requirements
  - Software Developement : Functional and nonfunctional requirements
  - Testing : Functional and nonfunctional requirements 




<요구사항 도출 기법>
- 인터뷰
- 워크숍
- 관찰
- 설문지
- 브레인 스토밍
- 문서 분석



<인터뷰>
- 직접 대화를 통하여 요구사항 도출
- 개이이나 소규모 그룹을 대상으로 실시하기 때문에 통제가 수월하다
- 친밀감을 형성하고 경청하는 자세가 중요
- 범위에 벗어나지 않기
- 폐쇄적인 질문보다 가능한 개방형 질문
  - 폐쇄적 질문(closed question) : yes or no와 같이 미리 정해진 해답을 가지는 질문이며 보통 확인을 받을 때 사용 
    - 개방형 질문(open question) : 답이 정해진 게 없으며 상세한 정보를 획득할 때 사용
- 5 whys 기법 활용하여 문제의 보다 근본 원인 식별



<5 Whys 예시>
- 문제점 : 육안 검사 시 간과한 점이 있다
  why 1 : 왜 간과하였는가 -> 제대로 보지 못하는 때가 있다
  why 2 : 왜 제대로 못 보는가? -> 잘 안보일 때가 있다
  why 3 : 왜 잘 안보이는가 -> 조명이 어둡다
  why 4 : 왜 조명이 어두운가 -> 조명 위치가 안좋다
  why 5 : 왜 조명 위치가 안좋은가 -> 작업장소에서의 조명위치에 기준이 없다
- 해결책 : 작업장소에서의 조명 위치, 밝기의 기준을 정하고 표준화한다



<워크숍>
- 이해관계자의 협업을 통한 요구사항 도출 및 정의
- 다양한 이해관계자, facilitator, 서기 참여
- 특정 주제 기반의 의견 공유
- 다양한 이해관계자의 요구사항을 동시에 도출
- 의견 충돌을 해소하고 가능한 한 빨리 합의에 도달
- 정해진 시간 집약적인 의견 교환 가능



<설문>
- 대규모 사용자 그룹의 요구를 이해하기 위한 조사 방법
- 상용 제품에 대한 피드백
- 가장 문제가 되는 영역을 파악할 때 사용
- 우선 순위 결정과 같은 정량적인 데이터의 제시가 필요할 때 



<브레인스토밍(Brainstorming)>
- 짧은 시간에 소수의 그룹(6-8)이 '최대한 많은 아이디어'를 이끌어 내가 위한 방법(집단적 창의적 발상 기법)
- 4S 원칙
  - 비판금지(Support) : 아이디어를 내놓은 동안에 어떤 아이디어라도 절대적 비판이나 평가하지 않는다
  - 자유분방(Silly) : 우스꽝스러운 발상과 기발한 발상 모두 대환영. 창의적 아이디어가 숨어있다
  - 양산(Speed) : 양은 질을 낳는다는 말이 있듯이 아이디어가 많을수록 그 속에 좋은 아이디어가 나타날 확률이 높다
  - 결함과 개선(Synergy) : 브레인소트밍에서 나오는 모든 아이디어는 기록하고 여러 아이디어를 결합해서 제3의 아이디어를 이끌어낼 수 있도록 한다



<관찰>
- 업무 환경에서 사용자 워크플로우를 관찰하여 현 시스템의 문제점을 식별하고 신규 시스템이 더 나은 워크플로우를 제공하는 방법 파악
- 적극적인 관찰(active observation) : 상용자가 업무 중에도 질문을 할 수 있다. 이는 사용자가 어떤 행위를 수행했을 때 그 이유를 바로 이해하는데 도움이 된다
- 수동적 관찰(passive observation) : 사용자의 업무를 방해하지 않고 조용한 관찰을 한다



<문서 분석>
- 문서 분석에는 사업계획서, 기술문서, 문제점 보고서, 기존 요구사항 문서 등의 검토가 포함된다
- 기존 시스템이나 신규 시스템에 대한 정보 습득
- 시스템 교체 프로젝트인 경우 더 이상 필요 없는 기능 뿐만 아니라 계속 유지해야하는 기능 식별
- 문제 보고서나 개선 요구서는 시스템이 추후 제공할 아이디어 제공