4.1 요구
요구
- 시스템에 대한 고객의 요청을 확정한 것
- 프로젝트 성공 필수 조건
- 제약 사항
- 특정 프로그래밍 언어, 특정 제품 사용
- SW 시스템 해결책을 제한
요구 분석
- SW의 개발 실질적인 첫 단계
- 사용자의 요구에 대하여 이해하고 정리하는 작업
- 세 가지 작업
- 요구 추출
- 요구 분석 및 정의
- 요구 확인
4.2 요구 추출
- 요구 분류
- 기능의 종류
4.3 요구 분석
- 요구 후보를 분석하고 결정하여 요구로 확정
- 요구 품질
- 원자적
- 완전성
- 비모호성, 통일성
- 추적성
- 우선순위화
- 테스트 가능성
도메인 분석
- 설계 모델링에 필요한 여러 개념과 비즈니스 룰 파악
- 방법
- 도메인 개념 찾기
- 도메인 사전 작성
- 비즈니스 규칙 정리
시나리오 기반 분석
- 다양한 사람들이 참여하여 다양한 용어와 개념 전달하여 요구 도출
- 커뮤니케이션의 장벽 해소
- 시나리오 기반(5H1W)
- 사용자 스토리
- 사용자/역할(who)는 목표/혜택/이익(why)를 얻기 위하여 행위/작업(what)을 원한다.
4.4 유스케이스
- 도메인 분석과 모델링 사이의 관문
- 결과를 액터, 사용사례, 관계들로 구성된 시스템 명세로 매핑하는 작업
- 요소
- 액터, 시스템 범위, 유스케이스, 관계
- 분석 과정
- 액터 찾기, 유스케이스 찾기, 유스케이스 사이의 관계 찾기
유스케이스 다이어그램
- 시스템의 기능을 나타내기 위하여 사용자 요구 추출 분석에 사용
- 구성
- 사용 사례 : 시스템 기능
- 액터 : 시스템과 상호작용 하는것(사용자, 시스템)
액터
- 시스템과 상호작용 하는 외부 엔터티
- 구별되는 이름과 설명 필요
- 액터가 될 수 있는 것
- 사용자가 맡은 일
- 다른 시스템
- 외부 엔티티는 사람, 하드웨어, 다른 자동화 시스템이 될 수 있음
- 여러 개의 참여 액터를 가질 수 있음
- 예시(사건관리 시스템)
- 시스템은 나중에 구체적인 사용 사례로 대치
- 같은 사람이 동시에 두 가지 역할을 할 수도 있지만 다른 액터로 표현
- 사건관리 시스템의 액터
- 관련 액터를 그루핑
- 소방관, 경찰관 → FieldOfficer
- 사고처리 본부 → Dispatcher
- 시장이나 행정관리 → 액터 X
- 액터 찾는 방법
- 찾음으로 써 시스템 범위, 필요한 사실을 발견
시나리오
- 시스템을 사용할 떄 무엇을 하고 경험하는지 글로 표현한 것
- 단일 액터의 관점
- 구체적인 상호작용
- 사용 사례의 인스턴스
- 비디오 대여
- 정의
- 간단한 단어로 시나리오 이름 표현
- 참여 객체 인스턴스
- 시나리오에 참여하는 객체들과 소속 클래스
- 사건의 흐름
- 사건을 순서대로 기술
- 작성에 도움이 되는 문서
- 사용자 지침서
- 절차를 설명한 매뉴얼
- 회사 표준 규격
- 사용자 노트 및 양식
- 사용자와 인터뷰
유스케이스 찾기
- 여러 개별 시나리오를 묶은 것
- 정상적인 흐름
- 오류, 예외 케이스
- 시나리오로부터 유스케이스 형성
- 개발자와 사용자가 함께 작성
- 현재의 응용 도메인에 대하여 기술한 여러 문서 이용
- 필요한 질문
- 시스템이 어떤 작업을 수행하기를 액터가 원하는가?
- 액터가 원하는 정보는 무엇인가?
- 누가 데이터 생성? 언제 자주 일어나나?
포함 관계
- 유스케이스 사이의 중복 제거
- 어떤 유스케이스가 다른 유스케이스를 포함하는 관계
확장 관계
- 유스케이스가 일정한 조건 아래 확장된 동작을 포함한다면 다른 유스케이스를 확장하는 관계
- Ex.) 결제 과정에 멤버십이 있는 경우 할인 적용
- 기본 유스케이스인 ‘결제’는 자체로 완전한 유스케이스
액터와 사용사례의 관계
- 통신관계
- 사용사례에 대한 정보 흐름
- 구동시키는 액터
- 사용사례와 통신하는 액터
- 기본 사용 사례는 독립적으로 존재할 수 있는 stand-alone 사용 사례
- 기본 사용 사례는 extension point에서 확장
- 포함 관계
- 사용 사례는 특정한 위치에 다른 사용 사례 포함 가능
- 여러 사용 사례에 같은 이벤트 플로우가 중복되는 것을 피할 수 있음
확장 vs 포함 관계
- 차이점
- 관계의 방향
- 포함관계
- 출발 사용 사례 —→ 목표 사용 사례(구동 조건이 출발에 기록)
- 확장관계
- 기본 사용 사례 ←— 확장 사례
- 확장 적용 조건이 확장 사용 사례의 시작 조건에 기록
- 선택방법
- 예외적이며 선택적이며 가의 발생 X → 확장
- 두 개 이상의 사용 사례가 공유 → 포함
4.5 요구 명세
작성 방법
- IEEE 830(현재는 ISO/IEC/IEEE 29148)
- 사용자와 개발자간의 이해를 돕기 위함
- Gilbert가 제안한 요구 분석서 작성시 주의사항
- 모두가 쉽게 이해할수 있도록 씀
- 개발자 사용자가 모두 동의
- 목표 시스템에 의하여 수행될 모든 기능을 정확히 기술
- 제약 조건 기술
