modify agent and skill
This commit is contained in:
NINI
@@ -1,5 +1,5 @@
|
||||
name = "requirement-agent"
|
||||
description = "Drafts verifiable requirements for FESA FEM solver features before formulation, implementation, and reference validation."
|
||||
description = "Analyzes new FESA FEM solver feature requirements and produces verifiable requirements analysis before formulation, implementation, and reference validation."
|
||||
sandbox_mode = "read-only"
|
||||
model_reasoning_effort = "extra high"
|
||||
|
||||
@@ -7,12 +7,12 @@ developer_instructions = """
|
||||
You are the Requirement Agent for the FESA structural analysis solver project.
|
||||
|
||||
Mission:
|
||||
- Convert solver feature requests into a verifiable requirements baseline.
|
||||
- Produce a Feature Requirement Specification and a Requirement Verification Matrix.
|
||||
- Analyze new solver feature requests into a verifiable new solver feature requirements analysis baseline.
|
||||
- Produce a New Solver Feature Requirements Analysis document and a Requirement Verification Matrix.
|
||||
- Keep the output aligned with docs/AGENT_RULES.md.
|
||||
|
||||
Skill references:
|
||||
- Use $fesa-requirements-baseline when drafting or revising requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
|
||||
- Use $fesa-requirements-baseline when analyzing, drafting, or revising new solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
|
||||
|
||||
Hard boundaries:
|
||||
- Do not implement code.
|
||||
@@ -28,7 +28,7 @@ Source priorities:
|
||||
3. Stored project references under references/, when present.
|
||||
4. Publicly cited requirements, verification, FEM benchmark, or V&V sources only when the user asks for research-backed requirements.
|
||||
|
||||
Requirement drafting rules:
|
||||
New solver feature requirements analysis rules:
|
||||
- Write requirements as "The FESA solver shall ..." statements.
|
||||
- State what the solver must do, not how it must be implemented.
|
||||
- Keep each requirement singular, measurable, feasible, verifiable, and traceable.
|
||||
@@ -36,7 +36,7 @@ Requirement drafting rules:
|
||||
- Mark unverifiable requirements as needs-user-decision.
|
||||
- Replace vague claims such as "accurate", "fast", or "Abaqus-like" with measurable acceptance criteria or an explicit open question.
|
||||
|
||||
Required Feature Requirement Specification sections:
|
||||
Required New Solver Feature Requirements Analysis sections:
|
||||
1. Metadata: feature_id, title, status, owner_agent, date.
|
||||
2. Purpose and expected behavior.
|
||||
3. In scope.
|
||||
@@ -51,7 +51,7 @@ Required Feature Requirement Specification sections:
|
||||
12. Open questions.
|
||||
13. Downstream handoff.
|
||||
|
||||
Requirement record format:
|
||||
Requirements analysis record format:
|
||||
id: FESA-REQ-<FEATURE>-###
|
||||
statement: "The FESA solver shall ..."
|
||||
category: functional | physics | numerical | input | output | verification | constraint
|
||||
@@ -66,7 +66,7 @@ trace_to:
|
||||
downstream_agents: ["Research Agent", "Formulation Agent", "Reference Model Agent"]
|
||||
status: draft | needs-user-decision | approved
|
||||
|
||||
Verification planning rules:
|
||||
Requirements analysis verification planning rules:
|
||||
- Every must requirement must have a verification method and acceptance criterion.
|
||||
- Numerical requirements must include units, coordinate system, and tolerance.
|
||||
- Reference-comparison requirements must identify the required reference artifact files.
|
||||
@@ -74,13 +74,13 @@ Verification planning rules:
|
||||
- If reference artifacts are missing, hand off requirements to Reference Model Agent.
|
||||
|
||||
Downstream handoff rules:
|
||||
- Research Agent: theory sources, benchmark questions, and standards to investigate.
|
||||
- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints.
|
||||
- I/O Definition Agent: input and output schema requirements.
|
||||
- Reference Model Agent: references/<feature>/ artifact requirements.
|
||||
- Implementation Planning Agent: tests to write first and acceptance criteria.
|
||||
- Research Agent: theory sources, benchmark questions, and standards identified by the requirements analysis.
|
||||
- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints from the requirements analysis.
|
||||
- I/O Definition Agent: input and output schema requirements from the requirements analysis.
|
||||
- Reference Model Agent: references/<feature>/ artifact requirements from the requirements analysis.
|
||||
- Implementation Planning Agent: tests to write first and acceptance criteria from the requirements analysis.
|
||||
|
||||
Output language:
|
||||
- Write feature requirement documents in Korean Markdown unless the user requests another language.
|
||||
- Write new solver feature requirements analysis documents in Korean Markdown unless the user requests another language.
|
||||
- Keep requirement IDs, categories, and machine-readable fields in English.
|
||||
"""
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
name: fesa-requirements-baseline
|
||||
description: Use when defining FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
|
||||
description: Use when analyzing new FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
|
||||
---
|
||||
|
||||
# FESA Requirements Baseline
|
||||
# FESA New Solver Feature Requirements Analysis
|
||||
|
||||
Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
|
||||
Use this skill to turn a new solver feature request into a verifiable new solver feature requirements analysis baseline that downstream agents can use without guessing.
|
||||
|
||||
## Inputs
|
||||
|
||||
@@ -20,26 +20,26 @@ Read these first:
|
||||
## Workflow
|
||||
|
||||
1. Assign a stable `feature_id` in kebab case.
|
||||
2. Define purpose, included scope, excluded scope, and analysis definition.
|
||||
3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
|
||||
4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
|
||||
5. Record Tolerance Policy values or mark them `needs-user-decision`.
|
||||
6. Record Reference Artifact Requirements under `references/<feature-id>/`.
|
||||
7. Build a Requirement Verification Matrix that maps requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
|
||||
2. Analyze purpose, included scope, excluded scope, and analysis definition.
|
||||
3. Convert requested behavior into analyzed `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
|
||||
4. Analyze and record verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
|
||||
5. Analyze and record Tolerance Policy values or mark them `needs-user-decision`.
|
||||
6. Analyze and record Reference Artifact Requirements under `references/<feature-id>/`.
|
||||
7. Build a Requirement Verification Matrix that maps analyzed requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
|
||||
8. Keep unresolved decisions visible as open issues; do not hide gaps behind vague wording.
|
||||
|
||||
## Output Contract
|
||||
|
||||
Produce or revise `docs/requirements/<feature-id>.md` with:
|
||||
Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature requirements analysis document with:
|
||||
|
||||
- Metadata with `feature_id`, status, owner agent, and date
|
||||
- Metadata with `feature_id`, analysis status, owner agent, and date
|
||||
- Purpose, In Scope, Out Of Scope, and Analysis Definition
|
||||
- Input and Output Requirements
|
||||
- Verification Quantities
|
||||
- Tolerance Policy
|
||||
- Reference Artifact Requirements
|
||||
- Requirement Verification Matrix
|
||||
- Open Questions and Downstream Handoff
|
||||
- Open Questions and Downstream Handoff from the requirements analysis
|
||||
|
||||
## Boundaries
|
||||
|
||||
@@ -52,9 +52,9 @@ Produce or revise `docs/requirements/<feature-id>.md` with:
|
||||
|
||||
## Quality Gate
|
||||
|
||||
- Every `must` requirement has a verification method and acceptance criteria.
|
||||
- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
|
||||
- Every reference-comparison requirement names required artifacts.
|
||||
- Every `must` requirement analyzed in the document has a verification method and acceptance criteria.
|
||||
- Every numerical requirement analyzed in the document has units, coordinate system, and tolerance or an explicit owner for the decision.
|
||||
- Every reference-comparison requirement analyzed in the document names required artifacts.
|
||||
- Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
|
||||
|
||||
## Handoff
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
interface:
|
||||
display_name: "FESA Requirements Baseline"
|
||||
short_description: "Define solver requirements"
|
||||
default_prompt: "Use $fesa-requirements-baseline to define verifiable FESA solver requirements."
|
||||
display_name: "FESA Requirements Analysis"
|
||||
short_description: "Analyze new solver requirements"
|
||||
default_prompt: "Use $fesa-requirements-baseline to analyze new FESA solver feature requirements."
|
||||
|
||||
@@ -15,7 +15,7 @@ FESA는 Abaqus, Nastran 같은 유한요소법 기반 구조해석 솔버를 C++
|
||||
## 기본 개발 워크플로우
|
||||
솔버 기능 개발은 아래 순서를 기본으로 한다.
|
||||
|
||||
1. 솔버 기능에 대한 요구조건 정의
|
||||
1. 새로운 솔버 기능 요구조건 분석
|
||||
2. 책, 논문 등 연구자료 조사
|
||||
3. 코드 구현을 위한 유한요소 정식화
|
||||
4. 솔버 입출력 데이터 정의
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ Before changing code or documents, every Agent must read:
|
||||
## Global Solver Workflow
|
||||
All solver features follow this stage-gated workflow:
|
||||
|
||||
1. Define solver feature requirements.
|
||||
1. Analyze new solver feature requirements.
|
||||
2. Research books, papers, manuals, benchmarks, and reference implementations.
|
||||
3. Write FEM formulation for implementation.
|
||||
4. Define solver input and output data.
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ Build the FESA structural solver foundation around the initial feature `mitc4-li
|
||||
|
||||
## Current High-Level Plan
|
||||
1. Maintain project-level documentation and handoff files.
|
||||
2. Define requirements for `mitc4-linear-static-shell`.
|
||||
2. Analyze new solver feature requirements for `mitc4-linear-static-shell`.
|
||||
3. Gather research evidence for MITC4, OpenSees `ShellMITC4`, Abaqus S4/S4R, patch tests, and Scordelis-Lo.
|
||||
4. Write FEM formulation for the MITC4 linear static shell feature.
|
||||
5. Define Abaqus `.inp` input subset and HDF5 output/reference schemas.
|
||||
|
||||
+9
-1
@@ -18,9 +18,11 @@
|
||||
- Moved solver plan/design documents to `docs/project-plan/` and updated agent, skill, test, and document references.
|
||||
- Extracted common per-run rules from the solver agent design into `docs/AGENT_RULES.md`.
|
||||
- Updated `.codex/agents/*.toml`, `.codex/skills/*/SKILL.md`, and related tests to reference `docs/AGENT_RULES.md` instead of the solver agent design document.
|
||||
- Renamed the first solver development workflow stage to "새로운 솔버 기능 요구조건 분석" across `AGENTS.md`, `docs/`, `.codex/agents/requirement-agent.toml`, and `.codex/skills/fesa-requirements-baseline`.
|
||||
- Refined `requirement-agent` and `fesa-requirements-baseline` internals to describe a new solver feature requirements analysis document instead of a requirements drafting/specification task.
|
||||
|
||||
## In Progress
|
||||
- Ready for the next stage: requirements baseline for `mitc4-linear-static-shell`.
|
||||
- Ready for the next stage: new solver feature requirements analysis for `mitc4-linear-static-shell`.
|
||||
|
||||
## Next Tasks
|
||||
1. Create `docs/requirements/mitc4-linear-static-shell.md`.
|
||||
@@ -31,6 +33,12 @@
|
||||
6. Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
|
||||
|
||||
## Last Validation
|
||||
- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
|
||||
- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
|
||||
- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
|
||||
- 2026-06-08: `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
|
||||
- 2026-06-08: `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
|
||||
- 2026-06-08: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
|
||||
- 2026-06-05: After extracting `docs/AGENT_RULES.md`, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
|
||||
- 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
|
||||
- 2026-06-05: After document relocation and reference updates, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
|
||||
|
||||
@@ -153,7 +153,7 @@ INTAKE -> STATE AUDIT -> GATE DECISION -> HANDOFF PACKAGE -> STATUS REPORT
|
||||
## 상태 값
|
||||
|
||||
- `intake`: 기능 요청은 들어왔지만 첫 handoff가 완료되지 않았다.
|
||||
- `needs-requirements`: Requirement Agent가 요구조건을 정의하거나 수정해야 한다.
|
||||
- `needs-requirements`: Requirement Agent가 새로운 솔버 기능 요구조건 분석 산출물을 작성하거나 수정해야 한다.
|
||||
- `needs-research`: Research Agent가 source-backed research evidence를 제공하거나 수정해야 한다.
|
||||
- `needs-formulation`: Formulation Agent가 FEM 정식화를 작성하거나 수정해야 한다.
|
||||
- `needs-numerical-review`: Numerical Review Agent가 정식화를 검토하거나 재검토해야 한다.
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
이번 구성안은 ALL-FEM 논문의 구조를 확장하거나 재사용하는 계획이 아니다. 논문은 Agent 설계를 위한 참고 자료로만 사용하며, 본 프로젝트는 C++/MSVC 기반 독립 솔버 개발 워크플로우를 따른다.
|
||||
|
||||
## 설계 원칙
|
||||
- 기능 요구조건, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
|
||||
- 새로운 솔버 기능 요구조건 분석, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
|
||||
- 실행 가능성만으로 성공을 판단하지 않고, 레퍼런스 결과와 물리량을 비교해 기능 완료를 판정한다.
|
||||
- 테스트는 구현 전에 준비한다. 개발 대상 솔버 테스트와 레퍼런스 솔버 결과 비교 테스트를 함께 사용한다.
|
||||
- Abaqus나 Nastran을 Agent가 직접 실행하지 않는다. `references/`에 저장된 입력 파일과 레퍼런스 CSV 결과를 검증 기준으로 사용한다.
|
||||
@@ -21,7 +21,7 @@
|
||||
책임:
|
||||
- 기능 개발 요청을 단계별 작업으로 분해한다.
|
||||
- 각 Agent의 산출물을 연결하고 누락된 결정을 추적한다.
|
||||
- 요구조건, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
|
||||
- 요구조건 분석, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
|
||||
- 실패 시 어떤 Agent로 되돌릴지 결정한다.
|
||||
|
||||
주요 산출물:
|
||||
@@ -30,10 +30,10 @@
|
||||
- 실패 원인과 재작업 지시
|
||||
|
||||
### Requirement Agent
|
||||
솔버 기능 요구조건을 정의하는 Agent이다.
|
||||
새로운 솔버 기능 요구조건을 분석하는 Agent이다.
|
||||
|
||||
책임:
|
||||
- 해석 기능의 범위, 입력, 출력, 제약조건을 정의한다.
|
||||
- 해석 기능의 범위, 입력, 출력, 제약조건을 분석하고 명시한다.
|
||||
- 대상 요소, 재료 모델, 경계조건, 하중 조건, 해석 타입을 명확히 한다.
|
||||
- 검증해야 할 물리량과 tolerance 기준을 정한다.
|
||||
|
||||
@@ -240,7 +240,7 @@ python scripts/validate_workspace.py
|
||||
|
||||
| 개발 과정 | 담당 Agent | 필수 산출물 |
|
||||
| --- | --- | --- |
|
||||
| 1. 솔버 기능 요구조건 정의 | Requirement Agent | 요구조건, acceptance criteria |
|
||||
| 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent | 요구조건 분석, acceptance criteria |
|
||||
| 2. 연구자료 조사 | Research Agent | 자료 요약, benchmark 후보 |
|
||||
| 3. 유한요소 정식화 | Formulation Agent, Numerical Review Agent | 정식화 문서, 리뷰 결과 |
|
||||
| 4. 입출력 데이터 정의 | I/O Definition Agent | 입력/출력 schema |
|
||||
@@ -278,7 +278,7 @@ flowchart TD
|
||||
|
||||
## 검증 Gate
|
||||
|
||||
### Gate 1: 요구조건 승인
|
||||
### Gate 1: 요구조건 분석 승인
|
||||
통과 조건:
|
||||
- 대상 기능과 제외 범위가 명확하다.
|
||||
- 입력, 출력, tolerance, 검증 물리량이 정의되어 있다.
|
||||
|
||||
@@ -5,7 +5,7 @@ FESA will implement an initial finite element structural solver feature named `m
|
||||
|
||||
The implementation must follow the full solver development workflow:
|
||||
|
||||
1. Define solver feature requirements.
|
||||
1. Analyze new solver feature requirements.
|
||||
2. Research books, papers, manuals, and related solver implementations.
|
||||
3. Write the finite element formulation required for code implementation.
|
||||
4. Define solver input and output data contracts.
|
||||
@@ -56,10 +56,10 @@ Primary conceptual modules:
|
||||
- `ResultWriter`: HDF5 output.
|
||||
- `ReferenceComparator`: HDF5 reference comparison.
|
||||
|
||||
## Step 1: Requirements Baseline
|
||||
## Step 1: New Solver Feature Requirements Analysis
|
||||
Create `docs/requirements/mitc4-linear-static-shell.md`.
|
||||
|
||||
The requirement document must define:
|
||||
The requirements analysis document must define:
|
||||
- analysis type: linear static
|
||||
- element type: MITC4 shell
|
||||
- DOF order: `U1, U2, U3, UR1, UR2, UR3`
|
||||
|
||||
@@ -21,7 +21,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
|
||||
|
||||
| Skill | 적용 개발 과정 | 주요 사용자 Agent | 대표 산출물 |
|
||||
| --- | --- | --- | --- |
|
||||
| `fesa-requirements-baseline` | 1. 솔버 기능 요구조건 정의 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
|
||||
| `fesa-requirements-baseline` | 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
|
||||
| `fesa-research-evidence` | 2. 책, 논문 등 연구자료 조사 | Research Agent, Formulation Agent | `docs/research/<feature-id>-research.md` |
|
||||
| `fesa-formulation-spec` | 3. 코드 구현을 위한 유한요소 정식화 | Formulation Agent, Implementation Planning Agent | `docs/formulations/<feature-id>-formulation.md` |
|
||||
| `fesa-numerical-review` | 3. 정식화 독립 수치 검토 | Numerical Review Agent, Coordinator Agent | `docs/numerical-reviews/<feature-id>-review.md` |
|
||||
@@ -36,7 +36,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
|
||||
|
||||
예시 기능: `linear-truss-1d`
|
||||
|
||||
1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 기능 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 작성한다.
|
||||
1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 새로운 솔버 기능의 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 분석하고 작성한다.
|
||||
2. Research Agent는 `fesa-research-evidence`를 사용해 truss/bar element 이론, benchmark 후보, source reliability, applicability limits를 정리한다.
|
||||
3. Formulation Agent는 `fesa-formulation-spec`을 사용해 strong form, weak form, shape functions, B matrix, element stiffness, output recovery를 정리한다.
|
||||
4. Numerical Review Agent는 `fesa-numerical-review`를 사용해 rigid body modes, patch test, stiffness symmetry, Jacobian, locking 위험을 검토하고 `pass-for-implementation-planning` 여부를 판단한다.
|
||||
@@ -51,7 +51,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
|
||||
|
||||
### `fesa-requirements-baseline`
|
||||
|
||||
- 기능 요청을 검증 가능한 요구조건 baseline으로 만든다.
|
||||
- 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 baseline으로 만든다.
|
||||
- `shall` 문장과 `FESA-REQ-<FEATURE>-###` id를 사용한다.
|
||||
- 모든 `must` 요구조건은 verification method와 acceptance criteria를 가져야 한다.
|
||||
- FEM 정식화, C++ 구현, reference CSV 생성, release readiness 판단은 하지 않는다.
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 요구조건 문서 작성 가이드
|
||||
|
||||
이 디렉터리는 Requirement Agent가 작성하거나 제안한 기능별 요구조건 문서를 보관하는 위치다.
|
||||
이 디렉터리는 Requirement Agent가 작성하거나 제안한 새로운 솔버 기능 요구조건 분석 문서를 보관하는 위치다.
|
||||
|
||||
기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 baseline이어야 한다.
|
||||
기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 요구조건 분석 baseline이어야 한다.
|
||||
|
||||
## Requirement Agent 역할
|
||||
|
||||
Requirement Agent는 솔버 기능 요청을 검증 가능한 요구조건으로 바꾼다.
|
||||
Requirement Agent는 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 산출물로 바꾼다.
|
||||
|
||||
수행한다:
|
||||
- 기능 범위, 제외 범위, 입력, 출력, 제약조건을 정의한다.
|
||||
|
||||
Reference in New Issue
Block a user