IT Study/SW 공학 및 개발방법론

🧾 기능명세서(FRS)와 기술명세서(SRS)의 차이 및 작성법

cs_bot 2025. 4. 9. 17:58

1. 개요

  • 시스템 개발 과정에서 요구사항을 명확히 문서화하는 것은 품질 확보, 일정 관리, 개발 표준화 측면에서 핵심적인 활동임
  • 특히 기능명세서(FRS, Functional Requirements Specification)와 기술명세서(SRS, Software Requirements Specification)는 서로 다른 관점의 요구사항을 정의함
  • 두 명세서의 차이점과 역할을 명확히 이해하고, 이를 기반으로 한 작성법 숙지가 프로젝트 성공의 핵심 요소임

2. FRS (기능명세서)의 개념 및 목적

  • 사용자 관점에서 시스템이 수행해야 할 기능 중심의 요구사항을 기술한 문서임
  • 주로 업무 담당자(비기술자)와 시스템 분석가 간의 커뮤니케이션 도구 역할 수행
  • 시스템이 무엇을 해야 하는지(What to do)를 명확히 정의함
  • UI 흐름, 처리 조건, 업무 규칙 등을 상세히 정의하여 개발자의 이해를 도모함

✅ 예: “사용자가 로그인 시 아이디와 패스워드를 입력해야 하며, 5회 이상 실패 시 계정 잠금 처리함”

3. SRS (기술명세서)의 개념 및 목적

  • 개발자 관점에서 시스템 구현에 필요한 기술적 요구사항을 구체적으로 정의한 문서임
  • 기능 요구사항을 포함하되, 비기능 요구사항(NFR), 시스템 제약조건, 인터페이스 명세 등을 포함함
  • 소프트웨어가 어떻게 작동하는지를 설명하며, 설계 및 구현의 기준으로 활용됨
  • IEEE 830, ISO/IEC/IEEE 29148 등의 표준 기반으로 구성됨

✅ 예: “로그인 모듈은 Spring Security 기반으로 구현하며, 비밀번호는 SHA-256 해시 후 저장함”

4. FRS와 SRS의 주요 차이점

구분 FRS (기능명세서) SRS (기술명세서)
작성 주체 시스템 분석가, 기획자 개발자, 시스템 설계자
주요 독자 사용자, 기획자 개발자, 테스터, 아키텍트
관점 사용자 관점 (무엇을 해야 하는가) 시스템 관점 (어떻게 구현할 것인가)
포함 내용 기능 흐름, UI 요구사항, 업무 조건 기능/비기능 요구사항, 설계 조건, 기술 스택
작성 시점 요구사항 정의 초기 상세 설계 및 구현 이전
예시 표현 자연어 기반 서술 정형화된 문서 양식, 모델링 포함 가능

5. FRS 작성법

5.1 기본 구성 항목

  1. 목표 및 범위 정의
    • 시스템 또는 모듈이 제공할 주요 기능과 범위를 정의함
  2. 기능 목록(Use Case)
    • 기능 단위로 사용자 행위와 시스템 응답을 기술함
    • 예: 로그인, 조회, 등록, 수정, 삭제 등
  3. 업무 규칙 정의
    • 기능별 조건, 제약사항, 입력/출력 값 정의
    • 예: 필수입력 항목, 금지 조건 등
  4. UI 흐름 및 화면 명세
    • 각 기능의 UI 구성 요소 및 입력 방식 정의
  5. 비즈니스 시나리오
    • 실제 사용자의 업무 흐름과 시나리오 기반 설명 포함

5.2 작성 시 유의사항

  • 사용자가 이해할 수 있는 용어로 작성함
  • 모호하거나 중복되는 표현 지양
  • 실제 운영 상황을 가정한 시나리오 중심 구성 권장

6. SRS 작성법

6.1 기본 구성 항목

  1. 소개 및 시스템 개요
    • 시스템의 목적, 범위, 정의, 약어, 관련 문서 등 포함
  2. 기능 요구사항 (FR)
    • FRS의 기능 내용을 기술 관점에서 재정의
    • 입력, 처리, 출력에 대한 논리적 상세 설계 기반 작성
  3. 비기능 요구사항 (NFR)
    • 성능, 보안, 확장성, 이식성, 가용성 등 기술적 요구사항 포함
  4. 외부 인터페이스 명세
    • UI, 하드웨어, 외부 시스템, 네트워크와의 연계 방식 명세
  5. 데이터 명세
    • 주요 데이터 구조, 테이블 정의, ERD 등 포함 가능
  6. 제약조건 및 설계 가정
    • 사용 언어, 운영체제, DBMS, 프레임워크, 타 시스템 의존성 등 기술

6.2 작성 시 유의사항

  • IEEE 또는 ISO/IEC 표준 문서 구성 기반 작성 권장
  • 명확하고 일관된 용어 사용
  • 테스트 가능성과 추적 가능성 확보 위한 식별자(Requirement ID) 부여 필수

7. FRS와 SRS의 연계

  • FRS를 기반으로 SRS 작성이 이루어지며, 양자 간 일관성 확보가 중요함
  • 요구사항 추적 매트릭스(Requirement Traceability Matrix, RTM)를 활용해 기능별 구현 및 테스트 연계 확보
  • FRS 변경 시 SRS도 연동해 갱신 필요

8. 결론

  • FRS는 사용자의 요구를 이해하고 개발자와의 커뮤니케이션 기반을 제공하는 문서임
  • SRS는 개발을 위한 기술적 기준을 정의하고 명확한 시스템 구현을 위한 청사진 제공함
  • 두 문서는 역할이 다르나, 상호 보완적 관계에 있으며, 개발 초기부터 표준화된 작성 절차 수립이 중요함
  • 정보시스템 개발 시 요구사항 명세 정확도가 프로젝트 성공의 핵심 요소이며, 이에 대한 체계적 이해와 작성 역량이 중요한 자질 중 하나임
댓글수0