UNPKG

aiwg

Version:

Cognitive architecture for AI-augmented software development with structured memory, ensemble validation, and closed-loop correction. FAIR-aligned artifacts, 84% cost reduction via human-in-the-loop, standards adopted by 100+ organizations.

aiwg.io

jmagly/aiwg

118 lines (64 loc) • 3.19 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
# Software Requirements Specification (Traditional) Template ## Cover Page - ``Project Name`` - `Software Requirements Specification for`Subsystem or Feature`` - `Version`1.0`` ## Revision History | Date | Version | Description | Author | | --- | --- | --- | --- | | ``dd/mmm/yy``|``x.x``|`<details>`|`<name>` | ## Ownership & Collaboration - Document Owner: System Analyst - Contributor Roles: Software Architect, Test Architect, Requirements Reviewer - Automation Inputs: Vision, use-case library, supplementary specification - Automation Outputs: `software-requirements-specification.md` with sections 1–4 ## 1 Introduction > Provide context for the SRS, including purpose, scope, terminology, references, and document organization. ### 1.1 Purpose ### 1.2 Scope ### 1.3 Definitions, Acronyms, and Abbreviations ### 1.4 References ### 1.5 Overview ## 2 Overall Description > Summarize product perspective, major capabilities, user classes, operating environment, constraints, and assumptions. ## 3 Specific Requirements > Document functional and non-functional requirements. Use structured subsections below and duplicate as needed. ### 3.1 Functionality #### 3.1.1 ``Functional Requirement`` > State behavior, stimulus/response, and acceptance criteria. ### 3.2 Usability #### 3.2.1 ``Usability Requirement`` > Describe usability targets (learnability, accessibility, training, UI conventions). ### 3.3 Reliability #### 3.3.1 ``Reliability Requirement`` > Specify availability, fault tolerance, recovery, and defect thresholds. ### 3.4 Performance #### 3.4.1 ``Performance Requirement`` > Capture response time, throughput, capacity, degradation modes, and resource usage limits. ### 3.5 Supportability #### 3.5.1 ``Supportability Requirement`` > Describe maintainability constraints, diagnostics, coding standards, or tooling needs. ### 3.6 Design Constraints #### 3.6.1 ``Design Constraint`` > Enumerate mandated technologies, architectural restrictions, or compliance constraints. ### 3.7 Online User Documentation and Help System Requirements > Detail in-product help, tutorials, or documentation deliverables. ### 3.8 Purchased Components > Identify third-party components, licensing restrictions, and interoperability requirements. ### 3.9 Interfaces #### 3.9.1 User Interfaces #### 3.9.2 Hardware Interfaces #### 3.9.3 Software Interfaces #### 3.9.4 Communications Interfaces > For each interface type, describe protocols, data formats, error handling, and dependency considerations. ### 3.10 Licensing Requirements ### 3.11 Legal, Copyright, and Other Notices ### 3.12 Applicable Standards > Record obligations tied to licensing, legal terms, or standards (industry, regulatory, organizational). ## 4 Supporting Information > Provide appendices, indexes, or reference materials used to elaborate requirements (storyboards, prototypes, > traceability matrices, etc.). ## Agent Notes - Reference related use-case IDs and supplementary requirements for each section. - Highlight constraints and interfaces that downstream architects must honor. - Verify the Automation Outputs entry is satisfied before signaling completion.