[정처기 필기] 「1」 | 요구사항 확인 - (1.4) 요구사항 정의, 분석, CASE와 HIPO

[정처기 필기] 「1」 | 요구사항 확인 - (1.4) 요구사항 정의, 분석, CASE와 HIPO

「1」 소프트웨어 설계

- > 요구사항 확인, 화면 설계, 애플리케이션 설계, 인터페이스 설계

「2」 소프트웨어 개발

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

1 소프트웨어 생명 주기

2 스크럼(Scrum) 기법

3 XP(eXtreme Programming) 기법

4 현행 시스템 파악

5 개발 기술 환경 파악

> 6 요구사항 정의

> 7 요구사항 분석

> 8 요구사항 분석 CASE와 HIPO

9 UML(Unified Modeling Language)

10 주요 UML 다이어그램

6. 요구사항 정의

요구사항의 개념 및 특징

 

소프트웨어가 문제를 해결하기 위해 제공하는 서비스에 대한 설명, 운영되는데 필요한 제약조건 등

 

- 소프트웨어 개발이나 유지보수 과정에서 필요한 기준, 근거를 제공

- 이해관계자들 간의 의사소통을 원활하게 하는데 도움

- 제대로 정의되어야 이후 과정의 목표와 계획을 수립할 수 있음

 

요구사항의 유형

 

기술하는 내용에 따라 기능 요구사항(Functional requirements), 비기능 요구사항(Non-functional requirements)으로 구분, 기술 관점과 대상의 범위에 따라 시스템 요구사항(System requirements), 사용자 요구사항(User requirements)으로 구분

 

유형	내용
기능 요구사항 (Functional requirements)	- 무엇을 하는지, 어떤 기능을 하는지 - 입력이나 출력으로 무엇이 포함되는지, 어떤 데이터를 저장하거나 연산을 수행하는지 - 반드시 수행해야 하는 기능 - 제공받기 원하는 기능
비기능 요구사항 (Non-functional requirements)	- 시스템 장비 구성 (하드웨어, 소프트웨어, 네트워크 등) - 성능 (처리속도 및 시간, 처리량, 가용성 등) - 인터페이스 (다른 소프트웨어, 하드웨어 및 통신 인터페이스, 다른 시스템과 정보교환에 사용되는 프로토콜과의 연계 등) - 데이터 (초기 자료구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축) - 테스트 (도입되는 장비 성능테스트, 시스템이 제대로 운영되는지 테스트, 점검 등) - 보안 (시스템의 데이터 및 기능, 운영 접근을 통제) - 품질 (관리가 필요한 품질 항목, 품질 평가 대상 - 가용성, 정합성, 상호 호환성, 대응성, 신뢰성, 사용성, 유지/관리성, 이식성, 확장성, 보안성 등 구분) - 제약사항 (시스템 설계, 구축, 운영에 관련하여 파악된 기술, 표준, 업무, 법/제도 등) - 프로젝트 관리 요구사항 (프로젝트의 원활한 수행을 위한 관리 방법) - 프로젝트 지원 요구사항 (프로젝트의 원활한 수행을 위한 지원 사항이나 방안)
사용자 요구사항 (User requirements)	- 사용자 관점에서 본 시스템이 제공해야 할 요구사항 - 친숙한 표현으로 이해하기 쉽게 작성
시스템 요구사항 (System requirements)	- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항 - 전문적이고 기술적인 용어로 작성 - == 소프트웨어 요구사항

 

요구사항 개발 프로세스

 

개발 대상에 대한 요구사항을 도출, 분석한 후 명세서(Specification Document)에 정리한 다음 확인 및 검증하는 구조화된 활동

 

- 요구사항 개발 프로세스가 진행되기 전 정보를 수집, 평가한 보고서를 토대로 타당성 조사(Fesasibility Study)가 선행되어야 함

- 요구공학(Requirement Engineering)의 한 요소

 

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

 

>요구공학(Requirements Engineering)<

 

무엇을 개발해야 하는지 요구사항을 정의, 분석 및 관리하는 프로세스를 연구하는 학문

 

- 복잡하고 대형화 되어가는 소프트웨어 개발 환경에 따라 요구사항도 더 복잡해지고, 잦은 변경 발생 

