소프트웨어 요구사항 명세서(SRS) 작성법

Writing an Effective Software Requirements Specification (SRS)

프로젝트의 나침반이자 약속, SRS

• 이해관계자 간의 의사소통
  고객, 사용자, 개발팀, 테스트팀 등 프로젝트 관련자들이 개발될 시스템에 대해 동일한 이해를 갖도록 돕습니다.
• 개발의 기초 제공
  설계, 구현, 테스트 등 후속 개발 단계의 기준점 역할을 합니다.
• 변경 관리의 기준
  프로젝트 진행 중 발생하는 요구사항 변경을 추적하고 관리하는 근거가 됩니다.
• 검증 및 확인의 기반
  개발된 시스템이 사용자의 요구를 충족하는지 검증(Verification)하고 확인(Validation)하는 기준을 제공합니다.

1. 서론 (Introduction)
   • 목적 (Purpose)
     : SRS 문서 자체의 목적과 이 문서를 읽어야 할 대상을 기술합니다.
   • 범위 (Scope)
     : 개발할 소프트웨어의 이름, 목표, 주요 기능 등을 간략히 설명하고, 시스템이 무엇을 하고 무엇을 하지 않는지를 명확히 합니다.
   • 정의, 약어, 두문자어 (Definitions, Acronyms, and Abbreviations)
     : 문서 내에서 사용되는 전문 용어나 약어들을 정의합니다.
   • 참고 자료 (References)
     : SRS 작성에 참고한 다른 문서(예: 프로젝트 계획서, 관련 표준) 목록을 제시합니다.
   • 개요 (Overview)
     : SRS 문서의 나머지 부분이 어떻게 구성되어 있는지, 각 장의 내용은 무엇인지 간략히 안내합니다.
2. 전반적인 설명 (Overall Description)
   • 제품의 관점 (Product Perspective)
     : 개발할 시스템이 다른 관련 시스템이나 기존 시스템과 어떤 관계를 맺는지 설명합니다. (예: 독립형 제품인지, 더 큰 시스템의 일부인지)
   • 제품 기능 (Product Functions)
     : 시스템이 수행해야 할 주요 기능들을 요약하여 설명합니다. 상세한 기능 요구사항은 다음 장에서 다룹니다.
   • 사용자 특성 (User Characteristics)
     : 시스템을 사용할 주요 사용자 그룹과 각 그룹의 지식 수준, 경험, 기술적 배경 등을 기술합니다.
   • 제약 조건 (Constraints)
     : 개발 과정이나 결과물에 영향을 미치는 제한 사항들을 명시합니다. (예: 특정 하드웨어/소프트웨어 사용, 개발 언어 제한, 예산/일정 제약, 보안 규정 준수 등)
   • 가정 및 의존성 (Assumptions and Dependencies)
     : SRS의 내용이 사실이라고 가정하는 사항이나, 프로젝트 성공에 영향을 미치는 외부 요인들을 기술합니다.
3. 세부 요구사항 (Specific Requirements)

   이 부분이 SRS 문서의 핵심이며, 시스템이 충족해야 할 모든 요구사항을 구체적으로 기술합니다.

   일반적으로 기능 요구사항, 비기능 요구사항, 인터페이스 요구사항 등으로 구분하여 작성합니다. 이 부분은 아래에서 더 자세히 살펴보겠습니다.
4. 부록 (Appendices) 및 색인 (Index)

   (선택 사항)

   본문에 포함하기 어려운 추가 정보(예: 데이터 모델, 상세한 유스케이스 기술서)나 용어 색인 등을 제공할 수 있습니다.

• 주로 "시스템은 ~을 할 수 있어야 한다 (The system shall...)" 또는 "사용자는 ~을 할 수 있다 (The user can...)" 형태로 기술됩니다.
• 각 기능은 명확하고, 모호하지 않으며, 검증 가능하게 작성되어야 합니다.

• "사용자는 아이디와 비밀번호를 사용하여 시스템에 로그인할 수 있어야 한다."
• "시스템은 도서명, 저자, 출판사 키워드를 사용하여 도서 검색 기능을 제공해야 한다."
• "관리자는 새로운 사용자 계정을 생성하고 기존 사용자 정보를 수정/삭제할 수 있어야 한다."
• "상품 주문 시, 시스템은 재고를 확인하고 사용자에게 재고 부족 알림을 보내야 한다."

