본문으로 건너뛰기

요구사항 명세서 작성 가이드

Template​

ID 체계​

요구사항 설명 작성 수준​

적절한 수준 (권장):

  • 누가(액터) + 무엇을(행위) + 핵심 비즈니스 로직
  • 중요한 비즈니스 정보 포함
  • UI/구현 상세는 제외

좋은 예:

  • ✅ "운영자가 아웃바운드 콜을 완료 상태로 변경할 수 있다. 완료 시 완료 사유와 메모를 기록한다."
  • ✅ "시스템은 매일 자정에 미완료 콜 목록을 조회하여 알림을 발송한다."
  • ✅ "사용자가 콜 메모를 작성할 수 있다. 메모는 최대 500자까지 입력 가능하다."

나쁜 예:

  • ❌ "사용자가 콜을 완료할 수 있다" (너무 간단, 비즈니스 로직 없음)
  • ❌ "사용자가 콜 상세 화면(/calls/:id)에서 '완료' 버튼을 클릭하면 CompleteCallModal이 나타나고..." (너무 상세, 구현 포함)
  • ❌ "PUT /api/calls/:id/complete를 호출하여 call.status를 'COMPLETED'로..." (구현 수준)

기능 그룹 분류 방법​

업무 흐름 중심으로 분류:

기능을 사용자의 업무 프로세스 순서대로 그룹화

예시 - 아웃바운드 콜 관리:

  • 1.1 콜 생성 및 스케줄링
  • 1.2 콜 실행 및 처리
  • 1.3 콜 결과 관리 및 분석

분류 시 고려사항:

  • Aggregate 경계가 아닌 업무 흐름 기준
  • 사용자가 이해하기 쉬운 순서

비기능 요구사항 작성 시점​

비기능 요구사항 섹션은 Optional

작성이 필요한 경우:

  • 명시적인 성능 기준이 있을 때 (예: 응답시간 1초 이내)
  • 특정 보안 요구사항이 있을 때 (예: 데이터 암호화, 접근 로그)
  • 가용성, 확장성 등 명확한 기준이 있을 때

작성하지 않아도 되는 경우:

  • 일반적인 웹 애플리케이션 수준의 성능이면 충분한 경우
  • 제약사항으로 표현 가능한 경우

제약사항 카테고리 구분​

제약사항은 3가지 카테고리로 분류:

1. 권한 제약 (CR-001~099)

  • 누가 무엇을 할 수 있는지에 대한 제약
  • 예: "운영자만 콜을 완료 처리할 수 있다"
  • 예: "본인이 작성한 메모만 수정할 수 있다"

2. 데이터 제약 (CR-101~199)

  • 데이터 처리 방식에 대한 제약
  • 예: "소프트 삭제만 허용한다"
  • 예: "개인정보는 암호화하여 저장한다"
  • 예: "데이터는 최대 3년간 보관한다"

3. 시스템 제약 (CR-201~299)

  • 시스템 동작 방식에 대한 제약
  • 예: "배치 처리는 매일 자정에 실행된다"
  • 예: "동시 접속자는 최대 100명으로 제한한다"

가정사항 vs 제약사항 구분​

제약사항 (Constraint):

  • 확정된 규칙이나 제한
  • "~해야 한다", "~만 가능하다"
  • 예: "사용자는 한 번에 하나의 콜만 처리한다"
  • 예: "데이터는 최대 3년간 보관한다"

가정사항 (Assumption):

  • 불확실하지만 설계의 전제로 두는 사항
  • "~일 것이다", "~가 필요할 수 있다"
  • 향후 실제 요구사항으로 전환될 가능성
  • 예: "사용자는 국제화/지역화가 필요할 것이다"
  • 예: "향후 모바일 앱 지원이 필요할 수 있다"

판단 기준:

  • 지금 당장 구현해야 하는가? → 제약사항
  • 미래에 필요할 수도 있는가? → 가정사항
  • 확정된 정책/규칙인가? → 제약사항
  • 예상/추정/가능성인가? → 가정사항