[ Chapter 2 ] 요구사항 확인

현행 시스템 파악절차 3단계

• 1단계
  • 시스템 구성 파악
  • 시스템 기능 파악
  • 시스템 인터페이스 파악
• 2단계
  • 아키텍쳐 구성 파악
  • 소프트웨어 구성 파악
• 3단계
  • 하드웨어 구성 파악
  • 네트워크 구성 파악

개발 기술 환경 파악

• 운영체제(OS, Operating System)
  • 컴퓨터 시스템의 자원들을 효율적으로 관리하여, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
• 데이터베이스 관리 시스템(DBMS)
  • 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어
• 웹 애플리케이션 서버(WAS , Web Application Server)
  • 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다.
  • 미들웨어(Middle Ware)
    : 운영체제와 해당 운영체제에 의해 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
• 오픈소스(Open Source)
  • 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로 오픈 소스 라이선스를 만족하는 소프트웨어
• 가비지 컬렉션(Garbage Collection)
  • 실제로는 사용되지 않으면서 가용 공간 리스트에 반환되지 않는 메모리 공간인 가비지(Garbage)를 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

요구사항 정의

• 요구사항 개념
  • 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등
• 요구사항 유형
  • 기능 요구사항
  • 비기능 요구사항
  • 사용자 요구사항
  • 시스템 요구사항

요구사항 개발 프로세스

 도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

• 요구사항 도출(Elicitation)
• 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
  
• [ 주요 기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등 ]
• 브레인스토밍(Brain Storming) : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 산출해내는 방법
• 프로토타이핑(Prototyping) : 프로토타입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출해내는 방법
• 유스케이스(Use Case) : 사용자의 요구사항을 기능 단위로 표현하는 것
• 요구사항 분석(Analysis)
• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 요구사항 명세(Specification)
• 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미
• 요구사항 확인(Validation)
• 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

요구사항 분석 기법

• 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다.
• 요구사항 분류(Classification)
• 기능 요구사항과 비기능 요구사항으로 분류한다.
• 우선순위에 따라 분류한다.
• 소프트웨어에 미치는 영향의 범위에 따라 분류한다.
• 등등
• 개념 모델링(Conceptual Modeling)
• 현실 세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라하고, 모델을 만드는 과정이 모델링
• [ 종류 : 유스케이스 다이어그램, 데이터 흐름모델, 상태모델, 데이터모델 등등 ]
• 모델리 표기는 "UML(Unified Modeling Language)를 사용한다.
• 요구사항 할당(Allocation)
• 요구사항을 만족시키기 위한 구성 요소를 식벼하는 것이다.
• 요구사항 협상(Negotiation)
• 요구사항이 서로 충돌 될 경우 이를 적절히 해결하는 과정
• 정형 분석(Formal Analysis)
• 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정

요구사항 확인 기법

• 요구사항 검토(Review), 프로토타이핑(Prototyping), 모델 검증(Model Verification), 인수 테스트(Acceptance Tests) 등이 있다.
• 요구사항 검토(Review)
• 문서화된 요구사항을 훑어보면서 확인하는 것
  
• 프로토타이핑(Prototyping)
• 초기 도출된 요구사항을 토대로 프로토타입(prototype)을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정
• 장점 : 빠르게 제작, 반복된 과정으로 발전된 결과물 얻음, 이해하기 쉬어 의사소통 원활 등
  단점 : 사용자 관심이 핵심에서 벗어나 프로토타입에 집중될 수 있다. 과대평가 될 수 있다. 비용이 부담 될 수 있다.
• 모델 검증(Verification)
• 개발된 모델이 요구사항을 충적시키는지 검증하는 것이다.
• 인수 테스트(Acceptance Tests)
• 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

UML ( Unified Modeling Language )

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• UML은 객체지향 방법론의 장점을 통합했으며, 객제 기술에 관한 국제표준화기구에서 표준으로 지정함
• UML을 이용해서 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다.
• 각각의 다이어그램을 사물과 사물 간의 관계를 용도에 맞게 표현
• 구성요소에는 사물, 관계, 다이어그램 등이 있다.
  
