4장 요구 분석
- 소프트웨어 개발의 실제적인 첫 단계
- 사용자의 요구를 이해하는 단계
- 요구분석
1) 현재의 상태를 파악하고 요구를 정의한 후
문제해결과 구현될 시스템의 목표를 명확히 도출
1-1) 요구 추출
1-2) 도메인 분석
1-3) 모델링
1-4) 프로토타이핑과 시험
2) 명세서작성 (Software Requirement Specification, SRS)
- 요구 관리 (Requirement Management)
4.1 요구
- 소프트웨어 요구(requirement)란 시스템이 제공하여야 할 서비스와
이 서비스를 수행하는데 있어서 제약 사항
- 소프트웨어 요구 공학(requirement engineering)
: 이 서비스와 제약을 찾고, 분석하고, 문서로 남기며, 확인하는
일련의 과정을 지칭
- 요구 사항을 어떻게 정리해야하는지
: Unambiguous
: Correct
: Complete
: Consistent
: Feasible
: Traceable
- 기능적 요구 vs. 비기능적 요구
- 요구 추출의 어려움
: 사용자가 `진정으로' 원하는 요구를 찾아내는 일은 비용과 일정의 제약이
있는 상황에 쉬운 일은 아니다.
cf. 이해 당사자(stakeholder)의 우선순위가 다르고 시스템에 요구하는
역량이 다르기 때문
: 개발 팀이 응용 도메인에 대하여 충분히 알지 못한다.
: 사용자가 소프트웨어에 대한 요구를 정확히 표현하기 어렵다.
: 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생긴다.
: 소프트웨어 요구에 대한 명세와 구현이 분리될 수가 없어 정확히 명시하기
어렵다.
: 요구 추출 작업이 관리자, 사용자, 개발자 모두에게 과소평가되는 경우가
많다.
: 비기능적 요구를 파악하고 이해하지 못한다.
: 요구는 개발하는 동안 계속 바뀔 수 있고 심지어 사용 중에도 바뀔 수 있다.
4.2 요구 추출
- 요구 추출 대상 (그림 4.3)
: 고객
: 도메인 전문가
: 이해 당사자
: 사용자
: 역공학 (레거시 legacy 시스템)
- 요구 추출 방법
: 질문 리스트 (P.187~188)
: 고객 발표
: 문헌 조사
: 업무 절차 및 양식 조사
: 설문
: 인터뷰
: 브레인스토밍
: 프로토타이핑
: 사용자 스토리 (사용자가 시스템 역량을 기술한 사례)
- 사용자의 니즈 ==> 요구 목록 도출
: 요구 목록
일련 번호 (R1, R2, ..., C1, C2, ...)
우선 순위
4.3 도메인 분석
- 4.2 요구 사항 도출과 함께
이 요구 사항의 배경을 *이해*하고 개념을 *발견*하는 과정
: 설계 모델링에 필요한 개념과 비즈니스 규칙을 파악하는 목적으로 수행
- 도메인 정의
: 시스템의 대상 비즈니스를 도메인으로 분류하여 파악
(예제 4.3) 의료 시스템의 도메인(업무, 기관)을 나열하고
각 도메인의 범위를 기술
- 도메인 분석
: 도메인 개념 찾기
도메인 사전 작성
: 각 도메인 개념을 나열
: 도메인 개념의 타입을 분류 (예: 프로세스, 객체, 역할, 기능, 역할)
: 설명
비즈니스 규칙 정리
: 도메인 사전에 드러나지 않는 규칙
: 분류 - 사실, 추론, 액션 구동자, 제약, 계산 등
(예제 4.4, 4.5, 4.6)
: 도메인 분석 최종 산출물은 도메인 개념을 조직화한 사전
4.4 사용 사례
시스템이 사용자에게 제공하는 상호작용의 기본 단위
: 사용 사례를 모으면 시스템을 구성
: 사용 사례는 외부 관점에서 시스템을 설명
: 사용 사례는 기술 독립적
: 사용 사례로 시스템의 흐름도를 파악하려는 목적은 아님
: 사용 사례는 개발자와 이해당사자 (stakeholder) 간의 계약
: 사용 사례는 소프트웨어 개발 전 주기에서 사용된다.
도메인 분석과 다음 단계에 진행할 모델링(과 설계)를 연결해주는 역할
사용 사례 다이어그램과 명세 - 사용 사례를 정리하는 표기법
사용 사례 다이어그램
: 액터, 사용 사례, 시스템 범위, 사용 사례 간 관계 (포함과 확장)
액터
: 시스템과 상호 작용하는 외부 엔티티
사용 사례
: 액터 입자에서 본 시스템의 동작. 외부 동작
: 여러 세부 시나리오를 통합하여 일반화한 것 (정상 흐름, 오류, 예외 상황을 포괄적으로 포함)
시스템이 복잡하면 사용 사례가 많아져서 조직화할 필요가 있음
사용 사례 간의 포함 관계와 확장 관계
: 포함 관계 - 무조건적으로 포함하는 것
: 확장 관계 - 조건부로 포함하는 것
유스케이스를 작성하는 요령
: 액터는 (시스템을 사용하는) 사람, 외부 시스템, (임베디드 장치의) 센서나 모터 등 부품
: 외부에서 구분해서 인지하지 못하는 두 기능은 하나의 유스케이스로 표현
: 외부에서 구분하는 두 기능은 각각 별도의 유스케이스로 표현
: 논리적으로 유사한 기능을 하는 유스케이스들을 하나의 패키지로 묶어 정리할 수 있음
: 하나의 유스케이스는 정상적인 시나리오 뿐만 아니라 예외적인 시나리오 등을 모두 포괄한다.
: 각 유스케이스는 이를 활성화하는 액터가 연결되어 있어야 한다.
: 동일한 유스케이스에 두 액터가 연결 => 이 액터들에게 동일한 기능을 제공하는 경우
각 액터가 사용하는 기능들의 합집합을 이 유스케이스가 표현하는 것이 아님
: 유스케이스 간의 선/후행 관계는 다른 다이어그램 (액티비티)에서 표현
4.5 요구분석 명세서 (SRS)
SRS 목차 - 교재 참고
: 기능 요구 - 사용 사례
SRS는 소프트웨어 개발 전주기에 매우 중요 (슬라이드 그림 참고)
SRS는 소프트웨어 개발에 관여하는 모든 개발자 및 이해관계자에게 중요 (슬라이드 그림 참고)
4.6 요구 관리 도구
요구 목록의 정의와 추적성 및 변경 관리
Eclipse 플러그인의 ProR (웹사이트에서 찾아볼 것)
