02. 요구사항 확인

요구분석 기법

요구공학

• 고객 요구를 체계적으로 수집, 분석, 명세화, 검증, 추적, 변경되는 요구사항을 도출하고 관리하는 기법

필요성

분석의 어려움 : 이해부족, 의사소통, 잦은 요구사항의 변겅
요구사항 변화 : 요구사항은 개발 초기에 불완전하고, 개발 동안 지속적으로 변화
관점별 차이 발생 : 묵시적 요구사항, 변경과 추적에 대한 문제, 해당 업무에 대한 지식

개발 프로세스

1. 도출 | Elicitation

• 요구사항 분류

• 도출 기법

1. 분석 | Analysis

• 요구사항 분류

• 개념 모델링

• 기술 구조 설계 및 요구사항 할당

• 요구사항 협상

1. 명세 | Specification

• 시스템 정의서

• 시스템 요구사항 명세서

• 소프트웨어 요구사항 명세서

1. 확인 | Validation

• 검토

• 프로토타이핑

• 모델 검증

• 인수테스트

도출 | Elicitation

• 소프트웨어가 해결해야 할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가 확인
• 요구사항 도출 기법

  • 인터뷰 | Interview

    사용자들과의 이야기, 대담을 통한 요구사항 도출

  • 관찰 또는 문화기술적 연구 | ethnography

    사용자의 모습을 지켜보고 사용자들이 무엇을 사용하는지, 어떻게 사용하는지 등을 살피는 기법

  • 사용자 스토리

    애자일에서 사용

    사용자 요구사항을 간단하게 정리한 문서

  • 시나리오

    사용자의 요구사항을 이야기식으로 풀어내는 방법

  • 설문조사

    이해당사자들로부터 요구를 찾는 도구

  • 브레인스토밍

    여러 명으로부터 정보를 얻는 효과적인 방법

  • 포커스 그룹

    제품의 요구사항에 대한 아이디어를 만들기 위해 소집된 사용자 대표 그룹

분석 | Analysis

• 실질적인 첫 번째 단계
  • 소프트웨어 개발 출발점
• 요구사항들 간에 상충되는 것을 해결
  • 사용자의 요구를 추출해 목표를 정하고 어떤 방식으로 해결할 것인지 결정
  • 요구사항 명세서를 작성
• 소프트웨어의 범위 파악
• 업무환경과의 상호작용 파악
  • 도메인 분석
    • 개념
      • 요구사항의 배경을 말한다
      • 설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악한다
    • 배경파악을 위한 세 가지 단계
      • 도메인 개념 찾기
      • 도메인 사전 작성
      • 비즈니스 규칙 정리
• 구조적 분석 도구

  • 자료 흐름도

    Data Flow Diagram

  • 자료 사전

    Data Dictionary

  • 소단위 명세서

    Mini-Spec

  • 개체 관계도

    Entity Relationship Diagram

  • 상태 전이도

    State Transition Diagram

• 객체지향 분석도구
  • Unified Modeling Language
  • Modeling

명세 | Specification

• 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성
• 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성
• 요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기반	수학, 논리학	자연어, 그림 중심
작성기법	수학적 기호, 정형화된 표기법	일반 명사, 동사 등의 자연어를 기반으로 서술하거나다이어그램으로 작성
장점	명세 오류 및 모호성 쉽게 파악	사용자/개발자 간의 의사전달 용이
단점	작성이 어렵고 많은 시간 소요	내용이 모호하고 완전한 검증 곤란
언어 종류	VDM, Z, Petri-net, CSP	FSM, Decision, Table, ER Modeling, State Chart(SADT)

• 산출물
  • 시스템 정의서
  • 시스템 요구사항 명세서
  • 소프트웨어 요구사항 명세서

확인 | Validation

• 분석가가 요구사항을 이해했는지 확인

  Validation

• 요구사항 문서가 일관성 있고 완전한지 검증

  Verification

• 이해관계자들이 문서를 검토하고 형상관리를 수행

요구사항 분석 기법

요구사항 분류 | Requirement Classification

• 기능 / 비기능 분류

	기능요구	비기능요구
