[정보처리기사] 요구사항 정의 ( 정리, 공부 )

요구사항 정의

요구사항의 개념

1) 개념

• 소프트웨어에서 제공하는 기능에 대한 설명과 운영에 필요한 제약조건
• 소프트웨어 개발과정에 필요한 기준과 근거를 제공
• 요구사항 도출, 분석, 명세, 확인의 프로세스

2) 요구사항의 유형

① 기능 요구사항

• 시스템의 기능과 입출력 및 연산에 대한 요구사항
• 목표 시스템 구현을 위해 소프트웨어가 가져야 하는 기능적 속성에 대한 요구사항

② 비기능 요구사항

• 장비, 성능, 품질 등에 대한 요구사항
• 데이터 송수신 시 암호화와 내용 문서화 등에 관련된 요구사항
• 응답 시간, 처리량, 사용의 용이성과 신뢰도에 대한 요구사항

③ 사용자 요구사항

• 시스템이 사용자에게 제공해야 하는 것들에 대한 요구사항
• 사용자에게 친숙한 표현으로 이해하기 쉽게 작성

④ 시스템 요구사항

• 시스템이 다른 시스템 및 사용자에게 제공해야 하는 것들에 대한 요구사항
• 개발자 관점으로 작성되며 전문적, 기술적인 용어로 표현

---

요구사항 도출

1) 개념

• 소프트웨어 요구사항의 출저를 파악
• 소프트웨어 요구사항을 어떠한 방법으로 수집할 것인지 파악
• 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별
• 소프트웨어 개발 생명 주기 동안 지속적으로 반복되는 단계

2) 요구사항 도출 기법

① 인터뷰(Interview)

• 가능한 많은 사용자로부터 인터뷰를 수행
• 회의록을 작성하고, 가능한 인터뷰 내용을 녹취하여 참고

② 설문조사(Question Investigation)

• 인터뷰가 어려울 때는 설문 형식으로 조사
• 시스템의 문제점, 개선할 점 등을 끌어낼 수 있는 설문을 진행

③ 프로토타이핑(Prototyping)

• 기본적인 기능들만 빠르게 구현하여 사용자에게 피드백을 받는다.

④ 스토리텔링(Storytelling)

• 이야기 형식으로 요구사항을 기록한다.
• 개발자와 사용자가 같이 대화를 통해서 요구사항을 도출

⑤ 유스케이스(Use case)

• 사용자의 요구사항을 기능 단위로 표현

---

유스케이스 다이어그램

1) 유스케이스 다이어그램의 구성 요소

① 시스템 범위(scope)

• 개발하고자 하는 시스템 범위를 사각형으로 표시한 것

② 유스케이스

• 구현하고자 하는 기능을 타원으로 표시한 것
• 기능의 이름은 단순 명료하게 작성

③ 액터(actor)

• 시스템 외부에서 시스템과 상호작용하는 요소들(사람, 다른 시스템 등)을 표시한 것
• 액터의 이름은 특정 개인이 아닌 조직의 역할 등을 사용하여 결정
• 프라이머리 액터, 세컨더리 액터

- 프라이머리 액터(Primary actor) : 시스템을 사용함으로써 이득을 얻는 액터로 scope의 왼쪽에 위치하며, 보통 사람을 의미
- 서컨터리 액터(secondary actor) : 프라이머리 액터가 이득을 얻기 위해 도움을 주는 액터로 scope의 오른쪽에 위치하며, 보통 외부 시스템을 의미한다. 박스에 <<actor>>를 입력하여 표기한다.

④ 관계(relationship)

• 액터와 유스케이스 또는 유스케이스 간의 상호작용을 화살표 등으로 표시하는 것이다.
• 포함, 일반화, 확장 관계가 있다.

2) 유스케이스 다이어그램의 관계

① 포함 관계(필수적)

• 공통적으로 쓰이는 기능을 따로 떼어내어 새로운 유스케이스를 생성한 경우에 연결되는 관계
• 원래의 유스케이스에서 새로운 유스케이스 방향으로 점선 화살표를 그리고, <<include>>를 표시

