• Define Vision
• Find and Outline Requirements
• Detail Requirements
• Requirements

A formal definition of a requirement, taken from  [ICS03], is:

"A formal statement of: (1) An attribute to be possessed by the product or a function to be performed by the product. (2) the performance standard for the attribute or function. (3) the measuring process to be used in verifying that the standard has been met."

Informally, 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 users want
• What the system must include to satisfy the user and business needs
• How one will demonstrate that the requirements have been satisfied 

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 abstraction, 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 abstraction, 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 nonfunctional requirements.

Quality requirements that apply to the system as a whole are captured as structured text in Artifact: Supporting Requirements.  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.

Finally, Artifact: Test Case may be considered a form of requirement stating how the system will be verified.

• Work Items List