정의	- 시스템의 기능에 대한 요구 - 외형적으로 나타내는 기능과 동작	- 시스템이 제공하는 기능과는 관련이 없는 요구 - 기능요구를 지원하기 위하여 파생적으로 필요한 도구
특징	- 외부 사용자에게 직접적으로 혜택을 줄 수 있는 시스템의 기능 - 업무절차나 기계 동작을 실현한 것 - 동사로 표현 - 사용 사례로 정리	- 요청된 기능 이외 시스템이 갖추어야 할 조건과 특징 - 응답속도, 고장에서 회복되는 기간, 보안 등 - 형용사로 표현 - 품질 속성 시나리오로 정리
종류	- 입력의 검증 - 정확한 작업순서 - 비정상적인 상태(overflow, network error)에 대한 응답 및 복구 - 매개변수의 유효성 - 입출력 관계	- 외부인터페이스 - 메모리 제약 - 성능요구(처리량, 반응 속도, 실시간 처리, 자원 이용률) - 사용자의 특성과 가정 - 설치 환경의 적합성

• 요구사항이 소프트웨어에 미치는 영향 범위 파악

• 생명주기 동안 변경이 발생하는지 확인

개념 모델링 | Conceptual Modeling

• 요구사항을 더 쉽게 이해할 수 있도록 현실 세계 상황을 단순화하여 개념적으로 표현

• 모델링 표기는 주로 UML을 사용

요구사항 할당 | Requirement Allocation

• 요구사항을 만족시키기 위한 구성 요소를 식별

• 식별된 구성 요소들 간에 어떻게 작용하는지 분석하는 과정에서 추가 요구사항 발견

요구사항 협상 | Requirement Negotiation

• 요구사항이 서로 충돌될 경우 적절히 해결하는 과정

• 요구사항이 서로 충돌될 경우 우선순위를 부여하여 문제 해결

정형분석 | Formal Analysis

• 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정

---

UML | Unified Modeling Language

개념

• 프로그램 설계를 표현하기 위해 사용하는 표기법

• 시스템 개발 과정에서 이해관계자 사이에 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어

• 소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시각화, 문서화하는 언어

• 프로그램언어가 아닌 기호와 도식을 이용하여 표현하는 방법을 정의

특징

가시화 언어 : 소프트웨어의 개념 모델을 시각적인 그래픽 형태로 작성
명세화 언어 : 분석, 설계, 구현 단계의 각 과정에서 필요한 모델을 명세화할 수 있는 언어
구축 언어 : 명세화된 설계 모델은 다양한 언어의 소스코드로 변환하여 구축
문서화 언어 : 일련의 과정을 문서로 남겨 계속 유지 보수

구성요소

사물 | Things

• 모델을 구성하는 가장 중요한 기본 요소이며 다이어그램 안에 관계가 형성될 수 있는 대상

구조사물

• 시스템의 개념적, 물리적 요소
• ex) Class, Use Case, Component

행동사물

• 시간과 공간에 따른 요소들의 행위
• ex) 상호작용, 상태머신

그룹사물

• 요소들을 그룹으로 묶은 것
• ex) Package

주해사물

• 부가적 설명이나 제약조건
• ex) 주석, 노트

관계 | Relationships

• 사물과 사물 사이 연관성

일반화 관계 | Generalization |      ▷

• 한 클래스가 다른 클래스를 포함하는 상위 개념일 때의 관계
• 객체지향 개념에서는 일반화 관계를 상속관계(Inheritance)라고 함

연관 관계 | Association |      

• 2개 이상 사물이 서로 관련된 관계
• 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 표시
• 다중성 : 관계 사이에 개입하는 클래스의 인스턴스 개수

• Directed Association

  >

의존 관계 | Dependency | —–>

• 연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능(지역변수, 매개변수 등)을 사용(참조)할 때 표시
• 연관 관계와 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같이 매우 짧은 시간(일시적)만 유지
• 한 클래스의 명세가 바뀌면 다른 클래스에 영향을 줌
• 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우

실체화 관계 | Realization | —–▷

• 인터페이스를 구현받아 추상 메서드를 오버라이딩 하는 것을 의미
• 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정

집합 관계-집약 | Aggregation |       ◇

• 한 객체가 다른 객체를 소유하는 관계
• 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적
• 전체 객체가 사라진다 해도 부분 객체는 사라지지 않음

집합 관계-합성(복합) | Composition |       ◆

• 부분 객체가 전체 객체에 속하는 관계로 긴밀한 필수적 관계
• 전체 객체의 라이프타임과 부분 객체의 라이프타임은 의존적
• 전체 객체가 없어지면 부분 객체도 없어짐

다이어그램 | Diagram

• 사물과 관계를 도형으로 표현

구조 다이어그램

