728x90
요구사항 정의
요구사항의 개념 및 특징
요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다.
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
- 소프트웨어의 내용을 확인할 수 있게 하므로 참여하는 이해관계자들 간의 의사소통을 원할하게 하는데 도움을 준다.
- 제대로 정의되어야만 이후 과정의 목표와 계획을 수립할 수 있다.
요구사항의 유형
일반적으로
기술하는 내용에 따라 '기능 요구사항'과 '비기능 요구사항'으로 구분하며,
기술 관점과 대상의 범위에 따라 '시스템 요구사항'과 '사용자 요구사항'으로 나눈다.
요구사항 개발 프로세스
개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동이다.
1. 요구사항 도출
시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것이지 식별하고 아해하는 과정이다.
- 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
- 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별
- 다양한 이해관계자 간의 효율적인 의사소통이 중요
- 소프트웨어 개발 생명 주기 동안 지속적으로 반복
- 주요 기법에는 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있다.
2. 요구사항 분석
개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.
- 사용자 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정
- 도출된 요구사항들을 토대로 소프트웨어의 범위를 파악
- 도출된 요구사항들을 토대로 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해
- 자료 흐름도, 자료 사전 등의 도구가 사용
3. 요구사항 명세
분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
- 요구사항을 문서화 할 때는 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 하며, 비기능 요구사항은 필요한 것만 명확하게 기술해야 한다.
- 요구사항은 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성해야 한다.
- 설계 과정에서 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 한다.
- 구체적인 명세를 위해 소단위 명세서가 사용될 수 있다.
4. 요구사항 확인
개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 활동이다.
- 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인하는 것이 필요
- 요구사항 명세서의 내용이 이해하기 쉬운지, 일관성은 있는지, 회사의 기준에 맞는지, 그리고 누락된 기능은 없는지 등을 검증 하는 것이 중요
- 이해 관계자들이 검토해야 한다
- 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대한 형상 관리를 수행
요구사항 분석
요구사항 분석의 개요
소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미한다.
- 사용자의 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정
- 요구사항 분석을 통한 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화해야 한다.
- 소프트웨어 분석가에 의해 요구사항 분석이 수행되며, 이 작업 단계를 요구사항 분석 단계라고 한다.
- 요구사항 분석을 위해 UML(Unified Modeling Language), 자료 흐르도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구를 이용한다.
구조적 분석 기법
자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법이다.
- 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화 한다.
- 도형 중심의 도구를 사용하므로 분석가와 사용자 간의 대화가 용이하다.
- 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있다.
- 사용자의 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있다.
- 시스템 분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능하다.
자료 흐름도(DFD)
자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 자료 흐름 그래프, 버블 차트라고도 한다.
- 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
- 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다.
- 자료는 Process를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출한다.
- 자료 흐름도에서 자료의 흐름과 기능을 Process, Data Flow, Data Store, Terminator의 네 가지 기본 기호로 표시한다.
자료 사전
자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터라고 한다.
- 자료 흐름도에서 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용할 수 있다.
요구사항 분석 CASE와 HIPO
요구사항 분석을 위한 CASE(자동화 도구)
요구사항 분석을 위한 자동화 도구는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미한다.
- 표준화와 보고를 통한 문서화 품질 개선
- 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정
- 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성
- 변경이 주는 영향 추적의 용이성
- 명세에 대한 유지보수 비용의 축소
종류
요구사항 분석을 위한 자동화 도구에는 SADT, SREM, PSL/PSA, TAGS, EPOS 등이 있다.
SADT(Structured Analysis Design Technique)
- SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구이다.
- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구이다.
SREM(Software Requirements Engineering Methodology) = RSL/REVS
- TRW 사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구이다.
PSL/PSA
- 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구이다.
- PSL(Problem Statement Language): 문제(요구사항)기술 언어
- PSA(Problem Statement Analyzer): PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기
TAGS(Tachnology for Automated Generation of Systems)
- 시스템 공학 방법 응용에 대한 자동 접근 방법으로, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구이다.
- 구성: IORL, 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론
- IORL: 요구사항 명세 언어
HIPO
시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.
- 기본 시스템 모델을 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구이다.
- 체계적인 문서 관리가 가능하다.
- 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
- 변경, 유지보수가 용이하다.
- 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.
HIPO Chart의 종류
가시적 도표(Visual Table of Contents), 총체적 도표(Overview Diagram), 세부적 도표(Detail Diagram)가 있다.
- 가시적 도표(도식 목차): 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
- 총체적 도표(총과도표, 개요 도표): 프로그램을 구서하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
- 세부적 도표(상세 도표): 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
728x90
'정보처리기사 > 정처기-1과목' 카테고리의 다른 글
| [정처기-1과목] 1-1 소프트웨어 생명 주기와 모형 (0) | 2022.12.30 |
|---|
