1. 요구사항 확인 - 2) 요구사항 분석

(1) 요구분석 기법

1. 요구 분석 개념

• 도출된 요구사항 간 상충 해결, 소프트웨어 범위 파악, 외부 환경과의 상호작용 분석
• 개발 대상에 대한 요구사항 중 명확하지 않거나 이해되지 않는 부분을 발견 및 걸러내는 과정

2. 요구 분석의 특징

• 분석 결과의 문서화 → 유지 보수에 유용하게 활용
• 보다 구체적인 명세를 위해 소단위 명세서 활용 가능
  • 소단위 명세서 : 데이터 흐름도에 나타나있는 처리 목을 1~2 페이지 정도의 소규모 분량으로 요약 작성하는 논리적 명세서
• 개발 비용이 가장 많이 소요 X → 유지 보수 단계가 가장 많이 소요

3. 요구 분석 기법

→ 요구 사항 확인(Validation), 구현 검증(Verification), 비용 추적 가능하도록

1. 요구사항 분류
   • 기능/비기능 분류
   • 요구사항이 소프트웨어에 미치는 영향 범위 파악
   • 생명 주기동안 변경이 발생하는지 확인
   • 하나 이상의 상위 요구사항에서 유도 or 다른 원천으로부터 직접 발생인지 분류
2. 개념 모델링 생성 및 분석
   • 요구사항을 더 쉽게 이해할 수 있도록 현실 세계 상황을 단순화, 개념적으로 표현
   • 객체 모델, 데이터 모델, 유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표 기반 모델, 사용자 인터페이스 등 다양한 개념 모델 작성 가능
   • 모델링 표기는 주로 UML을 사용
3. 요구사항 할당
   • 아키텍처 구성요소를 식별하는 활동
   • 다른 구성요소와 어떻게 상호작용하는지 분석 → 추가 요구사항 발견 간으
4. 요구사항 협상
   • 두 이해관계 사이 상충될 경우 적절한 지점 합의하기 위한 기법
   • 각각 우선순위 부여 → 중요도 파악 가능 → 문제 해결 도움
5. 정형 분석
   • 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현
   • 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
   • 요구사항 분석의 마지막 단계

4. 요구사항 분석 기술

• 청취 기술
• 인터뷰와 질문 기술
• 분석 기술 : 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성, 일관성 확보하는 기술
• 중재 기술
• 관찰 기술
• 작성 기술
• 조직 기술 : 방대한 정보를 일관성 있는 정보로 구조화하는 능력
• 모델 작성 기술

5. 요구사항 분석에 사용하는 기능 모델링 기법

1) 데이터 흐름도 (Data Flow Diagram: DFD)

1. 데이터 흐름도 개념
   • 데이터가 각 프로세스에 따라 흐르면서 변환되는 모습을 나타낸 그림
   • 시스템 분석과 설계에 유용
   • 시스템 모델링 도구로 가장 보편적으로 사용됨
   • 자료 흐름 그래프 or 버블 차트라고도 함

2. 데이터 흐름도 특징

• 구조적 분석 기법에 이용
• 데이터 흐름에 중심
• 제어의 흐름은 중요 X
• 시간 흐름을 명확하게 표현 X

3. 데이터 흐름도 구성 요소

• 처리기(Process) : 입력된 데이터를 원하는 형태로 변환하여 출력하기 위한 과정 → 원(O)로 표시
• 데이터 흐름(Data Flow) : DFD의 구성요소(프로세스, 데이터 저장소, 외부 엔터티)들 간의 주고받는 데이터 흐름을 나타냄 → 화살표(→)로 표시
• 데이터 저장소(Data Store) : 데이터가 저장된 장소 → 평행선(=)로 표시, 평행선 안에는 장소의 이름을 넣음
• 단말(Terminator) : 프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나나탬 → 사각형(ㅁ) 표시, 사각형 안에는 외부 엔터티의 이름을 넣음

2. 자료 사전

1. 자료 사전(Data Dictionary) 개념

   • 자료 요소, 자료 요소들의 집합, 흐름, 저장소의 의미와 그들의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전
   • 파일 혹은 DB에 있는 사료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이, 서술과 같은 데이터를 포함하는 참조를 위한 작업

2. 자료 사전의 작성 목적

