시스템 분석·설계 개요
시스템 분석·설계는 소프트웨어 개발의 초기 단계로, 요구사항을 파악하고 시스템 구조를 정의합니다. 정보처리기사에서는 요구사항 분류, 모델링 기법, 설계 원칙이 출제됩니다.
요구사항 분류
기능적 요구사항 (Functional Requirements)
- 시스템이 해야 할 기능을 기술
- 예: “사용자는 이메일로 회원가입할 수 있다”
- 유스케이스, 유저 스토리로 표현
비기능적 요구사항 (Non-Functional Requirements)
- 시스템의 품질 특성을 기술
- 성능: 응답 시간 3초 이내
- 보안: 개인정보 암호화 저장
- 가용성: 99.9% 업타임
- 확장성: 동시 접속자 10만명 지원
- 유지보수성: 모듈화 구조 적용
요구사항 개발 프로세스
- 도출(Elicitation): 인터뷰, 설문, 관찰, 프로토타입으로 요구사항 수집
- 분석(Analysis): 요구사항 충돌 해결, 우선순위 결정
- 명세(Specification): SRS(소프트웨어 요구사항 명세서) 작성
- 검증(Validation): 요구사항이 완전·일관·실현 가능한지 확인
유스케이스 (Use Case)
사용자(액터)와 시스템 간 상호작용을 기술하는 행위 시나리오입니다.
구성 요소
- 액터(Actor): 시스템과 상호작용하는 외부 개체 (사용자, 외부 시스템)
- 유스케이스: 시스템이 제공하는 기능 단위
- 관계: 연관(Association), 포함(Include), 확장(Extend), 일반화(Generalization)
Include vs Extend
- Include: 항상 포함되는 공통 기능 (예: 로그인 확인은 모든 기능에 포함)
- Extend: 조건에 따라 선택적으로 포함 (예: 결제 시 쿠폰 적용은 선택적)
구조적 설계 원칙
응집도(Cohesion) vs 결합도(Coupling)
- 높은 응집도: 모듈 내 요소들이 밀접히 관련. 좋음
- 낮은 결합도: 모듈 간 의존성 최소화. 좋음
응집도 유형 (높은 순)
기능적 > 순차적 > 교환적 > 절차적 > 시간적 > 논리적 > 우연적
결합도 유형 (낮은 순)
데이터 < 스탬프 < 제어 < 외부 < 공통 < 내용
ERD에서 관계형 스키마 변환
- 1:1 관계: 어느 쪽 테이블에 외래 키 추가 (선택)
- 1:N 관계: N 쪽 테이블에 외래 키(FK) 추가
- M:N 관계: 별도 연결 테이블 생성 (두 테이블의 기본 키를 복합 키로)
시험 핵심 포인트
- 기능 요구사항: “무엇을 해야 하는가” / 비기능 요구사항: “어떻게 잘 해야 하는가”
- Include: 항상 포함 / Extend: 조건부 포함
- 높은 응집도 + 낮은 결합도 = 좋은 설계
- M:N 관계: 반드시 연결 테이블 생성
- SRS: 소프트웨어 요구사항 명세서 (IEEE 830 표준)
마무리
시스템 분석·설계는 개념 이해와 적용이 모두 필요한 파트입니다. 유스케이스 관계 유형(Include/Extend)과 ERD 변환 규칙은 자주 출제되므로 예시와 함께 학습하세요.