14.14 기능 명세서(Functional Specification)와 비기능 요구사항 정의

1. 기능 명세서의 개념과 구조

기능 명세서(Functional Specification Document, FSD)는 제품 또는 시스템이 수행하여야 할 기능적 행동을 체계적으로 기술한 문서이다. IEEE 830 표준(IEEE Std 830-1998)에 따르면, 소프트웨어 요구사항 명세서(Software Requirements Specification, SRS)는 시스템의 기능적·비기능적 요구사항을 명확하고 완전하며 일관되게 기술하여야 한다.

기능 명세서는 프러덕트 오너와 서비스 기획자가 정의한 제품 요구사항을 개발 팀이 구현할 수 있는 수준의 기술적 명세로 전환하는 교량 문서(Bridge Document)의 기능을 수행한다. 기능 명세서의 표준적 구성 요소는 다음과 같다. 기능의 명칭과 식별자이다. 기능의 목적과 범위이다. 입력(Input)과 출력(Output)의 정의이다. 처리 논리(Processing Logic)의 기술이다. 사용자 인터페이스의 상세이다. 데이터 요구사항이다. 예외 처리(Exception Handling)의 규정이다. 인수 기준(Acceptance Criteria)이다.

1.1 애자일 환경에서의 기능 명세

애자일 개발 환경에서 전통적 기능 명세서의 형태는 변화하였다. 상세한 사전 명세(Big Upfront Specification)보다 사용자 스토리와 인수 기준의 조합, 그리고 백로그 정제(Refinement) 과정에서의 점진적 명확화가 선호된다. 그러나 딥테크 기업에서 안전 관련 시스템, 규제 대상 제품, 또는 하드웨어-소프트웨어 통합 제품의 경우, 공식적 기능 명세서의 작성이 여전히 필수적인 경우가 많다.

프러덕트 오너는 기능 명세의 충실도(Fidelity) 수준을 제품의 특성과 규제 요구에 맞추어 결정하여야 한다. 안전 관련 기능에 대하여는 엄밀한 형식적 명세가, 일반 기능에 대하여는 사용자 스토리 기반의 경량 명세가 적절하다.

2. 비기능 요구사항의 정의

2.1 비기능 요구사항의 개념

비기능 요구사항(Non-functional Requirements, NFR)은 시스템이 ‘무엇을’ 하는가(기능)가 아니라 ‘어떻게’ 하는가(품질 속성)를 규정하는 요구사항이다. Bass, Clements and Kazman(2012)에 따르면, 비기능 요구사항은 시스템의 품질 속성(Quality Attributes)으로 표현되며, 시스템의 아키텍처적 결정에 결정적 영향을 미친다.

2.2 비기능 요구사항의 분류

ISO/IEC 25010(SQuaRE) 표준에 따른 소프트웨어 품질 특성의 분류 체계는 비기능 요구사항의 체계적 정의를 위한 프레임워크를 제공한다.

성능 효율성(Performance Efficiency)은 시간 행동(Time Behaviour), 자원 활용(Resource Utilization), 그리고 용량(Capacity)을 포함한다. 구체적으로 응답 시간(Response Time), 처리량(Throughput), 동시 접속자 수, 그리고 자원 소비량 등이 정량적으로 명시되어야 한다.

신뢰성(Reliability)은 성숙성(Maturity), 가용성(Availability), 결함 허용성(Fault Tolerance), 그리고 복구 가능성(Recoverability)을 포함한다. 가용성 목표(예: 99.99%), 평균 고장 간격(Mean Time Between Failures, MTBF), 그리고 평균 복구 시간(Mean Time To Recovery, MTTR)이 대표적 지표이다.

보안성(Security)은 기밀성(Confidentiality), 무결성(Integrity), 부인 방지(Non-repudiation), 책임 추적성(Accountability), 그리고 인증(Authenticity)을 포함한다.

유지보수성(Maintainability)은 모듈성(Modularity), 재사용성(Reusability), 분석 가능성(Analysability), 수정 가능성(Modifiability), 그리고 시험 가능성(Testability)을 포함한다.

이식성(Portability)은 적응성(Adaptability), 설치 가능성(Installability), 그리고 대체 가능성(Replaceability)을 포함한다.

2.3 비기능 요구사항의 정량화

비기능 요구사항은 가능한 한 정량적으로 명세되어야 한다. “빠르게 응답하여야 한다“는 비기능 요구사항이 아니라 희망 사항에 불과하다. “95번째 백분위수(95th Percentile) 응답 시간이 200밀리초 이내여야 한다“가 측정 가능하고 검증 가능한 비기능 요구사항이다.

Gilb(1988)의 Planguage 접근법은 비기능 요구사항의 정량적 명세를 위한 체계적 프레임워크를 제공한다. 이 접근법에서 각 비기능 요구사항은 척도(Scale), 측정 방법(Meter), 목표값(Goal), 최소 수용 수준(Minimum), 그리고 현재 수준(Baseline)이 명시된다.

3. 딥테크 기업에서의 요구사항 정의 특수성

딥테크 기업에서 기능 및 비기능 요구사항의 정의는 다음과 같은 특수성을 가진다.

안전 무결성 수준(Safety Integrity Level, SIL)의 반영이다. IEC 61508, ISO 26262, DO-178C 등 기능 안전 표준이 적용되는 제품에서는 각 기능의 안전 무결성 수준이 명시되어야 하며, 이에 따른 개발·검증 활동의 수준이 결정된다.

실시간 요구사항의 명세이다. 실시간 시스템에서 시간적 정확성(Timeliness)은 핵심 비기능 요구사항이며, 최악 실행 시간(WCET), 마감 시한(Deadline), 그리고 주기(Period)가 엄밀하게 명시되어야 한다.

하드웨어-소프트웨어 인터페이스 요구사항이다. 하드웨어와 소프트웨어의 인터페이스에 대한 요구사항(전기적 사양, 통신 프로토콜, 타이밍, 데이터 포맷)이 기능 명세에 포함되어야 한다.

환경적 요구사항이다. 딥테크 제품이 운용되는 물리적 환경(온도 범위, 습도, 진동, 전자기 간섭 등)에 대한 요구사항이 비기능 요구사항에 포함되어야 한다.

4. 프러덕트 오너의 역할

기능 및 비기능 요구사항의 정의에서 프러덕트 오너의 역할은 사업적·사용자 관점의 요구를 기술적 명세로 전환하는 과정을 주도하는 것이다. 프러덕트 오너는 기능적 요구의 우선순위를 결정하고, 비기능 요구사항의 목표 수준을 이해관계자 및 기술 팀과 협의하여 설정한다. 특히 비기능 요구사항의 수준 설정은 사업적 가치(높은 성능이 가져오는 비즈니스 가치)와 기술적 비용(높은 성능 달성에 소요되는 개발 비용 및 시간) 사이의 상충(Trade-off)을 관리하는 의사결정이므로, 프러덕트 오너와 기술 리더의 공동 판단이 필수적이다.