② 일반화 관계

• 특정 유스케이스와 다른 유스케이스에 대한 상위(일반적), 하위(구체적) 관계를 표현
• 하위 유스케이스에서 상위 유스케이스 방향으로 속이 빈 실선 삼각 화살표를 그린다.

③ 확장 관계(선택적)

• 특정한 조건이 만족되는 경우에만 실행되는 유스케이스를 표현한 관계
• 선택적 유스케이스에서 원래의 유스케이스 방향으로 점선 화살표를 그리고, <<extend>>를 표시

3) 유스케이스 다이어그램 작성 시 주의사항

• 유스케이스는 실행 순서를 나타낼 수 없기 때문에 흐름도처럼 그려선 안 된다.
• 불필요하고 과도한 포함 관계 사용을 자제해야 한다.

4) 유스케이스 기술서 구성 요소

① 유스케이스명 : 액터가 시스템을 이용하여 달성하고자 하는 목적을 간결하게 기술한다.

② 액터명 : 시스템에서 업무를 수행하는 그룹의 역할을 이름으로 지정한다.

③ 개요 : 유스케이스 수행 내용을 간략히 추려서 기술한다.

④ 사전조건 : 유스케이스의 기본 흐름이 올바르게 동작될 수 있는 조건을 기술한다.

⑤ 사후조건 : 유스케이스가 실행된 후에 만족해야하는 조건을 기술한다.

⑥ 기본 흐름

• 시스템과 액터 사이에 목적을 달성하기 위한 기본적인 상호작용 흐름을 기술한다.
• 어떠한 오류나 예외가 발생하지 않고 모든 것이 완전하게 수행되는 것을 전제로 기술한다.
• 첫 번째 단계는 해당 유스케이스를 시작하는 사건(trigger)을 기술한다.

⑦ 대체 흐름

• 경우에 따라 실행되거나 예외 처리에 필요한 흐름을 기술한다.
• 기본 흐름의 각 단계별로 다수의 대체 흐름이 생성될 수 있다.

---

요구사항 분석

1) 요구사항 분석의 개념

• 사용자 요구사항의 타당성을 조사
• 요구사항들 중 서로 다르거나 중복, 상충되는 것을 해결
• 최적화된 요구사항을 기초로 소프트웨어 개발 비용과 일정에 대한 제약을 설정
• 소프트웨어의 범위를 파악하고 다른 환경과 어떻게 상호작용하는지 이해
• 정리된 요구사항을 문서화

2) 요구사항 분석 기법

① 요구사항 분류(Requirement Classification)

• 요구사항의 범위와 우선순위를 분류
• 기능적, 비기능적 요구사항으로 분류
• 사용자, 개발자 요구사항으로 분류
• 형상관리 대상인지 아닌지를 분류

② 개념 모델링(Conceptual Modeling)

• 사용자와 이해관계자, 주변 시스템이 상호작용하는 시나리오를 개념 모델로 작성
• 각각의 모델에 요구되는 기능과 서비스를 분석
• 요구사항을 구체화하는 도구로 UML을 사용

③ 요구사항 할당(Requirement Allocation)

• 요구사항을 만족시킬 수 있는 구성 요소들을 식별한 후 업무에 맞게 할당
• 개발자, 시스템, 소프트웨어, 데이터베이스 등의 구성요소를 식별
• 각 구성 요소별 상호작용으로 인한 추가적인 요구사항이 있는지 파악

④ 요구사항 협상(Requirement Negotiation)

• 요구사항이 서로 충돌하는 경우 적절한 기준점을 찾아 이를 적절히 해결하는 과정

- 2명 이상의 이해관계자가 요구하는 요구사항이 서로 충돌하는 경우
- 요구 사항과 자원이 서로 충돌하는 경우
- 기능 요구사항과 비기능 요구사항이 서로 충돌하는 경우

