정보처리기사 - 요구사항 분석 단계

2-2. 요구사항 분석 단계

(기존 시스템의 문제점을 파악하고 사용자 인터뷰를 통해 새로운 요구사항을 도출하여 수집하며, 이 요구사항을 최적화된 상태로 정리한 후 특정 표현 도구를 사용하여 다이어그램 등으로 나타냄)

소프트웨어 개발 생명주기에서 요구사항 분석 단계에 대해 설명하세요.

소프트웨어 개발의 궁극적인 목적은 개발된 소프트웨어를 사용하는 고객이 만족하도록 하는 것이기 때문에, 고객이 원하는 품의 제품을 정해진 개발 기간과 주어진 예산 범위 안에서 개발해야 합니다.

그러려면 먼저 사용자의 요구사항을 정확히 파악하고 분석하는 작업이 필요합니다.

요구사항이란 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과, 서비스가 정상적으로 운영되는데 필요한 제약조건을 의미합니다.

요구사항

기능 요구사항(Functional requirements)이란?

시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항입니다.

비기능 요구사항(Non-Functional requirements)이란?

품질이나 제약사항과 관련된 요구사항입니다.

사용자 요구사항(User requirements)이란?

사용자 관점에서 본 시스템이 제공해야 할 요구사항입니다.

시스템 요구사항(System requirements)이란?

개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에게 제공해야 할 요구사항으로,

소프트웨어 요구사항이라고도 합니다.

---

요구사항 개발 프로세스

요구사항 개발 프로세스에 대해 설명하세요.

개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음, 확인 및 검증하는 일련의 구조화된 활동입니다.

도출(Elicitation), 분석(Analysis), 명세(Specification), 확인(Validation) 순서로 진행됩니다.

요구사항 도출

요구사항 도출/수집(Requirement Elicitation)이란?

시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정입니다.

대표적으로 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있습니다.

---

요구사항 분석

요구사항 분석(Requirement Analysis)이란?

요구사항이 정리되면 정리된 내용을 한눈에 파악할 수 있도록 문서로 기록하거나 그래프로 표현하여,

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

소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동입니다.

대표적으로 자료 흐름도(DFD), 자료 사전(DD)이 있습니다.

구조적 분석 기법

자료 흐름도(DFD, Data Flow Diagram)에 대해 설명하세요.

자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법입니다.

자료 흐름 그래프 또는 버블 차트라고도 합니다.

• 프로세스(Process): 자료를 변환시키는 시스템의 한 부분을 나타내며 처리, 기능, 변환, 버블이라고도 합니다. 원형으로 표기합니다.
• 자료 흐름도(Data Flow): 자료의 이동이나 연관 관계를 나타냅니다. 화살표로 표기합니다.
• 자료 저장소(Data Store): 시스템에서의 파일, 데이터베이스 등의 자료 저장소를 나타냅니다. 평행한 두 직선으로 표기합니다.
• 단말(Terminator): 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받습니다. 사각형으로 표기합니다.

자료 사전(DD, Data Dictionary)에 대해 설명하세요.

자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것입니다.

데이터를 설명하는데이터로, 데이터의 데이터 또는 메타 데이터라고도 합니다.

• =: 자료의 정의, ~로 구성되어 있다(is composed of)
• +: 자료의 연결, 그리고(And)
• ( ): 자료의 생략, 생략 가능한 자료(Optional)
• [ ]: 자료의 선택, 또는(Or)
• { }: 자료의 반복, Iteration of
• * *: 자료의 설명, 주석(Comment)

---

요구사항 분석용 CASE(자동화 도구)란?

요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구입니다.

• SADT: 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구로, SoftTech사에서 개발했습니다. 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구입니다.
• SREM=RSL/REVS: TRW사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구입니다.
• PSL/PSA: PSL과 PSA를 사용하는 자동화 도구입니다.
• TAGS: 시스템 공학 방법 응용에 대한 자동 접근 방법입니다.