• 조직에 속해 있는 다른 사람들에게 특정 자료 용어가 무엇을 의미하는지 알려주기 위해, 용어 정의 조정, 취합, 문서화
• 어떠한 자료의 흐름도 자료사전에 정의되어 있어야 함.

3. 자료 사전 기호

• =
  • 자료의 정의 → ~로 구성되어있다는 것을 의미
  • 정의는 주석을 사용하여 의미 기술
  • 자료 흐름과 자료 저장소에 대한 구성 내역 설명, 원소에 대해 값이나 단위를 나타냄
• +
  • 자료의 연결(and, along with)
• ( )
  • 자료 생략 가능
• { }
  • 자료의 반복 → 좌측엔 최소 반복, 우측엔 최대 반복 횟수
  • 디폴트로 최소는 0 / 최대는 무한대
• [ ]
  • 자료의 선택
  • 택일 기호 [ | ]는 ' | ' 로 분리된 항목 중 하나가 선택된다는 것을 표시

• ---

  • 자료의 설명 (주석)

4. 자료사전의 작성 원칙

• 자료 의미 기술
  • 자료의 의미는 주석을 통해 기술
  • 그 자료가 대상 시스템에서 사용되는 적합한 뜻을 표현해야 함
  • 중복되는 기술은 회피
• 자료 구성항목의 기술
  • 구성항목들을 그룹화
  • 각 그룹에 대해 의미 있는 이름 부여
  • 이름이 붙여진 각 그룹을 다시 정의
• 동의어 규정 준수
  • 사용자의 용어를 통일시키는 것보다는 사용하는 용어를 이용하여 자료를 정의
  • 하향식 분할하는 과정에서 부주의하게 동의어를 사용하는 것을 주의
• 자료 정의의 중복 제거
  • 동일한 자료에 대해 여러명의 분석가가 독립적으로 분석을 시행 → 자료 정의의 중복 제거 필요

(2) UML

1. UML의 개념

• 객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어

2. UML의 특징

• 가시화 언어
• 구축 언어 : 다양한 프로그래밍 언어로 실행 시스템 예측 가능, UML ↔ 코드 상호 변환 가능
• 명세화 언어
• 문서화 언어

3. UML 구성 요소

• 사물 : 명사 or 동사
• 관계 : 형용사 or 부사
• 다이어그램

4. UML 다이어그램

• 구조적/정적 다이어그램
  • 클래스 : 속성, 동작으로 구성 / 시스템 구조 및 문제점 도출 가능
  • 객체 : 클래스에 속한 객체들 → 객체 인스턴스 대신 실제 클래스 사용
  • 컴포넌트 : 코드 컴포넌트 기반의 물리적 구조
  • 배치 : 컴포넌트 사이의 종속성 및 위치 표현
  • 복합체 구조 : 클래스나 컴포넌트가 복합 구조를 갖는 경우
  • 패키지 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계
• 행위적/동적 다이어그램
  • 유스케이스 : 사용자 관점에서 시스템 활동 표현 → 시스템적 기능 요구 정의에 활용
  • 시퀸스 : 객체간 상호 작용을 메시지 흐름으로 표현
  • 커뮤니케이션 : 객체들이 주고받는 메시지 뿐만 아니라 객체간의 연관까지 표현
  • 상태 : 자신의 속한 클래스의 상태 혹은 타 객체와 상호작용에 따른 변화 → 진입조건, 탈출 조건, 상태 전이 등
  • 활동 : 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 어떤 기능을 수행하는지 표현
  • 타이밍 : 객체 상태 변화, 시간 제약을 명시적으로 표

5. UML 상세

1) 클래스 다이어그램

1. 클래스 다이어그램 개념 : 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간의 정적인 관계를 표현

2. 클래스 다이어그램 구성 요소

• 클래스 이름
• 속성
• 연산
• 접근 제어자
  • - : 클래스 내부접근만 허용(private)
  • + : 클래스 외부 접근 허용(public)
  • # : 동일 패키지, 파생 클래스에서 접근 가능(protected)
  • *~ *: 동일 패키지 클래스에서 접근 가능(default)

2) 유스케이스 다이어그램

1. 유스케이스 다이어그램 개념
   • 시스템이 제공하고 있는 기능 및 그와 관련된 요소를 사용자의 관점에서 표현
2. 유스케이스 다이어그램 구성 요소

