요구사항과 분석 기법

요구사항(requirement)은 시스템이 해야 할 일과 지켜야 할 조건을 적은 것이다. 요구가 틀리면 아무리 잘 만들어도 쓸모없는 시스템이 되므로, 개발의 첫 단계에서 요구를 찾고 정리하고 검증한다. 시험에서는 기능 vs 비기능 요구사항(non-functional requirement) 구분, 자료 흐름도(data flow diagram)의 구성 요소, HIPO(Hierarchy plus Input-Process-Output, 계층 입력 처리 출력), 요구사항 검토 방법을 묻는다.

기능 요구사항과 비기능 요구사항

기능 요구사항(functional requirement)은 시스템이 무엇을 하는지다. 어떤 입력을 받아 어떤 출력을 내는지, 어떤 데이터를 저장하고 계산하는지가 여기에 든다. 예를 들어 "회원은 비밀번호를 재설정할 수 있다"가 기능 요구사항이다.

비기능 요구사항(non-functional requirement)은 기능을 얼마나 잘, 어떤 제약 아래 하는지다. "검색 결과는 2초 안에 보여야 한다"(성능), "비밀번호는 암호화해 저장한다"(보안)가 여기에 든다. 기능은 다 있어도 느리거나 불안하면 쓸 수 없으므로 비기능 요구도 명시해야 한다. 시험은 비기능 요구를 장비 구성, 성능, 인터페이스, 데이터를 구축하는 데 필요한 요구, 테스트, 보안, 품질 요구의 일곱 갈래로 나누고, 품질 요구 안에 가용성(availability)·정합성·상호 호환성·대응성·이식성·확장성 같은 항목을 둔다. 정합성은 데이터가 서로 모순 없이 맞는 정도, 상호 호환성은 다른 시스템과 정보를 주고받을 수 있는 정도, 대응성은 문제가 생겼을 때 빠르게 반응하는 정도, 이식성은 다른 환경으로 옮겨 쓸 수 있는 정도, 확장성은 규모가 커져도 잘 버티는 정도다.

구분	묻는 질문	예
기능	무엇을 하나	주문, 조회, 계산, 저장
비기능	얼마나 잘·어떤 제약에서	성능, 보안, 가용성, 장비 구성, 인터페이스

요구사항 분석

요구사항 분석(requirement analysis)은 사용자의 요구를 이해하고 문서로 정리하는 활동이다. 요구가 실현 가능한지 따지고 비용과 일정의 제약을 정해 목표를 분명히 한다. 흔히 요구를 모으는 도출, 분석, 명세서로 쓰는 명세, 명세서를 검토하는 확인 순서로 진행한다.

자료 흐름도

자료 흐름도(DFD, Data Flow Diagram)는 데이터가 시스템 안에서 어디서 와서 어떻게 바뀌어 어디로 가는지를 그림으로 나타낸다. 처리 순서나 조건 분기는 그리지 않고 데이터의 흐름만 그리므로, 업무를 처음 파악할 때 전체 모습을 빠르게 볼 수 있다. 구성 요소는 네 가지다.

요소	뜻	기호
프로세스(process)	데이터를 변환하는 처리	원
자료 흐름(data flow)	데이터의 이동	화살표
자료 저장소(data store)	파일·DB 같은 저장 장소	평행한 두 직선
단말(terminator)	시스템 밖의 입력원·출력처	사각형

프로세스는 버블(bubble)이라고도 하고, 단말은 고객이나 외부 기관처럼 시스템 밖의 대상이다.

HIPO

HIPO(Hierarchy plus Input-Process-Output, 계층 입력 처리 출력)는 시스템의 기능을 계층 구조로 나누고, 각 기능의 입력·처리·출력을 표로 적는 문서화 기법이다. 큰 기능을 작은 모듈로 쪼개 내려가는 하향식 방식이라 전체 구조와 세부 기능을 함께 보기 쉽다. 기능을 모듈로 나눈 계층 그림을 HIPO 차트(HIPO chart)라고 부른다.

요구사항 검증 방법

요구사항 명세서에 오류가 남으면 뒤 단계에서 고칠수록 비용이 커진다. 그래서 명세서를 사람이 직접 읽고 결함을 찾는 검토(review)를 한다. 세 가지는 누가 주도하고 언제 읽는지로 구분한다.

방법	진행 방식
동료 검토(peer review)	작성자가 내용을 설명하고 동료들이 들으며 결함을 찾는다
워크스루(walkthrough)	명세서를 미리 나눠 주고 짧은 회의에서 결함을 찾는다
인스펙션(inspection)	작성자를 뺀 전문가들이 명세서를 꼼꼼히 확인한다1

동료 검토는 작성자가 설명하는 쪽이고, 워크스루(walkthrough)는 사전 배포 후 짧게 모여 보는 비공식 검토이며, 인스펙션(inspection)은 역할과 절차를 정해 두고 하는 가장 형식적인 검토다. 이 밖에 시제품을 보여 주는 프로토타이핑(prototyping), 요구마다 테스트 케이스(test case)를 만들어 보는 테스트 설계, 도구로 변경 추적과 일관성을 확인하는 CASE(Computer Aided Software Engineering, 컴퓨터 지원 소프트웨어 공학) 도구 활용도 검증 방법이다.

시험 포인트

• "시스템이 무엇을 하는지" → 기능 요구사항. "성능·보안·가용성·제약" → 비기능 요구사항.
• DFD 4요소 → 프로세스·자료 흐름·자료 저장소·단말. 제어 흐름은 그리지 않는다.
• "입력·처리·출력을 계층 구조로 표현, 하향식" → HIPO.
• "작성자를 제외한 전문가가 확인" → 인스펙션. "미리 배포 후 짧은 회의" → 워크스루. "작성자가 설명" → 동료 검토.

참고

1. 세 정의는 국내 시험 기준이다. 영어권 자료에서는 인스펙션에도 작성자(author)가 역할로 참여하고, IEEE 1028 표준이 정한 워크스루는 보통 작성자가 이끈다. 시험 답안에는 위 표의 구분을 쓴다. ↩︎