HIPO(Hierarchy Input Process Output)란?

시스템 분석 및 설계, 또는 문서화에 사용되는 기법으로 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것입니다.

하향식 소프트웨어 개발을 위한 문서화 도구로, 기능과 자료의 의존 관계를 동시에 표현할 수 있습니다.

기호, 도표 등을 사용하므로 보기 쉽고 이해하기 쉽다는 장점이 있습니다.

모델과 모델링의 차이에 대해 설명하세요.

모델은 어떤 복잡한 대상의 핵심 특징만 선별하여 일정한 관점으로 단순화시켜 기호나 그림 등을 사용해 체계적으로 표현한 것입니다.

하나의 사물을 여러 관점에서 바라볼 수 있게 해줍니다. (ex) 원통의 보는 각도에 따라 다른 도형으로 보임

소프트웨어를 개발할 때도 여러 관점의 모델에서 필요한 정보를 얻어 개발하게 됩니다.

모델링은 모델을 제작하는 작업으로, 객체지향 개발에서는 UML의 다양한 다이어그램을 통해 개발하려는 소프트웨어의 범위나 개략적인 구조와 기능을 이해할 수 있습니다.

UML의 수많은 다이어그램들이 소프트웨어 개발 과정에서 하나의 모델로 사용됩니다.

모델링 언어란?

소프트웨어 개발에서 모델링 언어는 요구사항 정의 및 분석, 설계의 결과물을 다양한 다이어그램으로 표현하는 표기법입니다.

애매모호한 표현이 없고 일관되어 모델링하는 데 매우 유용하며 개발자 간에 원활한 의사소통이 가능해집니다.

모델링 개발 방법론에 따라 사용하는 도구가 다릅니다.

구조적 방법론이란?

정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론으로,

1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론입니다.

대표적으로 자료 흐름도(DFD), 자료 사전(DD), 처리명세서 등으로 표현합니다.

정보공학 방법론

기업 전체 또는 기업의 주요부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을 상호 연관성 있게 통합, 적용하는 데이터 중심 방법론입니다.

대표적으로 개체-관계 다이어그램(ERD: Entity-Relationship Diagram)으로 표현합니다.

객체지향 방법론이란?

현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 개체들을 조립해서 필요한 소프트웨어를 구현하는 방법론입니다.

대표적으로 UML, 유스케이스 다이어그램(요구사항)으로 표현합니다.

컴포넌트 기반(CBD: Component Based Design) 방법론이란?

기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론입니다.

UML

UML(Unified Modeling Language)이란?

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어입니다.

Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였으며, OMG(Ojbect Management Group)에서 표준으로 지정하였습니다.

UML 구성 요소로는 사물(Things), 관계(Relationships), 다이어그램(Diagram)이 있습니다.

UML의 구성 요소 중 사물(Things)이란?

다이어그램 안에서 관계가 형성될 수 있는 대상들로 구조, 행동, 그룹, 주해 사물로 구분됩니다.

• 구조 사물(Structural Things): 시스템의 개념적, 물리적 요소를 표현하는 것으로, 클래스, 유스케이스, 컴포넌트, 노드 등이 있습니다.
• 행동 사물(Behavioral Things): 시간과 공간에 따른 요소들의 행위를 표현하는 것으로, 상호작용, 상태 머신 등이 있습니다.
• 그룹 사물(Grouping Things): 요소들을 그룹으로 묶어서 표현하는 것으로, 패키지 등이 있습니다.
• 주해 사물(Annotation Things): 부가적인 설명이나 제약조건 등을 표현하는 것으로, 노트 등이 있습니다.

UML의 구성 요소 중 관계(Relationship)이란?

사물과 사물 사이의 연관성을 표현하는 것으로, 연관, 집합, 포함, 일반화, 의존, 실체화 관계로 구분됩니다.