종류	설명
클래스 다이어그램Class Diagram	- 클래스의 속성과 클래스 사이의 관계를 표현- 시스템 구조 파악(정적 구조 표현) 및 구조상 문제점을 도출- Class Name, Attribute, Operation 순서로 구성
객체 다이어그램Object Diagram	- 클래스에 속한 객체(Instance)를 특정 시점의 객체와 객체 사이 관계로 표현- 객체의 상태변화를 나타냄
컴포넌트 다이어그램Component Diagram	- 컴포넌트 사이 관계나 인터페이스를 표현- 탭이 달린 직사각형으로 표현
배치 다이어그램Deployment Diagram	- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현- 노드와 통신 경로를 표현
복합체 구조 다이어그램Complex Structure Diagram	클래스나 컴포넌트가 복합구조를 가질 시 그 내부 구조를 표현
패키지 다이어그램Package Diagram	유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

행위 다이어그램

종류	설명
유스 케이스다이어그램Use Case Diagram	- 유저의 요구를 분석하며 기능 모델링 작업에 사용- 시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하는데 사용- 외부에서 보는 시스템의 동작으로 외부 객체들이 어떻게 상호작용하는지 모델링- 구성요소 : Actor, Use Case, System
순차 다이어그램Sequence Diagram	- 특정 행동이 어떠한 순서로 어떤 객체와 상호작용 하는지 표현- 현재 시스템이 어떠한 시나리오로 움직이고 있는지(흐름)를 나타냄- 수직 방향이 시간의 흐름을 나타냄- 구성요소 : 활성객체, 메시지, 생명선, 제어사각형- 메시지 유형 : 동기 메시지, 비동기 메시지, 반환 메시지, 자체 메시지
커뮤니케이션다이어그램CommunicationDiagram	동작에 참여한 객체들이 주고받는 메시지와 객체 간 연관까지 표현
상태 다이어그램State Diagram	객체가 자신이 속한 클래스의 상태 변화 및 다른 객체 간 상호작용에 따라 상태 변화에 의한 동작순서 표현
활동 다이어그램Activity Diagram	- 시스템이 어떤 기능을 수행하는지에 따라 객체 처리 로직이나 조건에 따른 처리 흐름을 순서에 따라 표현- (비즈니스 프로세스)업무의 흐름을 표현하거나 유스케이스의 구체적인 흐름을 나타내기 위해 사용- 객체 연산에 대한 플로우 차트로 활용될 수 있음
상호작용다이어그램Interaction Diagram	상호작용 다이어그램 간 제어흐름 표현
타이밍 다이어그램Timing Diagram	객체 상태 변화와 시간 제약 명시적 표현

확장 모델 스테레오 타입

• UML에서 제공하는 기본 요소 외에 추가적인 확장 요소를 나타내는 것

• Stereotype 유형

  • <<Interface>> : 인터페이스 클래스
  • <<Abstract>> : 추상화 클래스
  • <<Enumeration>> : 열거형 타입 클래스
  • <<Utility>> : 인스턴스가 없는 static 메서드만 모아둔 클래스
  • <<Create>> : 생성자

주요 다이어그램

Class Diagram

표기법	접근 제한자	사용 범위
-	private	해당 클래스 내에서만 접근 가능
#	protected	상속, 동일 패키지 내에서만 접근 가능
+	public	어디서든 접근 가능

Use Case Diagram

구성요소	설명
System	만들고자 하는 프로그램 명칭
Actor	시스템의 외부에 있고 시스템과 상호작용을 하는 사람, 시스템 표현
Use Case	사용자 입장에서 바라본 시스템 기능
Relation	액터와 유스케이스 사이의 의미있는 관계

관계	설명	표기
연관 관계Association	- 유스케이스와 액터 간의 상호작용이 있음을 표현- 유스케이스와 액터를 실선으로 연결
포함 관계Include	유스케이스를 수행할 때 반드시 실행되어야 하는 경우	—–>
확장 관계Extend	유스케이스를 수행할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우	<—–
일반화 관계Generalization	유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스	▷

Sequence Diagram

관계	설명
객체(Object) & 생명선(Lifeline)	- 객체(활동 주체)는 직사각형으로 표현- 라이프라인은 객체에서 이어지는 점선으로 표현- 점선은 위에서 아래로 갈수록 시간의 경과를 의미
활성 박스 (Activation Box)	- 라이프라인상에서 기다란 직사각형으로 표현- 현재 객체가 어떤 활동을 하고 있음을 의미
메시지 (Message)	-인스턴스 간 주고받은 데이터- 동기 메시지, 비동기 메시지, 자체 메시지, 변환 메시지

---

Agile

방법론

• 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과, 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론

• 어느 특정 개발 방법론을 가리키는 말이 아닌 애자일 개발을 가능하게 해주는 다양한 방법론 전체를 일컫는 말

