[정보처리기사 필기] 요구사항 정의, 분석, CASE와 HIPO

요구사항 정의

---

1. 요구사항의 개념 및 특징

요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건등을 나타낸다.

• 요구사항은 소프트웨어 개발이나 유지보수에 필요한 기준가 근거를 제공
• 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들간 의사소통을 원활하게 해줌
• 요구사항은 '도출 -> 분석 -> 명세 -> 확인' 의 과정을 거친다

2. 요구사항의 유형

요구사항은 일반적으로 기술하는 내용에따라 기능, 비기능 으로 나눌수 있다. 기술 관점과 대상의 범위에 따라서는 시스템 요구사항, 사용자 요구사항으로 나눈다.

 

• 기능 요구사항: 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
• 비기능 요구사항: 기능 요구사항이 아닌것. 시스템의 장비 구성, 성능, 인터페이스, 데이터, 테스트, 보안, 품질 등
• 사용자 요구사항: 사용자 관점에서 시스템이 제공해야할 사항
• 시스템 요구사항: 개발자 관점에서 시스템 전체가 제공해야 할 사항

3. 요구사항 개발 프로세스

요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 결과를 명세서에 정리. 또 확인 후 검증 하는 일련의 구조화된 활동.

• 요구사항 개발 프로세스가 진행되기 전에 개발 프로세스가 비즈니스 목적에 부합되는지, 예산은 적정한지 등에 대한 정보를 수집, 평가한 보고서를 토대로 타당성 조사가 선행되어야함
• 요구사항 조사는 요구공학의 한 요소

---

요구공학(Requirements Engineering)

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

요구사항 변경의 원인과 처리방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화 하는것을 목표로함

---

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

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

• 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
• 이 단계에서 개발자와 고객사이의 관계가 만들어지고 이해관계자가 식별됨. 효율적인 의사소통이 중요
• 소프트웨어 개발 생명 주기 동인 지속적으로 반복됨
• 주요기법: 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등

5. 요구사항 분석

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

• 사용자 요구사항의 타당성을 조사, 비용과 일정에 대한 제약 설정
• 서로 상충되는 요구사항을 중재하는 과정
• 도출된 요구사항을 토대로 소프트웨어의 범위 파악, 소프트웨어와 주변환경이 상호작용하는 방법 이해
• 분석에 사용되는 도구: 자료 흐름도(DFD), 자료 사전(DD) 등

6. 요구사항 명세

분석된 요구사항을 바탕으로 모델 작성, 문서화 하는것

• 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 하며, 비기능 요구사항은 필요한 것만
• 사용자가 이해하기 쉬우며, 개발자가 효율적으로 설계할 수 있도록 작성되어야 한다
• 설계과정에서 잘못된 부분 나올경우 그 내용을 요구사항 정의서에서 추적할 수 있어야함
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있다

---

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

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

---

7. 요구사항 확인(요구사항 검증)

개발자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하게 작성되어는지 확인하는 것

• 요구사항이 실제 요구를 반영하는지, 상충되는것은 없는지 확인
• 명세서 내용이 이해하기 쉬운지, 일관성이 있는지, 기준에 맞는지, 그리고 누락된 기능이 없는지 검증
• 이해관계자들이 검토해야함
• 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리 수행

형상 관리(SCM; Software Configuration Management) : 소프트웨어 개발 과정의 각 단계에서 만들어지는 프로그램과 문서, 데이터 등을 통칭하여 형상이라고 함. 이것들의 변경사항을 관리하는 일련의 과정

 

요구사항 분석

---

1. 요구사항 분석 개요

요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계. 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미

• 타당성 조사, 비용과 일정에 대한 제약 설정
• 요구를 정확하게 추출하여 목표를 정하고, 어떻게 해결할 것인지 결정
• 요구사항 분석을 통한 결과는 소프트웨어 설정 단계에서 필요한 기본적인 자료가 되므로 정확하고 일관성 있게 분석하여 문서화
• 소프트웨어 분석가에 의해 수행된다

2. 구조적 분석 기법

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

• 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화. 때문에 분석가와 사용자간 대화가 용이
• 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제 가능
• 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해 가능
• 시스템 분석의 질 향상, 시스템 개발의 모든단계에서 필요한 명세서 작성 가능
• 구조적 분석 기법: 자료 흐름도(DFD), 자료사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구를 이용하여 모델링 한다.

