요구사항 확인

요구사항이란 무엇일까요

요구사항은 사용자가 시스템에게 바라는 것, 그리고 시스템이 지켜야 할 조건을 말합니다. 개발은 결국 요구사항을 코드로 옮기는 일이라, 요구사항이 틀리면 아무리 잘 만들어도 쓸모없는 시스템이 됩니다. 게다가 요구사항의 잘못은 늦게 발견할수록 고치는 비용이 크게 늘어납니다.

요구사항은 두 종류로 나눠 봅니다. 기능 요구사항은 시스템이 무엇을 해야 하는지입니다. '회원은 비밀번호를 바꿀 수 있어야 한다', '주문하면 확인 메일을 보내야 한다' 같은 것입니다. 비기능 요구사항은 그 기능을 얼마나 잘, 어떤 조건에서 해야 하는지입니다. '검색 결과는 2초 안에 보여야 한다'(성능), '비밀번호는 암호화해서 저장한다'(보안), '24시간 멈추지 않아야 한다'(가용성)처럼 품질이나 제약에 관한 것입니다.

비기능 요구사항은 눈에 잘 띄지 않아 빠뜨리기 쉽지만, 빠뜨리면 다 만든 뒤에 구조를 뒤엎어야 할 수도 있습니다. 그래서 요구사항을 모을 때는 두 종류를 모두 챙기는 습관이 중요합니다.

요구분석기법 ① 요구사항을 모으는 순서

요구사항을 다루는 과정은 크게 네 단계로 나눕니다. 도출(Elicitation)은 요구사항을 찾아내 모으는 단계, 분석(Analysis)은 모은 요구사항을 정리하고 서로 부딪히는 것을 풀어내는 단계, 명세(Specification)는 정리된 요구사항을 문서로 분명하게 적는 단계, 확인(Validation)은 적은 내용이 정말 사용자가 원하는 것인지 검증하는 단계입니다. '도출 → 분석 → 명세 → 확인' 순서를 꼭 기억해 두세요.

도출 단계에서 쓰는 기법은 여러 가지입니다. 관계자를 직접 만나 묻는 인터뷰, 많은 사람에게 한꺼번에 묻는 설문, 여럿이 모여 자유롭게 아이디어를 내는 브레인스토밍, 실제 업무 현장을 지켜보는 관찰, 관계자들이 함께 모여 집중적으로 정리하는 워크숍이 있습니다. 또 간단한 시제품(프로토타입)을 먼저 보여 주고 반응을 듣는 프로토타이핑, 사용자가 시스템으로 무엇을 하는지 시나리오로 정리하는 유스케이스도 자주 씁니다.

사용자는 원하는 것을 말로 정확히 설명하지 못하는 경우가 많습니다. '편하게 해 주세요'라는 말 뒤에 숨은 실제 필요를 찾으려면 한 가지 기법만 쓰기보다 여러 기법을 섞는 것이 좋습니다.

요구분석기법 ② 분석하고, 적고, 확인하기

분석 단계에서는 모은 요구사항을 기능과 비기능으로 나누고(요구사항 분류), 그림이나 모델로 표현해 구조를 이해하며(개념 모델링), 어떤 요구사항을 어느 구성 요소가 맡을지 정합니다(요구사항 할당). 영업팀은 빠른 처리를, 보안팀은 엄격한 확인을 원하는 것처럼 요구사항끼리 부딪히면 관계자와 조율해 우선순위를 정합니다(요구사항 협상).

명세 단계에서는 요구사항을 문서로 적습니다. 적는 방식은 두 가지입니다. 정형 명세는 수학적 기호와 논리를 써서 뜻이 하나로만 읽히게 적는 방식으로, Z, VDM, 페트리넷(Petri-net) 같은 표기가 쓰입니다. 정확하지만 읽고 쓰기 어렵습니다. 비정형 명세는 자연어 문장이나 그림, 표로 적는 방식입니다. 이해하기 쉽지만 읽는 사람마다 뜻을 다르게 받아들일 위험이 있습니다.

확인 단계에서는 명세서를 관계자들이 함께 읽으며 빠진 것이나 틀린 것, 서로 모순되는 것을 찾는 검토(리뷰)를 합니다. 프로토타입을 써 보게 하거나 모델이 앞뒤가 맞는지 검사하는 방법도 씁니다. 확인을 마친 요구사항은 이후 변경을 관리하기 위한 기준(베이스라인)이 됩니다.

UML: 모두가 같은 그림으로 이야기하기

요구사항과 설계를 말로만 주고받으면 사람마다 다르게 이해하기 쉽습니다. UML(Unified Modeling Language)은 소프트웨어를 그림으로 표현하는 표준 언어로, 개발자와 고객, 개발자끼리 같은 그림을 보며 이야기할 수 있게 해 줍니다. 객체지향 분석·설계 방법론을 만든 럼바우, 부치, 야콥슨의 방식을 하나로 합쳐 만들었고, 표준화 컨소시엄인 OMG(Object Management Group)가 관리합니다.

UML은 세 가지 요소로 이뤄집니다. 사물(Things)은 그림에 등장하는 대상, 즉 클래스나 유스케이스 같은 것들입니다. 관계(Relationships)는 사물 사이를 잇는 선입니다. 다이어그램(Diagram)은 사물과 관계를 모아 하나의 관점에서 그린 그림입니다.

