5. 요구사항 발견 기법
5.1 요구사항 발견에서 사용하는 기법
5.2 이시가와 다이어그램
5.3 고객의 발표
5.4 기존 시스템의 분석
5.5 문헌(규정,양식) 조사, 업무절차, 설문조사
5.6 인터뷰
5.7 브레인스토밍
5.8 프로토타이핑
5.9 사용자스토리
5.10 유스케이스, DFD
5.11 요구사항 관리도구
5.12 도메인분석
5.13 정리
5.14 연습문제
5.1 요구사항 발견에서 사용하는 기법
요구사항의 발견은
Information System의 개발 과정 중에서 가장 중요하다.
이것의 수행을 위해 수많은 기법들이 개발되어 사용되고 있다
. 그중에서 가장 많이 사용되는
기법을 정리한다
[ 기법의 종류 ]
이시가와 다이어그램
고객의 발표
기존 시스템의 분석
문헌조사
, 업무절차, 설문조사
인터뷰
브레인스토밍
, JAD, JRP
프로토티이핑
사용자스토리
유스케이스
DFD
5.2 이시가와 다이어그램
이시가와 다이어그램은 주로 결함이나 문제에 대한 원인을 분석하기 위하여 사용하는 기법이다
.
fishbone diagram, cause-effect diagram, Fishikawa, herringbone이라고도 불린다.
이시가와 다이어그램은 아래와 같은 모습을 가지게 된다
. 즉, 특정 결과나 특성에 영향을
미치는 요인을 아래와 같은 형태로 표현하게 된다
5.2 이시가와 다이어그램
고객만족이
낮아지고 있다
이시가와 다이어그램을 그리는 방법을 단계별로 살펴본다
.
(예) 중원 전자의 고객만족도가 점점 낮아지고 있다. 그래서, 왜 그런일이 발생하는 지에 대한 분석을 위하여
중원 전자의 실무자와 임원들이 워크숍 장소에 모두 모였다
. 그들은 고객만족도가 낮아지는 것에 대한 심각성을
인식하고 왜 그런일이 발생했는지에 대한 분석을 하고자 한다
전체의 진행을 담당하는 김현수 전무가 앞으로 나가서
, 벽에 있는 칠핀에 아래와 같은 큰 선을 그었다
그리고
, 모임의 효과(effect)인 “고객만족이 낮아지고 있다＂를 적었다.
그다음에 참석자들에게 개인의 의견을 부탁했다
5.2 이시가와 다이어그램
고객만족이
낮아지고 있다
직원의 불친절
직원의 태도
서비스 센터의 직원이 의견을 내었다
.
직원이 불친절하기 때문입니다
.
이말을 듣고 김현수 전무는 이야기한다
. 그것은 직원의 태도에 대한 것이군요 그러면 이렇게 표시하면 되겠네요
하면서 위와 같이 표시하였다
: 여기에서 “직원의 태도＂라는 큰 분류를 얻었고, 여기에 속하는 항목으로 “직원의 불친절＂을 확인하였다
5.2 이시가와 다이어그램
고객만족이
낮아지고 있다
직원의 불친절
직원의 태도
품질의 저하
제품 품질
직원의 불친절
비정규직의 증가
보증기간의 축소
영업 및 서비스 센터의 직원이 의견을 내었다
.
제품의 품질이 나쁘게 출시되고 있습니다
제품이 보증기간이
2년에서 1년으로 줄어서 그런 것 같습니다.
서비스 센터에서 비정규직을 활용하므로
, 고객에게 불친절한 것 같습니다.
이말을 듣고 김현수 전무는 이야기한다
. 그것은 “직원의 태도”에 대한 것과 “제품 품질”에 대한 것이군요
그러면 이렇게 표시하면 되겠네요
. 하면서 위와 같이 표시하였다
5.2 이시가와 다이어그램
고객만족이
낮아지고 있다
직원의 불친절
직원의 태도
주말운영시간의 폐쇄
조직
고객지원에 대한 안내의 부실
품질의 저하
제품 품질
경쟁사의 서비스 강화
주변환경
직원의 불친절
비정규직의 증가
보증기간의 축소
유사제품의 출시
이어서 참석자들은 아래와 같은 의견을 내놓았고
그것은 옆의 그림처럼 표현되었다
경쟁사가 서비스를 강화하기 때문입니다
.
유사제품이 많이 출시되어 비교하기 때문입니다
주말에 고객 지원센터를 운영하지 않기 때문입니다
고객지원에 대한 안내가 부실하기 때문입니다
위의 의견들은 “주변환경”
, “조직” 으로
분리되어 표현됩니다
.
5.2 이시가와 다이어그램
고객만족이
낮아지고 있다
직원의 불친절
직원의 태도
예산의 축소
조직
고객지원에 대한 안내의 부실
품질의 저하
제품 품질
경쟁사의 서비스 강화
주변환경
비정규직의 증가
보증기간의 축소
보증범위와 대상에 대한 인식 부족
유사제품의 출시
주말운영시간의 폐쇄
이어서 참석자들은
“고객지원 예산의 축소” 때문이라는 의견을
제시하였는데
, 이것은 “주말 운영시간의 폐쇄＂에
대한 근본적인 문제가 되므로
,
그림을 오른쪽과 같이 변경합니다
.
다음으로 “보증범위와 대상에 대한 인식부족”이라는
의견을 제시하였는데
, 이것은 “고객 지원에 대한 안내의
부실＂이라는 부분에 대한 세부사항이 되므로
오른쪽 그림과 같이 표현합니다
.
5.2 이시가와 다이어그램 (연습문제 해답)
고객만족이
낮아지고 있다
직원의 불친절
직원의 태도
예산의 축소
조직
고객지원에 대한 안내의 부실
품질의 저하
제품 품질
경쟁사의 서비스 강화
국내환경
비정규직의 증가
보증기간의 축소
보증범위와 대상에 대한 인식 부족
유사제품의 출시
주말운영시간의 폐쇄
직원의 교육
서비스 교육 필요
보증기간확대
제품포장재 불량
국제환경
환율의 급등
A
B
C
D
D
5.3 고객의 발표
고객의 발표는 요구사항을 파악하기 위한 좋은 방법이다
. 이것을 위한 가이드는 다음과 같다.
고객은 임원과 사용자로 나누어서 발표하도록 조정한다
. 즉 임원의 요구사항과 사용자의 요구사항을 분리하여 듣는다
고객이 발표할 때는 “데이터“
, “프로세스“, “인터페이스“, “외부연결 기능＂의 관점에서 발표하도록 조정한다
고객은 고객의 언어로 이야기한다
.
시스템 분석가나 개발자는 고객의 발표에 대하여 기술적 관점이 아닌 고객의 관점에서 이해하도록 한다
.
가능하다면
, 발표자료를 참석자들이 미리 검토할 시간을 주도록 한다
발표할 때는
Information System에 관련된 사람들은 전부 참석하도록 한다
발표는 일방적인 것이 아니라
, 프로젝트에 관련된 사람들의 의견 교환의 장이 되도록 한다
5.4 기존 시스템의 분석
시스템을 개발하는 경우에
, 새로 개발하는 경우는 거의 발생하지 않는다. 그러므로 이미 기존에 사용하고 있는 시스템에
대한 분석은 고객의 요구 사항을 이해하고
, 향후 개발을 수행하는데 매우 중요한 과정이다
기존 시스템의 분석을 통하여 개발하고자 하는 시스템이 수행하는 것에 대한 기본 자료를 확보한다
- 사용자에게 제공하는 화면
- 시스템의 각 단계에서 취급하는 데이터
- 업무의 진행 프로세스와 시스템의 연계
- 예외사항에 대한 대처방안(데이터타입, 프로세스 오류, 프로그램 장애)
- 현재 시스템이 가지고 있는 문제의 구체적 파악(사용자, 임원)
기존 시스템의 소스분석을 통하여 중요 핵심 로직에 대한 절차와 처리방법을 확보한다
가능한 경우
, Reverse Engineering을 통하여 핵심 로직에 대한 실행 가능한 절차를 확보한다
기존 시스템의 산출물을 통하여 아래의 사항을 확인한다
- 제공하는 기능 목록
- 사용하는 기능 목록 및 사용하지 않는 기능 목록
- DBMS의 구조
- H/W의 구조
- Software Architecture
- 상용 시스템의 배치도
- Component 목록 및 소스/실행파일
5.5 문헌조사, 업무절차, 설문조사
시스템을 개발하는 경우에
, 새로 개발해야 하는 시스템에 대한 파악을 위하여 아래의 과정을 수행할 수 있다
문현 조사
- 업무 관련 규정집
- 업무 운영 매뉴얼
- 각 팀별로 만들어진 가이드라인
- 산업 및 기업 표준
- 관련 정부 정책 및 규제, 가이드
- 해당 도메인에 대한 교육자료나 튜토리얼
업무절차
- 사용중인 양식의 분석
- 결재관련 절차의 분석(양식별)
- 결재에 준하는 절차에 대한 분석(전결, 대결, 비결재 항목)
설문조사
- 필요한 경우에 필요한 그룹을 대상으로 별도의 설문조사를 수행해서 요구사향에 대한 발견 및 확인의 절차를 수행한다
- 설문은 “분석된 내용에 대한 확인의 측면”과 “표현하기 어려운 요구사항에 대한 발견”의 관점에서 수행한다
- 설문은 자체에서 수행하거나, 외부에 의뢰하여 진행한다
5.6 인터뷰
시스템을 개발하는 경우에
, 고객의 의견을 직접 듣기 위하여 인터뷰를 수행한다. 이때 아래의 사항을 주의한다
[ 인터뷰 진행 절차 ]
필요성의 확인 고객과의 협의에 의한 대상 및 일정 확인 인터뷰계획서 작성 인터뷰 수행 결과의 분석 및 반영
[ 주의 사항 ]
-
인터뷰는 시간과 “어떤 고객을 대상으로 할 것인가”가 가장 중요하다
. 그러므로, 확인해야 하는 내용에 따라서 적당한
대상을 선정하고 최장
1시간 이내에 완료해야 한다
-
질문서는 인터뷰를 하기 전에 작성되어야 하며 정확한 내용과 시간이 명시되어야 한다
. 그리고 고객에게 질문서를 미리
제공하는 것도 좋은 방법이다
(거부감과 부정적 시각을 상쇄하는데 효과적이다)
-
인터뷰의 수행에 따른 주의 사항은 다음과 같다
.
실천해야 할 것
피해야 할 것
예의바른 질문과 태도를 유지할 것
불필요한 내용은 피할 것
고객의 답변을 주의깊게 들을 것
결과를 가정하여 이야기하지 말 것
고객이 이해할 수 있는 용어를 사용할 것
질문자는 말을 줄일 것
명확한 표현을 사용할 것
녹음하지 말 것
고객이 설명할 수 있도록 질문할 것
개인적 편견을 가지고 듣지 말 것
정해진 주제에 대해서만 이야기 할 것
고객이 결론을 말하기 전에 미리 가정하거나 말하지 말 것
5.6 인터뷰
인터뷰 계획서의 예
인터뷰 담당자
: 조민호,
인터뷰 일자
: 2019. 12. 15 15:00 ~ 16:00)
인터뷰 장소
: 프로젝트 회의실
인터뷰 목적
: 학사 운영 시스템의 기능 추가
인터뷰 대상
: 학사 시스템 운영자
시간
질문
대답
1~2분
-
소개
, 감사의 말
-
인터뷰의 필요성
5 분
질문
1
-
학사 시스템에서 과거 수강 정보를
보여주는 것이 왜 필요합니까
?
5 분
질문
2
-
중국말로된 버전을 이번에 출시해야
하는지
, 아니면 미루어도 되나요?
…..
1~2분
-
참석자에 대한 감사의 말
-
인터뷰자료가 어떻게 사용되는지 설명
인터뷰에 대한 의견
(담당자가 작성)
5.7 브레인스토밍
브레인스토밍
(Brainstorming)은 창의적인 아이디어를 생산하기 위한 학습도구이자 회의기법이다
브레인 스토밍은 집단적인 창의력 발상 기법으로 집단에 소속된 인원들이 자발적으로 자연스럽게 제시된
주제에 대하여 의견을 제시하고 이것을 통하여 해답을 찾고자 노력하는 것이다
1930년 알렉스 오스본(Alex Faickney Osborn)의 저서인 “Applied Imagination”을 통해 대중화 되었다
브레인스토밍은 자유롭고
, 익명성을 보장하며, 다른 참가자의 의견에 대해 이의제기나 기타 활동을 하지 않고
자신의 의견을 표현하는 것이 핵심이다
.
프로젝트에서 브레인스토밍을 하는 방법중의 하나가
JAD(Joint Application Development)이다.
JAD는
- 프로젝트에 관련된 사람(고객, 사용자)들이 외부의 격리된 장소에서 만나서
- 요구사항을 정의하기 위한 공동작업을 수행한다
- 이때, 온전히 요구사항 도출에 집중하고, 다른 업무의 방해를 받지 않아야 하며
- 결과는 요구사항에 대한 문서로 작성되어야 한다
JRP(Joint Requirement Planning)은
- JAD를 수행햐는 기법으로
- 요구사항 정의나 문제의 분석를 위하여
- 구성된 그룹 회의 절차를 말한다 (예: 회의실의 구성, 회의결과의 정리 형태, 회의진행 방법등에 대한 절차)
5.8 프로토타이핑
프로토타입
(Prototype)은 수행하는 것은 프로토타이핑(Prototyping)이라 한다
프로토타입은 시스템의 예상 기능이나 화면을 미리 구현하여 고객과 협의하는 것을 말한다
프로토타입은 사용자의 숨겨진 혹은 미처 인식하지 못한 요구사항을 발견하는 데 유용한 기법이다
프로토타입은 전용 언어를 사용할 수도 있지만
, 일반적인 툴을 이용하여 진행할 수 있다
(예) 저자의 경우, 프로젝트를 진행하기 전에 중요한 화면 10~30개 정도를 파워포인트를 이용하여
미리 제작한다
. 그래서 A 화면에서 B화면, C화면으로 넘어가는 과정과, 각 화면에서 보여지는
자료
, 버튼의 모양/위치, 작동 시기등에 대하여 고객과 화면을 중심으로 협의를 한다
웹프로젝트를 수행하는 경우에는
, 드림위버를 이용하여 미리 화면을 구성하고, 이것을 기반으로
고객과 협의하는 과정을 진행하였다
프로젝트 결과물에 대한 고객의 만족도는 화면의 구성
, 사용의 편리성에 좌우되는 경우가 많다.
이런 점을 고려한다면
, 프로토타입은 성공적인 프로젝트를 위한 요구사항의 발견 및 개발에 대한 기대치를
조율하는 데 유용한 기법이다
5.9 사용자 스토리
사용자 스토리는
XP/에자일 방법에서 사용자의 요구사항을 발견하기 위하여 사용하는 방법이다
사용자 스토리는 사용자와 개발자가 함께 제작한다
사용자 스토리는 시스템에 대한 고객의 요구사항을 고객의 언어로 기술한 것이다
사용자 스토리는 “사용자 역할“
, “행위와 목표” 그리고 “이유”를 아래와 같은 형식으로 기술하고,
이카드를 한쪽에 모아서 요구사항을 파악하기 위한 기본 자료로 사용한다
스토리
ID
M102
작성일자
2014-08-22
우선순위
상 중하
추정
1주
담당개발자
홍길동
스토리
쇼핑몰 회원은 카테고리를 선택하여 카테고리에 속한 상품의 목록을
조회한다
.
비고
하위카테고리가 존재하는 카테고리에는 상품이 포함되지 않는다
.
최하위 카테고리를 선택한 경우에만 상품 목록이 조회되어야 한다
.
[
사용자 스토리 카드의 예 ]
5.10 유스케이스 , DFD
유스케이스와
DFD는 사용자의 요구사항을 발견하기 위햐 가장 일반적으로 사용하는 기법이다.
유스케이스는 객체지향 방법론에서 별도로 설명한다
DFD는 구조적 방법론에서 별도로 설명한다
5.11 요구사항 관리 도구
요구사항의 관리를 위해서 별도의 도구를 사용하는 경우가 많다
.
이때 도구가 제공하는 기능은 다음과 같다
.
- 요구사항 정리 기능
- 요구사항의 변경 및 이력관리
- 필요한 용어 정의
- 요구사항의 우선순위
- 요구사항에 대한 일정관리
요구사항 관리를 위한 대표적인 도구는 다음과 같다
- IBM의 RequisitePro
https://www.ibm.com/developerworks/rational/library/445.html
- DOORS
https://www.ibm.com/support/knowledgecenter/en/SSYQBZ_9.6.1/com.ibm.doors.requirements.doc/helpindex_doors.html
- ProR : 이클립스에서 수행되는 공개 소프트웨어
https://www.eclipse.org/rmf/
5.12 도메인 분석
도메인
시스템
도메인은 고객이 수행하는 비즈니스에 적용되는 것이다
(예) 의료 도메인, 물류 도메인
컴퓨터에 기반한 환경에 적용되는 개념이다
(이책에서의 정의)
시스템은 설계
, 모델링, 구현의 단계를 포함한다
고
객
의
영
역
개
발
자
의
영
역
[ 도메인 분석의 영역 ]
-
도메인 정의
-
도메인 개념 정리
: 요구의 필요성, 중요성, 접근방식을 결정
-
도메인 사전 작성
: 단어 정의, 타입
-
도메인 비즈니스 규칙 정리
: 기본적인 절차, 규칙의 파악
Information System을 개발하기 전에, 요구사항의 분석을 성공적으로 수행하기 위해서는 고객이 종사하는 분야(=도메인:Domain)에 대한
지식이 필요하다
. 그러므로, 도메인 분석의 위치와 도메인의 이해를 위해 해야 할 일에 대하여 정리해 본다
5.13 정리
