1. 요구공학 (Requirements Engineering)
- 소프트웨어 개발의 기초가 되는 요구사항을 정의, 문서화, 관리하는 프로세스
- 관계자 간 소통 효율성 향상, 비용 절감
- 요구사항 변경 추적 가능 및 손실 최소화
1. 요구공학 프로세스 단계
- 도출 (Elicitation): 요구사항 수집
- 분석 (Analysis): 분류, 모델링, 협상
- 명세 (Specification): 시스템 정의 및 명세서 작성
- 검증 (Validation): 테스트로 요구사항 점검
2. 요구사항 관리 도구
- 요구사항 정의 및 변경 관리를 위한 도구
- 주요 기능
- 변경 영향 분석 및 비용 편의성 제공
- 변경 이력 추적 가능
- 조직적 관리 및 우선순위/리스크 관리
- 협업 환경 제공
2. 요구사항 도출 (Requirement Elicitation)
1. 요구사항 도출 정의
- 소프트웨어가 해결할 문제를 이해하는 첫 번째 단계.
- 요구사항을 어디서, 어떻게 수집할지 결정하는 과정.
- 목적: 이해관계자와 개발자, 고객 간 의사소통 강화.
2. 요구사항 도출 기법
다양한 도출 기법
- 인터뷰: 다양한 사용자 의견 청취.
- 설문: 내부 정보와 개선 의견 수집.
- 사용자 스토리: 바라는 기능을 이야기로 형상화.
- 업무절차 조사: 업무 매뉴얼 등 분석.
- 브레인스토밍: 여러 아이디어 수집.
- 프로토타이핑: 빠르게 예시 구현 후 피드백.
- 유스케이스: 시스템 이용자와의 관계 표현.
2-1) 유스케이스 다이어그램 (Use Case Diagram)
1. 정의
- 사용자와 다른 외부 시스템들이 목표 시스템을 이용해 수행하는 기능을 사용자 관점에서 표현한 도표
- 주요 요소: 시스템 범위, 액터(actor), 유스케이스, 관계.
2. 구성 요소
- 사용자(주) 액터: 상호작용을 통해 이득을 얻는 대상 (주로 사람).
- 시스템(부) 액터: 주 액터의 목적 달성을 위해 제공되는 외부 시스템
- 유스케이스: 제공 서비스나 기능.
- 관계: 유스케이스 간 연결.
- 시스템 범위 : 관련 유스케이스들을 사각형으로 묶어서 표현.
3. 작성 주의사항
- 실행순서가 아닌 관계를 간단히 표현. (흐름도처럼 그리지 않음)
4. 유스케이스 기술서
- 액터가 시스템과 상호작용하는 과정을 보다 구체적으로 ㅓ술한 문서
기술서 구성 요소
- 유스케이스명, 액터명, 개요, 사전조건, 사후조건, 기본흐름, 대체흐름.
2-3) 유스케이스 다이어그램의 관계
1. 포함 관계 (Include)
- 공통으로 사용되는 기능을 별도로 추출하여 새로운 유스케이스로 생성.
- 기존 유스케이스에서 새로운 유스케이스 방향으로 점선 화살표를 연결하고, <<include>>를 표시.
- 예: 회원 등록 시, "정보 확인" 기능을 포함.
2. 일반화 관계
- 유스케이스 간의 상위-하위 관계를 표현.
- 상위 유스케이스에서 하위 유스케이스 방향으로 속이 빈 실선 화살표를 연결.
- 예: "회원 관리"는 "회원 등록"과 "회원 삭제"를 포함.
3. 확장 관계 (Extend)
- 특정 조건에서만 실행되는 유스케이스를 연결하는 관계.
- 선택적 유스케이스에서 원래 유스케이스 방향으로 점선 화살표를 연결하고, <<extend>>를 표시.
- 예: 회원 등록 시, "추가 인증" 기능이 선택적으로 실행.
3. 요구사항 분석 (Requirement Analysis)
1. 정의
- 도출된 요구사항을 분석하여 목표 시스템의 기능 및 특성을 조정.
- 문제 해결: 모호한 요구사항 명확화.
2. 요구사항 분석 특징
- 소프트웨어의 범위를 명확히 파악하고 외부 환경과 상호작용 분석 가능.
- 분석된 자료는 시스템 설계와 문서화에 활용.
- 요구사항 변경이 전체 개발 과정에 미치는 영향을 정확히 분석 필요.
2. 요구사항 분석 기법
- 요구사항 분류
- 기능적 요구사항: 시스템의 기능, 제어 연산 등.
- 비기능적 요구사항: 성능, 보안, 품질 등.
2. 개념 모델링
- 업무 처리의 실체(Entity)와 그들의 관계(Relation)를 모델링.
- UML(Unified Modeling Language) 사용.
3. 정량적 요구사항 할당
- 시스템의 각 요소들에 요구사항을 명확히 할당.
4. 요구사항 협상
- 충돌하는 요구사항 간 합의 도출.
- 예: 이해관계자 요구 간 충돌, 기능 vs 비기능 간 충돌.
5. 정형 분석
- 요구사항을 정형화된 언어로 분석하여 명확히 표현.
3. 구조적 분석
- 정형화된 분석 절차에 따라 요구사항을 파악하고 도형 중심으로 표현한 도표.
- 분석 원리: 추상화, 정형화, 분할 정복, 계층화.
도구
- 자료 흐름도 (DFD)
- 시스템 내 데이터 흐름을 시각적으로 표현.
- 구성 요소: 단말, 프로세스, 자료 흐름, 자료 저장소.
2. 자료 사전 (DD)
- 자료의 이름과 속성을 메타 데이터(데이터의 정의 및 설명 등을 위해 사용하는 데이터)로 정의.
- 기호 활용: =(정의), +(연결), [](선택), *(주석) 등.
3. NS(Nassi-Schneiderman) 차트
- 순차, 선택, 반복 제어구조를 표현.
4. HIPO (Hierarchy Input Process Output)
- 기능과 데이터 관계를 계층적으로 표현.
- 3가지 도표: 가시적(Table of Contents), 총체적(Overview Diagram), 세부적(Detail Diagram).
4. 요구사항 명세 (Requirement Specification)
- 분석된 요구사항을 체계적이고 명확하게 문서화하여 검토, 평가, 승인 가능하도록 만드는 것.
1. 명세 방식 분류
정형 명세 기법
- 수학적 표현으로 정확하게 요구사항을 기술.
- 오류 모호성을 쉽게 파악 가능.
- 단점: 이해하기 어렵고 작성에 시간 소요.
비정형 명세 기법
- 자연어로 요구사항을 친숙하게 표현.
- 개발자와 사용자의 의사소통이 용이.
- 단점: 명확성과 완전성 확보가 어려움.
2. 명세 작성 시 고려사항
- 정확성: 요구사항이 소프트웨어에 완전히 반영.
- 명백성: 애매한 표현 없이 명확히 기술.
- 완전성: 모든 기능, 제약사항, 속성 포함.
- 일관성: 요구사항 간 모순이나 상충이 없음.
- 중요도: 우선순위에 따른 요구사항 나열.
- 수정 가능성: 변경 시 다른 요구사항에 영향 최소화.
- 추적성: 관련 문서와 자료를 참조 가능.
5. 요구사항 검증 (Requirement Validation)
1. 요구사항 검증 기법
- 요구사항을 기반으로 생성된 결과물이 올바르게 반영되었는지 확인하는 방법.
- 잘못된 요구사항은 소프트웨어 수정 비용을 증가시킬 수 있음.
검증 기준
- 유효성: 요구사항을 만족하는 기능 제공 여부.
- 일관성: 서로 상충되는 요구사항 존재 여부.
- 완전성: 모든 요구사항이 포함되었는지 여부.
- 현실성: 환경, 예산 등으로 인해 개발 가능 여부.
- 검증 가능성: 소프트웨어에서 요구사항 검증 가능 여부.
검증 방법
- 단계별 검토: 프로토타이핑, 모델 검증, 인수 테스트 등.
2. 요구사항 검증 방법 종류
- 검토 (Review)
- 작성된 요구사항 명세서를 검토 담당자들이 직접 검증하는 일반적 방법.
종류
- 동료 검토 (Peer Review): 작성자가 아닌 이해관계자가 직접 분석.
- 워크스루 (Walkthrough): 사전 검토 후 짧은 회의로 결함 확인.
- 인스펙션 (Inspection): 작성자 외 전문가가 상세 분석.
2. 프로토타이핑
- 빠른 시제품을 개발해 즉각적인 피드백을 받고 문제를 조기에 발견.
- 단점: 반복될수록 비용 증가 가능.
3. 모델 검증
- 분석 단계에서 작성된 모델이 요구사항을 만족하는지 검증.
- 동적 분석(실제 실행을 통해 검증하는 것)이 아닌 정적 분석(모델 구조와 상호작용 점검).
4. 인수 테스트 (Acceptance Test)
- 완성된 소프트웨어를 인수자가 직접 테스트하여 요구사항 만족 여부 확인.
- 테스트 계획 수립이 필요.
정리
1. 요구공학 (Requirements Engineering)
- 소프트웨어 개발의 기초가 되는 요구사항을 정의, 문서화, 관리하는 프로세스.
- 관계자 간 소통 효율성 향상, 비용 절감, 변경 추적 가능 및 손실 최소화.
요구공학 프로세스 단계
- 도출 (Elicitation): 요구사항 수집.
- 분석 (Analysis): 분류, 모델링, 협상.
- 명세 (Specification): 시스템 정의 및 명세서 작성.
- 검증 (Validation): 테스트로 요구사항 점검.
2. 요구사항 관리 도구
- 정의: 요구사항 정의 및 변경 관리를 위한 도구.
주요 기능
- 변경 영향 분석 및 비용 편의성 제공.
- 변경 이력 추적 가능.
- 조직적 관리 및 우선순위/리스크 관리.
- 협업 환경 제공.
3. 요구사항 도출 (Requirement Elicitation)
- 소프트웨어가 해결할 문제를 이해하는 첫 번째 단계.
- 목적: 이해관계자와 개발자, 고객 간 의사소통 강화.
요구사항 도출 기법
- 인터뷰: 사용자 의견 청취.
- 설문: 내부 정보와 개선 의견 수집.
- 사용자 스토리: 바라는 기능을 이야기로 표현.
- 업무절차 조사: 업무 매뉴얼 분석.
- 브레인스토밍: 아이디어 수집.
- 프로토타이핑: 빠르게 예시 구현 후 피드백.
- 유스케이스: 시스템 이용자와의 관계 표현.
4. 유스케이스 다이어그램 (Use Case Diagram)
- 사용자와 외부 시스템들이 목표 시스템을 이용해 수행하는 기능을 사용자 관점에서 표현한 도표.
주요 요소
- 시스템 범위, 액터(actor), 유스케이스, 관계.
유스케이스 다이어그램의 관계
- 포함 관계 (Include): 공통 기능을 추출해 연결 (<<include>>).
- 일반화 관계: 상위-하위 관계 표현 (속이 빈 실선 화살표).
- 확장 관계 (Extend): 특정 조건에서만 실행되는 관계 (<<extend>>).
5. 요구사항 분석 (Requirement Analysis)
- 도출된 요구사항을 분석하여 목표 시스템의 기능 및 특성을 조정.
분석 기법
- 요구사항 분류:
- 기능적 요구사항: 시스템 기능, 제어 연산.
- 비기능적 요구사항: 성능, 보안, 품질.
2. 개념 모델링:
- 업무 처리 실체(Entity)와 관계(Relation)를 모델링 (UML 사용).
- 정량적 할당: 시스템 각 요소에 요구사항 할당.
- 요구사항 협상: 충돌 해결 및 합의 도출.
- 정형 분석: 정형화된 언어로 분석하여 명확히 표현.
6. 구조적 분석 (Structured Analysis)
- 정의: 정형화된 분석 절차로 요구사항을 도형 중심으로 표현.
- 분석 원리: 추상화, 정형화, 분할 정복, 계층화.
구조적 분석 도구
- 자료 흐름도 (DFD): 데이터 흐름을 시각적으로 표현.
- 자료 사전 (DD): 데이터 정의 및 속성 기술 (메타 데이터).
- NS 차트: 순차, 선택, 반복 제어구조 표현.
- HIPO: 기능과 데이터를 계층적으로 표현.
7. 요구사항 명세 (Requirement Specification)
- 정의: 분석된 요구사항을 체계적, 명확하게 문서화.
명세 방식 분류
- 정형 명세 기법:
- 수학적 표현, 명확한 오류 파악 가능.
- 단점: 작성 어렵고 시간 소요.
2. 비정형 명세 기법:
- 자연어 기반, 의사소통 용이.
- 단점: 명확성과 완전성 부족.
작성 시 고려사항
- 정확성, 명백성, 완전성, 일관성, 수정 가능성, 추적성.
8. 요구사항 검증 (Requirement Validation)
- 정의: 요구사항이 올바르게 반영되었는지 확인.
검증 기준
- 유효성, 일관성, 완전성, 현실성, 검증 가능성.
검증 방법 종류
- 검토 (Review): 명세서를 이해관계자가 직접 검증.
- 동료 검토, 워크스루, 인스펙션.
2. 프로토타이핑: 빠른 시제품으로 문제 조기 발견.
3. 모델 검증: 분석 모델의 구조와 상호작용 점검.
4. 인수 테스트: 인수자가 소프트웨어 만족 여부 확인.
'정처기' 카테고리의 다른 글
| UI 요구사항 (0) | 2025.02.11 |
|---|---|
| UML (0) | 2025.02.11 |
| 소프트웨어 개발 환경 분석 (0) | 2025.02.11 |
| 소프트웨어 개발 방법론 테일러링 (0) | 2025.02.11 |
| 소프트웨어 개발 방법론 (0) | 2025.02.09 |