하향식 방법: 소프트웨어의 기능을 전체적인 수준에서 상세 수준까지 위에서 아래로 단계별로 분리하여 모델링 하는 것

자료 흐름도(DFD; Data Flow Diagram)

자료흐름도는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술 하는 방법. 자료 흐름 그래프, 버블 차트라고도 한다.

• 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용됨
• 자료 흐름도는 자료흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다
• 자료는 처리(Process)를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료 발생 시 기능 수행 후 출력 자료 산출
• 자료의 흐름과 기능을 프로세스(Process), 자료 흐름(Flow), 자료 저장소(Data Store), 단말(Terminator) 의 네가지로 표시 

기호	의미
프로세스(Process)	자료를 변환시키는 시스템의 한 부분을 나타냄. 처리, 기능, 변환, 버블 이라고도 함 원이나 둥근 사각형으로 표시하고 프로세스 이름 기입
자료 흐름(Data Flow)	자료의 이동(흐름) 이나 연관 관계 화살표 위에 자료 이름 기입
자료 저장소(Data Store)	시스템에서의 자료 저장소(파일, 데이터베이스)를 나타낸다. 이중선 이나 오른쪽이 뚫린 도형에 자료 저장소 이름을 기입한다.
단말(Terminator)	시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받는다(정보의 생산자와 소비자) 사각형이나 겹친사각형안에 이름 기입

자료 흐름도 예시[1]

자료 사전(DD; Data Dictionary)

자료 사전은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것. 데이터를 설명하는 것으로. 이런것을 데이터의 데이터 또는 메타 데이터라 함

• 표시된 자료에 대한 정보를 더 체계적이고 조직적으로 모아 편리하게 사용가능

자료 사전에서 사용되는 표시 기호[2]

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

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

이점

• 표준화와 보고를 통한 문서의 품질 개선
• 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정
• 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이
• 변경이 주는 영향 추적의 용이성과 명세에 대한 유지보수 비용의 축소

종류

SADT(Structed Analysis and Design Technique)

• SoftTech 사에서 개발 하여 널리 이용되어온 구조적 분석 및 설계 도구
• 블록 다이어 그램 채택한 자동화 도구

SREM(Software Requirements Enginnering Methodology) = RSL/REVS

• TRW사에서 우주 국방 시스템 그룹에 의해 실시간 처리 소프트 웨어 시스템에서 요구사항을 명확히 기술할 목적으로 개발한 것으로, RSL과 REVS 사용

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

REVS(Reqirement Engineering and Validation System): RSL로 기술된 요구사항들을 자동으로 분석하여 명세서 출력하는 분석기

 

PSL/PSA

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

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

PSA(Problem Statement Analyzer):  기술한 요구사항을 자동 분석하여 보고서 제출하는 분석기

 

TAGS(Technology for Automated Generation of Systems)

• 시스템 공학 방법 응용에대한 자동 접근 방법. 개발 주기의 전 과정에 이용 가능한 통합 자동화 도구
• 구성: IORL, 요구사항 분석과 IORL처리를 위한 도구, 기초적인 TAGS방법론 

IORL: 요구사항 명세 언어

 

4. HIPO

HIPO(Hierarchy Input Process Output)는 시스템의 분석 및 설계나 문서화할 때  사용되는 기법. 시스템 실행 과정인 입력, 처리, 출력의 기능 나타냄

이점

• 하향식 소프트웨어 개발을 위한 문서화 도구로, 체계적인 문서관리 가능
• 기호, 도표 등을 사용하여 보고 이해하기 쉽다
• 기능과 자료의 의존관걔를 동시에 표현가능
• 변경, 유지보수 용이
• 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO Chart 라고 한다

HIPO Chart 종류

• 가시적 도표(도식 목차): 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
• 총체적 도표(총괄 도표, 개요 도표): 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보제공
• 세부적 도표(상세 도표): 총체적 도표에 표시된 기능을 구성하는 기본요소 들을 상세히 기술

 

---

 

출처

[1] www.gisa79.com

[2] https://colomy.tistory.com/122

 

 

자료 참고: 

시나공 정보처리기사 필기 2022

표지