• 경량(Lightweight)프로세스라고도 함

• 프로젝트를 시작한 후 끊임없이 개선 노력

방법론 등장 배경

• 기존 소프트웨어 개발 방법론의 문제점을 개선하기 위함

• 기존 소프트웨어 개발 방법론의 주요 문제점

  • 계약과 계획준수를 중요시하는 갑과 을의 문화가 지배적
  • 문서를 중시
  • 프로세스나 툴 적용을 중시
  • 성과가 나쁠 때 계획 또는 통제의 실패로 인식

선언문

• 공정과 도구보다 개인과 상호작용을

• 포괄적인 문서보다 작동하는 소프트웨어를

• 계약 협상보다 고객과의 협력을

• 계획을 따르기보다 변화에 대응하기를

• 우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다

특징

• 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용

• 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선

• 팀원들과의 주기적인 회의와 제품을 시연함으로써 소프트웨어를 점검

• 작업 계획을 짧게 세우고, 반복적으로 수행함으로 변화에 유연하게 대처

방법론 종류

XP | eXtream Programming

특징

• 문서보다는 코드를 중시하고, 5가지 핵심가치와 12개 실천 항목이 존재
• 개발을 세분화하여 1~3주의 반복적으로 개발을 진행
• 기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것

5가지 핵심가치

용기 : 고객의 요구사항 변화에 능동적인 대처
존중 : 개발자의 역량을 존중하고 충분한 권한과 권리 부여
의사소통 : 개발자, 관리자, 고객 간의 원활한 의사소통
피드백 : 의사소통에 따른 즉각적인 피드백
단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제

12가지 실천사항

짝 프로그래밍 | Pair Programming

하나의 작업을 2명의 프로그래머가 코딩&리뷰 공동 수행
계획 세우기 | Planning Game

게임처럼 선수와 규칙, 목표를 두고 기획 수행
테스트 기반 개발 | Test Driven Development

선 단위 테스트 후 실제 코드 작성
고객 상주 | Whole Team

개발 효율을 위해 고객을 프로젝트 팀원으로 상주
지속적인 통합 | Continuous Integration

상시 빌드 및 배포가 가능한 상태로 유지
코드 개선 | Design Improvement

코드 개선 작업 수행(가시성, 성능 등), 불필요한 기능 제거 및 리팩토링
잦은 릴리즈 | Small Releases

짧고 잦은 릴리즈로 고객이 변경사항을 볼 수 있게 함(잦은 피드백)
코딩 표준 | Coding Standards

표준화된 관례에 따라 코드 작성
공동 코드 소유 | Collective Code Ownership

시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능
간단한 디자인 | Simple Design

가능한 가장 간결한 디자인 상태 유지
시스템 메타포어 | System Metaphor

최종적으로 개발되어야 할 시스템의 구조를 조망
작업시간 준수 | Sustainable Pace

일주일에 40시간 이상 작업 금지, 2주 연속 오버타임 금지

스크럼 | SCRUM

특징

• 소프트웨어에 포함될 기능&개선점에 대한 우선순위를 부여
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 완성
• 항상 팀 단위로 생각하고, 날마다 15분 정도의 회의

주요 개념

제품 백로그 | Product Backlog

개발할 제품에 대한 요구사항 목록(소프트웨어 요구사항, 아키텍처 정의 등)
스프린트 | Sprint

반복적 개발 주기, 1~3주의 짧은 기간을 목표로 설정
스프린트 계획 회의 | Sprint Planning Meeting

스프린트 목표와 스프린트 백로그를 계획하는 회의
스프린트 백로그 | Sprint Backlog

각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
일일 스크럼 회의 | Daily Scrum Meeting

날마다 진행되는 15분 정도의 미팅
실행 가능한 제품 | Shippable Product

스프린트의 결과로써 나오는 실행 가능한 제품
제품 책임자 | Product Owner

제품 백로그를 정의하여 우선순위를 정해줌
스크럼 마스터 | Scrum Master

프로젝트 관리자이며 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡음
속도 | Velocity

한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

ETC

크리스털 | Crystal

프로젝트의 규모와 영향의 크기에 따라서 여러 종류의 방법론을 제공
FDD | Feature-Driven Development

feature마다 2주정도의 반복 개발을 실시

신규 기능 단위로 하는 개발 방법론
ASD | Adaptive Software Development

합동 애플리케이션 개발을 사용하는 방법론

개발을 혼란 자체로 규정하고, 혼란을 전체로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론
린 | Lean

도요타 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론