Chapter 2-1. 화면 정의서
분석 단계에서 사용자 요구사항 정의서를 작성하였다면 설계 단계에서는 화면 정의서, 테이블 설계서, API 명세서의 작성 방법을 알아보도록 하겠습니다. 구현 단계에서 실제 개발을 하기 위해 필요한 개발자의 실질적이 설계 도면이라고 볼 수 있으므로 꼼꼼하게 체크하여 최대한 구현 가능한 수준으로 설계하는 과정이 필요합니다. 물론 아무리 꼼꼼하게 설계된 설계도면이라 할지라도 실제 구현 단계에서 설계 문서가 수정될 수 있습니다.
소프트웨어 개발 단계
- 분석 단계
- 소프트웨어를 개발하기 위해서 만들려고 하는 것에 대한 분석이 먼저 이루어집니다. 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성함으로써 보다 구체적으로 분석합니다.
- 설계 단계
- 분석이 끝났다면 실제로 구현하기 위해서 올바른 설계를 합니다. 설계 또한 이전에 작성됐던 SRS를 기반으로 하여 범주에 벗어나지 않는 설계를 할 필요가 있습니다. 설계 단계에서는 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성함으로써 보다 구체적으로 설계합니다.
- 구현 단계
- 분석 → 설계의 과정을 통해 실질적인 구현의 준비를 마무리합니다. 구현 단계에서는 실제 개발 작업이 이루어지며 소프트웨어의 모습이 갖춰지는 단계입니다. 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화 합니다.
- 시험 단계
- 구현이 완료되면 전체적인 테스트를 할 필요가 있습니다. 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서를 작성함으로써 보다 구체적으로 시험을 진행합니다. 또한 시험 단계에서 사용자, 운영자를 위한 지침서(매뉴얼)를 작성합니다.
화면 정의서
설계 단계에서 요구되는 모든 문서를 작성해보고 이를 실제 프로젝트를 진행하는 구현 단계에서 참조 자료로 활용해보면 좋겠으나 시간이 부족하다는 점과 실제 개발 업무가 아닌 학습을 위한 프로젝트 과정임을 감안하여 내용을 축소해야 합니다. 하지만 설계 단계에서 작성하는 ‘화면 정의서'는 매우 중요합니다. 그러므로 우리는 ‘화면 정의서'를 작성해 볼 필요가 있습니다.
1. 작성 목적
시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술한다.
NIA(한국정보화진흥원)에서는 화면 정의서의 작성 목적을 위와 같이 정의하고 있습니다. 작성할 부분이 상당히 많은 문서지만 매우 중요한 설계 단계 문서이므로 어떻게 작성하는지 직접 경험해보고 해당 문서를 구현 단계에서 활용하여 개발 할 수 있는 것에 목표를 두면 좋습니다. 이 문서는 실제 수강생들이 부담없이 사용할 수 있는 수준으로 일부 편집하여 커스터마이징 된 문서를 작성하는 방식으로 진행될 예정입니다.
2. 작성 방법
전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술하고, 화면 및 출력으로 구분하여 목록을 작성하며, 화면의 상세 설계 내용을 화면별로 기술한다.
화면을 쉽고 편리하게 그릴 수 있는 툴을 사용하여 예상하는 화면을 그리고 예상 화면을 문서에 삽입 한 후, 화면에 대한 설명을 추가하여 하나의 화면 정의를 합니다. 각 화면에는 화면 아이디를 부여하여 해당 화면을 쉽게 구분할 수 있게 합니다. 또한 화면에서 기능 동작에 대한 정의를 함께 표시합니다. 해당 동작은 앞서 작성한 사용자 요구사항 정의서의 아이디를 부여하여 두 문서가 연관성을 갖게 합니다.
3. 항목 설명
(이해를 돕기위해 문서 양식에 예제 추가)
- 화면 ID : 설계된 화면에 고유값을 부여합니다.
- 화면명 : 알아볼 수 있는 화면에 대한 제목을 부여합니다.
- 화면 유형 : 입력 / 출력 중 알맞은 유형을 선택합니다. 기타 유형이 존재한다면 알맞게 작성합니다.
- 메뉴 경로 : 해당 화면이 서비스의 어디에 위치하는지 설명합니다.
- 화면 개요 : 화면의 간단한 설명을 추가합니다.
- 화면 미리보기 : 와이어 프레임과 같은 화면 설계 툴을 사용하여 작성된 화면 미리보기 이미지를 삽입하고 해당 화면에서 기능을 수행하는 항목을 번호를 매겨 표시합니다.
- 기능 번호 : 화면 미리보기에서 표시된 기능의 번호를 기입합니다.
- 요구사항 아이디 : 해당 기능이 사용자 요구사항 명세서에 기술된 어떤 항목인지를 아이디로 표시합니다.
- API 활용 여부 : 이 기능이 API를 활용하는 기능인지를 구분합니다.
- API 주소 : API 활용 여부가 YES라면 어떤 API를 호출하는지 기입합니다.
- 유효성 체크 : 기능이 동작하는 동안 화면 내에서 필수적으로 사용되어야 할 데이터에 대한 유효성 체크를 합니다. 예) 회원 가입을 할 때 아이디와 비밀번호는 필수로 작성되어야 한다. → 아이디, 비밀번호
Wireframe & Prototype
와이어프레임(wireframe)
와이어프레임은 선(wire)으로 틀(frame)을 잡는다는 뜻으로, 제품 기획 단계에서 페이지를 어떻게 구성할 것인지 구조를 잡기 위한 목적으로 만듭니다.
와이어프레임을 표현할 때의 품질 수준을 전문용어로 피델리티(fidelity)로 표현하며 3가지 레벨이 나눕니다.
1. Low Fidelity Wireframe (Lo-Fi Wireframe)
손으로 빠르게 그린 수준의 와이어프레임을 Lo-Fi 와이어프레임이라고 합니다. 작성하는데 시간이 많이 들지 않아 수정하거나 새로운 의견을 반영하기 쉽습니다. 아이디어를 구체화시키며 큰 그림을 잡을 때 좋습니다.
2. Middle Fidelity Wireframe (Mid-Fi Wireframe)
Lo-Fi 와이어프레임을 그리면서 아이디어가 어느 정도 구체화되고 확정된 후에 보기 좋게 다듬어주면 Mid-Fi 와이어프레임이 됩니다. Mid-Fi 수준에서는 와이어프레임을 봤을 때 해당 페이지가 어떻게 작동하게 될지 예상할 수 있습니다.
3. High Fidelity Wireframe (Hi-Fi Wireframe)
와이어프레임을 완성본에 가깝게 작성한 것을 Hi-Fi 와이어프레임이라고 합니다. 와이어프레임이라기보다는 목업에 가까운 형태이며, 작성하는데 시간도 많이 들고 수정도 어렵기 때문에 와이어프레임을 작성하는 목적과는 맞지 않아 Hi-Fi한 수준까지 만드는 경우는 거의 없습니다.
프로토타입(prototype)
프로토타입은 실제 제품과 거의 흡사하게 구현한 것으로, 페이지 이동과 상호 작용이 가능합니다. 본격적으로 개발에 들어가기 전 단계에 작성하며, UI의 상호 작용을 시뮬레이션하는 것이 목적입니다.
프로토타입 역시 얼마나 최종 결과물과 흡사하게 만들었는지에 따라서 피델리티 레벨이 나뉩니다.
1. Low Fidelity Prototype (Lo-Fi Prototype)
구체적인 내용이 작성되어 있지 않은 상태에서 간단한 상호 작용과 페이지 이동 정도만 테스트해 볼 수 있는 수준의 프로토타입을 Lo-Fi 프로토타입이라고 합니다. User flow 상에서 빠지거나 어색한 기능 혹은 페이지가 없는지 빠르게 검토할 수 있습니다.
2. High Fidelity Prototype (Hi-Fi Prototype)
최종 결과물과 거의 유사한 수준으로 만든 프로토타입을 Hi-Fi 프로토타입이라고 합니다. 이 단계에서는 디자인을 거의 확정하게 되며, 실제 제품과 거의 다름없이 작동하기 때문에 사용성 테스트가 가능합니다. 테스트를 통해 개발 비용이 들어가기 이전에 UI/UX 관련 문제를 발견하고 수정할 수 있어 비용 절감 효과를 볼 수 있습니다.
3. Middle Fidelity Prototype (Mid-Fi Prototype)
Hi-Fi 프로토타입처럼 완성도가 높지는 않지만, Lo-Fi 프로토타입보다는 최종 결과물에 가까운 프로토타입을 Mid-Fi 프로토타입이라고 합니다. 사용성 테스트를 하기 위해서는 적어도 Mid-Fi 수준의 프로토타입을 작성해 주는 것이 좋습니다.
차이점 정리
프로토타입만 잘 작성해도 화면 구성과 사용자 흐름(user flow)을 개선함으로써 좋은 UI, 좋은 UX를 디자인할 수 있어 최종 결과물의 완성도를 향상할 수 있습니다. 또한 프로젝트 기획 내용을 직관적으로 전달할 수 있어 내부 인원은 물론 프로젝트 외부 인원과의 소통에도 큰 도움이 됩니다. 후에 여러분이 직접 프로젝트를 기획부터 시작할 일이 생긴다면, 기획 단계에서 완성도 있는 프로토타입을 만드는 것을 목표해 보시기 바랍니다.
Chapter 2-2. 테이블 명세서
소프트웨어 개발 단계
- 분석 단계
- 소프트웨어를 개발하기 위해서 만들려고 하는 것에 대한 분석이 먼저 이루어집니다. 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성함으로써 보다 구체적으로 분석합니다.
- 설계 단계
- 분석이 끝났다면 실제로 구현하기 위해서 올바른 설계를 합니다. 설계 또한 이전에 작성됐던 SRS를 기반으로 하여 범주에 벗어나지 않는 설계를 할 필요가 있습니다. 설계 단계에서는 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성함으로써 보다 구체적으로 설계합니다.
- 구현 단계
- 분석 → 설계의 과정을 통해 실질적인 구현의 준비를 마무리합니다. 구현 단계에서는 실제 개발 작업이 이루어지며 소프트웨어의 모습이 갖춰지는 단계입니다. 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화 합니다.
- 시험 단계
- 구현이 완료되면 전체적인 테스트를 할 필요가 있습니다. 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서를 작성함으로써 보다 구체적으로 시험을 진행합니다. 또한 시험 단계에서 사용자, 운영자를 위한 지침서(매뉴얼)를 작성합니다.
테이블 명세서
설계 단계에서 요구되는 모든 문서를 작성해보고 이를 실제 프로젝트를 진행하는 구현 단계에서 참조 자료로 활용해보면 좋겠으나 시간이 부족하다는 점과 실제 개발 업무가 아닌 학습을 위한 프로젝트 과정임을 감안하여 내용을 축소해야 합니다. 하지만 설계 단계에서 작성하는 ‘테이블 명세서'는 매우 중요합니다. 그러므로 우리는 ‘테이블 명세서'를 작성해 볼 필요가 있습니다.
1. 작성 목적
최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술한다.
NIA(한국정보화진흥원)에서는 테이블 명세서의 작성 목적을 위와 같이 정의하고 있습니다. 작성할 부분이 상당히 많은 문서지만 매우 중요한 설계 단계 문서이므로 어떻게 작성하는지 직접 경험해보고 해당 문서를 구현 단계에서 활용하여 개발 할 수 있는 것에 목표를 두면 좋습니다. 이 문서는 실제 수강생들이 부담없이 사용할 수 있는 수준으로 일부 편집하여 커스터마이징 된 문서를 작성하는 방식으로 진행될 예정입니다.
2. 작성 방법
부서에서 운영하는 데이터베이스 목록을 작성하고, 데이터베이스의 물리적 상세내용을 기술한다.
서비스에서 사용될 테이블을 미리 설계하고 그 내용을 문서화 합니다. 구현 단계에서 개발이 진행됨에 따라 테이블 설계서의 내용이 일부 변경될 수 있는 점은 감안하고 작성합니다. 다른 문서에 비해 상대적으로 작성하기 쉬울 수 있습니다. 데이터베이스를 개발 학습시에 많이 다뤄 보았고 개발시 머릿속으로 데이터의 입출력에 대한 고민을 많이 해 보았기 때문입니다. 학습이나 개발했을 때를 떠올리며 어떤 테이블을 설계하고 각 테이블이 어떤 관계를 이루는지에 대해 고민하여 설계한다면 많은 도움이 될 수 있습니다.
3. 항목 설명
(이해를 돕기위해 문서 양식에 예제 추가)
- 데이터베이스 명 : 데이터베이스 명칭을 기입합니다.
- 테이블 명 : 테이블 명칭을 기입합니다.
- 요구사항 ID : 테이블이 사용되는 요구사항 정의서의 ID를 맵핑합니다.
- 테이블 설명 : 테이블의 목적 및 역할을 간략하게 기술합니다.
- 컬럼명 : 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술합니다.
- 컬럼 ID : 테이블 컬럼 ID를 기술합니다.
- 타입 및 길이 : 컬럼의 타입과 최대 허용 길이를 기술합니다.
- NOT NULL : 필수항목 여부를 나타냅니다.
- PK (Primary Key) : 주키 여부를 나타냅니다.
- FK (Foreign Key) : 외래키를 의미합니다.
- INX (Index) : 인덱스를 의미합니다.
- 기본값 : 속성의 기본값이 있는 경우에 그 값을 기술합니다.
- 제약조건 : 속성의 특이한 제약조건이 있는 경우 기술합니다.
