소프트웨어 설계 2강. 요구사항 확인과 분석 모델

고객이 그네를 설명하면 개발자는 나무에 매달린 널빤지를 만듭니다. 이 오래된 만화가 요구공학이라는 분야를 통째로 낳았습니다.

풀고 시작

요구사항은 발견되는 것이지 받아 적는 게 아닙니다

소프트웨어 실패 원인을 조사하면 늘 상위권에 요구사항 문제가 올라옵니다. 고객이 거짓말을 해서가 아닙니다. 고객도 자기가 뭘 원하는지 정확히 모르기 때문이죠. 그래서 요구공학(Requirements Engineering)은 받아쓰기가 아니라 발굴 작업에 가깝습니다.

절차는 넷입니다. 도출(elicitation)에서 인터뷰, 설문, 브레인스토밍, 워크숍, 프로토타이핑으로 요구를 끌어냅니다. 분석(analysis)에서 요구끼리 충돌하는 지점을 찾고 우선순위를 매깁니다. 명세(specification)에서 문서로 적습니다. 확인(validation)에서 이 문서가 정말 고객이 원한 것인지, 그리고 만들 수 있는 것인지 검토합니다.

요구사항은 두 종류로 갈립니다. 기능 요구사항은 시스템이 무엇을 하는가입니다. 로그인이 되어야 한다, 주문서를 출력해야 한다 같은 것이죠. 비기능 요구사항은 어떻게 동작해야 하는가입니다. 응답이 2초 안에 와야 한다, 동시 접속 1만 명을 견뎌야 한다, 개인정보는 암호화해야 한다 같은 품질과 제약이 여기 들어갑니다. 시험은 이 둘을 섞어 놓고 고르게 합니다. "몇 초 안에", "몇 명까지", "얼마나 안전하게"가 붙으면 대개 비기능이라고 기억하시면 잘 맞습니다.

구조적 분석의 삼총사

객체지향이 오기 전, 구조적 분석은 시스템을 데이터의 흐름으로 그렸습니다. 그 도구가 셋입니다.

자료 사전 기호는 거의 매회 나옵니다. 등호는 정의, 더하기는 구성, 중괄호는 반복, 대괄호는 선택, 소괄호는 생략 가능, 별표 두 개는 주석입니다. 예컨대 회원 정보를 아이디와 비밀번호와 선택적 전화번호로 정의한다면, 등호로 잇고 더하기로 묶고 전화번호만 소괄호에 넣습니다.

자료 흐름도를 그릴 때는 하향식 분할을 씁니다. 시스템 전체를 원 하나로 그린 배경도(context diagram)에서 출발해 1레벨, 2레벨로 쪼개 갑니다. 이때 상위와 하위의 입출력 흐름이 일치해야 하는데 이를 균형(balancing)이라고 부릅니다.

HIPO(Hierarchy plus Input Process Output)도 자주 나옵니다. 하향식으로 기능을 분해해 도표로 그리는 기법이고, 전체 구조를 보여 주는 가시적 도표, 입력과 처리와 출력을 요약한 총괄 도표, 상세하게 적은 세부적 도표로 구성됩니다.

검토는 세 가지 격식으로 나뉩니다

명세서를 썼으면 확인해야 합니다. 확인 기법은 격식의 정도에 따라 셋으로 나뉩니다.

동료 검토(peer review)는 작성자가 명세 내용을 설명하고 동료들이 듣다가 결함을 찾는 가장 가벼운 방식입니다. 워크스루(walkthrough)는 회의 전에 자료를 미리 배포해 읽고 오게 한 뒤, 짧은 회의에서 결함을 찾습니다. 인스펙션(inspection)은 작성자를 제외한 전문가들이 공식 절차와 체크리스트를 갖고 결함을 찾는 가장 엄격한 방식입니다. 작성자가 빠진다는 것이 인스펙션의 표지입니다.

여기서 확인(validation)과 검증(verification)의 구분도 짚고 갑시다. 검증은 "제품을 올바르게 만들고 있는가", 확인은 "올바른 제품을 만들고 있는가"를 묻습니다. 앞은 명세대로 만들었는지의 문제이고, 뒤는 그 명세가 애초에 고객이 원한 것이었는지의 문제죠.

정리된 요구는 다음 강에서 UML이라는 공통 언어로 옮겨집니다. 그림으로 그려야 비로소 서로 다른 것을 상상하고 있었다는 사실이 드러나거든요.

인출 문제

생각해볼 질문 (정답 없음)

고객이 원한다고 말한 것과 실제로 필요한 것이 다를 때, 개발자는 어느 쪽을 만들어야 할까요. 그 판단의 권한은 누구에게 있어야 공정할까요.

이전: 1강 소프트웨어 생명주기와 개발 방법론 · 다음: 3강 UML과 객체지향 설계