- 요구사항 변경의 원인과 처리 방법 이해, 품질을 개선하여 소프트웨어 프로젝트 실패 최소화가 목적

 

요구사항 도출(Requirement Elicitation, 요구사항 수집)

 

시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견 교환하여 식별하고 이해하는 과정 => 질문 기술

 

- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계

- 도출 단계에서 개발자와 고객 사이의 관계가 만들어지고, 이해관계자(Stakeholder) 식별

- 효율적인 의사소통이 중요

- 소프트웨어 개발 생명 주기동안 지속적으로 반복

- 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, (라피도) 프로토타이핑, 유스케이스 등

 

요구사항 분석(Requirement Analysis)

 

요구사항 중 모호한 것을 발견하고 걸러내기 위한 과정 => 분석, 중재 기술

 

- 타당성을 조사하고, 비용과 일정에 제약을 설정

- 상충되는 요구사항을 중재하는 과정

- 도출된 요구사항을 토대로 소프트웨어의 범위를 파악

- 소프트웨어와 주변 환경이 상호작용하는 방법을 이해

- 자료 흐름도(DFD), 자료 사전(DD) 등

 

요구사항 명세(Requirement Specification)

 

분석된 요구사항을 바탕으로 모델을 작성, 문서화 => 관찰, 모델 작성 기술

 

- 기능 요구사항은 완전하고 명확하게 기술, 비기능 요구사항은 필요한 것만 명확하게 기술

- 사용자가 이해하기 쉽고, 개발자가 설계하기 쉽도록 작성

- 설계 과정에서 잘못된 부분이 확인이 될 경우, 요구사항 정의서에서 추적할 수 있어야 함

- 구체적인 명세는 소단위 명세서(Mini-Spec) 사용

 

>소프트웨어 요구사항 명세서 / 요구사항 명세 기법<

 

- 소프트웨어 요구사항 명세서(SRS; Software Requirement Specification)

소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건 등 명시

  : 시스템의 모든 동작과 품질도 기술되어야 함

  : 프로젝트 유형에 맞게 양식을 만들어 사용

  : 시스템 기능, 데이터, 외부 인터페이스, 품질 요구사항은 요구사항 단위 별로 개별 요구사항 명세서를 작성

 

- 요구사항 명세 기법

 

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	자연어를 기반으로 서술, 다이어그램
특징	- 정확, 간결하게 표현 - 일관성이 있으므로 완전성 검증 가능 - 표기법이 어려워 사용자가 이해하기 어려움	- 일관성이 떨어지고, 해석이 다를 수 있음 - 내용이 쉬워, 의사소통이 용이
종류	VDM, Z, Petri-net CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등

 

요구사항 확인(Requirement Validation, 요구사항 검증)

 

개발 자원을 요구사항에 할당하기 전 요구사항 명세서가 정확하고 안전한지 검토하는 활동

 

- 분석가가 정확히 이해 후 명세서를 작성했는지 확인이 필요

- 실제 요구를 반영하는지, 상충되는 요구사항은 없는지 점검

- 개발 완료 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 중요

- 내용이 이해하기 쉬운지, 일관성 있는지, 회사의 기준에 맞는지 등 검증

- 이해관계자들이 검토해야 함

- 검증 과정을 통해 모든 문제를 확인할 수 있는 것은 아님

- 요구사항 관리 도구를 이용하여 수행

7. 요구사항 분석

요구사항 분석의 개요

 

개발 대상에 대한 사용자의 요구사항의 이해하고 문서화하는 활동

 

- 분석가에 의해 분석이 수행되며, 요구사항 분석 단계라 함

- UML(Unified Modeling Language), 자료 흐름도(DFD; Data Flow Diagram), 자료 사전(DD; Data Dictionary), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등 도구 이용

 

구조적 분석 기법

 

자료의 흐름과 처리를 중심으로 하는 분석 방법

 

- 도형 중심의 분석용 도구, 분석 절차 이용

- 하향식 방법을 사용하여 시스템 세분화, 분석의 중복을 배제

- 분석의 질이 향상, 모든 단계에서 필요한 명세서 작성이 가능

 

자료 흐름도(DFD)

 

자료의 흐름, 변환과정과 기능을 도형 중심으로 기술하는 방법 == 자료 흐름 그래프, 버블 차트

 

