요구사항 확인 2

랑아·2023년 4월 14일

소프트웨어 설계 정보처리기사

정보처리기사 - 소프트웨어 설계

목록 보기

10/11

요구사항 정의

01. 요구공학

1) 요구공학의 개념

시스템 요구사항 문서를 생성, 검증, 관리하기 위해서 수행되는 구조화된 활동의 집단
요구사항의 요구사항 획득, 요구사항 분석, 요구 명세서, 검증 및 요구사항 변경 관리 등에 대한 전반적인 활동과 관리를 체계적, 반복적으로 수행하는 것

2) 요구사항 개발 프로세스

1. 요구사항 도출(Requirement Elicitation)

개발된 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
소프트웨어 요구사항의 출처가 누구이며 어느 부서인지, 어디에 있는지 파악
소프트웨어 요구사항을 어떠한 방법으로 수집할 것인가를 파악
이해관계자가 식별되고, 개발팀과 고객 사이의 관계가 만들어지는 단계
다양한 이해관계자와 효율적이고 다양한 의사소통이 매우 중요함
도출 기법에는 인터뷰, 스토리텔링, 프로토타이핑, 워크숍, 벤치마킹 등이 있음

2. 요구사항 분석(Requirement Analysis)

사용자의 요구를 이해하는 실질적인 첫 번째 단계
요구사항의 타당성을 조사
소프트웨어 요구사항들 사이에 서로 다르거나 상충되는 것을 해결
소프트웨어의 범위를 파악
소프트웨어 개발 비용과 일정에 대한 제약을 설정
소프트웨어가 다른 환경과 어떻게 상호 작용하는지 이해
소프트웨어 요구사항을 최적화하여 정확히 분석
분석 기법에는 DFD(Data Flow Diagram), DD(Data Diagram), E-R Diagram, UML Diagram 등이 있음
요구사항을 분석하고 정의해서 문서화

3. 요구사항 명세(Requirement Specification)

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

4. 요구사항 명세기법

정형 명세기법
- 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용하여 서술
- 사용자의 요구 특성을 정확하게 표현
- 가장 강력한 표현 방법으로 도구 사용이 필수적
- 명세서가 간결하고, 명세와 구현이 일치
- 수학적인 이해가 필요하기 때문에 사용자와 개발자 간의 부담이 발생
- 종류
  - VDM, Z, CSP, CSS 등
비정형 명세기법
- 사용자의 요구를 표현할 때 자연어를 기반으로 서술
- 가장 일반적이고, 친숙하지만 명세서로는 바람직하지 못함
- 사용자의 요구를 표현할 때 상태, 기능, 객체 중심으로 서술
- 이해가 용이하며, 사용자와 개발팀 간의 의사 전달 방법이 다양함
- 불충분한 명세서가 작성될 수 있으며, 모호성이 발생할 수 있음
- 종류
  - FSM, Decision Table, E-R, SADT 등
요구사항 명세서 작성 시 고려사항
- 고객과 개발자가 쉽게 이해할 수 있도록 작성
- 사용자와 개발자가 모두 동의한 내용을 작성(계약서 역할)
- 시스템의 모든 기능과 모든 제약조건을 기술
- 요구사항 검증을 위해 품질 측정 및 검증 방법, 인수 테스트 기준 등을 기술
- 우선순위에 따른 중요도를 기술
- 요구사항을 쉽게 알아볼 수 있도록 식별자 사용
요구사항 명세서 작성 원칙
- 명확성 : 요구사항 명세 내용은 하나의 의미만을 부여함
- 완전성 : 기능, 성능, 범위, 제약사항 등 모두 요구사항을 포함
- 검증 가능성 : 요구사항의 충족 여부와 달성 여부를 확인할 수 있게 함
- 일관성 : 명세 내용 간에 상호 모순이 발생하지 않도록 함
- 수정 용이성 : 요구사항 변경을 쉽게 수정할 수 있도록 함
- 추적 가능성 : 요구사항 명세 근거로 오류 추적이 가능해야 함
- 개발 후 이용성 : 운영 및 요지보수를 효과적으로 사용할 수 있어야 함

5. 요구사항 확인(Requirement Validation)

분석가가 소프트웨어 요구사항을 이해했는지 확인이 필요함
요구사항 명세서가 표준에 적합하고 이해가 가능한지 확인
요구사항 명세서가 일관성이 있고, 완전한지 검증하는 것이 중요함
이해관계자들이 문서를 검토해야 하므로 쉽게 작성되어있는지 확인
소프트웨어 요구사항 관리 도구를 이용하여 요구사항 정의 명세서를 형상 관리함
소프트웨어 요구사항이 실제로 적용되기 전에 문제를 파악하기 위한 여러 형태로의 검증을 수행

3) 요구사항 도출 기법

1. 사용자 그룹 인터뷰

