6. 요구사항 개발
(1) 요구사항 개발
1️⃣ 요구공학정의 및 목적
: 고객이 원하는 것을 어떻게 정확하게 뽑아낼 수 있을까?
❶ 이해관계자 사이의 원활한 의사소통 수단을 제공
❷ 요구사항 누락 방지, 상호 이해 오류 등의 제거로 경제성을 제공
❸ 사용되는 도구 - 자료흐름도, 자료 사전, 소단위 명세서 등
❹ 요구사항 변경 이력 관리 (문서화)를 통해 개발 비용 및 시간 절약
요구사항 베이스 라인 (기준선) : 이해 당사자 간의 명시적 합의 내용 & 프로젝트 목표 달성 여부 확인 기준
2️⃣ SWEBOK에 따른 요구사항 개발 프로세스
SoftWare Engineering Body of Knowledge, 소프트웨어 공학 지식 체계
도출(Elicitation) - 분석(Analysis) - 명세(Specification) - 확인(Validation)
3️⃣ 요구사항 도출
소프트웨어가 해결할 문제 이해
현재 상태 파악 후 문제 정의 - 결과 목표 도출
이해 관계자(Stakeholder)가 식별됨
요구사항 도출 기법
| 종류 | ||
| 고객의 발표 | 브레인 스토밍 | Use Case |
| 문서 조사 | 워크숍 | 벤치 마킹 |
| 설문 | 인텨뷰 | EPR(업무 재설계) |
| 업무 절차 및 양식 조사 | 관찰 및 모델의 프로토 타이핑 | RFP(제안 요청서) |
4️⃣ 요구사항 분석
요구사항 분석을 위한 기법
| 종류 | ||
| 사용자 의견 청취 | 사용자 인터뷰 | 현재 사용중인 각종 문서 분석과 중재 |
| 관찰 및 모델 작성 기술 | 설문조사 | - |
요구분석 수행 단계 : 문제 인식 - 전개 - 평가와 종합 - 검토 - 문서화
정형 분석
구문과 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현
요구사항 분석의 마지막 단계에서 이루어짐
5️⃣ 요구사항 분류
| 분류 | 종류 | 설명 |
| 기술 내용에 따른 분류 | 기능 요구사항 | 시스템이 실제로 어떻게 동작하는지 |
| 비기능적 요구사항 | 시스템 구축에 대한 성능, 보안, 품질, 안정성등 실제 수행에 보조 | |
| 기술 관점 및 대상에 따른 분류 | 시스템 요구사항 & 사용자 요구사항 | |
요구사항 분류 기준
❶ 기능 요구사항 & 비기능 요구사항 구분 - 우선순위 확인
❷ 요구사항이 1개 이상의 고수준 요구사항으로부터 유도된 것인지 확인
❸ 이해관계자나 다른 Source로 부터 직접 발생한 것인지 확인
❹ 요구사항이 제품 관련인지 프로세스 관련인지 확인하고 소프트웨어에 미치는 영향의 범위를 확인
❺ 소프트웨어 생명주기 동안에 변경이 발생하는지 확인
[관련 기출 문제]
6️⃣ 요구사항 명세
요구사항 명세 기법
| 구분 | 정형 명세 | 비정형 명세 |
| 기법 | 수학적기반 & 모델링 기반 | 상태, 기능, 객체 중심 명세 기법 + 자연어 기반 |
| 종류 | Z, VDM | FSM(Finite State Machine) |
| Petri-Net (모형 기반) | Decision Table, ER 모델링 | |
| LOTOS (대수적 방법) | State Chart (SADT) | |
| CSP | UseCase | |
| CCS | 사용자 기반 모델링 | |
| 장점 | ❶ 정확하고 간결하게 명세 가능 ❷ 명세와 구현의 일치성 |
❶ 명세 작성 이해가 쉽다 ❷ 의사전달 방법이 다양 |
| 단점 | ❶ 낮은 이해도 ❷ 이해관계자의 부담 가중 |
❶ 불충분한 명세 기능 ❷ 모호성 |
요구사항 명세 속성
정확성 : 정확하게 작성
명확성 : 한 가지로 해설 해야함
완전성 : 모든 것을 표현 (기능 + 비기능)
일관성 : 요구사항 간 충돌 x
수정 용이성 : 수정이 가능해야함
추적성 : RFP, 제안서를 통해 추적이 가능
7️⃣ 요구사항 확인
: 요구 사항 분석 단계를 거쳐 문서로 만들어진 내용을 확인하고 검증하는 단계
요구사항 관리 도구를 이용해 이해관계자들이 문서를 검토 & 문서를 형상 관리를 해야함
표준에 적합? 이해가능? 일관성? 완전? 에 대한 검증을 수행
🤔 형상관리란?
애플리케이션 개발 단계에서 도출되는 프로그램, 문서, 데이터 등의 모든 자료를 형상단위라 한다.
이를 관리하며, 어플리케이션 버전 관리등을 하는 활동을 형상관리라고 한다
요구사항 관리의 필요성
❶ 요구사항 변경으로 인한 비용 편익 분석
❷ 요구사항 변경의 추적
❸ 요구사항 변경에 따른 영향 평가
(2) 요구사항 확인 기법
1️⃣ 요구사항 확인을 위한 도구
| 종류 | |
| 프로토타이핑 | Prototyping |
| 모델 검증 | Model Verification |
| 요구사항 검토 | Requirement Reviews |
| 인수 테스트 | Acceptance Tests |
2️⃣ 프로토타이핑(Prototyping)
: 도출된 요구사항을 토대로 프로토 타입을 제작하며, 추가 요구사항을 지속해서 반영하는 과정
절차 : 요구사항 분석 - 프로토타입 설계 - 개발 - 고객 평가 - 프로토타입 정제 - 완제품 생산
3️⃣ 모델 검증 (Model Verification)
: 분석 단계에서 개발된 모델의 품질을 검증
정적분석 : 명세를 확인
동적 분석 : 직접 실행
4️⃣ 인수테스트
: 최종 제품이 요구사항을 만족하는지 확인하는 단계
| 순서 | 테스트 순서 |
| 1 | 계약 인수 테스트 |
| 2 | 규정 인수 테스트 |
| 3 | 알파 검사 |
| 4 | 베타 검사 |
| 5 | 사용자 인수 테스트 |
| 6 | 운영 인수 테스트 |
[관련 기출 문제]
7. UML
(1) 개념 모델링
종류
| 종류 | |||
| Use Case Diagram | Data Flow Model | State Model | Goal-Based Model |
| User Interactions | Object Model | Data Model | |
(2) UML (Unified Modeling Language)
1️⃣ UML
객체지향 소프트웨어 개발시 사용하는 모델링 기술과 방법론을 통합하여 만든 범용 모델링 언어
Rumbaugh의 OMT 방법론 + Booch의 Booch 방법론 + Jacobson의 OOSE 방법론
UML 특성 : 도식화 하는 것 (시각화 / 문서화 / 명세화 / 구축)
UML 소프트웨어에 대한 관점
| 관점 | 설명 | 예시 |
| 기능적 관점 | 사용자 측면에서 본 기능 | Use Case Diagram |
| 정적 관점 | 소프트웨어 구셩 요소 사이의 구조적 관계 | Class Diagram |
| 동적 관점 | 시스템 내부 동작 | Sequence Diagram, State Diagram, Activity Diagram |
UML의 기본 구성
| 구성 | 설명 |
| 사물 (Thing) | 객체지향 모델을 구성하는 기본요소 |
| 관계 (Relationship) | 객체 간 연관성 표현 |
| 다이어그램 (Diagram) | 객체 간 관계를 도식화 ❶ 정적 모델 : 구조 다이어그램 ❷ 동적 모델 : 행위 다이어그램 |
스테레오 타입
UML에서 제공하는 기본요소 외 추가적인 확장 요소를 표현할 때,
길러멧 (Guillemet) `<< >>` 을 사용
UML 접근 제어자
| 접근제어자 | 표기 | 설명 |
| Public | + | 어떤 클래스의 객체에서든 접근 가능 |
| Private | - | 해당 클래스로 생성된 객체만 접근 가능 |
| Protected | # | 해당 클래스와 동일한 패키지, 상속관계의 하위 패키지만 접근 가능 |
| Package | ~ | 동일 패키지에 있는 클래스의 객체들만 접근 가능 |
연관관계 다중성 표현
| 표기 | 의미 |
| 1 | 1 (객체 연결) |
| * or 0..* | 0이거나 그 이상 |
| 1..* | 1이거나 1 이상 |
| 0..1 | 0이거나 1 |
| 1, 3, 6 | 1이거나 3이거나 6 |
| n | n개 |
| n..* | n이거나 n개 이상 |
2️⃣ 럼바우(Rumbaugh) 객체지향 분석 기법 ⭐️
객체 모델링 : 현실 세계의 대상체를 모델링 하여 객체를 다이어그램으로 표시
동적 모델링 : 제어 흐름, 상호작용, 동작 순서 등을 상태 다이어그램으로 표시
기능 모델링 : 여러 프로세스 간의 자료 흐름을 표시
[관련 기출 문제]
(3) UML 다이어그램의 분류
1️⃣ 구조적 다이어그램
: 정적이고 구조 표현을 위한 다이어그램
| 다이어그램 유형 | 목적 |
| 클래스 다이어그램 | 클래스의 정적 구조를 표현, 클래스 간 관계 표현 |
| 객체 다이어그램 | 객체 정보 표현 |
| 복합체 구조 다이어그램 | 복합 구조의 클래스와 컴포넌트 내부 구조 표현 |
| 배치 다이어그램(Deployment Diagram) | SW, HW, 네트워크 등의 물리 구조 표현 |
| 컴포넌트 다이어그램 | 컴포넌트 구조 사이의 관계 표현 |
| 패키지 다이어그램 | 패키지의 관계를 표현 |
2️⃣ 행위 다이어그램
: 동적이고 순차적인 표현을 위한 다이어그램
| 다이어그램 유형 | 목적 | |
| Use Case 다이어그램 | 사용자 관점에서 시스템 행위를 표현 | |
| 활동 다이어그램 | 업무 처리 과정이나 연산이 수행되는 과정을 표현 | |
| 상태 머신 다이어그램 | 객체의 생명주기를 표현 | |
| Collaboration Diagram | 순차 다이어그램과 동일, 모델링 공간에 제약 x 구조적인면 중시 | |
| 상호작용 다이어그램 |
순차 다이어그램 |
시스템 동작을 정형화, 시간에 따른 메시지 발생 순서 강조 |
| 요소 : 생명선, 통로, 상호작용, 발생, 실행, 상태 불변,메시지, 활성, 객체, Actor | ||
| 상호작용 개요 다이어그램 | 여러 상호작용 다이어그램 사이의 제어 흐름 표현 | |
| 통신 다이어그램 | 객체 사이 관계를 중심으로 상호작용 표현 | |
| 타이밍 다이어그램 | 객체 상태 변화와 시간 제약을 명시적 표현 | |
(4) 클래스 다이어그램 관계 표현
1️⃣ 클래스 다이어그램
: 시스템을 구성하는 객체 간의 관계를 추상화한 모델을 논리적 구조로 표현
2️⃣ UML 관계 표현
| 구성 | 설명 |
| Composition (포함 관계) | 전체/부분 객체 라이프 타임 의존적 |
| Directed Association (단방향 연관관계) | 한쪽은 알지만 반대쪽은 상대방의 종재 모름 |
| Usage(Dependency) | - |
| Generalizaion (일반화 관계) | 상속관계를 표현 / 한클래스가 다른 클래스를 포함하는 상위 개념일 때 사용 |
| Aggregation (집합 관계) | 클래스 사이 전체나 부분이 같은 관계 |
| Association (양방향 연관관계) | 양쪽 클래스가 서로의 존재를 인식 |
| Dependency (의존 관계) | 연관 관계와 같으나 메소드와 사용할 때처럼 짧은 시간동안 유지 |
| Realization (실체화 관계) | 책임 집합 인터페이스와 실제로 실현한 클래스들의 사이를 표현 |
3️⃣ UML의 연관관계
: 한 사물의 객체가 다른 사물의 객체와 연결된 것을 표현
이름 - 관계의 의미를 표현
역할 - 수행하는 역할을 명시
[관련 기출 문제]
4️⃣ UML 의존 관계
연관 관계와 같지만 메소드를 사용할 때와 같이 매우 짧은 시간만 유지
영항을 주는 객체에서 영향을 받는 객체 방향으로 점선 화살표를 연결
5️⃣ UML 일반화 관계
객체 지향에서 상속 관계를 표현
한 클래스가 다른 클래스를 포함하는 상위 개념일 때 사용
6️⃣ UML의 집합 관계
A 객체가 B 객체에 포함된 관계
'부분'을 나타내는 객체를 다른 객체와 공유할 수 있다
7️⃣ UML 포함 관계
부분 객체가 전체 객체에 속하는 강한 집합 연관의 관계를 표현하는 클래스
부분 객체는 다른 객체와 공유가 불가능
8️⃣ UML 실체화 관계
인터페이스와 실제 구현된 일반 클래스 간의 관계로 존재하는 행동에 대한 구현을 표현
한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
(5) Use Case Diagram
1️⃣ Use Case Diagram의 개념
사용자 요구를 기능적 축면에서 기술할 때 사용하는 도구
Actor와 Use Case로 구성된다.
Use Case Diagram 작성 단계 : 액터 식별 - use case 식별 - 관계 정의 - use case 구조화
2️⃣ Use Case Diagram 요소
| 요소 | 설명 |
| 시스템 경계 (System Boundary) | 시스템이 제공해야하는 사례들의 범위 |
| Actor | 서비스를 이용하는 외부 객체 |
| Use Case | 개별적인 서비스 기능 |
| 접속 관계 (communication Association) | 각 유스케이스 사이에 연결되는 관계 |
| 사용 관계 | 여러 유스케이스에서 공통으로 수행해야하는 기능을 모델링하기 위해 사용 |
| 확장 관계 | 확장 기능 & 확장 대상 유스케이스 사이에 형성되는 관계 |
[관련 기출 문제]
8. 소프트웨어 아키텍처
(1) 소프트웨어 아키텍처
1️⃣ ISO/IEC 9126 모델
소프트웨어 품질 특성과 평가를 위한 국제 표준
| 내외부 품질 | 기능성 / 신뢰성 / 사용성 / 효율성 / 유지보수성 / 이식성으로 구분 |
| 사용 품질 | 효과성 / 생산성 / 안정성 / 만족도 |
| 외부 지표 | 실제 운영하는데 있어 만든 지표 |
| 내부지표 | 실제 코딩하는 설계하는데 있어 만든 지표 |
(2) UI 표준을 위한 환경 분석
1️⃣ 사용자 경향 분석
2️⃣ 기능 및 설계 분석
| 분석 | 설명 | 예시 |
| 기능 조작성 분석 | 사용자 편의를 위한 조작에 관한 분석 | ❶ 스크롤바 지원 가능 여부 ❷ 마우스 조작 시 동작 확인 |
| 오류 방지 분석 | 조작 시 오류에 대해 예상 가능한지 확인 | ❶ 의도치 않은 페이지 이동 ❷ 기능 버튼 이름이 사용자 조작과 일치한지 |
| 최소한의 조작으로 업무 처리 가능한 형태 분석 | 작업 흐름에 가장 적합한 레이아웃인지 확인 | ❶ 기능 특성에 맞는 UI인지 확인 ❷ 조작 단계 최소화와 동선 단순 여부 확인 |
| UI의 정보 전달력 확인 | 중요 정보인지, 쉽게 전달 가능한지 등을 확인 | 오류 발생 시 해결 방법 접근에 용이한지 |
3️⃣ 요구사항 요소
데이터 요구 - 기능 요구 - 제품, 서비스 품질 - 제약 사항
4️⃣ 정황 시나리오 작성
❶ 개발하는 서비스의 초기 모양을 상상하는 단계
❷ 사용자 관점에서 작성, 요구사항 정의에서 가장 기초적인 시나리오
❸ 육하원칙을 따르며 사용자가 주로 사용하는 기능 기반으로 작성
[관련 기출 문제]
9. UI 표준 및 지침
(1) UI 표준 지침
1️⃣ UI 분야
표현에 관한 분야
정보 제공과 전달 분야
기능분야
2️⃣ UI 개발 시스템이 가져야할 기능
사용자 입력의 검증
에러 처리와 에러 메시지 처리
도움과 프롬프트 제공
(2)UI 설계
1️⃣ UI 설계 원칙
직관성 : 누구나 쉽게 이해할 수 있도록
유효성 : 사용자 목적을 정확히 달성할 수 있도록 유용하고 효과적
학습성 : 사용자가 쉽게 배우고 익힐 수 있어야 함
유연성 : 사용자 요구를 충분히 수용
2️⃣ UI 설계 지침
| 구분 |
| 사용자 중심 |
| 일관성 |
| 단순성 |
| 가시성 |
| 표준화 |
| 접근성 |
| 결과 예측 가능 |
| 명확성 |
| 오류 발생 해결 |
(3) UI 표준
1️⃣ 한국형 웹 콘텐츠 접근석 지침 2.1 4가지 원칙
인식의 용이성
운용의 용이성
이해의 용이성
견고성
(4) UX(User eXperience)
1️⃣ UX 사용자 경험
사용자가 제품을 사용하면서 느끼고 생각해게 되는 모든 경험을 의미
이를 통해 감성공학이 발생
[관련 기출문제]
10. UI 설계
(1) UI 설계 단계
1️⃣ UI 설계 단계
| 문제 정의 | 시스템의 목적과 해결해야할 문제를 정의 |
| 사용자 모델 정의 | 사용자 특성 결정 |
| 작업분석 | 사용자 특징을 세분화 후 수행해야할 작업 정의 |
| 컴퓨터 오브젝트 및 기능 정의 | 작업 분석을 통해 어떤 사용자 인터페이스에 표현할지 정의 |
| 사용자 인터페이스 정의 | 모니터 마우스 등 상호작용 오브젝트를 통해 시스템 상태 정의 |
| 디자인 평가 | 사용성 공학을 통해 평가 (GOMS, Heuristics 등) |
디자인 평가의 종류
GOMS : 인간이 어떤 행위를 할지 예측하여 문제를 해결하는데 필요한 시간을 평가하기 위한 기법
Heuristics : 어림짐작을 통해 답을 도출하는 방법
2️⃣ UI 상세 설계 단계
UI 메뉴 구조 설계 - 내 / 외부 화면과 폼 설계 - UI 검토 수행
시나리오 작성 원칙
❶ UI 전체적 기능, 작동 방식을 개발자가 쉽게 이해할 수 있도록 구체적으로 작성
❷ 대표 화면 레이아웃 & 하위 기능 정의 - Tree 구조나 Flowchart 표기법 이용
❸ 공통 적용이 가능한 UI 요소와 상호작용을 일반적인 규칙으로 정의
❹ 상호 작용의 흐름 및 순서, 분기, 조건, 루프를 명시
❺ 예외 상황에 관한 사례를 정의 - UI 시나리오 규칙 지정
❻ 기능별 상세 기능 시나리오를 정의하되 UI 일반 규칙 지키기
시나리오 문서 작성 요건
완전성, 일관성, 이해성, 가독성, 수정용이성, 추적용이성
(2) UI 설계 도구
1️⃣ UI 설계에 도움을 주는 도구들
| 종류 | 설명 | 종류 |
| 와이어 프레임 | UI 중심의 화면 레이아웃을 선을 이용하여 개략적으로 작성 | mockup, Valsamiq, 카카오 오븐 |
| 목업 | 실물과 흡사한 정적인 모형 | 카카오오븐, power mockup |
| 프로토타입 | 상호작용이 결합하여 실제 작동하는 모형 | |
| 스토리보드 | 정책, 프로세스, 와이어프레임, 설명이 모두 포함된 설계 문서 |
[관련 기출문제]
(3) UI 프로토타입
1️⃣ UI Prototype
도출된 요구사항을 토대로 프로토타입을 제작하여 시스템과 비교하면서
추가 요구사항을 반영할 수 있다.
툴 : HTML/CSS, AXURE, 카카오 오븐, 네이버 Proto Now
(4) 감성공학
1️⃣ 감성공학
인간이 가지고 있는 감성을 제품 설계를 통해 실현하는 공학적 접근 방법
감성 공학 요소 기술
기초 기술 / 구현 기술 / 응용 기술
2️⃣ 감성 공학 접근 방법
| 구분 | 설명 |
| 1류 (의미 미분법) | 인간의 감각, 감성을 표현하는 어휘를 이용 |
| 2류 | 1류와 기본 틀을 공유, 어휘 수집 전 단계에서 생활양식을 추가 |
| 3류 | 1류의 감성 어휘 대신 감각 척도로 감성을 표출하는 방법 |
3️⃣ HCI (Human Computer Interaction or Interface)
: 인간과 컴퓨터의 상호작용을 연구
[관련 기출문제]
[참고 영상]
[정보처리기사 필기 절대족보] 핵심이론 1과목-1(소프트웨어 설계)