- 프로세스와 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용

- 프로세스(Process), 자료 흐름(Flow), 자료 저장소(Data Store), 단말(Terminator)의 네 가지 기호로 표시

 

기호	표기법
프로세스(Process)	○
자료 흐름(Data Flow)	→
자료 저장소(Data Store)	=
단말(Terminator)	□

 

작성 지침

- 처리(Process)를 거쳐 변환될 때마다 새로운 이름 부여

- 어떤 처리(Process)가 출력 자료를 산출하기 위해선 반드시 입력 자료가 발생해야 함

- 상위 단계의 처리(Process)와 하위 자료 흐름도의 자료 흐름은 일치되어야 함

- 입력 화살표(데이터의 입력 및 수정)가 있다고 해서 반드시 출력 화살표가 있어야 하는 것은 아님

 

자료 사전

 

자료 흐름도의 자료를 더 자세히 정의하고 기록, 데이터를 설명하는 데이터 == 데이터의 데이터, 메타 데이터

 

- 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 편리하게 사용

 

기호	의미
=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
(  )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{  }	자료의 반복 : Iteration of { }n  { }m  => m번 이상 n번 이하로 반복
*  *	자료의 설명 : 주석(Comment)

8. 요구사항 분석 CASE와 HIPO

요구사항 분석을 위한 CASE(자동화 도구)

 

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

 

자동화 도구 사용 이점

- 표준화와 보고를 통한 문서화 품질 개선

- 데이터베이스 모두가 이용 가능, 분석자들 간의 적절한 조정

- 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등 발견 용이성

- 변경이 주는 영향 추적의 용이성

- 명세에 대한 유지비용의 축소

 

종류

SADT, SREM, PSL/PSA, TAGS, EPOS 등

 

- SADT(Structured Analysis and Design Technique)

  : SoftTech 사에서 개발, 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 이용된 구조적 분석 및 설계 도구

  : 블록 다이어그램 채택

 

- SREM(SoftwareRequirements Engineering Methodology) = PSL/REVS

  : TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 개발, RSL/REVS 사용

  : RSL(Requirement Statement Language) > 요소, 속성, 관계, 구조를 기술하는 요구사항 기술 언어

 

요소	요구사항 명세를 개발하기 위한 개체와 개념
속성	요소를 수정하거나 수식
관계	개체들 간의 관계
구조	정보 흐름을 묘사

 

  : REVS(Requirement Engineering and Validation System) : RSL로 기술된 요구사항을 분석, 명세서를 출력하는 요구사항 분석기

 

- PSL/PSA

  : 미시간 대학에서 개발, PSL, PSA 사용

  : PSL(Problem Statement Language) > 문제(요구사항) 기술 언어

  : PSA(Problem Statement Analyzer) > PSL로 기술한 요구사항 분석 후 다양한 보고서 출력하는 문제 분석기

 

- TAGS(Technology for Automated Generation of Systems)

  : 시스템 공학 방법 응용에 대한 자동 접근 방법, 개발 전 과정에 이용 가능

  : 구성 > IORL, 요구사항 분석, IORL 처리를 위한 도구, 기초적인 TAGS 방법론

  : IORL > 요구사항 명세 언어

 

HIPO(Hierarchy Input Process Output)

 

시스템의 분석 및 설계, 문서화할 때 사용되는 기법이며, 입력, 처리, 출력의 기능을 나타내는 문서화 도구

 

- 하향식 소프트웨어 개발을 위한 문서화 도구

- 체계적인 문서 관리 가능

- 기호, 도표 사용하여 보기 쉽고, 이해 쉬움

- 기능과 자료의 의존 관계를 동시에 표현

- 변경, 유지보수 용이

- 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함

 

HIPO Chart의 종류

 

가시적 도표(Visual Table of Contents), 총체적 도표(Overview Diagram), 세부적 도표(Detail Diagram)

 

- 가시적 도표(도식 목차) : 시스템의 전체적인 기능과 흐름을 계층(Tree) 구조도로 보여줌

- 총체적 도표(총괄도표, 개요 도표) : 프로그램을 구성하는 기능을 기술, 입력, 처리, 출력에 대한 전반적인 정보 제공하는 도표

- 세부적 도표(상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

 

 

 

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)