Day13)정처기 1과목 요구사항 확인·화면 설계 정리 | p.1-2~p.1-55

정처기 공부 기록 · 7월 29일 · 실기 1과목

요구사항 확인 · 화면 설계
p.1-2~p.1-55

오늘의 한 줄 목표

좋은 프로그램은 코딩부터 시작하지 않는다. 무엇을 만들어야 하는지 정확히 확인하고, 사용자가 이해할 화면으로 설계하는 것부터 시작한다.

1. 오늘 공부한 내용

오늘 범위는 1과목의 01. 요구사항 확인과 02. 화면 설계입니다. 현행 시스템을 파악한 뒤 이해관계자의 요구를 수집·분석·검증하고, 그 결과를 사용하기 쉬운 화면(UI)으로 표현하는 흐름을 다룹니다.

1현행 시스템 분석
현재 업무·사용자·장비·소프트웨어·데이터·연계 시스템과 문제점을 조사

2요구사항 확인
기능·비기능 요구사항을 수집하고 우선순위·완전성·일관성을 검증

3분석 모델 확인
유스케이스·클래스·시퀀스·상태 다이어그램으로 요구사항을 구조화

4UI 요구사항·화면 설계
사용자·업무·환경을 고려해 직관적이고 일관된 화면과 흐름을 설계

현행 시스템 분석: 새로 만들기 전에 현재를 안다

현행 시스템 분석은 ‘지금 무엇을 쓰고 있는가’를 파악하는 일입니다. 단순한 장비 목록이 아니라, 업무가 어떻게 흐르고 어디에서 불편·오류·중복이 생기는지까지 확인해야 새 시스템의 요구사항을 제대로 정할 수 있습니다.

업무·사용자 — 누가 어떤 업무를 어떤 순서로 하는지, 수작업·중복 입력·승인 지연 같은 문제는 무엇인지 확인합니다.

기술 환경 — 서버·PC·모바일, 운영체제, DBMS, 네트워크, 보안 장비, 기존 소프트웨어와 버전을 조사합니다.

데이터 — 어떤 데이터가 어디에 저장되는지, 데이터의 양·품질·중복·개인정보 여부와 이행 필요성을 확인합니다.

연계 시스템 — 외부 기관·결제·인증·사내 시스템 등과 어떤 방식으로 데이터를 주고받는지, 인터페이스 제약은 무엇인지 파악합니다.

제약사항 — 예산, 일정, 법·규정, 보안 기준, 기존 장비 활용 여부, 운영 인력과 같은 현실적인 제한도 요구사항의 일부입니다.

초보자식으로 말하면

카페 주문 앱을 새로 만든다고 할 때, 현행 시스템 분석은 ‘현재 주문을 종이로 받는지·POS는 무엇인지·누가 재고를 수정하는지·배달 앱과 연동하는지·피크 시간에 주문이 얼마나 몰리는지’를 알아보는 단계입니다.

요구사항: 사용자가 원하는 것과 시스템이 지켜야 할 것

요구사항은 시스템이 제공해야 할 기능과 만족해야 할 조건을 문서로 명확히 한 것입니다. “좋은 앱으로 만들어 주세요”는 요구사항이 아닙니다. 누가, 어떤 상황에서, 무엇을, 어느 수준으로 할 수 있어야 하는지 구체적으로 표현해야 합니다.

구분	무엇을 말하나?	예시
기능 요구사항	시스템이 무엇을 해야 하는지	사용자는 주문을 등록·취소할 수 있어야 한다.
성능 요구사항	처리 시간·동시 사용자·처리량	동시 1,000명 접속 시 주문 조회는 3초 이내여야 한다.
보안 요구사항	인증, 권한, 개인정보, 감사 기록	관리자 기능은 승인된 계정만 사용할 수 있어야 한다.
품질·운영 요구사항	가용성, 유지보수성, 호환성, 법·규정	장애 발생 후 2시간 안에 서비스를 복구할 수 있어야 한다.

요구사항을 얻고, 분석하고, 검증하는 과정

1) 도출(Elicitation) — 인터뷰, 설문, 워크숍, 관찰, 기존 문서 분석, 프로토타입 등을 통해 이해관계자의 요구를 수집합니다.

2) 분석(Analysis) — 모호한 표현을 구체화하고, 서로 충돌하는 요구를 조정하며, 우선순위·범위·실현 가능성을 판단합니다.

3) 명세(Specification) — 합의한 요구를 문서·모델·화면 정의서 등으로 기록해 개발자와 사용자가 같은 내용을 보게 합니다.

4) 검증(Validation) — 빠진 것은 없는지, 모순은 없는지, 시험 가능한지, 실제 업무 목적에 맞는지 검토합니다.

IIBA의 요구사항 분석 체계도 이해관계자 정보 수집과 결과 확인, 그리고 요구사항의 분석·설계·검증을 분리된 중요한 활동으로 봅니다. 즉, 인터뷰로 들은 말을 그대로 적는 것만으로는 충분하지 않습니다.

좋은 요구사항의 조건

완전성 — 필요한 기능·예외 상황·제약이 빠지지 않아야 합니다.

일관성 — 서로 모순되는 문장이 없어야 합니다. 예를 들어 ‘누구나 수정 가능’과 ‘관리자만 수정 가능’이 함께 있으면 안 됩니다.

명확성 — ‘빠르게’, ‘편리하게’ 같은 말 대신 숫자·조건·대상을 넣어 해석이 하나로 되게 합니다.

검증 가능성 — 개발 후 시험으로 충족 여부를 판단할 수 있어야 합니다.

