SRS 요구사항 명세서가 개발 기준을 만드는 방식

합의가 기록되지 않으면 요구사항은 각자 다른 기준이 된다

소프트웨어 요구사항 명세서(SRS)는 개발할 대상의 목표, 범위, 제약을 문서로 고정하는 장치다. 고객, 개발자, 프로젝트 관리자가 같은 결과물을 상정하도록 만들고, 개발 중에 발생하는 해석 차이를 줄인다. 계약과 분쟁의 맥락에서는 초기 요구를 판단하는 기준이 되기도 한다.

금융회사의 모바일뱅킹 개발에서 고객이 “빠른 시스템”을 요구했다고 하자. 명세가 없다면 개발자는 응답속도 3초를 목표로 삼을 수 있고, 고객은 1초 이내를 기대할 수 있다. SRS에 “모든 트랜잭션은 정상 네트워크 환경에서 1초 이내 응답”이라고 적으면 성능 기대치를 같은 문장으로 맞출 수 있다. 재개발 비용과 분쟁을 막는 기준도 이때 생긴다.

설계 판단은 요구사항에서 시작한다

SRS는 구현 목록이 아니라 설계의 출발점이다. 아키텍처를 정하고, 모듈 간 인터페이스를 나누며, 데이터 구조와 알고리즘을 선택할 때 무엇을 만족해야 하는지 알려준다.

⤢✕

대규모 전자상거래 플랫폼에 “시스템은 초당 5,000건의 트랜잭션을 처리해야 함”이라는 요구사항이 기록돼 있다면, 개발팀은 이를 바탕으로 수평 확장이 가능한 마이크로서비스 아키텍처, 로드 밸런싱, 캐싱 시스템, NoSQL 데이터베이스를 검토하게 된다. 선택의 근거가 개인 경험이나 추측이 아니라 요구사항으로 옮겨간다.

테스트와 인수의 기준을 같은 문서에서 꺼낸다

개발 결과물이 처음 약속한 요구를 충족하는지 확인하려면 검수 기준이 필요하다. SRS는 테스트 계획과 테스트 케이스, QA 활동, 인수 테스트의 출발점이 된다.

⤢✕

의료 정보 시스템의 SRS에 “환자 데이터는 HIPAA 규정을 준수해야 함”이라고 명시했다면, QA팀은 데이터 암호화 적용 여부, 접근 제어 메커니즘, 감사 로그 기능, 데이터 백업 및 복구 프로세스를 검증 항목으로 삼을 수 있다.

기능 요구는 입력부터 예외 처리까지 적는다

SRS에는 시스템 기능뿐 아니라 입력, 처리, 출력, 비기능적 요구사항, 외부 시스템 인터페이스도 담긴다. 로그인 기능처럼 흔한 기능도 정상 흐름과 대체 흐름, 권한과 감사 조건까지 적어야 구현과 검증의 대상이 분명해진다.

기능 ID: F-001
기능명: 사용자 로그인
설명: 등록된 사용자가 시스템에 접근하기 위한 인증 과정
액터: 등록 사용자
선행조건: 사용자가 시스템에 등록되어 있어야 함
후행조건: 인증된 사용자는 권한에 따른 시스템 접근 가능
기본 흐름:
1. 사용자는 이메일과 비밀번호 입력
2. 시스템은 입력된 정보 검증
3. 정보가 유효하면 사용자 인증 및 세션 생성
4. 대시보드 화면으로 리다이렉트
대체 흐름:
2a. 유효하지 않은 정보 입력 시
  2a.1. 오류 메시지 표시
  2a.2. 로그인 화면 유지
비기능적 요구사항:
- 로그인 시도 5회 실패 시 계정 잠금
- 로그인 처리는 2초 이내 완료
- 모든 로그인 시도는 감사 로그에 기록

불명확한 요구사항이 만드는 비용

요구사항을 충분히 정리하지 않으면 범위 크리프가 발생할 수 있다. 불명확한 요구가 지속적인 기능 추가로 이어지고, 잘못 이해한 방향을 수정하느라 재작업이 늘어난다. 목표가 흐려지면 일정이 늦어지고, 검증 기준이 없으면 품질 관리도 어려워진다. 이해관계자가 기대한 결과와 실제 결과물이 달라지는 문제도 뒤따른다.

영국 NHS(National Health Service)의 IT 시스템 개발 프로젝트는 2002-2011년에 진행됐다. 초기 SRS 작성이 부실했고 지속적인 요구사항 변경이 발생했으며, 예산의 3배 이상 비용이 소요돼 £121억에 이른 뒤 프로젝트는 최종 취소됐다.

요구사항 문서는 작성 이후에도 관리 대상이다

좋은 SRS는 모호하지 않아야 하고, 필요한 요구사항을 빠뜨리지 않아야 한다. 서로 충돌하는 요구사항 없이 일관성을 유지하고, 각 요구사항의 출처와 변경 이력을 추적할 수 있어야 한다. 또한 충족 여부를 객관적으로 확인할 방법을 포함해야 한다.

⤢✕

IEEE 830이 제시하는 문서 골격

IEEE 830의 SRS 구조는 소개, 전반적 설명, 세부 요구사항으로 나뉜다.

소개에는 문서의 목적과 범위, 정의 및 약어, 참조 문헌, 개요를 둔다. 전반적 설명에서는 제품 관점과 기능, 사용자 특성, 제약사항, 가정 및 종속성을 다룬다. 세부 요구사항에는 외부 인터페이스 요구사항, 기능적 요구사항, 성능 요구사항, 설계 제약사항, 품질 속성, 기타 요구사항을 기록한다.

SRS 작성은 프로젝트 초기에 시간을 요구하지만, 이후 설계와 테스트, 인수에서 같은 판단 기준을 계속 사용할 수 있게 한다. 요구사항을 문서로 남기는 일은 개발 과정의 효율성과 결과물의 품질을 함께 다루는 작업이다.