thanhnvandClaude Opus 4.8
664bd1f00c
Physically move the pure-code subtrees out of .specify into the package, leaving compat symlinks at the old .specify/<dir> paths so every existing reference (internal CASAN_HARNESS_ROOT + external CI/docker/mjs) keeps resolving. Runtime state stays put. Moved (git mv): scripts/ tests/ security/ templates/ config/ governance/ memory/ .specify/<dir> -> packages/casan-harness/<dir> (+ .specify/<dir> symlink) Stays in .specify (state/governance/domain, handled later): logs/ agentops/ level5/ init-options.json traceability-map.json Python `.resolve()` self-location followed the compat symlink into packages and lost the app root; generate-casan-demo-context.py, generate-agentops-dashboard.py and dashboard-server.py now walk UP for the `.specify` state marker instead of a fixed parent depth (fixes "missing trace files" in run-casan4). Full gate: PASS=64 FAIL=0 SKIP=3 (CASAN_CI_STEP_TIMEOUT_SEC=1200 — track-a ~450s runs close to the 600s default and can tip over under load; this is timing variance, not a regression — it passed cleanly with headroom). Runtime log/audit artifacts kept unstaged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
249 lines
7.5 KiB
Markdown
249 lines
7.5 KiB
Markdown
# Software Requirements Specification — [PROJECT_NAME]
|
|
|
|
**Project Code:** [PROJECT_CODE] | **Doc Code:** [DOCUMENT_CODE] | **Version:** [VERSION] | **Date:** [EFFECTIVE_DATE]
|
|
|
|
## Record of Change
|
|
|
|
| No | Date | Version | Description | Reason |
|
|
|----|------|---------|-------------|--------|
|
|
| 1 | [dd/mm/yyyy] | 1.0 | Initial version | Feature request |
|
|
|
|
---
|
|
|
|
## TABLE OF CONTENTS
|
|
|
|
1. [Introduction](#1-introduction)
|
|
- 1.1 [Purpose](#11-purpose)
|
|
- 1.2 [Scope](#12-scope)
|
|
- 1.3 [Definitions, Acronyms, and Abbreviations](#13-definitions-acronyms-and-abbreviations)
|
|
- 1.4 [References](#14-references)
|
|
- 1.5 [Overview](#15-overview)
|
|
2. [Overall Description](#2-overall-description)
|
|
- 2.1 [Product Perspective](#21-product-perspective)
|
|
- 2.2 [Product Functions](#22-product-functions)
|
|
- 2.3 [User Characteristics](#23-user-characteristics)
|
|
- 2.4 [Constraints](#24-constraints)
|
|
- 2.5 [Assumptions and Dependencies](#25-assumptions-and-dependencies)
|
|
3. [Specific Requirements](#3-specific-requirements)
|
|
- 3.1 [Functionality](#31-functionality)
|
|
- 3.2 [Usability](#32-usability)
|
|
- 3.3 [Reliability](#33-reliability)
|
|
- 3.4 [Performance](#34-performance)
|
|
- 3.5 [Supportability](#35-supportability)
|
|
- 3.6 [Design Constraints](#36-design-constraints)
|
|
- 3.7 [Online Documentation Requirements](#37-online-documentation-requirements)
|
|
- 3.8 [Purchased Components](#38-purchased-components)
|
|
- 3.9 [Interfaces](#39-interfaces)
|
|
- 3.10 [Licensing Requirements](#310-licensing-requirements)
|
|
- 3.11 [Legal, Copyright, and Other Notices](#311-legal-copyright-and-other-notices)
|
|
- 3.12 [Applicable Standards](#312-applicable-standards)
|
|
4. [Supporting Information](#4-supporting-information)
|
|
- 4.1 [Glossary](#41-glossary)
|
|
- 4.2 [Open Issues](#42-open-issues)
|
|
|
|
---
|
|
|
|
## 1 Introduction
|
|
|
|
### 1.1 Purpose
|
|
|
|
[Purpose of this SRS and what system/feature it specifies.]
|
|
|
|
**Target Audience**: [developers, testers, project managers, stakeholders]
|
|
|
|
### 1.2 Scope
|
|
|
|
**System Name**: [Name]
|
|
**Objectives**: [Key goals]
|
|
**In Scope**: [What is included]
|
|
**Out of Scope**: [What is excluded]
|
|
|
|
### 1.3 Definitions, Acronyms, and Abbreviations
|
|
|
|
| Term | Definition |
|
|
|------|------------|
|
|
| IPA | Information-technology Promotion Agency |
|
|
| SRS | Software Requirements Specification |
|
|
| OWASP | Open Web Application Security Project |
|
|
| [TERM] | [Definition] |
|
|
|
|
### 1.4 References
|
|
|
|
| No | Title | Version |
|
|
|----|-------|---------|
|
|
| 1 | [PROJECT_NAME] Constitution | — |
|
|
| 2 | IEEE 830-1998 SRS Standard | — |
|
|
| 3 | OWASP Top 10 | Latest |
|
|
|
|
### 1.5 Overview
|
|
|
|
Sections: **1** Introduction · **2** Overall Description · **3** Specific Requirements · **4** Supporting Information.
|
|
|
|
---
|
|
|
|
## 2 Overall Description
|
|
|
|
### 2.1 Product Perspective
|
|
|
|
[Context: new product / enhancement / component of larger system.]
|
|
|
|
- **System Interfaces**: [Other systems this interacts with]
|
|
- **User Interfaces**: [General UI characteristics]
|
|
- **Software Interfaces**: [Databases, libraries, OS dependencies]
|
|
- **Communications**: [Network protocols, message formats]
|
|
|
|
### 2.2 Product Functions
|
|
|
|
[Summary of major functions — details are in Section 3.]
|
|
|
|
- [FUNCTION_1]: [description]
|
|
- [FUNCTION_2]: [description]
|
|
|
|
### 2.3 User Characteristics
|
|
|
|
| User Type | Characteristics | Primary Use |
|
|
|-----------|----------------|-------------|
|
|
| [TYPE_1] | [description] | [tasks] |
|
|
| [TYPE_2] | [description] | [tasks] |
|
|
|
|
### 2.4 Constraints
|
|
|
|
- **Regulatory**: [Legal/compliance requirements]
|
|
- **Security**: [OWASP Top 10 compliance required]
|
|
- **Development Standards**: [IPA coding/doc standards]
|
|
- **Other**: [Hardware, integration, or operational limits]
|
|
|
|
### 2.5 Assumptions and Dependencies
|
|
|
|
**Assumptions**:
|
|
- [ASSUMPTION_1]
|
|
|
|
**Dependencies**:
|
|
- [DEPENDENCY_1]
|
|
|
|
---
|
|
|
|
## 3 Specific Requirements
|
|
|
|
### 3.1 Functionality
|
|
|
|
Functional requirements format:
|
|
|
|
**FR-[CAT]-NNN**: [Title]
|
|
- **Description**: [What the system shall do]
|
|
- **Input**: [Inputs required]
|
|
- **Processing**: [High-level logic]
|
|
- **Output**: [Result/output]
|
|
- **Priority**: High / Medium / Low
|
|
- **Dependencies**: [Other FR IDs, if any]
|
|
- **Acceptance Criteria**:
|
|
- Given [condition], when [action], then [result]
|
|
|
|
#### 3.1.1 [Feature Category 1]
|
|
|
|
**FR-[CAT]-001**: [Title]
|
|
- **Description**: [...]
|
|
- **Input**: [...]
|
|
- **Processing**: [...]
|
|
- **Output**: [...]
|
|
- **Priority**: [High/Medium/Low]
|
|
- **Dependencies**: —
|
|
- **Acceptance Criteria**:
|
|
- Given [...], when [...], then [...]
|
|
|
|
[Add more FR-[CAT]-NNN entries as needed]
|
|
|
|
### 3.2 Usability
|
|
|
|
**UR-001**: [Users shall become productive within X hours of training]
|
|
**UR-002**: [Common tasks completable within X steps/seconds]
|
|
**UR-003**: [Accessibility or standards compliance requirement]
|
|
|
|
### 3.3 Reliability
|
|
|
|
**RR-001**: System shall be available [XX%] of the time; planned downtime windows: [specify].
|
|
**RR-002**: Recovery time after failure shall not exceed [X] minutes.
|
|
**RR-003**: Data calculations shall be accurate to [X] decimal places.
|
|
|
|
### 3.4 Performance
|
|
|
|
**PR-001**: [Operation] shall complete within [X] seconds at average load (95th pct ≤ [Y]s).
|
|
**PR-002**: System shall handle at least [X] concurrent users / [Y] transactions per second.
|
|
**PR-003**: [Capacity or resource utilization constraint]
|
|
|
|
### 3.5 Supportability
|
|
|
|
**SR-001**: Code shall conform to [standard]; test coverage ≥ [X]%.
|
|
**SR-002**: All errors shall be logged with stack traces; health-check endpoints provided.
|
|
**SR-003**: [Naming conventions or other maintainability requirements]
|
|
|
|
### 3.6 Design Constraints
|
|
|
|
**DC-001**: Technology stack — Language: [X]; Framework: [Y]; Database: [Z].
|
|
**DC-002**: Architecture — [Pattern, e.g., MVC/microservices]; component communication via [protocol].
|
|
**DC-003**: Tooling — VCS: Git; CI/CD: [tool]; Test framework: [tool].
|
|
|
|
### 3.7 Online Documentation Requirements
|
|
|
|
[Requirements for user manuals, context-sensitive help, or auto-generated API docs. Mark "Not applicable" if none.]
|
|
|
|
### 3.8 Purchased Components
|
|
|
|
| Component | Vendor | Version | License | Purpose |
|
|
|-----------|--------|---------|---------|---------|
|
|
| [NAME] | [VENDOR] | [VERSION] | [LICENSE] | [PURPOSE] |
|
|
|
|
All components must have no critical CVEs and be actively maintained.
|
|
|
|
### 3.9 Interfaces
|
|
|
|
#### 3.9.1 User Interfaces
|
|
|
|
**UI-001**: [Screen name] — [description, key inputs, available actions]
|
|
|
|
#### 3.9.2 Software Interfaces
|
|
|
|
**SI-001**: [System] — Type: [REST/gRPC/MQ]; Protocol: [HTTP/S]; Format: [JSON]; Auth: [method].
|
|
|
|
#### 3.9.3 Hardware Interfaces
|
|
|
|
[Describe or mark "Not applicable".]
|
|
|
|
#### 3.9.4 Communications Interfaces
|
|
|
|
[Network protocol, message format, TLS requirements, or "Not applicable".]
|
|
|
|
### 3.10 Licensing Requirements
|
|
|
|
[License enforcement rules, or "Not applicable".]
|
|
|
|
### 3.11 Legal, Copyright, and Other Notices
|
|
|
|
[Copyright statement, open-source license disclosures, disclaimers.]
|
|
|
|
### 3.12 Applicable Standards
|
|
|
|
| Standard | Application |
|
|
|----------|-------------|
|
|
| IPA Documentation Standards | Document structure |
|
|
| OWASP Top 10 | Security requirements (Sec 3.1, 3.9) |
|
|
| IEEE 830-1998 | SRS structure |
|
|
|
|
---
|
|
|
|
## 4 Supporting Information
|
|
|
|
### 4.1 Glossary
|
|
|
|
[Additional term definitions not in Section 1.3, if needed.]
|
|
|
|
### 4.2 Open Issues
|
|
|
|
| ID | Description | Status |
|
|
|----|-------------|--------|
|
|
| ISS-001 | [description] | Open |
|
|
|
|
---
|
|
|
|
**Document Status**: [Draft/Review/Approved] | **Last Updated**: [DATE]
|