Requirements are the project team's to-do list.

Requirements define what is needed and focus the project team. They are the primary method used to communicate the goals of the project to everyone on the team.

• What the stakeholders need; and
• What the system must include to satisfy the stakeholder needs.

Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning work, verifying and validating the system (acceptance), and managing the scope of the project.

Requirements may take different forms, including Use Cases and Scenarios, unstructured text, structured text, or a combination, and they may be stated at different levels of granularity. At the highest level of granularity, features define the services that the system must provide to solve the customer's problem. These are captured as structured or unstructured text in the Artifact: Vision. At the next level of granularity, Use Cases define the functionality that the system must provide to deliver the required features. These are captured as Use Cases (see Artifact: Use Case) that describe the sequence of actions performed by the system to yield an observable result of value.

A system must perform according to the behavior that Use Cases specify. However, there are system requirements that do not represent a specific behavior:

• Legal and regulatory requirements, as well as application standards
• Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements
• Interface requirements to be able to communicate with external systems
• Design constraints, such as those for operating systems and environments and for compatibility with other software

These quality requirements are often referred to as non-functional requirements.

Quality requirements that apply to the system as a whole are captured as structured text in Artifact: Supporting Requirements Specification.  Quality requirements that are closely associated with a particular Use Case are often captured in the Use Case itself to simplify review, understanding, and maintenance.