기능적/비기능적 요구사항 - 구조설계서 작성 (1/4)

소프트웨어 설계 문서는 프로그래밍 언어의 문법처럼 반드시 따라야하는 규칙이 있는것은 아니다. 설계 문서의 주 목적은 소프트웨어 시스템을 모르는 사람에게 설명하는 것이므로 어떤 양식을 사용하든 위 목적에 충분히 부합한다면 잘 작성한 설계 문서라고 할 수 있다. 그러나 '충분히 설명할 수 있는 문서'라는 기준은 애매모호하다. 문서를 작성한 사람이나 소프트웨어를 개발한 사람은 전문적인 용어에 익숙하고 객체들 사이의 관계를 명확히 이해하고 있기 때문에 시스템을 추상화한 다이어그램을 이해하는것이 어렵지 않겠지만 시스템을 경험하지 못한 사람에겐 전문적인 용어는 외계어일 것이고 다이어그램은 초현실주의 작품으로 보이게 된다.

설계자와 독자의 간극을 해소하고자 오래 전부터 학계에서는 '어떤 문서가 바람직한 소프트웨어 문서인지'를 놓고 연구를 했었다. 학자들마다 뚜렷한 소신을 가진 탓에 바람직한 소프트웨어 문서의 절대적인 기준(사람의 의견은 매우 주관적이니까)은 내놓지는 못했으나 설계 문서라면 반드시 다뤄야 하는 내용과 이것을 표현하는 방법에 대해선 어느정도 공감대를 이뤘다. 예를 들어 설계문서라면 소프트웨어가 가진 기능을 설명하는 것이 필요하다고 생각해 기능적 요구사항이란 항목을 작성하게 됐고 위 항목은 UML(Unified Modeling Language)을 이용해 작성하는 것이 좋다고 여기게 됐다. 학계에선 기능적 요구사항을 도출하는 방법을 가지고 '내가 옳니 네가 틀리니' 하며 논쟁하고 있지만 산업계에선 어느정도 공감대가 형성된 요소들을 토대로 설계문서를 작성하고 있다.

이기적인 총무는 소프트웨어 설계 문서라면 반드시 포함되어야할 내용을 충실하게 작성하는 것을 목표로 뒀다. 비주얼 스튜디오나 크롬처럼 대형 소프트웨어도 아니기 때문에 특수한 내용이 추가될 일이 없기도 하다. 예전에 과제로 쓰던 설계 문서의 템플릿에서 반드시 필요하다고 생각하는 것들만 더 추려서 작성했다. 크게 네개 항목으로 나뉜다.

1. 시스템 개요

시스템을 처음 접한 사람에게 소프트웨어에 대해서 대략적으로 설명하는 항목이다. 소프트웨어를 만든 목적, 시스템이 동작하는 환경과 주요한 기능에 대해서 다룬다.

이 항목에서는 소프트웨어가 어떤 수익을 줄 수 있는지, 사업적인 측면을 중점으로 서술하기도 하는데 이기적인 총무는 돈을 벌려고 만든 시스템은 아니기 때문에 시스템이 갖고 있는 기능을 충실하게 작성하는 것에 초점을 뒀다.

아래의 그림은 시스템이 동작하는 환경(System Boundary)과 소프트웨어를 개발하는 범위를 다룬 그림이다. 시스템과 상호 통신하는 외부의 주체를 설명하고 이들 각각이 어떤 역할을 하는지 설명한다. 위 그림에서는 Actor1(졸라맨처럼 생긴)로 표현된 모바일 사용자가 이기적인 총무를 사용하는 것을 표현했다. 사용자를 제외하면 시스템이 별도로 외부와 통신하는 일이 없기 때문에 간단하게 표현 할 수 있었다. 만약 정부가 관리하는 서버와 통신한다면 또다른 Actor를 추가해야 할 것이다.

