Modern Software Requirements Specification – General Checklist

1. Correct and Complete

• All required functional capabilities are documented.
• Intended users, actors, external systems, and major use cases are identified.
• Inputs, outputs, data flows, sources, and destinations are defined where relevant.
• External software, services, platforms, APIs, libraries, and reused components are identified.
• Platform, environment, deployment, configuration, and adaptation requirements are identified.
• Performance requirements are defined where applicable, including response time, throughput, capacity, concurrency, and latency.
• Resource constraints are identified where applicable, including compute, memory, storage, network, and cost.
• Reliability, availability, recoverability, and continuity requirements are identified.
• Security requirements are identified.
• Privacy, data handling, retention, and access requirements are identified.
• Safety requirements are identified where applicable.
• Accessibility and usability requirements are identified where applicable.
• Maintainability, supportability, portability, interoperability, and testability requirements are identified where applicable.
• Applicable legal, regulatory, contractual, licensing, and policy constraints are identified.
• Design or implementation constraints are documented when they are genuinely required.
• Startup, shutdown, restart, upgrade, rollback, migration, and recovery behavior is addressed where relevant.
• Expected behavior under invalid input, unavailable dependencies, partial failure, overload, timeout, interruption, and other abnormal conditions is defined.
• Data accuracy, precision, integrity, ordering, consistency, and freshness requirements are defined where relevant.
• Required calculations, rules, algorithms, formulas, or external references are specified sufficiently to determine correct behavior.
• Human interactions, administrative operations, and automated interactions are considered.
• Logging, monitoring, diagnostics, auditability, and operational visibility requirements are identified where relevant.
• Backup, restore, archival, deletion, and disaster-recovery requirements are identified where relevant.
• Acceptance criteria and verification methods are identified for significant requirements.
• Delivery, packaging, deployment, documentation, and handoff requirements are identified.
• Requirements are traceable to their source, objective, stakeholder need, constraint, or higher-level requirement where appropriate.
• Unknown, deferred, or unresolved requirements are explicitly marked and tracked to resolution.

2. Consistent and Unambiguous

• Requirements do not conflict with one another.
• Requirements do not conflict with known architecture, interface, platform, policy, or higher-level constraints.
• Each important concept, entity, interface, state, and data element has a clear and consistent name.
• Terminology, acronyms, abbreviations, units, and notation are defined and used consistently.
• A requirement has one authoritative definition, even if it is referenced from multiple views or artifacts.
• Functional descriptions, diagrams, schemas, examples, tests, and interface definitions agree with the requirements text.
• Inputs and outputs are consistent with the processing described.
• Message formats, schemas, events, and data attributes are consistent across interfaces.
• Ordering, timing, frequency, retry, timeout, and sequencing requirements are mutually consistent.
• Capacity, load, performance, and resource assumptions are consistent across the specification.
• Mathematical rules and units are defined consistently.
• Requirement language clearly distinguishes mandatory behavior from optional, recommended, or informational material.
• Requirements are stated precisely enough that independent readers are unlikely to interpret them differently.
• Requirements remain consistent with the intended operational context.

3. Feasible and Realistic

• Required input data is expected to exist, be accessible, and have adequate quality.
• External systems and destinations are capable of receiving or providing the required data and behavior.
• Requirements are achievable with available or reasonably obtainable technology.
• Required infrastructure, services, tools, skills, environments, and dependencies are available or planned.
• Performance, capacity, availability, accuracy, and recovery targets are technically realistic.
• Resource and cost constraints are realistic under expected and peak workloads.
• External dependency assumptions are documented and reasonable.
• Security, privacy, safety, regulatory, and operational requirements can be implemented without contradicting core functional requirements.
• Scope is realistic relative to schedule, staffing, budget, complexity, and operational support.
• Known technical risks, uncertainties, and experimental assumptions are identified.

4. Well-Structured and Standards-Conformant

• The purpose, scope, boundaries, and operating context of the software are clear.
• Major functions are described in relation to the overall system or product.
• Requirements are uniquely identifiable.
• Requirements are written as independently understandable statements where practical.
• Requirements are concise, clear, and free of unnecessary implementation detail unless implementation is itself constrained.
• Terminology and notation are understandable to the intended audience.
• A glossary or shared vocabulary exists where specialized terminology is used.
• Required organizational, industry, legal, contractual, or documentation standards are followed.
• References to external standards or specifications identify the applicable version or authority where necessary.
• Requirement priority, criticality, source, status, or ownership is recorded when useful.
• The specification distinguishes requirements from rationale, examples, assumptions, design notes, and commentary.
• The document has been reviewed for errors, omissions, duplication, and unclear wording.

