Answer first
Start with labels, not a live system or requirements decision.
A safe first use is a local packet containing only fictional or organization-approved, minimum-necessary labels: source, owner, time/version, stated purpose, type, and an honest status of supplied, unknown, or conflicting. AI can format labels and draft neutral questions. Accountable people retain every system-access, requirements, scope, analysis, solution, test, change, and communication decision.
Mission outcome
What you make in one focused session.
Source register
Supplied policy, workflow, requirement-reference, and change-reference labels tied to an owner and time/version.
Unknown log
Gaps and conflicts that remain visible instead of becoming invented requirements or solution choices.
Review handoff
Neutral questions and an authority map ending only at needs_review.
Field map
Six bounded steps
Choose a fictional or approved label-only scope.
Name the purpose and accountable owners. Exclude live systems, repositories, code, credentials, tickets, logs, records, requirements, user/customer data, architecture, test results, vendor material, and change records.
Register supplied labels without treating them as verified requirements.
Capture only source label, owner, time/version, purpose, type, and status. Do not ask AI to infer a business need, priority, scope, acceptance criterion, constraint, risk, feasibility, or solution.
Use AI as an organizer, not an analyst or system operator.
AI may format fields, group duplicates, and surface blanks. It must not retrieve or interpret data, validate a requirement, make an analysis conclusion, recommend a design, or approve testing.
Turn gaps into neutral reviewer questions.
Keep missing authority, freshness, policy, data basis, security/privacy review, acceptance, test, release, or change path as
unknown. Ask the authorized owner which process governs the gap; do not fill it from model inference.Route decisions to the owner who has them.
Business and product owners govern need and priority; system and architecture owners govern feasibility and design; security, privacy, records, legal, change, vendor, delivery, and communications owners govern their respective authorities.
Stop at the review handoff.
Create a local
needs_reviewreceipt only. Do not access a system, decide requirements, select a solution, approve a test, alter a record, deploy, send, report, or publish.
Bounded agent roles
Three clerks. No systems analyst of record.
O*NET places systems analysts near system capability, workflow, limitation, user-assistance, and testing context.1 That context makes this manual more conservative, not less: it preserves review labels and does not analyze a real system.
Safe versus approval-required
AI prepares labels. Authorized people decide and act.
| AI may prepare | Named human approval is required |
|---|---|
| Format fictional or organization-approved, minimum-necessary source and process labels. | Access, retrieve, upload, query, inspect, interpret, share, retain, or disclose a system, repository, code, ticket, log, record, requirement, user/customer data, credential, architecture, test result, vendor material, or change record. |
| Preserve supplied source, owner, time/version, purpose, type, and unknown/conflict status. | Discover, validate, prioritize, scope, accept, or reject a requirement; make an analysis conclusion; decide feasibility, risk, or a business need. |
| Draft neutral questions about authority, freshness, policy, data, security, privacy, records, acceptance, test, release, change, vendor, legal, or communications review. | Select or approve a solution, architecture, integration, control, vendor, test, release, rollback, system change, or deployment. |
| Produce a local review-only receipt. | Write a system record, communicate with a user/customer/vendor/third party, publish, procure, deploy, or take any external action. |
Failure modes
Five shortcuts that quietly become systems work.
| Mistake | Why it fails | Repair |
|---|---|---|
| “Read the tickets and tell me what users need.” | It asks the model to access private records and draw a requirements conclusion. | Do not enter tickets. Preserve only approved labels and route discovery to accountable business and systems owners. |
| “What should the scope be?” | It asks the model to make a business and delivery decision. | Keep scope authority unknown and route it through the approved requirements process. |
| “Which architecture is best?” | It asks the model to recommend a consequential technical design. | Preserve supplied constraints as labels and route design selection to accountable architecture and security owners. |
| “Approve these tests for release.” | It can substitute model output for verified testing and release authority. | Do not enter test evidence. Route test and release decisions to named quality and delivery owners. |
| “Update the change record and tell the team.” | That is a system write and external communication, not preparation. | Stop at the local receipt. An authorized person decides any record or communication action. |
Runnable local artifact
Systems Analysis Requirements & Review Desk
Enter only fictional or organization-approved, minimum-necessary labels. This form stays in the browser and produces a review-only receipt. It does not send, save, retrieve, query, analyze, decide, or connect to anything.
Primary sources
What this manual is built on.
- O*NET OnLine: Computer Systems AnalystsOccupation context; profile marked Updated 2026. [1]
- NIST AI 600-1: Generative AI ProfileVoluntary cross-sector generative-AI risk-management context; source page updated April 2026. [2]
- NIST SP 800-218: Secure Software Development Framework 1.1SDLC practices and common-vocabulary context; final February 2022. [3]
- NIST SSDF publicationsOfficial current publication status and final generative-AI community-profile context; checked August 2026. [4]
- CISA Secure by DesignSecurity-early governance context; checked August 2026. [5]
Sources provide context, not permission to access a system, decide requirements, select a design, approve a test, change anything, or take external action. Recheck current sources, organization policy, qualified reviewers, and applicable requirements before non-fictional use.
Related guides
Where this guide fits.
Proposed links: the Occupation AI Workflow Guide Directory for the broader shelf; the Computer Systems Engineer & Architect Evidence Desk for architecture-decision boundaries; the Software Developer Workflow Guide for implementation; the Software QA Analyst & Tester Evidence Desk for test and release boundaries; and the Network Support Triage & Review Desk for operational-triage boundaries. Use these related guides to keep each workflow's authority boundary clear.