[정보처리기사 실기] 요구사항 확인

1. 현행 시스템 분석하기

현행 시스템 파악의 정의

   소프트웨어뿐만 아니라 하드웨어, 네트워크 등 관련 인프라를 확인하고 어떤 기술 요소를 적용할 것인지를 판단하기 위한 사전 지식 습득 과정

 

현행 시스템 파악 절차

1.  시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악

2.  아키텍처 구성 파악, 소프트웨어 구성 파악

3.  하드웨어 구성 파악, 네트워크 구성 파악

 

2. 요구사항 확인하기

요구사항의 유형

•  기능 요구사항(Functional requirements) : 시스템 기능 관련 요구사항

•  비기능 요구사항(Non-functional requirements) : 시스템 품질이나 제약사항 관련 요구사항

•  사용자 요구사항(User requirements) : 사용자 관점 요구사항

•  시스템 요구사항(System requirements) : 개발자 관점 요구사항

 

요구사항 개발 프로세스

1. 도출(Elicitation) : 이해관계자가 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정

2. 분석(Analysis) : 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

3. 명세(Specification) : 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 과정

4. 확인(Validation) : 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 과정

 

요구사항 도출 기법

• 워크숍

• 인터뷰

• 집단창의력기법(브레인스토밍, 델파이 등)

• 설문지 및 설문조사

• 프로토타입 등

   *요구사항 도출의 필요성 : 범위 기준선 제공, 일정·원가 영향, 추적성 제공

 

요구사항 분석 기법

• 요구사항 분류(Requirement Classification) : 기능/비기능, 요구사항 범위, SDLC(Software Development Life Cycle) 등 여러 가지 기준을 가지고 분류 

• 개념 모델링(Conceptual Modeling) : 개체(Entity)들과 관계 및 종속성을 반영하여 모델링, 표기는 주로 UML을 사용

• 요구사항 할당(Requirement Allocation) : 요구사항을 만족시키기 위한 아키텍처 구성 요소 식별

• 요구사항 협상(Requirement Negotiation) : 이해관계자가 서로 상충되는 내용을 요구하거나, 기능과 비기능 요구사항들이 서로 상충되는 경우에 진행하게되는 협의

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

 

요구사항 명세

• 소프트웨어 요구 명세서(SRS : Software Requirements Specification) : 요구분석 단계의 요구사항과 스펙을 정리한 산출물로써 소프트웨어 프로젝트의 중심이 되는 요구사항 명세 문서

• 평가 기준 : 정확성, 명확성, 완전성, 일관성, 중요성, 검토 가능, 수정 가능, 추적 가능

• 유의사항 : 이해성, 상호성, 기능 정의, 제약 조건, 테스트 기준, 품질 측정

 

요구사항 확인 기법

• 요구사항 검토(Requirement Reviews) : 시스템 정의서, 시스템 사양서 등을 완성한 시점에서 진행

• 프로토타이핑(Prototyping) : 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 도출되는 요구사항을 반영하여 지속적으로 개선

• 모델 검증(Model Verification) : 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증

• 인수 테스트(Acceptance Tests) : 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인

 

UML(Unified Modeling Language)

   시스템 개발 과정에서 이해관계자 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어

• 구성요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram) 등

• 특징 : 가시화 언어, 구축 언어, 명세화 언어, 문서화 언어

• UML 4+1 View Model : 다양한 이해관계자들의 관점으로 SW Architecture를 구축하는 설계 방법

  1. Use-Case View : 사용자 관점(end-user), 요구사항 분석을 통한 시스템 기능 명세

  2. Logical View :  설계자 관점(Designer), 전체 레이어 구성

  3. Implementation View : 개발자 관점(Programmer), 컴포넌트와 이들 간의 상호 관계 정의

  4. Process View : 시스템 통합 관점(Integrator), 비기능적 요구사항 기술

  5. Deployment View : 시스템 엔지니어 관점(System Engineer), 물리적 노드 프로세스 분산 및 배치

http://www.jidum.com/jidums/view.do?jidumId=967

• 관계의 종류

  1. 연관(Association) 관계 : 2개 이상의 사물이 서로 관련되어 있음을 표현

  2. 상속(Inheritance)/일반화(Generalization) 관계 : 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)로 표현

  3. 실체화(Realization)/구현(Implementation) 관계 : 사물이 할 수 있거나 해야 하는 기능으로 그룹화할 수 있는 관계를 표현

  4. 의존(Dependency) 관계 : 사물의 변화가 다른 사물에도 영향을 미치는 관계를 표현

  5. 집합(Aggregation) 관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현, 서로 독립적

  6. 포함(Composition) 관계 : 집합 관계의 특수한 형태, 서로 독립될 수 없고 생명주기를 함께함

https://en.wikipedia.org/wiki/Class_diagram

• 다이어그램의 종류

  • 구조적(Structural) 다이어그램 : 정적 모델링에서 사용

    1. 클래스 다이어그램(Class Diagram) : 클래스와 클래스 간의 관계를 기술

    2. 컴포넌트 다이어그램(Component Diagram) : 컴포넌트의 구조와 연관 관계를 기술

    3. 객체 다이어그램(Object Diagram) : 특정 시점의 객체와 객체 사이의 관계를 기술

    4. 복합체 구조 다이어그램(Composite Structure Diagram) : 하나의 클래스의 실행 시의 내부 구조를 기술

    5. 배치 다이어그램(Deployment Diagram) : 시스템의 물리적인 배치를 기술

    6. 패키지 다이어그램(Package Diagram) : 시스템의 컴파일 시의 계층적인 구조를 기술

  • 행위(Behavioral) 다이어그램 : 동적 모델링에서 사용

    1. 활동 다이어그램(Activity Diagram) : 절차적이고 병렬적인 행위를 기술

    2. 유스케이스 다이어그램(Use Case Diagram) : 사용자가 상호작용하는 시스템의 모습을 기술

    3. 상태 다이어그램(State Diagram) : 객체의 상태에 따른 작업과 이벤트에 따른 상태의 변화 기술

    4. 시퀀스 다이어그램(Sequence Diagram) : 객체들간의 상호작용을 순서에 초점을 맞춰 기술

    5. 상호작용 개요 다이어그램(Interaction Overview Diagram) : 시퀀스와 활동 다이어그램의 결합

    6. 커뮤니케이션 다이어그램(Communication Diagram) : 객체들 간의 상호작용을 연결에 초점을 맞춰 기술

    7. 타이밍 다이어그램(Timing Diagram) : 객체들 간의 상호작용을 시간 제약에 초점을 맞춰 기술

 

3. 분석모델 확인하기

분석모델 검증 과정

1. 유스케이스 모델 검증 : 액터, 유스케이스, 유스케이스 명세서

2. 개념 수준 분석 클래스 검증 : 클래스 도출, 클래스명과 속성, 클래스들 간 관계

3. 분석 클래스 검증 : 스테레오 타입, 경계 및 제어 클래스 도출, 관계 및 상세화 정도