5. Verifiable and Testable

• Every mandatory requirement can be verified by test, inspection, analysis, demonstration, review, measurement, or another defined method.
• Acceptance criteria are objective enough to determine pass or fail.
• Quantitative requirements include measurable limits, thresholds, ranges, tolerances, or service levels where appropriate.
• Required test data, fixtures, simulations, environments, or external dependencies can reasonably be provided.
• Normal, boundary, error, failure, recovery, and degraded-operation cases can be verified.
• Security, privacy, reliability, performance, accessibility, and other quality requirements are verifiable where applicable.
• Test results can be evaluated against predetermined expected outcomes.
• Requirements avoid unverifiable terms such as “fast,” “easy,” “secure,” “robust,” or “user-friendly” unless those terms are defined by measurable criteria.
• Required observability exists to determine whether the system behaved correctly.
• Automated verification is possible for repeatable requirements where practical.

6. Operable and Evolvable

• Deployment and configuration requirements are defined where relevant.
• Environment-specific configuration is separated from fixed system behavior where practical.
• Upgrade, downgrade, rollback, migration, and backward-compatibility expectations are defined where relevant.
• Changes to APIs, schemas, storage formats, protocols, or externally visible behavior have an evolution strategy.
• Failure of external dependencies has a defined operational response.
• Monitoring can identify important failures, degradation, capacity problems, and security-relevant events.
• Logs, metrics, traces, and audit records contain sufficient information for diagnosis without unnecessarily exposing sensitive data.
• Administrative, maintenance, recovery, and support operations are accounted for.
• Expected system behavior during maintenance or partial unavailability is defined where necessary.
• The requirements permit foreseeable system evolution without unnecessarily constraining the implementation.

7. Secure and Responsible

• Authentication and authorization requirements are identified where applicable.
• Sensitive data, credentials, secrets, and privileged operations are identified and appropriately protected.
• Trust boundaries and externally controlled inputs are identified.
• Requirements address validation and safe handling of untrusted or malformed input.
• Required audit, accountability, and security-event recording is defined.
• Third-party software, services, dependencies, and supply-chain risks are considered.
• Required update, patching, vulnerability-response, and deprecation behavior is identified where relevant.
• Privacy requirements follow principles such as minimum necessary collection, purpose limitation, controlled access, retention, and deletion where applicable.
• Potential misuse, abuse, unsafe behavior, or harmful failure modes are considered where relevant.
• Human approval, override, escalation, or intervention requirements are identified for decisions that should not be fully automated.

8. Automation, AI, and Agentic Behavior — If Applicable

• The system clearly defines which actions may be performed automatically and which require human approval.
• Permissions and authority granted to automated components follow least-privilege principles.
• External tools, APIs, files, commands, and data sources accessible to automated components are explicitly bounded.
• Preconditions and postconditions for consequential automated actions are defined.
• The system verifies important assumptions before taking irreversible, destructive, costly, privileged, or externally visible actions.
• Automated actions are attributable and auditable.
• Failure, timeout, retry, cancellation, and partial-completion behavior is defined for multi-step automated workflows.
• Duplicate or repeated execution is safe or prevented where necessary.
• The system has defined behavior when model, tool, dependency, or external-system output is uncertain, malformed, unavailable, or contradictory.
• Generated or inferred information is validated before use when incorrect output could materially affect the system.
• Human review or escalation is available for sufficiently high-impact or ambiguous cases.
• Autonomous loops have appropriate termination conditions, resource limits, and safeguards against uncontrolled repetition.
• Model, prompt, policy, tool, configuration, or workflow changes can be versioned and evaluated where applicable.
• Evaluation criteria cover not only successful task completion but also unsafe actions, incorrect assumptions, boundary violations, and recovery behavior.
• The system records sufficient context to reconstruct significant automated decisions and actions without retaining unnecessary sensitive information.

9. Final Review

• Every requirement serves an identifiable need or constraint.
• Every mandatory requirement has a plausible implementation path.
• Every mandatory requirement has a plausible verification path.
• Important assumptions are explicit rather than hidden.
• Important failure modes are addressed rather than left to implementation guesswork.
• External dependencies and trust assumptions are visible.
• Nonfunctional requirements are treated as requirements, not aspirations.
• The specification describes required outcomes without over-constraining design unnecessarily.
• Unresolved questions are visible and assigned for resolution.
• The resulting specification is sufficient for implementation, review, testing, operation, and acceptance without requiring critical behavior to be guessed.