Files
thanhnvandClaude Opus 4.8 36a4812ef3 refactor(structure): promote app to repo root + remove redundant workspace cruft
Standard production layout: the OKR app (was nested under AINative_OKR_CASAN5/) is now
the repository root. No more wrapper directory.

- Promote AINative_OKR_CASAN5/* -> repo root (backend/ frontend/ packages/ apps/
  .specify/ docs/ infra/ nginx/ scripts/ + configs). Merge tool dirs: .gitea (kept the
  active deploy ci.yml, added harness-ci.yml + runbooks), .claude (agents/commands +
  launch.json), .github moved up.
- Remove redundant: 00_SUBMISSION_PACKAGE, scattered root notes (FPT_CASAN_Full.md,
  tu-tuong-casan.md, casan-tu-sinh..., casan_harness_assessment.md, source-review...,
  README_CASAN5_REFINED.md), casan-next-plans/ and optimize-docs/ (competition/planning
  artifacts — roadmap + design history preserved in git log / commit messages).
- Update all references to the old layout:
  - .gitea/workflows/{ci,harness-ci}.yml, .github/workflows/{ci,deploy}.yml:
    working-directory .; drop AINative_OKR_CASAN5/ prefix; .specify/{tests,scripts}
    -> packages/casan-harness/... (.specify/logs state kept)
  - .claude/launch.json, .gitea/*-runbook.md: path prefixes
  - CLAUDE.md, README.md: docs/input -> apps/okr/domain/input
  - policy-bundle.yaml: 8 policy paths -> packages/casan-harness/...; manifest re-signed
- secrets-scan.sh: fixture excludes -> new package/domain paths.

Full gate from the new root: PASS=64 FAIL=0 SKIP=3.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 13:26:36 +09:00

7.5 KiB

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
  2. Overall Description
  3. Specific Requirements
  4. Supporting Information

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.]

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".]

[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]