개요
오늘은 소프트웨어 개발을 위해 사용자로부터 요구사항(User Requirements)을 도출하는 방법과 분석 절차, 그리고 사용자 인터페이스(UI, User Interface)의 설계 과정에 대해서 알아보도록 하겠습니다.
개인 또는 기업과 같은 고객이 비즈니스 목적을 위해 개발자 또는 IT 회사에 프로그램을 만들어줄 것을 의뢰할 수 있습니다.
이때, 고객으로부터 어떤 프로그램을 제작하길 원하는지 니즈를 반영하고 이에 맞는 현실적은 개발 계획을 수립하는 것은 당연한 과정일 것입니다.
하지만, 고객으로부터 어떤 요청을 받았는지 체계적으로 기록해두지 않으면 향후 개발 과정에서 예기치 못한 문제가 생겼거나,
상황에 따라서는 요청한 내용을 고객과 협의하여 정정해야할 수도 있을 것입니다.
이러한 상황에 가장 큰 도움이 되는 것은 바로 '요구사항 명세서(Requirements Specification)' 입니다.
단어의 뜻에서 충분히 유추하실 수 있듯이 요구사항 명세서는 고객으로부터 요청받은 의뢰 내역에 대하여 최대한 상세히 기록하고,
이를 기반으로 하여 향후 개발 일정을 계획하며 개발이 완료 되었을 때에는 주문대로 프로그램이 잘 만들어졌는지 확인하는 좋은 자료가 됩니다.
따라서, 고객의 요구사항을 잘 기록하고 관리하기 위한 요구사항 도출 프로세스와 분석 기법, 그리고 인터페이스 설계에 대해서 알아보도록 하겠습니다.
요구사항 도출 과정
소프트웨어를 개발하기 전, 고객으로부터 의뢰받은 요구 사항을 기록하는 과정은 아래와 같은 절차를 따릅니다.
| 단계 | 설명 |
| 요구사항 도출 | 소프트웨어가 해결해야할 문제를 이해하고 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법을 결정, 수집된 요구사항을 구체적으로 표현하는 단계 |
| 요구사항 분석 | 도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계 |
| 요구사항 명세 | 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계 |
| 요구사항 확인 및 검증 | 분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)하는 단계 |
사용자 요구사항 도출 기법
다양한 고객의 요구사항을 최대한 수용하고 양질의 프로그램을 만들 수 있도록 아래와 같은 도출 기법을 사용할 수 있습니다.
| 구분 | 설명 |
| 페르소나 정의 | - 잠재적 사용자의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 가상의 사용자 - 향후 개발될 프로그램 사용자가 소프트웨어를 사용하면서 경험할 '사용자 경험(User Experience)'을 예측 및 분석할 수 있음 |
| 콘셉트 모델 정의 |
- 여러 가지 추상적인 콘셉트(=개념)들 사이의 관계를 보여주는 다이어그램을 정의 |
| 사용자 요구사항 정의 | - 리서치 및 페르소나 결과물을 토대로 요구사항을 도출하고, 우선순위를 정하는 과정 |
| UI 컨셉션 | - 정리된 요구사항을 구체화하는 단계로 화면 디자인 단계 전에 대표 화면 설계를 진행하는 단계 |
요구사항 주요 수집 기법
사용자가 잘 정리된 요구사항 명세서를 개발자 또는 개발 회사에 건네주는 경우도 있겠지만,
때로는 시장의 경향성을 분석하여 회사 차원에서 자체적으로 요구사항을 분석해 제품을 출시할 수도 있습니다.
그리고 이러한 과정에서 불특정 다수의 사용자를 만족시킬 수 있는 요구사항은 아래와 같은 기법을 통해 수집할 수 있습니다.
| 수집 기법 | 설명 |
| 델파이 기법 (Delphi Method) | - 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 방법 |
| 롤 플레잉 (Role Playing) |
- 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법 |
| 워크숍 (Workshop) | - 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법 - 소집단 정도의 인원으로 특정 문제나 과제에 대한 새로운 지식, 기술, 아이디어, 방법들을 서로 교환하고 검토하는 연구회 및 세미나 |
| 설문 조사(Survey) |
- 설문지 또는 여론 조사 등을 이용해 간접적으로 정보를 수집하는 방법 |
| 3C 분석 | - 고객(Customer), 경쟁하고 있는 자사(Company)와 경쟁사(Competitor)를 비교하고 분석하여 자사를 어떻게 차별화해서 경쟁에서 이길 것인가를 분석하는 기법 |
| SWOT 분석 |
- 기업의 내부 환경과 외부 환경을 분석하여 Strength(강점), Weakness(약점), Opportunity(기회), Threat(위협) 요인을 규정하고 이를 토대로 경영 전략을 수립하는 방법 |
| 시나리오 플래닝 (Scenario Plannig) | - 불확실성이 높은 상황 변화를 사전에 예측하고 다양한 시나리오를 설계하는 방법으로 불확실성을 제거해 나가려는 경영전략의 한 방법 |
| 사용성 테스트 (Usablility Test) | - 사용자가 직접 제품을 사용하면서 미리 작성된 시나리오에 맞추어 과제를 수행한 후, 질문에 답하도록 하는 테스트 |
요구사항 명세서(Requirements Specification)란?
- 요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말합니다.
- 서비스를 구현하기 위해 다양한 요구사항이 거론되는데, 이를 명확하게 정리해야 할 필요가 있습니다.
- 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트, 기획자, 경영진 등)가 합의한 스펙에 대한 사항을 명세합니다.
요구사항 명세 기법
| 구분 | 설명 |
| 소단위 명세서 | 데이터 흐름도에 나타나 있는 처리 항목을 1~2 페이지 정도의 소규모 분량으로 요약하여 작성하는 논리적 명세서 |
| 자료 사전 | 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전 |
| 요구사항 명세서 | 소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물 |
인터페이스 설계란?
- 시스템의 구조와 시스템들 사이의 관계를 표현하는 과정입니다.
- 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어를 일컫는 말입니다.
- 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어입니다.
- 순서적 연산에 의해 소프트웨어를 실행하는 절차입니다.
사용자 인터페이스(UI, User Interface) 설계 원칙
고객이 사용할 프로그램의 컨트롤러(Controller)가 될 수 있는 인터페이스는 아래와 같은 원칙을 준수해야 합니다.
| 설계 원칙 | 설명 |
| 직관성 (Intutiveness) |
누구나 쉽게 이해하고 쉽게 사용할 수 있어야 한다는 원칙 |
| 유효성 (Efficientcy) |
정확하고 원벽하게 사용자의 목표가 달성될 수 있어야 함 |
| 학습성 (Learnability) |
초보와 숙련자 모두가 쉽게 배우고 사용할 수 있도록 제작 |
| 유연성 (Flexibility) |
사용자와의 인터렉션을 최대한 포용하고 실수를 방지하도록 제작 |
사용자 인터페이스(UI) 구성 요소
사용자 인터페이스는 아래와 같은 요소로 구성될 수 있습니다.
| 구성 요소 | 설명 |
| Input Box | 사용자가 텍스트 데이터를 입력, 수정할 수 있는 상자 |
| Combo Box | 이미 지정된 목록 상자에 내용을 표시하여 선택할 수 있고, 새로운 내용도 입력할 수 있는 상자 |
| List Box | 이미 지정된 목록 상자에 내용을 표시하여 선택할 수 있으나, 새로운 내용을 입력할 수 없음 |
| Check Box | 여러 개의 선택지 중에서 1개 이상의 값을 선택할 수 있는 버튼 |
| Radio Button | 여러 개의 선택지 중에서 단 1개 만을 선택할 수 있는 버튼 |
사용자 인터페이스(UI) 품질 요구사항
사용자 인터페이스를 설계 및 개발할 때에는 아래의 요구사항을 만족할 수 있도록 해야 합니다.
| 품질 요구 사항 | 설명 |
| 신뢰성 (Reliability) |
시스템이 일정한 시간 또는 작동되는 시간 동안 의도하는 기능을 수행함을 보증하는 품질 기준 |
| 성숙성 (Maturity) |
소프트웨어 결함으로 인한 고장을 회피할 수 있는 소프트웨어의 능력 |
| 고장 허용성 (Fault Tolerance) |
소프트웨어 결함이나 인터페이스 오류 시에도 특정 수준 이상의 성능을 유지할 수 있는 능력 |
| 회복성 (Recoverability) |
소프트웨어 고장 발생 시 영향을 받은 데이터를 복구하고 성능의 수준을 다시 확보할 수 있는 능력 |
| 이식성 (Portablility) |
다른 플랫폼(운영체제)에서도 많은 추가 작업 없이 얼마나 쉽게 적용 가능한가에 대한 품질 기준 |
| 적용성 (Adaptability) |
고려된 소프트웨어의 목적을 위해 제공된 수단이나 다른 조치 없이 특정 환경으로 전환되는 능력에 따른 소프트웨어 특성 |
| 설치성 (Installability) |
특정 환경에 소프트웨어를 설치하는 데 필요한 노력의 정도에 따른 특성 |
| 대체성 (Replaceability) |
특정 운용 환경 하에서 동일한 목적 달성을 위해 다른 소프트웨어를 대신 사용할 수 있는 능력 |
UI 시나리오 문서 작성 요건
사용자가 만들어진 소프트웨어의 인터페이스를 통해 경험하게 될 다양한 경우의 수에 대해서 문서로 작성할 수 있습니다.
그리고 이러한 문서를 작성할 때에는 아래의 요건을 고려하여 작성하는 것이 좋습니다.
| 작성 요건 | 설명 |
| 완전성 (Complete) |
- UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 가능한 상세하게 기술 - 시스템 기능보다 사용자의 태스크에 초점을 맞춰 기술 |
| 일관성 (Consistent) |
- 서비스에 대한 목표, 시스템 및 사용자의 요구사항이 일관성이 있어야 하고, 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성 |
| 이해성 (Understandable) |
- 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명해야 하고, 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않도록 함 |
| 가독성 (Readable) |
- 문서를 쉽게 읽을 수 있어야 하고, 표준화된 탬플릿을 작성하여 적용 - 버전의 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 하고, 시각적인 효과를 위한 하이라이팅은 일관성 있게 활용 |
| 추적 용이성 (Traceable) |
- 쉽게 추적이 가능해야 하고, 변경 사항들이 언제 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 함 |
| 수정 용이성 (Modifiable) |
- 쉽게 변경이 가능해야 하고, 수정 또는 개선 사항을 시나리오에 반영하는 데 있어 쉽게 적용할 수 있어야 함 - 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 함 |
인터페이스 요구사항이란?
개발 대상 조직 내/외부 시스템 연동을 통하여 상호작용을 위한 접속 방법, 규칙을 의미합니다.
요구사항의 구성, 내/외부 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려사항을 반영합니다.
인터페이스 요구사항의 분류
| 요구 사항 | 설명 |
| 기능적 요구사항 | 소프트웨어가 내/외부 시스템 간의 연계를 통해 수행될 기능과 관련하여 가져야할 기능적 속성에 대한 요구사항. |
| 비기능적 요구사항 | 기능에 관련되지 않는 사항으로 기능 요구사항을 만족시키는 바탕에서 정상적으로 작동하기 위한 시스템 내/외부의 제약조건을 의미한다. |
인터페이스 요구사항의 분석 절차
- 요구사항 명세서에는 기능적인 요구사항과 비기능적인 요구사항을 명세하고 분류한 뒤 구체화해서 이해 관계자와 공유합니다.
- 소프트웨어 개발 요구사항 목록에서 시스템 인터페이스와 관련된 요구사항을 선별하여 시스템 인터페이스 요구사항 명세를 작성합니다.
- 시스템 인터페이스와 관련된 요구사항, 아키텍처 정의서, 현행 시스템의 대내외 연계 시스템 현황 등 관련 자료를 준비합니다.
- 시스템 인터페이스 요구사항 명세서를 파악하여 기능적/비기능적 요구사항을 구분합니다.
- 시스템 인터페이스 요구 명세서와 요구사항 목록, 기타 관련 자료를 비교 분석하여 내용을 추가, 수정하여 완성도를 높입니다.
- 앞서 정리된 문서를 이해관계자와 공유합니다.
인터페이스 요구사항 검증 방법
| 검증 방법 | 설명 |
| 프로토타이핑 | - 요구사항에 대한 이해를 위하여 기본적인 기능만 시제품으로 제공하여 사용자로부터 피드백을 받는 요구사항 분석 기법이다. |
| 테스트 설계 | - Test Case를 생성하고, 요구사항이 현실적으로 테스트 가능한지 검토한다. |
| CASE(Computer Aided Software Engineering) | - 소프트웨어를 개발하는 시점부터 요구 분석, 설계, 개발, 유지보수에 이르기까지 소프트웨어 생명주기의 전 단계를 연결한다. - 요구사항 변경의 추적과 분석을 통하여 요구사항을 관리한다. |
| 동료 검토 (Peer Review) |
- 명제 작성자가 동료들에게 설명하고 동료들이 결함을 찾는 방법이다. |
| 워크 스루 (Walk Through) |
- 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토 회의를 통해 오류를 - 조기에 검출하는 데 목적을 두는 요구사항 검토 방법이다. - 검토회의 전 명세서 배포 → 짧은 검토 회의 → 결함 발견의 순서로 진행된다. - 사용 사례를 확장하여 명세하거나 설계 다이어그램, 원시 코드, 테스트 케이스 등에 적용할 수 있다. - 복잡한 알고리즘 또는 반복, 실시간 동작, 병행 처리와 같은 기능이나 동작을 이해하려고 할 때 유용하다. - 단순한 테스트 케이스를 이용하여 프로덕트를 수작업으로 수행해보는 것이다. |
| 인스펙션 (Inspection) |
- 소프트웨어 요구, 설계, 원시 코드 등의 작성자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 검토 방법이다. |
UI 화면 설계를 위한 산출물
위와 같은 인터페이스 설계 및 검토 과정을 모두 마치면 아래와 같은 산출물, 즉 문서(Documents)들을 얻어낼 수 있습니다.
| 산출물 | 설명 |
| 와이어프레임 (Wireframe) |
이해 관계자들과의 화면구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해 화면 단위의 레이아웃을 설계하는 작업 |
| 스토리보드 (Storyboard) |
정책, 프로세스, 콘텐츠 구성, 와이어 프레임(UI, UX), 기능 정의, 데이터 베이스 연동 등 서비스 구축을 위한 모든 저옵가 담겨 있는 설계 산출물 |
| 프로토타입 (Prototype) |
정적인 화면으로 설계된 와이어 프레임 또는 스토리보드에 동적 효과를 적용하여 실제 구현된 것처럼 시뮬레이션을 할 수 있는 모형 |
요구사항 명세서 (Requirements Specification)
요구사항 명세서는 요구사항을 분석하여 명확하고 완전하게 기록하는 것을 말합니다. 소프트웨어 시스템이 수행해야 할 모든 기능과 구현상의 제약 조건에 대해 개발자와 관련자(클라이언트,
mklab-co.medium.com