• 사물(Thing)
• 구조사물, 행동사물, 그룹사물, 주해사물이 있다.
• 관계 (Relationships)
• 사물과 사물사이의 연관성을 표현한 것. 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있다.
• 연관관계(Association) : 2개 이상의 사물이 서로 관련되어 있음을 표현한다.
• 집합관계(Aggregation) : 하나의 사물이 다른 사무에 포함되어 있는 관계
• 포함되는 쪽과 포함되는 쪽은 서로 독립적
• 포함되는 족에서 포함하느 쪽으로 속이 빈 마름포를 연결하여 표현
• 포함관계(Comosition) ; 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
• 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기르 함께한다.
• 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
• 일반화(generalization)관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.
• 예를 들어 사람은 여자와 남자보다 일반적인 개념이고 반대로 여자와 남자는 사람보다 구체적인 개념이다.
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
• 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다.
• 의존관계(Dependency) : 연관관계와 같이 사물 사이에 서로 연관은 있으나, 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 영행을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표를 연결하여 표현
• 실체화관계(Realization) : 사물이 할 수 있거나 해야하는 기능(행위,인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현한다.
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
• 다이어그램(Diagram)
• 사물과 관계를 도형으로 표현한 것
• 정적모델링 : 구조적 다이어그램
  동적모델링 : 행위 다이어그램
• 구조적 다이어그램 종류
• 클래스 다이어그램(Class Diagram) : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
• 객체 다이어그램(Object Diagram) : 클래스에 속한 사물들 , 즉 인스턴스를 특정 시점의 객체와 객체사이의 관계로 표현
• 컴포넌트 다이어그램(Component Diagram) : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
  
• 구현단계에서 사용되는 다이어그램
• 배치 다이어그램(Deployment Diagram) : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
• 구현단계에서 사용되는 다이어그램
• 복합체 구조 다이어그램(Composite Structure Diagram) : 클래스나 컴포너트가 복합 구조를 갖는 경우 그 내부 구조를 표현
• 패키지 다이어그램(Package Diagram) : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계
• 행위 다이어그램의 종류
• 유스케이스 다이어그램(Use Case Diagram) : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용한다.
• 시퀀스 다이어그램(Squence Diagram) : 상호 작용하는 시스템들이나 객체들이 주고받는 메시지를 표현
• 커뮤니케이션 다이어그램(Communication Diagram): 메시지 뿐만 아니라 객체들 간의 연관까지 표현한다.
• 등등

기능 모델링 & 유스케이스 다이어그램

• 기능모델링 : 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능들을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 표현하는 것
• UML의 기능 모델링에는 1. 유스케이스 다이어그램, 2. 액티비티 다이어그램
• 유스케이스 다이어그램(Use Case Diagram)
• 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
• [ 구성요소 : 시스템 범위, 액터, 유스케이스, 관계 ]
• 시스템범위(System Scope) : 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
• 사각형 안쪽 상단에 시스템 명칭을 기술한다.
• 액터(Actor) : 시스템과 상호작용을 하는 모든 외부 요소로, 사람이나 외부 시스템을 의미
• 주액터 : 주로 사람이 해당
• 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템
• 유스케이스(Use Case) : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표기, 타원으로 표기
• 관계(Relation)
• 액터와 유스케이스, 유스케이스와 유스케이스 사이에 나타날 수 있다.
• 포함관계, 확장 관계, 일반화 관계의 3종류가 있다.
• 포함관계(Include) : 원래의 유스케이스에서 새롭게 만든 포함되는 유스케이스 쪽으로 점선 화살표를 연결한 후 화살표 위에 <<include>>라고 표기
• 확장관계(extend) : 확장될 유스케이스에서 원래의 유스케이스 쪽으로 점선 화살표를 연결한 후 화살표 위에 <<extends>>라고 표기
• 일반화(generalization) : 유사한 액터나 유스케이스를 하나의 그룹으로 묶고 싶을 때 그보다 일반적인 액터나 유스케이스를 만들어 이들을 연결하여 표현하는 관계

활동 다이어그램(Activity)

• 자료 흐름도와 유사한 것으로 사용자의 관점(view)에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
  
• 구성요소 : 액션, 액티비터, 노드, 스윔레인 등
• 액션(Action) : 더 이상 분해할 수 없는 단일 작업
• 노드(node)
• 스윔레인(swim Lane) : 액티비티 수행을 담당하는 주체를 구분

클래스 다이어그램(Class Diagram)

• 정적 모델링이란 : 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현
• 정적 모델링은 객체들을 클래스로 추상화하여 표현한다.
• UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다.
• 클래스 다이어그램
• 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 속성과 오퍼레이션에 대한 제약조건, 클래스 사이의 관계를 표현
• 구조적 다이어그램이다. 시스템 구성요소를 문서화하는 데 사용된다. 시스템모델링에 자주 사용된다.
• 클래스, 제약조건 ,관계 등으로 구성된다.
• 접근제어자
• public ( + ) : 어떤 클래스에서라도 접근 가능
• private ( - ) : 해당 클래스 내부에서만 접근 가능
• protected ( # ) : 동일 패키지 내의 클래스 도는 해당 클래스를 상속 받은 외부 패키지의 클래스에서 접근이 가능
• package( ~ ) : 동일 패키지 내부에 있는 클래스에서만 접근이 가능

커뮤니케이션 다이어그램 / 상태 다이어그램

• 커뮤니케이션(communication) 다이어그램
  : 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현
• 커뮤니케이션 다이어그램 구성요소
  : 액터 , 객체, 링크, 메시지 등
   링크(Link) : 객체들 간의 관계를 표현하는데 사용, 액터와 객체, 객체와 객체 간에 실선을 그어 표현
• 상태(State) 다이어그램
  : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
• 상태 다이어그램 구성요소
  : 상태, 이벤트, 상태 전환 등
• 상태(State) : 객체의 상태를 둥근 사간형 안에 기술, 시작상태(채워진 원), 종료상태(속이 채워진 원을 둘러싼 원) 으로 표현
• 이벤트(event) : 조건 외부 신호, 시간의 흐름 등 상태에 변화를 주는 현상
• 상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현
• 프레임(frame) : 상태 다이어그램의 범위를 표현