이 글의 핵심
요구사항은 기능과 비기능으로 나누고 명확성·완전성·일관성을 검토합니다.
UML 다이어그램은 표현 대상과 시간 흐름 여부로 구분하면 암기가 쉬워집니다.
테스트와 형상관리는 개발 후반의 활동이 아니라 생명주기 전체의 품질 관리 활동입니다.
요구사항에서 설계로 이동하는 과정
요구사항 도출에서는 인터뷰, 설문, 워크숍, 프로토타이핑 등을 활용해 이해관계자의 필요를 찾습니다. 분석 단계에서는 모호함과 충돌을 제거하고 우선순위와 제약을 구체화합니다.
기능 요구사항은 시스템이 제공할 동작을, 비기능 요구사항은 성능, 보안, 신뢰성, 사용성 같은 품질과 제약을 설명합니다. 설계는 이 요구를 모듈, 데이터, 인터페이스와 화면 구조로 변환합니다.
UML을 구조와 행위로 나누기
클래스, 객체, 컴포넌트, 배치 다이어그램은 시스템의 정적인 구조를 표현합니다. 유스케이스, 활동, 상태, 시퀀스 다이어그램은 사용자 상호작용이나 시간에 따른 행위를 표현합니다.
시퀀스 다이어그램은 객체 사이 메시지의 시간 순서를, 활동 다이어그램은 작업 흐름과 분기를, 상태 다이어그램은 한 객체의 상태 변화를 강조합니다. 문제의 중심 명사를 찾으면 다이어그램을 빠르게 고를 수 있습니다.
| 다이어그램 | 중심 질문 | 주요 요소 |
|---|---|---|
| 유스케이스 | 사용자가 어떤 기능을 쓰는가? | 액터·유스케이스·관계 |
| 클래스 | 객체의 구조와 관계는? | 클래스·속성·연산 |
| 시퀀스 | 메시지가 어떤 순서로 오가는가? | 생명선·메시지 |
| 상태 | 사건에 따라 상태가 어떻게 변하는가? | 상태·전이·이벤트 |
결합도는 낮추고 응집도는 높이기
좋은 모듈은 하나의 분명한 책임에 집중하고 다른 모듈의 내부 구현에 덜 의존합니다. 응집도가 높으면 관련 기능이 함께 모이고 결합도가 낮으면 변경 영향이 줄어듭니다.
설계 원칙과 패턴을 외울 때는 이름보다 어떤 변화에 유연해지는지 확인하세요. 인터페이스에 의존하거나 객체 생성을 분리하는 이유는 변경되는 부분을 격리하고 테스트하기 쉽게 만들기 위해서입니다.
테스트와 형상관리로 품질을 유지하기
단위 테스트는 작은 모듈을, 통합 테스트는 모듈 사이 인터페이스를, 시스템 테스트는 전체 요구사항을, 인수 테스트는 사용자 관점의 수용 여부를 확인합니다. 테스트 목적과 대상이 선택지의 핵심입니다.
형상관리는 변경되는 소스, 문서, 설정을 식별하고 버전과 변경을 통제하며 상태를 기록하고 감사를 수행합니다. 단순 백업이 아니라 승인된 기준선과 변경 이력을 일관되게 관리하는 활동입니다.
생명주기 문제는 “현재 산출물, 검토 주체, 다음 단계로 넘길 조건” 세 가지를 표시하면 비슷한 절차를 구분하기 쉽습니다.
자주 묻는 질문
검증과 확인은 어떻게 구분하나요?
검증은 산출물이 이전 단계의 명세와 설계에 맞게 만들어졌는지, 확인은 최종 결과가 사용자의 실제 요구와 목적을 충족하는지에 초점을 둡니다.
화이트박스와 블랙박스 테스트의 차이는 무엇인가요?
화이트박스는 내부 제어 구조와 경로를 기준으로, 블랙박스는 내부 구현을 보지 않고 입력과 출력 및 요구사항을 기준으로 테스트합니다.
시험 과목과 합격 기준은 Q-Net 정보처리기사 공식 안내를 기준으로 확인했습니다. 가풀은 시험 주관기관의 공식 서비스가 아니며, 일정과 규정은 접수 전 공식 공고를 다시 확인해야 합니다.