• 요구사항에 각각의 우선순위를 부여하면 문제 해결에 큰 도움

⑤ 정형 분석(Formal Analysis)

• 요구사항 분석의 마지막 단계
• 구문과 의미를 갖는 정형화된 언어로 요구사항을 표현
• 정확하고 명확한 표현으로 이해관계자 간의 오해를 최소화

3) 구조적 분석

① 구조적 분석의 원리

• 추상화 원칙(Principle of Abstract)

- 객채의 중요한 특징만을 간단하게 표현, 세부적인 것에 의해 제약을 받지 않고 문제해결을 고려

• 정형화 원칙(Principle of Formality)

- 주어진 문제를 해결하는 데 있어서 엄격하고 공학적인 접근 방법을 적용

- 문제 해결에 엄격한 방법론적 접근 방법을 적용하는 것

• 분할 정복의 개념(Divide-and-Conquer Concept)

- 규모가 큰 시스템을 작고 독립적인 서브 시스템으로 나눔

- 서브 시스템을 해결하여 다시 큰 시스템으로 합침

• 계층적 구조의 개념(Hierarchical Structure Concept)

- 여럿의 작은 독립적인 모듈들로 나누어 계층적 구조로 배열

- 모듈의 상호 연관 관계 및 구조에 대한 이해도 향상에 도움

② 구조적 분석의 특징

• 도형과 도표 등의 이미지 중심의 형태로 표현
• 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능
• 시스템 분석 시 사용자 참여 기회를 확대
• 분석의 중복성을 배제하고 하향식으로 분석

4) 구조적 분석 도구

① 자료 흐름도(DFD : Data Flow Diagram)

• 자료와 정보가 시스템의 구성 요소들 사이를 어떻게 흐르는지 그림으로 표현한 양식
• 자료의 흐름을 명확히 파악
• 작업 소요시간은 불분명
• 자료 흐름도 표기법

구성 요소	표기	설명
외부 입출력(Terminal)		자료 생성, 종착지
처리 과정(Process)		변환 과정, 모듈, 함수
자료 흐름(Data Flow)		인터페이스, 매개 변수
자료 저장소(Data Store)		파일, 데이터베이스, 디스크

• 자료 흐름도 작성 지침

- 자료는 처리가 될 때마다 새로운 명칭을 부여
- DFD의 최하위 프로세스는 소단위 명세서를 가짐
- 프로세스가 출력을 하기 위해서는 반드시 자료 입력이 진행
- 페이지당 버블(프로세스)의 수가 12개 이내
- 페이지의 단계는 2~3단계 이내
- 최종 단계의 버블은 코딩이 가능한 수준에서 멈춤

② 자료 사전(DD : Data Dictionary)

• 시스템과 관련된 모든 자료의 이름과 속성을 표기하고 조직화한 도구
• 모든 자료는 규칙에 맞게 정리하여 명세
• 자료 사전의 표기법 ★

이름	표기
자료의 정의	=
자료의 연결(그리고)	<자료> + <자료>
자료의 선택(또는)	[<자료>|<자료>|<자료>]
자료의 반복	{<자료>}ⁿ
자료의 생략	(<자료>)
자료의 설명(주석)	* *

③ NS(Nassi-Schneiderman) 차트

• NS차트의 3가지 제어 구조 : 순차, 선택, 반복
• NS 도표의 특징

- 논리의 기술에 중점을 준 도형 표현 방법
- 임의의 제어 이동이 어려움
- 시각적으로 명확히 식별되어 프로그램 구현이 쉬움

④ HIPO(Hierarchy Input Process Output)

• 시스템의 기능을 고유한 모듈로 분할하고 이들 간의 인터페이스를 계층 구조로 표현한 양식
• 입력, 처리, 출력으로 기본 시스템 모델이 구성
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용해서 직관적이며 이해가 쉬움
• 기능과 자료의 의존 관계를 동시에 표현 가능
• 수정 및 유지보수에 좋고 소규모 프로젝트에 적합
• 종류에는 가시적, 총체적, 세부적 도표 등

