: Agentic Programming을 위한 Software Requirements의 핵심 파악**
Functional Requirements (기능 요구사항)
“시스템이 무엇을 해야 하는가?”
Non-Functional Requirements (비기능 요구사항)
“시스템이 얼마나 잘 수행해야 하는가?” (성능/보안/비용)
<aside> ✅
예시: 쇼핑몰 서비스 요구사항 (단순화된 SRS 양식)
Functional Requirements
| ID | 요구사항 설명 |
|---|---|
| FR-01 | 시스템은 사용자가 이메일과 비밀번호로 회원가입할 수 있도록 해야 한다. |
| FR-02 | 시스템은 사용자가 로그인하고 세션을 유지할 수 있도록 해야 한다. |
| FR-03 | 시스템은 카테고리별 상품 목록을 표시해야 한다. |
| FR-04 | 시스템은 상세 상품 정보를 조회할 수 있도록 해야 한다. |
| FR-05 | 시스템은 사용자가 상품을 장바구니에 담을 수 있도록 해야 한다. |
| FR-06 | 시스템은 장바구니 내 수량 조절 기능을 제공해야 한다. |
| FR-07 | 시스템은 결제 인터페이스를 통해 주문을 완료할 수 있도록 해야 한다. |
| FR-08 | 시스템은 사용자가 과거 주문 내역을 조회할 수 있도록 해야 한다. |
| FR-09 | 시스템은 관리자가 상품을 생성, 수정, 삭제할 수 있도록 해야 한다. |
| FR-10 | 시스템은 관리자가 주문 상태를 변경할 수 있도록 해야 한다. |
Non-Functional Requirements
| ID | 요구사항 설명 |
|---|---|
| NFR-01 | 시스템은 정상 부하* 시 사용자 요청에 1초 이내로 응답해야 한다. |
| NFR-02 | 시스템은 최소 1,000명의 동시 사용자 접속을 지원해야 한다. |
| NFR-03 | 모든 사용자 비밀번호는 단방향 암호화 방식으로 저장해야 한다. |
| NFR-04 | 시스템은 연중무휴 24/7 가용성을 유지하며 99.9% 이상의 업타임을 보장해야 한다. |
| NFR-05 | 모든 트랜잭션은 매 시간마다 백업되며 1시간 내 복구가 가능해야 한다. |
| NFR-06 | 시스템은 주요 브라우저(Chrome, Edge, Safari, Firefox)를 지원해야 한다. |
| NFR-07 | UI는 색상 대비와 내비게이션에서 WCAG 2.1 접근성 기준을 충족해야 한다. |
*정상부하 : CPU 00%, Network 00% 등
</aside>
SRS (Software Requirements Specification) : 글로벌 표준 양식 확인무료 다운로드 링크
공식 표준 사이트들의 비싼 유료 다운로드 *~~바가지 요금~~*
https://www.iso.org/standard/72089.html
https://standards.ieee.org/ieee/29148/6937/
| 항목 | IEEE 830-1998 | ISO/IEC/IEEE 29148:2018 |
|---|---|---|
| 발행 연도 | 1998 | 2011 (2018 개정) |
| 현재 상태 | 폐기됨 | 사용 중 |
| 범위 | SRS 문서 구조 정의 | 시스템·소프트웨어 요구사항 엔지니어링 전 라이프사이클 포괄 |
| 주 목적 | SRS 문서 포맷 표준화 | 요구사항 도출, 분석, 명세, 검증, 관리 통합 가이드 |
| 요구사항 ID | 필수 아님 | 모든 요구사항에 ID 부여 필수 |
| 추적성(Traceability) | 명시 없음 | 요구사항–설계–검증 간 명시적 추적성 요구 |
| 검증 방법 | 포괄적 · 짧음 | Inspection/Test/Analysis/Demonstration 명확 정의 |
| 승인 기준(Acceptance Criteria) | 없음 | 각 요구사항마다 반드시 포함 |
| 이해관계자 정의 | 별도 섹션 없음 | 역할과 책임 명확 정의 |
| 비기능 요구사항 | 제한적 언급 | 성능, 보안, 신뢰성 등 품질 속성 상세 정의 |
| 문서 구조 | 서론, 전체 설명, 구체 요구사항, 부록 | 기획 → 도출 → 명세 → 검증 → 관리 단계별 구성 |
| 품질 기준 | 기초적 수준 | 요구사항 품질의 상세 기준 제공 |
| 산업 채택도 | 학계/레거시 위주 | 글로벌 프로젝트, 공공 조달, CMMI, ISO 기반 조직에서 광범위 사용 |
→ 실제 표준 양식은 문서화 구조가 매우 정교하고 방대함
⇒ 시작할 때는 적절한 크기의 템플릿으로 필요한 만큼 점진적으로 확장해 나가는 것이 중요함!
<aside> ✅
ISO/IEC/IEEE 29148:2018) SRS 양식에 맞춰가기*딸깍용 샘플이 아닙니다. 일부 편집된 실전 자료이므로, 구조 파악용(메타프롬프팅 가능)으로만 사용해 주세요
</aside>
설계 문서로 프로그램 로직 상세 가이드 하기설계 문서는 SRS에 명시할 수 있는 가장 구체적인 시스템적 요구사항! 설계 문서에는
UseCase,ERD,CLD,Component Diagram,Sequence Diagram등이 있음 AI 에이전트 활용 개발에서는 Sequence Diagram이 매우 효과적!
<aside> ✅
...
**3. 시스템 컨텍스트 및 인터페이스 (System Context and Interfaces)
3.1 클라이언트 애플리케이션
3.2 외부 시스템 연동
3.3 API 개요
3.4 인터랙션 시퀀스 *-> 시퀀스 다이어그램 (핵심 기능, 간결한 버전)*
3.4.1 문서 자동 생성 시퀀스
3.4.2 검증기(Validator) 실행 시퀀스
3.4.3 PMF(Product-Market Fit) 진단 시퀀스
3.4.4 노션/지라(Notion/Jira) 동기화 시퀀스
4. 세부 요구사항 (Specific Requirements)
...
6. 부록 (Appendix)
6.1 API 엔드포인트 목록
6.2 엔티티 및 데이터 모델
6.3 상세 인터랙션 모델 (확장된 시퀀스 다이어그램) *-> 시퀀스 다이어그램 (상세 확장 버전)
...***
</aside>
Program Scenario → Sequence Diagram 변환
Example : 🧭 Simple Payment Process Steps:
기존 예제 (5단계 서술에 충실)
sequenceDiagram
participant Client as 클라이언트
participant APIGW as API Gateway
participant Auth as 인증 서비스
participant Payment as 결제 서비스
participant Provider as 외부 결제 제공자
participant Ledger as 트랜잭션 원장
Client->>APIGW: 1. 결제 요청 전송
%% 2. 인증 단계
APIGW->>Auth: 2. 사용자 토큰 검증 요청
activate Auth
Auth-->>APIGW: 토큰 검증 완료
deactivate Auth
%% 3. 결제 처리 단계
APIGW->>Payment: 3. 결제 처리 요청
activate Payment
Note over Payment: 잔액 확인
Payment->>Provider: 외부 결제 제공자 API 호출
activate Provider
Provider-->>Payment: 결제 결과 수신
deactivate Provider
%% 4. 원장 기록 단계
alt 결제 성공
Payment->>Ledger: 4. 트랜잭션 원장에 결제 결과 기록
activate Ledger
Ledger-->>Payment: 기록 완료
deactivate Ledger
else 결제 실패
Note over Payment: 실패 처리
end
%% 5. 클라이언트 응답 단계
Payment-->>APIGW: 5. 결제 완료 응답
deactivate Payment
APIGW-->>Client: 최종 결제 결과 응답
수업중 진행 (11단계까지 도출)
sequenceDiagram
autonumber
participant Client as 클라이언트
participant Gateway as API Gateway
participant Auth as 인증 서비스 (Auth Service)
participant Payment as 결제 서비스 (Payment Service)
participant External as 외부 결제 제공자 (External API)
participant Ledger as 트랜잭션 원장 (Ledger)
Client->>Gateway: 결제 요청 전송
Gateway->>Auth: 사용자 토큰 검증 요청
Auth-->>Gateway: 검증 완료
Gateway->>Payment: 결제 처리 요청
Payment->>Payment: 잔액 확인 (Internal Check)
Payment->>External: 외부 결제 API 호출
External-->>Payment: 결제 승인 응답
Payment->>Ledger: 결제 결과 기록
Ledger-->>Payment: 기록 완료
Payment-->>Gateway: 결제 완료 응답
Gateway-->>Client: 최종 결제 완료 응답

Exercise : 🧭 Video Streaming Process Steps (Logged-in User)
PRD는 “사람·비즈니스 언어로 적힌 요구사항 집합”
| --- | --- | --- | --- |