• 유스케이스 : 시스템이 제공해야하는 서비스 → 액터가 시스템을 통해 수행하는 일련의 행위
• 액터 : 시스템과 상호작용하는 사람 또는 사물
• 시스템 : 전체 시스템의 영역

3) 시퀸스 다이어그램

1. 시퀸스 다이어그램 개념
   • 객체 간 상호작용을 메시지 흐름으로 표현
2. 시퀸스 다이어그램 구성요소

• 객체
  • 위쪽에 표시되며 아래로 생명선을 가짐
  • 객체는 사각형 안에 밑줄친 이름으로 명시
• 생명선
  • 객체로부터 뻗어나가는 점선
  • 실제 시간이 흐름에 따라 객체의 생명 주기동안 발생하는 이벤트를 명시
• 실행
  • 직사각형은 함수가 실행되는 시간을 의미
• 메시지
  • 객체 간의 상호작용의 수단

6. UML의 관계

• 연관 관계

  • 2개 이상의 사물이 서로 관련된 상태

  • 실선으로 연결, 방향성은 화살표

  • 양방향 관계의 경우 화살표 생략

    

• 집합 관계

  • 하나의 사물이 다른 사물에 포함

  • 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 빈 마름모를 연결

    

• 포함 관계

  • 집합 관계의 특수한 형태 → 포함하는 사물의 변화가 포함되는 사물에 영향 미치는 관계

  • 속이 채워진 마름모를 연결

    

• 일반화 관계

  • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현

  • 일반적인 개념 → 부모, 구체적인 개념 → 자식

  • 구체→일반으로 속이 빈 화살표를 연결

    

• 의존 관계

  • 서로 연관은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간만 연관을 유지하는 관계

  • 영향 주는 사물이 받는 사물쪽으로 점선 화살표 연결

    

• 실체화 관계

  • 사물이 할 수 있거나, 해야하는 기능으로 서로 그룹화 할 수 있는 관계를 표현

  • 사물에서 기능 쪽으로 속이 빈 점선 화살표 연결

    

(3) 애자일

1. 애자일 방법론의 개념

• 소프트웨어 개발 방법론의 하나로서 개발과 함께 즉시 피드백 → 유동적 개발

2. 애자일 방법론 등장 배경

• 소프트웨어 개발 환경의 변화 : 개발 트렌드 → 모바일 환경, 시장의 적시성과 잦은 배포의 중요성 부각
• 기존 방법론의 한계 : 문서 및 절차 위주 → 빠르게 적용하고 효율적으로 개발할 수 있는 방법론 필요

3. 애자일 방법론 특징

• 프로젝트 요구 사항은 기능 중심
• 절차와 도구보다 개인과 소통을 중요시
• 작업 계획을 짧게 세움 → 요구 변화 유연, 신속 대처
• 소프트웨어가 잘 실행되는 데 가치
• 고객과의 피드백 중요시

4. 애자일 선언문

1. 공정과 도구보다 개인과 상호작용
2. 계획을 따르기보다 변화에 대응
3. 포괄적인 문서보다 동작하는 소프트웨어
4. 계약 협상보다 고객과의 협력

5. 애자일 방법론 유형

1. XP(eXtreme Programming)

   • 의사소통 개선, 즉각적 피드백으로 품질 높이기 위한 방법론
   • 가치
     • 용기
     • 단순성 : 필요한 것만 하고 그 이상의 것들은 하지 않음
     • 의사소통
     • 피드백
     • 존중
   • 기본 원리
     • 짝 프로그래밍
     • 공동 코드 소유
     • 지속적이 ㄴ통합
     • 계획 세우기
     • 작은 릴리즈
     • 메타포어
     • 간단한 디자인
     • 테스트 기반 개발 : 테스트를 먼저 수행하고 테스트를 통과할 수 있도록 실제 코드 작성
     • 리팩토링
     • 40시간 작업
     • 고객 상주
     • 코드 표준

2. 스크럼

   • 매일 정해진 시간, 장소에서 짧은 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론'
   • 백로그 : 제품과 프로젝트에 대한 요구사항
   • 스프린트
   • 스크럼 미팅
   • 스크럼 마스터
   • 스프린트 회고
   • 번 다운 차트 : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트

3. 린

   • 낭비제거
   • 품질 내재화
   • 지식 창출
   • 늦은 확정
   • 빠른 인도
   • 사람 존중
   • 전체 최적화

6. 애자일과 전통적 방법론 비교