추적 가능성 — 요구사항이 설계·코드·테스트 케이스의 어디에 반영됐는지 연결해서 확인할 수 있어야 합니다.

변경 가능성 — 요구가 바뀌었을 때 영향 범위를 찾고 이력을 관리할 수 있어야 합니다.

분석 모델: 말로만 설명하지 않고 그림으로 확인하기

분석 모델은 복잡한 요구사항을 표준화된 그림으로 표현하는 방법입니다. 정처기에서는 UML 다이어그램의 역할을 구분하는 문제가 자주 나옵니다.

모델	무엇을 보여 주나?	문제 단서
유스케이스 다이어그램	외부 사용자(액터)와 시스템 기능의 관계	누가 어떤 기능을 사용하는가
클래스 다이어그램	클래스의 속성·연산과 클래스 사이 구조	객체의 정적인 구조
시퀀스 다이어그램	객체들이 시간 순서에 따라 주고받는 메시지	세로축 시간, 메시지 흐름
상태 다이어그램	객체가 사건에 따라 바뀌는 상태와 전이	대기·승인·취소 같은 상태 변화

UI 요구사항과 화면 설계

UI(User Interface)는 사용자가 시스템과 만나는 접점입니다. 화면을 예쁘게 꾸미는 것만이 아니라, 사용자가 실수 없이 목적을 달성하도록 입력·출력·선택·오류 안내·화면 이동을 설계하는 일입니다. 사람 중심 설계는 사용성·접근성을 개발 과정 전반에서 고려하는 접근입니다.

사용자 요구 — 초보자·숙련자·관리자 등 사용자 유형, 자주 하는 업무, 접근성·언어·기기 환경을 확인합니다.

기능·정보 요구 — 화면마다 보여 줄 정보, 입력 항목, 필수값, 계산·검증 규칙, 오류 메시지와 버튼 동작을 정의합니다.

화면 흐름 — 로그인 후 어디로 가는지, 목록에서 상세로 어떻게 들어가는지, 저장·취소 뒤 어디로 돌아가는지를 설계합니다.

프로토타입 — 실제 코딩 전 와이어프레임이나 시안을 보여 주고 피드백을 받으면, 요구사항 오해를 빨리 줄일 수 있습니다.

UI 설계 원칙: ‘직유학연’

직관성 — 처음 보는 사람도 의미와 사용 방법을 쉽게 이해해야 합니다. 익숙한 아이콘·용어·배치를 사용합니다.

유효성 — 사용자의 목적을 정확하고 빠르게 달성하게 해야 합니다. 불필요한 입력·클릭을 줄입니다.

학습성 — 초보자도 쉽게 배우고, 숙련자는 빠르게 사용할 수 있어야 합니다. 일관된 동작과 도움말이 필요합니다.

유연성 — 다양한 사용자·상황·기기에서 사용 가능하고, 사용자의 선택과 요구를 적절히 수용해야 합니다.

화면 설계 체크

같은 기능의 버튼은 같은 위치·색·이름으로 쓰고, 필수 입력값은 분명히 표시하며, 저장 전·후의 결과와 오류 원인을 사용자가 이해할 말로 알려 주는지 확인합니다.

2. 공부하면서 개인적으로 중요하다고 생각하는 용어

① 기능 요구사항과 비기능 요구사항
기능은 ‘무엇을 하는가’, 비기능은 ‘어느 수준과 조건으로 하는가’라는 차이를 확실히 구분해야 한다.

② 요구사항 검증 가능성
개발이 끝난 뒤 통과·실패를 판단할 수 없는 요구는 좋은 요구사항이 아니다. 숫자와 조건으로 써야 한다.

③ 추적 가능성
요구사항 하나가 설계·코드·테스트에 어떻게 이어졌는지 추적할 수 있어야 변경 때 누락을 막을 수 있다.

④ 직관성·유효성·학습성·유연성
UI 설계 원칙은 약어 ‘직유학연’으로 묶어 두면 화면 설계 문제에서 바로 떠올릴 수 있다.

3. 공부하면서 이해하지 못한 용어

① 요구사항 도출과 검증의 차이
도출은 이해관계자에게서 필요한 내용을 끌어내는 일이고, 검증은 그 내용이 빠짐·모순·모호함 없이 실제 목적에 맞는지 확인하는 일이다.

② 유스케이스와 시퀀스 다이어그램의 차이
유스케이스는 사용자와 기능의 큰 관계, 시퀀스는 객체들이 시간 순서대로 주고받는 메시지를 보여 준다.

③ UI와 UX의 차이
UI는 화면·버튼·입력창처럼 사용자가 직접 만나는 접점이고, UX는 그 접점을 쓰는 전체 경험과 만족을 포함하는 더 넓은 개념이다.

4. 오늘 공부한것 소회

요구사항 확인은 개발 전의 행정 절차라고만 생각했는데, 실제로는 프로젝트의 방향을 정하는 가장 중요한 단계였다. 특히 “빠르게”, “편하게” 같은 말은 사람마다 다르게 해석될 수 있다는 점이 기억에 남았다. 화면 설계도 예쁜 디자인보다 사용자가 실수 없이 목적을 달성하게 하는 일이 먼저라는 것을 알았다. 다음에는 UML 다이어그램의 역할을 그림 없이도 말할 수 있게 복습해야겠다.

범위 확인·추가 복습 자료

학습 일정의 p.1-2~p.1-55, 요구사항 확인과 화면 설계 범위를 기준으로 정리했습니다. 판본에 따라 세부 페이지·용어 배열은 달라질 수 있습니다.

IIBA 요구사항 분석·설계 정의 · ISO 9241-210 사람 중심 설계