• 연관(Association) 관계: 2개 이상의 사물이 서로 관련되어 있는 관계로, 사람과 집, 선생님과 학생과 같은 관계를 의미합니다.
• 집합(Aggregation) 관계: 하나의 사물이 다른 사물에 포함되어 있는 관계로, 컴퓨터와 프린터와 같은 관계를 의미합니다.
• 포함(Composition) 관계: 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계로, 문과 열쇠와 같은 관계를 의미합니다.
• 일반화(Generalization) 관계: 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계로, 동물과 코끼리, 치타와 같은 관계를 의미합니다.
• 의존(Dependency) 관계: 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게영향을 주는 짧은 시간 동안만 연관을 유지하는 관계로, 등급과 할인율과 같은 관계를 의미합니다.
• 실체화(Realization) 관계: 사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화할 수 있는 관계입니다. 헤엄칠 수 있다와 수영선수, 물고기와 같은 관계를 의미합니다.

UML의 구성 요소 중 다이어그램(Diagram)이란?

사물과 관계를 도형으로 표현한 것으로,

정적 모델링에서는 주로 구조적 다이어그램을, 동적 모델링에서는 주로 행위 다이어그램을 사용합니다.

구조적(Structural) 다이어그램 종류에 대해 설명하세요.

• 클래스 다이어그램(Class Diagram): 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현합니다.
• 객체 다이어그램(Object Diagram): 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현합니다. 럼바우 객체지향 분석 기법에서 객체 모델링에 활용됩니다.
• 컴포넌트 다이어그램(Component Diagram): 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현합니다. 구현 단계에서 사용합니다.
• 배치 다이어그램(Deplyment Diagram): 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현합니다. 구현 단계에서 사용합니다.
• 복합체 구조 다이어그램(Composite Structure Diagram): 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현합니다.
• 패키지 다이어그램(Package Diagram): 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현합니다.

행위(Behavioral) 다이어그램 종류에 대해 설명하세요.

• 유스케이스 다이어그램(Use Case Diagram): 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용합니다.
• 시퀀스 다이어그램(Sequence 다이어그램): 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현합니다.
• 커뮤니케이션 다이어그램(Communication Diagram): 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현합니다.
• 상태 다이어그램(State Diagram): 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현합니다. 럼바우 객체지향 분석 기법에서 동적 모델링에 활용됩니다.
• 활동 다이어그램(Activity Diagram): 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현합니다.
• 상호작용 개요 다이어그램(Interaction Overview Diagram): 상호작용 다어어그램 간의 제어 흐름을 표현합니다.
• 타이밍 다이어그램(Timing Diagram): 객체 상태 변화와 시간 제약을 명시적으로 표현합니다.

UML에서 스테레오 타입(Stereotype)이란?

UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것으로,

길러멧(Guilemet)이라고 부르는 겹화살괄호(« ») 사이에 표현할 형태를 기술합니다.

---

요구사항 명세

요구사항 명세(Requirement Specificaiton)이란?

분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것입니다.

• 정형 명세 기법: 수학적 원리, 모델 기반으로 수학적 기호나 정형화된 표기법으로 작성합니다. 요구사항을 정확하고 간결하게 표현할 수 있지만, 표기법이 어려워 사용자가 이해하기 어렵습니다. VDM, Z, Petri-net, CSP 등이 있습니다.
• 비정형 명세 기법: 상태, 기능, 객체 중심으로 일반 명사, 동사 등의 자연어를 기반으로 서술하거나 다이어그램으로 작성합니다. 자연어의 사용으로 인해 요구사항 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지지만, 내용의 이해가 쉬워 의사소통이 용이합니다. FSM, Decisioin Table, ER모델링, State Chart(SADT) 등이 있습니다.

요구사항 확인

요구사항 확인/검증(Requirement Validation)이란?

개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동으로,

요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상관리(SCM)을 수행합니다.

• SCM: 소프트웨어 개발 단계 각 과정에서 만들어지는 프로그램으로, 프로그램을 설명하는 문서, 데이터 등을 통칭하여 형상이라고 하는데 이 형상을 관리하는 일련의 활동입니다.