사용자를 대상으로 인터뷰를 수행하여 요구사항을 도출
가능한 많은 사용자로부터 인터뷰하는 것이 좋음
회의록 작성은 필수적이며 가능하면 인터뷰 내용은 녹음하여 반복 청취하는 것이 좋음

2. 이해관계자 설문 조사

사용자와 직접 만나기 어려울 때는 설문 형식으로 조사
현행 시스템의 문제점, 개선할 점 등을 끌어낼 수 있는 설문을 준비

3. 문헌 조사

유사한 소프트웨어의 업무 문서나 양식을 조사하여 현행 시스템 정보에 대해 이해함
산업 기술 표준, 정부 정책, 규제, 법규 등을 조사
개발팀은 개발 업체의 업무 교육이나 튜토리얼에 참가

4. 프로토타이핑

기본적인 기능만 빠르게 구현해서 사용자에게 피드백을 받음
개발자의 의도를 사용자로부터 빠르게 피드백 받고자 할 때 사용
프로토타입을 위한 프로그램 전용 언어로 가상적인 사용자 인터페이스 환경을 만들어 사용

5. 스토리텔링

이야기 형식으로 요구사항을 기술하여 자연스럽게 개발자가 요구사항에 대한 이해가 되도록 구성하는 기법
스토리텔링은 애자일 방법에서 주로 사용하는 방법으로 개발자와 사용자 간의 대화를 통해 함께 요구사항을 분석해내는 방법

6. 분석과 중재 기술

사용자의 요구사항을 철저하게 분석하여 오류와 이상 여부를 판단
사용자의 요구가 무리하거나 합리적이지 않을 경우 사용자를 이해시키고 설득시킬 수 있는 중재 기술이 필요

7. 관찰과 모델 작성 기술

업무 특성이나 사용자의 업무 처리를 자세히 관찰하여 업무의 흐름을 모델링할 수 있어야 함

02. 구조적 분석

1) 구조적 분석의 원리

1. 추상화 원칙(Principle of Abstract)

특정 대상에 대한 실체로부터 분리된 개념이나 관점으로 특정 대상을 간소하게 표한하는 방법
실체를 둘러싸고 있는 세부적인 것에 의한 제약을 받지 않고 문제의 해결을 고려할 수 있게 함

2. 정형화 원칙(Principle of Formality)

특정 대상을 수학적 알고리즘과 같이 연구할 수 있도록 하여 생각과 명령을 자동화시킬 수 있는 근거를 제공할 수 있게 함

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

복잡하고 규모가 큰 시스템을 좀 더 작고 독립적인 서브 시스템으로 나누고(분할), 작게 분할된 시스템들을 쉽게 이해한다(정보)는 개념

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

여러 개의 작은 독립적인 모듈로 나누어진 것들을 어떻게 배치하는 것이 좋을 것인가 하는 문제
계층적 구조는 모듈 상호 연관 관게 및 구조에 대한 이해도 향상에 크게 도움이 됨

2) 구조적 분석의 특징

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

3) 구조적 분석의 도구(방법론)

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

시스템을 구성하고 있는 구성 요소들 사이에 자료와 정보가 어떻게 흐르고 있는가를 그림으로 도식한 다이어그램
분석 단계의 가장 첫 번째로 작성되는 그래프 모형의 도형으로 분석의 핵심적인 구조인 동시에 3단계로 계층화하여 세분되는 과정을 거쳐 산출되는 도형

2. 자료 사전(DD : Data Diagram)

시스템과 관련된 모든 자료의 명세와 자료 속성을 파악할 수 있도록 조직화한 도구
소프트웨어에서 사용하는 모든 자료 항목을 규칙에 맞게 정리한 집합

3. 소단위 명세서(Mini-spec)

내부적인 처리가 아닌 처리에 영향을 미치는 조건만을 프로그램 설계 언어(PDL)로 간단하게 기술하는 명세서
- PDL(프로그램 설계 언어)
  - 프로그래밍 언어와 유사한 문법 구조를 가지고 있지만, 실제 컴퓨터가 이해할 수 있도록 변환하는 번역 기능이 없는 언어
  - 설계 단계에서 프로그램을 프로그램 문법 주고와 유사하게 표현하기 위한 언어
처리 절차나 논리적 활동을 기술하는 도구로 구조적 언어나 의사 결정표의 형태로 구성된 것
규모가 큰 자료 흐름도의 부족한 부분을 간략하게 서술
소규모일 경우에는 생략할 수 있음

4) 자료 흐름도(DFD)의 표기법

이름	표기법	의미
외부 입출력(Terminal)		자료의 생성지와 종착지, 정보의 생성자와 소비자
처리 과정(Process)		변환 과정, 모듈, 프로시저, 함수
자료 흐름(Data Flow)		자료의 흐름, 인터페이스, 매개 변수
자료 저장소(Data Store)		자료 저장, 파일, 데이터베이스, 디스크