• 사용자 관점에서 필요한 기능을 식별합니다. (유스케이스 분석이 도움이 됩니다.)
• 각 기능에 대해 입력, 처리 과정, 출력, 그리고 예외 상황 등을 구체적으로 명시합니다.
• "FR-001: 사용자 로그인"과 같이 각 요구사항에 고유한 식별자를 부여하여 추적 및 관리를 용이하게 합니다.

• 성능 (Performance)
  :
  "시스템은 일반적인 조건에서 사용자 요청에 대해 2초 이내에 응답해야 한다."
  "시스템은 동시에 1,000명의 사용자를 지원할 수 있어야 한다."
• 사용성 (Usability)
  :
  "시스템은 처음 사용하는 사용자도 10분 이내에 기본 기능을 익힐 수 있도록 직관적인 UI를 제공해야 한다."
  "모든 기능은 키보드만으로도 접근 가능해야 한다."
• 신뢰성 (Reliability)
  :
  "시스템은 연간 99.9%의 가용성을 보장해야 한다 (연간 다운타임 8.76시간 이내)."
  "시스템 오류 발생 시, 5분 이내에 자동으로 복구되어야 한다."
• 보안 (Security)
  :
  "모든 사용자 비밀번호는 암호화되어 저장되어야 한다."
  "시스템은 SQL 인젝션 및 XSS 공격으로부터 안전해야 한다."
• 유지보수성 (Maintainability)
  :
  "코드는 사내 코딩 표준을 준수해야 하며, 주요 모듈은 주석 처리되어야 한다."
  "새로운 결제 모듈 추가 시 기존 결제 시스템에 영향을 주지 않아야 한다."
• 이식성 (Portability)
  :
  "시스템은 Windows 및 Linux 운영체제에서 모두 동작해야 한다."

• 명확성 (Clear) 및 비모호성 (Unambiguous)
  모든 요구사항은 하나의 의미로만 해석될 수 있도록 명확하게 작성되어야 합니다. 주관적인 표현이나 애매한 용어 사용을 피해야 합니다.
  • 나쁜 예: "시스템은 사용자 친화적이어야 한다." (모호함)
  • 좋은 예: "시스템은 주요 기능에 대해 3번 이하의 클릭으로 접근 가능해야 한다." (구체적)
• 완전성 (Complete)
  시스템이 수행해야 할 모든 기능, 성능, 제약 조건 등이 빠짐없이 기술되어야 합니다.
  "나중에 정함(To Be Determined, TBD)"과 같은 부분은 최소화해야 합니다.
• 일관성 (Consistent)
  문서 내의 요구사항들이 서로 모순되거나 충돌하지 않아야 합니다.
  용어나 표현 방식도 일관되게 사용해야 합니다.
• 정확성 (Correct)
  모든 요구사항은 고객이나 사용자가 실제로 원하는 바를 정확하게 반영해야 합니다.
• 검증 가능성 (Verifiable / Testable)
  각 요구사항은 테스트나 분석을 통해 시스템이 해당 요구사항을 만족하는지 여부를 확인할 수 있도록 작성되어야 합니다.
  측정 불가능한 요구사항은 피해야 합니다.
• 추적 가능성 (Traceable)
  각 요구사항은 고유 식별자를 가져야 하며, 설계 문서, 코드, 테스트 케이스 등과 연결되어 변경 이력을 추적할 수 있어야 합니다.
• 수정 용이성 (Modifiable)
  요구사항은 변경될 수 있음을 염두에 두고, 변경이 발생했을 때 쉽게 수정하고 관리할 수 있도록 구조화되어야 합니다.
• 우선순위 부여 (Prioritized)
  모든 요구사항이 동일한 중요도를 갖지는 않습니다.
  MoSCoW (Must have, Should have, Could have, Won't have) 기법 등을 사용하여 각 요구사항의 우선순위를 명시하면 한정된 자원 내에서 효율적인 개발 계획을 세우는 데 도움이 됩니다.

다음 시간에는 요구사항을 분석하는 다양한 기법들, 예를 들어 정형/비정형 분석, 인터뷰, 워크숍 등에 대해 자세히 알아보겠습니다.

• IEEE 830-1998 - IEEE Recommended Practice for Software Requirements Specifications↗ (영문, IEEE 표준 SRS 가이드라인 - 유료 문서일 수 있음, 요약본이나 해설 자료 검색 필요)
• Software requirements specification - Wikipedia↗ (영문, 위키피디아의 SRS 설명)
• How to Write a Software Requirements Specification (SRS Document) - Perforce↗ (영문, SRS 작성 방법 상세 가이드)