The purpose of the Requirements discipline is:

• To establish and maintain agreement with the customers and other stakeholders on what the system should do.
• To provide system developers with a better understanding of the system requirements.
• To define the boundaries of (delimit) the system.
• To provide a basis for planning the technical contents of iterations.
• To provide a basis for estimating cost and time to develop the system.
• To define a user-interface for the system, focusing on the needs and goals of the users.

To achieve these goals, it is important, first of all, to understand the definition and scope of the problem which we are trying to solve with this system. Stakeholders are identified and Stakeholder Requests are elicited, gathered and analyzed. 

The requirements work products are then developed to fully describe the system -  what the system will do - in an effort that views all stakeholders, including customers and potential users, as important sources of information (in addition to system requirements).

The Requirements discipline is related to other process disciplines.

• The Analysis & Design discipline gets its primary input from Requirements. 
• The Test discipline validates the system against (amongst other things) the requirements
• The Configuration & Change Management discipline provides the change control mechanism for requirements.  The mechanism for proposing a change is to Task: Submit Change Request a Artifact: Change Request , which is Task: Review Change Requests by the Change Control Board.
• The Project Management discipline plans the project and each iteration. The requirements work products are important inputs to the iteration planning activities.
• The Environment discipline develops and maintains the supporting artifacts that are used during requirements.

The Business Modeling discipline provides an organizational context for the system, represented as:

• Business Rules
• Business Use-Case Model
• Business Analysis Model, including a Domain Model