만약 이기적인 총무에서 외부 서버를 만든다면 이것은 Actor로 표현해야할까? 이때 기준은 설계 문서에서 서버에 대해서 다루는지로 판단한다. 설계 문서가 서버에 대해서 요구사항과 개발에 필요한 구조를 도출한다면 이것은 개발해야할 범위중 하나이므로 Actor로 표현해선 안된다. 그렇지 않고 이미 완성된 서버를 사용하는 거라면 Actor로 표현해 밖으로 빼낸다. 네모칸 안은 우리가 개발 할 영역이고 밖에 Actor는 시스템과 통신하는 주체로 파악하면 쉽다.

Use Case는 시스템에서 제공하는 기능을 말한다. 예를들어 Virtual Box라면 'Host PC에서 다른 OS를 Virtual Machine으로 실행 할 수 있다'가 Use Case가 된다. Use Case Diagram에서는 시스템 경계의 네모상자 안에 개발해야할 주요 내용들을 채워 넣는다. 설계자는 시스템에서 필요한 Use Case를 도출하고 네모안에 타원으로 기록한다.

그림에서 보면 여러 개의 Use Case가 <<include>>로 연결된 것을 볼 수 있는데 이는 각각의 Use Case들 끼리 포함되는 관계인 것을 표현한 것이다.

2. 요구사항(Requirement)

요구사항(Requirement)이란 말 그대로 시스템이 갖춰야 할 요건들을 말한다. 정산하기나 모임 관리처럼 시스템이 갖고 있는 기능은 기능적 요구사항이라하고 정산하는 속도, 시스템의 메모리 사용량처럼 기능은 아니나 측정해서 제한을 두고 시스템이 만족하도록 해야 하는 것은 비기능적 요구사항이라 한다.

2.1 기능적 요구사항

Use Case Diagram에서 타원형으로 기록한 Use Case에 대해 세부적으로 작성한다. 각 Use Case 별로 시스템이 어떤 동작을 하게 되는지를 단계별로 설명하고 각 단계별로 발생 할 수 있는 예외 케이스를 정리한다.

원래는 UML로 표현하는데 소규모 소프트웨어는 표로 표현해도 이해하는데 어려움이 없을 것 같아서 위 그림처럼 표현했다. 위 그림은 지출내역을 생성하는 Use Case에 대해서 다룬 기능적 요구사항이다. 기본 동작은 총 9개의 단계로 나뉘며 체크로 표시한 부분은 동작 수행시 발생 가능한 예외 케이스에 대해서 처리 방법을 설명한 것이다. 예외 케이스를 꼼꼼하게 작성 할 수록 개발할 때 편리해진다.

2.2 비기능적 요구사항

비기능적 요구사항은 성능과 가용성처럼 기능적 요구사항에서 다루지 못한 품질적인 요소를 다룬다. 예를 들면 '페이스북 좋아요는 0.5초 이내에 업데이트 돼야 하고 시스템은 24시간 사용이 가능해야 한다'같은 것이다. 반드시 만족해야하는 요구사항이기 때문에 항목들은 객관적으로 측정 할 수 있어야 하고 제약사항은 현실적으로 구현 가능한 수준이어야 한다. 측정 방식이 객관적이지 못하면 SE 부서와 개발자마다 측정 방식이 달라 릴리즈 단계에서 애를 먹을 수 있고 제약 사항이 비현실적이면 애초 구현 불가능한 것을 삽질한 셈이 된다. 

이기적인 총무는 주요 기능이 회계이므로 시스템에서 정산한 금액이 정확해야 한다. 측정하는 방법은 시스템에서 계산하는 금액이 실제로 회계에서 정산한 금액과 동일한지로 판단했고 제약사항은 이 둘이 반드시 동일하도록 했다. 동일하지 않다면 회계 기능은 신뢰할 수 없는것이 되므로 비기능적 요구사항을 충족하지 못한것이 된다. 기능적 요구사항을 개발하면서도 비기능적 요구사항을 생각하면서 개발해야 한다.