요구사항 명세서

요구사항 명세서란

요구사항 명세서(Requirement Specification, SRS)는 합의된 요구를 추적 가능한 형태로 기록한 문서다. 분석 단계에서 정리된 요구를 누구나 같은 의미로 읽을 수 있는 문장으로 고정해, 설계·구현·검증이 공통의 기준으로 삼게 만드는 것이 목적이다.

말로 오간 요구는 시간이 지나면 해석이 갈리고 합의 내용이 흐려지지만, 명세서로 적힌 요구는 변하지 않는 기준점이 된다. 따라서 SRS는 단순한 기록물이 아니라 발주 측과 수행 측이 무엇을 만들기로 했는지를 확정하는 계약적 성격의 산출물이며, 요구사항 식별·분석·명세·검증·변경 다섯 단계의 결과가 한데 모이는 자리다.

필수 속성: ID와 유형

명세서에 적히는 각 요구는 단순한 문장이 아니라 관리 가능한 항목이어야 한다. 이를 위해 모든 요구에는 고유한 요구 ID를 부여해 다른 문서와 화면, 테스트 항목이 이 ID로 서로를 가리킬 수 있게 한다.

또한 각 요구가 기능 요구인지 비기능 요구인지 유형을 구분해 두어야, 성능·보안·가용성 같은 품질 조건이 화면 기능에 묻혀 사라지지 않는다. ID가 없으면 같은 요구를 매번 긴 문장으로 다시 호출해야 하고, 유형 구분이 없으면 비기능 요구사항이 누락되거나 검증에서 빠진다.

이 두 속성은 명세서를 추적 가능한 문서로 만드는 최소 골격이다.

출처·우선순위·이력

요구 항목에는 ID와 유형 외에도 출처, 우선순위, 변경 이력이 함께 기록되어야 한다. 출처는 그 요구가 어느 이해관계자나 어떤 문서에서 비롯되었는지를 가리켜, 나중에 다툼이 생겼을 때 근거를 되짚게 해 준다.

우선순위는 모든 요구를 동등하게 다룰 수 없는 현실에서 무엇을 먼저 만들고 무엇을 보류할지를 정하는 기준이 되며, 일정이 압박받을 때 협상의 토대가 된다. 변경 이력은 그 요구가 언제 어떻게 바뀌었는지를 남겨, 합의 시점과 현재 상태가 어긋나지 않도록 통제한다.

이 세 속성이 빠지면 명세서는 한 시점의 스냅숏으로 굳어 변경 관리와 연결되지 못한다.

검증 가능한 문장으로

명세서의 가치는 각 요구가 검증 가능한 형태로 적혔는지에 달려 있다. "빠르게 동작한다"거나 "사용하기 편하다" 같은 문장은 사람마다 다르게 해석되어 확인 단계에서 통과와 반려를 오가게 만든다.

같은 요구라도 어떤 조건에서 얼마의 기준을 만족해야 하는지를 측정 가능한 표현으로 적어야, 검증(Validation) 단계에서 합격 여부를 객관적으로 판정할 수 있다. 특히 비기능 요구사항은 모호하게 적히기 쉬운데, 수치와 조건을 명시하지 않으면 기능은 다 만들었으나 품질 기준을 충족하지 못해 검수에서 막힌다.

명세서를 쓸 때는 항상 "이 문장을 어떻게 확인할 것인가"를 함께 떠올려야 한다.

UseCase 모델과의 연결

명세서는 텍스트 요구 목록만으로 완결되지 않고, UseCase 모델 같은 보조 표현과 맞물릴 때 이해도가 높아진다. UseCase는 사용자가 시스템과 주고받는 상호작용의 흐름을 시나리오로 풀어내, 개별 요구 문장만으로는 보이지 않던 절차상의 누락과 예외 경로를 드러낸다.

텍스트 요구가 "무엇을"이라면 UseCase는 "어떤 흐름으로"를 보여 주므로, 두 표현을 요구 ID로 연결해 두면 한쪽에서 빠진 부분을 다른 쪽이 잡아낸다. 다만 표현 방식이 늘어날수록 서로 어긋날 위험도 커지므로, 어느 한쪽을 갱신하면 연결된 다른 쪽도 함께 맞추는 일관성 관리가 필요하다.

명세서가 추적성을 만든다

잘 작성된 명세서는 요구에서 설계, 구현, 검증까지 이어지는 추적의 척추가 된다. 각 요구 ID를 따라가면 그것이 어느 설계 항목으로 펼쳐졌고 어느 테스트로 확인되는지가 끊기지 않고 드러나, 변경이 생겼을 때 영향 범위를 빠르게 가늠할 수 있다.

반대로 명세서가 추적 속성 없이 단순 문장 나열에 그치면, 변경 한 건이 어디까지 파급되는지 알 수 없어 매번 전체를 다시 뒤져야 한다. 명세서는 작성하는 순간의 합의를 기록하는 동시에, 프로젝트 내내 변경을 통제하고 누락을 점검하는 기준으로 살아 움직여야 한다.

이 추적성이 확보될 때 비로소 요구사항 정의가 통제 가능한 상태로 유지된다.