Requirements Engineering

A functional requirement states a capability or business rule. In the Task Management API material, users can usually register and authenticate, manage profiles, create projects, add project members, create and asign tasks, chagne status and priority, and manage comments. Each capability should specify the actor, preconditions, input, expected result and failure cases. This makes the requirement testable instead of leaving developers to infer behavior from a feature name.

Non-functional requirements describe how well the system must operate. Examples include availability, latency, throughput, data durability, security, observability and maintainability. They should be measurable where possible. 'Fast' is ambiguous; a percentile latency target provides a criterion that can be measured under a stated workoad. NFRs are not secondary documentation: they strongly influence architecture and testing strategy.

A constraint limits the solution space, such as Java and Spring Boot,PostgreSQL, Docker, REST APIs or a single- region initial deployment. An assumption is a planning belief that may need validation, such as 80% read and 20% write workload, or the expectation that users belong to multiple projecs. Keeping these categoires separate pevents an assumption from being mistaken for a permanent technical requirement.

Authentication establishes who is making a request; authorisation decides what that identity may do to a particular resource. The requirements state that users cannot access projects they are not members of, cannot modify another user's profile without permission, and cannot modify another user's comment unless authorised. These checks must be enforced on the backend. Hiding a button in the frontend is not a security boundary.

A requirement becomes useful when it can be verified. For each workflow, test the valid path and important negative cases. For project creation, verify the project and owner membership are created together. For task assignment, verify that the assignee belongs to the project. For pagination, verify stable ordering and bounded responses. For security, verify that a user cannot access another user's resources by changing an identifier in the URL.

The supplied architecture exercise and requirements notes contain different traffic figures: the initial architecture assumptions mention roughly 1,200 peak requests per second, while the requirement document gives a target of about 500 requests per second and 10,000 concurrently connected or active users. Treat these as different planning snapshots, not as one reconciled guarantee. Before implementation or performance testing, choose and record the currenly approved workloa baseline.