requirements-analysislisted

# Requirements Analysis Converts what a person wrote into what an engineer can build, without adding anything they did not say. The output is not a summary. It is a specification with four separated registers: what was stated, what is being assumed, what constrains the work, and what nobody knows yet. ## 1. The separation rule Four registers, never merged, never silently promoted. | Register | Definition | |---|---| | Requirement | stated by the source, quotable | | Assumption | not stated, adopted to proceed, reversible on contradiction | | Constraint | a fact that limits the solution space | | Unknown | cannot be determined, blocks or does not block, stated | Promoting an assumption to a requirement without asking is the single most expensive error in this phase. It produces a system that satisfies a specification nobody wrote. Every assumption carries: what is assumed, why it was needed, what changes if it is wrong. ## 2. Input kinds Each carries different silences. | Input | Reliably present | Reliably missing | |---|---|---| | written specification | features, screens | error paths, permissions, limits | | PRD | user value, success criteria | data model, non functional needs | | feature list | scope breadth | rules, states, ownership | | mockups or screenshots | layout, happy path | empty states, errors, validation | | client conversation | intent, priorities | precision, edge cases | | existing API documentation | contracts | which parts are actually implement