본문으로 건너뛰기
고객의 요구 결정하기
- 많은 고객은 무엇을 원하는지 잘 모를 수도 있다.
- 객체지향 접근법은 고객과 사용자들의 초기정보를 획득하고 요구사항 workflow의 초기정보로 사용한다.
요구사항 workflow
- 도메인의 이해 -> UML을 사용하여 서술 -> 요구사항 결정 -> 반복
도메인 이해
- 도메인 : 대상 프로덕트가 사용될 일반 영역
- 개발팀원이 도메인의 용어를 이해하지 못하면 결함이 생길 수 있다.
- 전문용어를 설명하기 위해 용어사전(glossary를 만들어야 함.
비지니스 모델
- 비지니스 모델 : 비지니스 프로세스들의 서술. 고객의 비지니스의 이해를 도와줌
- 인터뷰 : 고객과 사용자의 모든 정보를 추출할때까지 고객의 멤버와 모임을 계속 가진다.
- 인터뷰 방법 : 폐쇄형 질문(명시된 질문과 대답), 개방형 질문(자유 발언)
- 인터뷰 유형 : 구조적 인터뷰(폐쇄형 질문을 사용), 비구조적 인터뷰(1~2개의 폐쇄형 질문으로 시작하여 폭넓은 개방형 질문을 사용)
다른 기법
- 설문지 : 구두로 응답을 듣는것보다 정확할 수 있음.
- 비지니스 양식 조사 : 양식의 필드와 흐름을 파악
- 직접 관찰 : 해당 회사의 직원과 동행하여 업무를 관찰
유스케이스
- 액터(actor)와 인터렉션(interaction)으로 표현
- 액터는 반드시 사람일 필요는 없으며 시스템이 될 수도 있다.
초기 요구사항
- 요구사항은 동적으로 계속 변경되므로, 개발팀이 동의하고 고객이 승인한 요구사항들의 리스트를 유지해야 함.
- 기능적 요구사항 : 프로덕트가 수행해야만 하는 액션을 명세
- 비기능 요구사항 : 플렛폼 제약, 신뢰성 등의 성질을 명세
요구사항 workflow용 CASE 도구
- 장점 : UML용 drawing tool은 손으로 작성하는 것보다 빠르며, 저장/갱신이 용이
- 단점 : 도구를 사용하기 위한 학습곡선이 있으며, 가격이 비싸다.
요구사항 workflow용 척도
- 요구사항의 불안정성을 측정하여야 함.
- 척도 : SW개발 프로세스의 동안의 변경된 요구사항의 수
요구사항 workflow의 난제
- 초기부터 대상 프로덕트 사용자의 진심어린 협력이 어려움
- 고객과의 협상능력이 필요함.
- 정보를 소유한 사람과 깊이 있는 논의를 위해 만날 시간이 적다.
- 유연성과 객관성을 가져야 한다.
