UI 문서 - 구조설계서 작성(2/4)

앞 포스트에선 이기적인 총무 소프트웨어를 만들게된 계기(시스템 개요)와 시스템이 제공하는 기능 및 품질(요구사항)에 대해서 소개했다면 지금부터는 앞 문서에서 설명한 소프트웨어가 사용자에게 화면으로 보여지는 형태를 정리한 문서, 즉 User Interface 가이드 문서(이하 UI 문서)를 만들어야 한다.

개발자가 아닌 일반인들도 들어보진 못했어도 한번 쯤은 봤을 것이다. 주로 전자제품을 산 후 사용설명서에서 접해보게 된다. 겨울철이니 가습기를 예로 들어 보자. 가습기 사용 설명서에는 어떤 단추를 눌러야 가습기를 실행 할 수 있으며 분무량을 조절하는 버튼은 어디 있는지 그리고 세척 할때는 어떤 부품들을 분해해서 세척할 수 있는지 설명되어 있다. 아무런 안내가 없으면 사용자가 직관적으로 판단해야하는데 전자제품을 아주 잘 다루는 고객을 제외하면 대부분 사용에 어려움을 겪게 된다. 소프트웨어도 똑같다. 이기적인 총무를 사용하는 사용자가 어떤 버튼을 눌러야 '결제 내역 추가'기능과 '정산하기'기능을 이용 할 수 있는지 소개하는 짤막한 화면이 필요하다. 애플리케이션을 처음 다운로드 받으면 반투명한 소개페이지가 나오는데 그것이 UI 문서로 봐도 무방하다.

이렇게만 생각하면 UI 문서는 오로지 사용자를 위한 문서인것 같으나 꼭 그렇지만은 않다. 개발자는 UI 문서를 통해 요구사항 분석에 있는 기능들이 화면에 어떻게 적용되는지 확인 할 수 있고 이를 통해 시스템의 전반적인 플로우를 파악 하게된다. 여기서 파악한 시스템 플로우는 화면을 관리하는 객체(Android의 경우는 Activity로 보면 된다)를 선정하고 각각의 기능을 명시할 때 중요한 요소가 된다. 또한 문서에 명시된 화면을 구현 할 때 특수한 기능이 필요한 경우가 종종 있는데 이런 요구사항들은 기능적 요구사항에는 명시되어 있지 않는 것이라 개발의 뒷발목을 잡는 경우가 많다. 이런 경우를 방지하기 위해선 개발 기한을 산정할 때 위 문서를 꼼꼼히 읽어보고 화면을 구현할 때 어떤 어려움이 있을지 미리미리 확인하는 것 절차가 필요하다. 이 작업을 통해 화면 기능 요구사항이 추가로 만들어진다. 이 작업이 완료되고 나면 개발자는 도출한 객체와 기존에 있던 기능적 요구사항 및 추가적으로 도출된 화면 요구사항을 꼼꼼히 분석하고 각각의 요소들을 어디에 배치 할 지 시스템 세부 설계 할 수 있게 된다. 

사실 UI문서는 커널이나 미들웨어처럼 콘솔화면 외엔 화면에 보여질게 없는 소프트웨어에선 필요 없기도 하고 Web처럼 html에서 View가 막강한 권한이 있는 경우 크게 중요하진 않기도 하다. 그런데 Android처럼 MVC(Model View Controller)패턴을 이용해서 구현해야 하는 경우 Model과 Controller 의 권한을 부여할 때 중요한 요소가 되고 View에서 할 수 있는 기능이 제한되어 있는 경우(xml로는 여러개 탭도 못만든다)는 매번 직접 기능을 구현해야해 예상치못한 기술적 난제가 되기도 한다. 이런 경우엔 UI 문서를 통해서 미리미리 어려움을 예측하는 것이 중요하다. 실제로 이기적인 총무 앱을 만들 때도 기능적 요구사항을 구현하는 것은 그다지 어렵지 않았으나 미리 계획한 UI문서를 만들때는 많은 어려움을 겪었다.

문서내용은 심플하다. 사용자에게 보여줄 화면들을 쭈욱 나열하고 요구사항에서 명시된 기능을 사용 할 수 있는 인터페이스를 설명하면 된다. 개발자가 이해할 수 있는 정도로만 쓰면 된다. Word 형식 보다는 ppt로 여러 개의 슬라이드로 설명하는 것이 훨씬 간편하고 이해하기 쉽다.

문서를 통해 문서는 총 3개의 탭으로 이뤄져 있으며 각각의 탭은 버튼을 클릭하는 것 뿐만 아니라 손가락 슬라이딩으로 좌우로 이동할 수 있어야 하는 것을 확인했다. 기능적 요구사항에는 없지만 실제로 구현해보려고 하면 생각보다 꽤 오래 걸린다. 위 화면을 구현하려고 꽤 오랜 시간을 구글링 하는데 썼던 것 같다.

위 화면을 통해 기능적 요구사항에 명시한 기능 '결제내역 추가/수정/삭제'이 사용자 화면에 어떻게 적용되는지 확인할 수 있었다.