도표명	설명
가시적 도표(Visual Table of Contents)	시스템의 전체적인 기능과 흐름을 계층적으로 표시
총체적 도표(Overview Diagram)	HIPO에 대한 전반적인 정보를 제공
세부적 도표(Detail Diagram)	총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

---

요구사항 명세

1) 개념

• 파악된 요구사항을 체계적으로 검토, 평가하고 승인될 수 있는 문서를 작성
• 개발자뿐만 아니라 고객도 알 수 있을 정도로 쉽게 작성

2) 요구사항 명세 기법

① 정형 명세 기법

• 수학적인 원리와 표기법을 이용하여 서술
• 사용자의 요구사항을 정확하게 표현
• 명세서가 간결하고 명세와 구현이 일치
• 수학적인 이해가 필요하며 도구 사용이 필수적

② 비정형 명세 기법

• 자연어를 기반으로 사용자의 요구를 서술
• 일반적이고 친숙하지만 명세서로는 불충분
• 사용자의 요구를 상태, 기능, 객체 중심으로 서술
• 의사 전달 방법이 다양하고 이해가 용이

3) 명세서 작성 시 고려사항

• 고객과 개발자가 쉽게 이해할 수 있도록 작성
• 시스템의 모든 기능과 모든 제약조건을 기술
• 요구사항 검증을 위해 품질 측정 및 검증 방법, 기준 등을 기술
• 우선순위에 따른 중요도를 기술

4) 명세서 작성 원칙

원칙	설명
명확성	명세 내용은 하나의 의미만 부여
완전성	모든 요구사항을 포함
검증 가능성	요구사항의 충족, 달성 여부 확인
일관성	내용 간에 상호 모순이 발생하는지 확인
수정 용이성	요구사항 변경이 용이한지 확인
추적 가능성	요구사항 명세 근거로 오류 추적이 가능
개발 후 이용성	운영 및 유지보수가 효과적인지 확인

---

요구사항 검증

1) 요구공학

① 요구공학의 개념

• 요구사항의 획득, 분석, 명세, 검증 및 변경관리를 체계적이고 반복적으로 수행하는 방법과 기술의 총칭
• 요구사항 명세서가 최종 산출물

- 요구사항 개발 절차 : 타당성 조사 → 요구사항 분석 및 추출  → 요구사항 명세화  → 요구사항 검증
- 요구사항 관리 절차 : 요구사항 협상  → 요구사항 기준선  → 요구사항 변경관리 → 요구사항 확인 및 검증 ★

② 요구사항 관리 도구

• 요구사항을 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있는 역할을 지원하는 것으로 IBM Rational, DOORS 등이 있다.
• 요구사항 관리 도구의 주요 기능

- 프로젝트 생성 : 타입 및 기본 모듈 템플릿, 역할별 뷰를 설정하여 프로젝트 생성
- 요구사항 작성 : 모든 요구사항에 고유의 ID가 생성, 부여되고 사용자에 의해 임의 변경 불가능
- 파일 내보내기 / 가져오기 : 요구사항의 일괄 등록 및 추출, 다양한 형식 파일 지원
- 이력 관리 : 요구사항별로 히스토리를 제공하여 변경 이력 관리
- 베이스라인 : 요구사항이 확정되고 관리의 시작점이 되는 기능 ★
- 요구사항 추적성 : 어느 요구사항이 베이스인지 구분하기 위한 기능
- 협업 환경 : 공유 모드를 제공하고 선점 사용자 외에는 수정 및 삭제 권한 제한
- 외부 연동 환경 : 설계 도구, 형상 관리 도구와의 연동 지원
- 확장성 : API를 통해 타 시스템과의 연동 기능 제공

2) 요구사항 검증 기법

① 요구사항 검토(Requirement Reviews)

• 요구사항 명세서를 훑어보는 가장 일반적인 검증 방법
• 요구사항 분석가는 요구사항을 정확히 이해해야함
• 고객 중심 프로젝트인 경우 검토자 그룹에 고객 검토자가 반드시 포함되어야함