관계는 여섯 가지를 구분할 수 있어야 합니다. 연관(Association)은 서로 관련이 있다는 가장 일반적인 연결입니다. 집합(Aggregation)은 전체와 부분 관계이지만 부분이 전체 없이도 따로 존재할 수 있는 경우입니다. 컴퓨터와 마우스처럼 떼어 내도 마우스는 남습니다. 포함(Composition, 합성)은 전체가 사라지면 부분도 함께 사라지는 강한 전체-부분 관계입니다. 일반화(Generalization)는 '동물'과 '강아지'처럼 일반적인 것과 구체적인 것의 관계, 즉 상속입니다. 의존(Dependency)은 한쪽이 다른 쪽을 잠깐 사용하는 짧은 관계로, 상대가 바뀌면 영향을 받습니다. 실체화(Realization)는 인터페이스에 정해진 기능을 클래스가 실제로 구현하는 관계입니다.

UML 다이어그램: 구조와 행위로 나눠 보기

다이어그램은 시스템의 무엇을 보여 주느냐에 따라 두 무리로 나뉩니다. 구조(정적) 다이어그램은 시스템이 어떤 부품으로 이뤄져 있는지, 시간과 상관없이 늘 그 자리에 있는 모습을 보여 줍니다. 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지 다이어그램이 여기에 속합니다.

행위(동적) 다이어그램은 시간이 흐르며 무슨 일이 일어나는지를 보여 줍니다. 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍 다이어그램이 여기에 속합니다. 그중 시퀀스 다이어그램은 객체들이 주고받는 메시지를 시간 순서대로 위에서 아래로 그리고, 커뮤니케이션 다이어그램은 같은 메시지 교환을 객체 사이의 연결 관계 중심으로 그립니다. 상태 다이어그램은 한 객체가 사건에 따라 어떤 상태로 바뀌는지, 활동 다이어그램은 처리 흐름을 순서도처럼 보여 줍니다.

요구사항 단계에서 특히 많이 쓰는 것은 유스케이스 다이어그램입니다. 시스템 밖에서 시스템을 쓰는 사람이나 외부 시스템을 액터(Actor)로, 액터가 시스템으로 하려는 일을 유스케이스로 그립니다. 어떤 유스케이스가 실행될 때 다른 유스케이스가 반드시 함께 실행되면 포함(include), 특정 조건에서만 덧붙여 실행되면 확장(extend) 관계로 표시합니다. 이렇게 관계의 성격을 꺾쇠 기호(<<include>>처럼)로 덧붙여 표시하는 것을 스테레오타입이라고 합니다.

애자일(Agile): 짧게 만들고 자주 확인하기

전통적인 폭포수 모델은 요구사항을 처음에 모두 확정하고 설계, 구현, 시험을 차례로 한 번씩 진행합니다. 계획대로 가면 좋지만, 중간에 요구사항이 바뀌면 되돌아가기 어렵습니다. 애자일은 이 문제를 줄이려고, 동작하는 소프트웨어를 짧은 주기로 조금씩 만들어 고객에게 보여 주고 의견을 받아 다음 주기에 반영하는 방식입니다.

애자일이 중요하게 여기는 가치는 네 가지로 정리됩니다. 정해진 절차나 도구보다 사람과 사람의 소통을, 빈틈없는 문서보다 실제로 동작하는 소프트웨어를, 계약 조건을 따지는 것보다 고객과 함께 일하는 것을, 처음 세운 계획을 지키는 것보다 변화에 맞춰 움직이는 것을 더 중요하게 봅니다. 뒤쪽 것이 필요 없다는 뜻이 아니라, 앞쪽에 더 무게를 둔다는 뜻입니다.

대표적인 애자일 방법론은 XP(eXtreme Programming)와 스크럼(Scrum)입니다. XP는 고객과의 긴밀한 협력과 개발 실천법을 강조하며, 다섯 가지 가치로 의사소통, 단순성, 피드백, 용기, 존중을 듭니다. 두 사람이 한 컴퓨터로 함께 코딩하는 짝 프로그래밍, 테스트를 먼저 작성하는 테스트 주도 개발, 코드를 자주 합치는 지속적 통합, 리팩토링, 작은 단위의 잦은 릴리즈 같은 실천법이 유명합니다.

스크럼은 팀이 일하는 방식을 정해 주는 틀입니다. 제품에 필요한 일의 목록(제품 백로그)을 우선순위대로 관리하는 제품 책임자(PO), 팀이 스크럼 규칙대로 일하도록 돕고 방해 요소를 치우는 스크럼 마스터, 실제로 만드는 개발팀이 있습니다. 보통 2~4주 정도의 짧은 개발 주기를 스프린트라고 하며, 매일 짧게 모여 진행 상황을 나누는 일일 스크럼, 주기 끝에 결과를 보여 주는 스프린트 리뷰, 일하는 방식을 돌아보는 회고를 합니다. 남은 일의 양을 시간에 따라 줄어드는 그래프로 보여 주는 것을 번다운 차트라고 합니다. 이 밖에 작업 흐름을 보드에 시각화하는 칸반, 낭비를 없애는 데 집중하는 린(Lean)도 애자일 계열로 분류됩니다.