요구사항 명세서(SRS), 구현과 검증의 기준을 세우는 방법

구현 전에 합의해야 할 기준

소프트웨어 요구사항 명세서(SRS)는 시스템이 수행할 기능과 제약 조건을 상세히 기록한 문서다. 개발자, 사용자, 발주처가 같은 대상을 이해하도록 만들고, 구현의 베이스라인 역할을 한다.

요구사항 오류는 발견 시점이 늦어질수록 수정 비용이 기하급수적으로 증가한다. 그래서 SRS는 개발 범위를 정하고 일정과 비용을 산정하며, 테스트 계획과 계약상 분쟁 해결의 기준으로도 쓰인다.

좋은 요구사항 문서가 갖춰야 할 성질

요구사항은 빠짐없이 작성되어야 한다. 시스템이 수행할 기능과 제약 조건을 누락 없이 포함하는 완전성이 필요하다. 문장도 모호해서는 안 된다. 모든 이해관계자가 같은 의미로 받아들일 수 있어야 한다.

문서 안의 요구사항끼리 충돌하지 않는 일관성, 테스트나 다른 검증 방법으로 확인할 수 있는 검증가능성도 중요하다. 요구사항의 출처와 변경 이력을 따라갈 수 있는 추적성, 변경이 발생했을 때 쉽게 고칠 수 있는 수정용이성까지 갖춰야 문서가 운영 가능한 기준이 된다.

SRS에 담는 범위

일반적인 SRS는 서론에서 목적, 범위, 용어 정의, 참조 문서를 밝히고 시스템 개요와 문서 구성을 설명한다.

전반적 기술에는 제품 관점, 제품 기능, 사용자 특성, 제약사항, 가정 및 의존성이 들어간다. 세부 요구사항은 다음 범위를 다룬다.

• 기능적 요구사항: 시스템이 수행해야 할 기능
• 비기능적 요구사항: 성능, 보안, 사용성, 신뢰성 등
• 인터페이스 요구사항: 사용자, 하드웨어, 소프트웨어, 통신 인터페이스
• 데이터 요구사항: 데이터베이스, 데이터 구조, 데이터 무결성

부록에는 분석 모델, 용어집, 참고 자료를 둘 수 있다.

자연어의 빈틈을 줄이는 정형 명세

정형 명세는 자연어 요구사항이 만드는 모호성을 수학과 논리학 기반 표현으로 줄이는 기법이다. 정확하고 모호하지 않은 표현을 사용할 수 있고, 자동화된 검증·분석 도구를 적용할 수 있다. 요구사항의 일관성과 완전성을 확인하는 데도 유리하다.

대표적인 정형 명세 언어로는 집합론과 1차 술어논리를 기반으로 하는 Z 표기법, 함수형 프로그래밍 접근 방식을 따르는 VDM(Vienna Development Method), 병렬 프로세스를 모델링하는 CSP(Communicating Sequential Processes), 동시성 시스템 모델링에 특화된 Petri Nets가 있다.

항공관제시스템의 실시간 비행 데이터 처리 정확성, 철도신호시스템의 신호 제어 로직, 우주 탐사 임무에 쓰이는 우주선 시스템 소프트웨어, 환자 생명과 직결되는 의료제어시스템 소프트웨어 검증에 활용할 수 있다.

⤢✕

설계가 명세를 만족하는지 확인하는 방식

정형 검증은 수학적·논리적 증명 방법으로 시스템 설계가 요구사항을 만족하는지 증명하는 기법이다. 모델 검증(Model Checking)은 시스템 상태 공간을 탐색해 특정 속성의 만족 여부를 확인한다. 정리 증명(Theorem Proving)은 논리적 공리와 추론 규칙으로 시스템 속성을 증명하며, 타입 검사(Type Checking)는 프로그램의 타입 안전성을 수학적으로 검증한다.

이 방식은 테스트만으로 찾기 어려운 결함을 식별하고 중요한 안전 속성을 보장하며 시스템 신뢰성을 높이는 데 도움이 된다. 반면 높은 전문성이 필요하고, 대규모 시스템에서는 복잡도가 증가한다. 모든 상황을 완벽하게 모델링하기도 어렵다.

⤢✕

작성과 변경 관리를 위한 실무 기준

요구사항 수집과 검토에는 관련 이해관계자가 참여해야 한다. 용어집(Glossary)을 작성해 일관된 용어를 쓰고, 도메인 특화 용어는 별도로 설명한다.

각 요구사항에는 고유 ID를 부여하고, 출처·변경 이력·요구사항 간 의존관계를 기록한다. 우선순위는 MoSCoW 방법(Must, Should, Could, Won't) 등을 이용해 정할 수 있으며, 핵심 요구사항과 선택적 요구사항을 구분한다.

검증 가능한 기준도 요구사항 안에 포함해야 한다. 예를 들어 “사용자 친화적이어야 한다”보다 “초보자가 30분 이내에 핵심 기능 사용법을 익힐 수 있어야 한다”처럼 작성해야 검토와 테스트가 가능하다.

문서 관리와 정형 검증에 쓰이는 도구

문서 작성에는 Microsoft Word, Excel, Google Docs를 사용할 수 있다. 요구사항 관리 도구로는 IBM Rational DOORS, Jama Software, Atlassian Jira + Confluence, ReqView, Modern Requirements가 있다.

정형 명세와 검증에는 Alloy 언어 기반의 Alloy Analyzer, B-Method 기반의 ProB, Promela 언어를 사용하는 SPIN, TLA+ 명세 언어용 TLA+ Toolbox를 활용할 수 있다.

철도 신호 제어 요구사항을 명세로 바꾸면

철도 신호 제어 시스템에서 자연어 요구사항은 다음처럼 쓸 수 있다.

열차가 동일 선로 구간에 진입하는 것을 방지해야 한다.

이를 Z 표기법으로 변환하면 다음과 같다.

SafeOperation ::= ∀ t1, t2: Train; s: Section •
                  t1 ≠ t2 ∧ position(t1) = s ⇒ position(t2) ≠ s

이 명세를 정형 검증 도구로 분석하면 열차 길이를 고려하지 않아 긴 열차가 두 구간에 걸쳐 있을 때 충돌 가능성이 남는 문제를 발견할 수 있다. 열차 속도와 제동 거리를 고려하지 않아 급정거 상황에 대응할 수 없다는 점도 확인 대상이다.

개선된 명세는 점유 구간과 제동 거리를 함께 표현한다.

SafeOperation ::= ∀ t1, t2: Train; s1, s2: Section •
                  t1 ≠ t2 ∧ occupies(t1, s1) ∧ occupies(t2, s2) ⇒ s1 ∩ s2 = ∅

BrakeDistance ::= ∀ t: Train; s: Section •
                 approachingSection(t, s) ⇒
                 distance(t, s) > calculateBrakeDistance(speed(t))

애자일과 운영 환경에서 달라지는 명세 관리

애자일 환경에서는 사용자 스토리와 인수 기준(Acceptance Criteria)을 활용하고, 요구사항을 점진적·반복적으로 상세화한다. 이 과정에서 이해관계자 피드백을 지속적으로 반영한다.

DevOps에서는 요구사항 변경을 지속적으로 통합하고, 자동화된 테스트로 요구사항을 검증한다. 운영 데이터는 요구사항을 개선하는 근거가 된다.

AI 기반 요구사항 분석은 자연어 처리로 요구사항의 모호성을 식별하고, 유사 프로젝트 데이터를 기반으로 누락 요구사항을 예측하며, 요구사항 간 충돌을 자동 감지하는 방향으로 활용될 수 있다.