② 프로토타이핑(Prototyping)

• 초기 도출된 요구사항을 토대로 견본을 만들어서 불분명한 사용자의 요구사항이나 새로운 요구사항을 검증하기 위한 방식
• 빠르게 제작할 수 있으며, 즉각적인 피드백이 가능
• 시스템의 문제점을 사전에 식별할 수 있고, 요구사항을 점진적으로 감소
• 반복적인 프로토타입 개선으로 비용이 증가할 수 있다.

③ 모델 검증(Model Verification)

• 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족하는지 검증하는 것
• 객체 모델의 경우 객체들 사이의 의사소통 경로를 검증하기 위해 정적 분석을 수행하는 것이 유용

④ 인수 테스트(Acceptance Tests)

• 개발이 완료된 소프트웨어를 직접 인수받아 요구사항을 충족하는지 검증
• 모든 요구사항을 어떻게 테스트할 것인지 계획을 세움

---

요구사항 검증 방법

1) 요구사항 검토

① 동료 검토

• 2~3명 정도의 검토 담당자가 수행
• 요구사항 명세서 작성자가 다수의 이해관계자들에게 명세서 내용을 설명
• 이해관계자들은 설명을 들으며 결함을 분석

② Walk Through(워크스루)

• 검토 자료를 회의 전에 배포
• 짧은 시간 동안 회의를 진행하여 오류를 검출하고 문서화
• 오류를 조기에 검출하는 데 목적을 두고 있음
• 소프트웨어 개발 단계마다 실시하는 비정형 검토 회의

③ Inspection(인스펙션)

• 소프트웨어 개발에 참여하지 않은 다른 전문가가 오류를 찾아내는 검토 방법
• 결과물 자체의 품질과 결과물을 만들어내는 과정도 포함

④ 프로토타입

• 검증이 필요한 주요 기능이나 일부분에 대한 견본을 개발하여 고객을 대상으로 시연하면서 요구사항을 검증

2) 테스트 설계

• 테스트 케이스를 생성하여 요구사항이 현실적으로 테스트 가능한지 검토
• 송수신 시스템에서 확인해야 할 사항을 각각 도출
• 데이터베이스에 적용하는 과정에서 오류가 발생하지 않는지 테스트 케이스를 작성

3) CASE(Computer Aided Software Engineering)

① CASE의 개념

• 소프트웨어 생명주기 전반을 지원하는 자동화 도구 혹은 방법론의 결합
• 소프트웨어 개발 과정의 일부 또는 전체를 자동화하기 위한 도구
• 객체지향 시스템뿐만 아니라 구조적 시스템 등 모든 분야에 적용
• 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공
• 자동화된 일관성 분석을 제공하는 CASE 도구를 활용
• 다양한 이해관계자가 공동 작업할 수 있고, 테스트 연계 및 결함, 형상관리 등의 기능을 제공하기 때문에 시스템 구축 업무를 효율적으로 수행 가능

② CASE의 특징

• 가격은 비싸지만 개발 기간이나 인력이 감소되기 때문에 전체 개발비용은 절감
• 전문 분석가의 지원이 필요
• 다양한 개발 모형과 그래픽을 지원 ★
• CASE 툴 간의 호환성 X
• 언어 번역 프로그램은 지원 X

③ SADT(Structured Analysis and Design Technique)

• SoftTech사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계도구
• 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구

④ SREM(Software Requirements Engineering Methodolgy)

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

RSL(Requirement Statement Language) : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어REVS(Requirement Engineering and Validation System) : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기

⑤ PSL/PSA 

• 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구

SPL(Problem Statement Language) : 문제 기술 언어
PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기

⑥ TAGS(Technology for Automated Generation of Systems)

• 시스템 공학 방법 응용에 대한 자동 접근 방법, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

---

※ <이기적> 환상의 콤비 정보처리기사 책으로 공부하며 정리한 내용입니다.