What are requirements?

    Requirements are simply statements that describe what your software will do. They are a tool that helps you understand what your customer wants, and helps you understand what you must build.

    Unless your project is a prototype used to test the feasability of a concept or a simple run once program used to produce a temporary data set, you should gather and record requirements for your project.

    Before you can design and code a project you need to know what it is expected to do. 

How do you do this?

    The gathering of requirements is usually broken down into requirements analysis and the creation of the requirements document itself, although these two steps really happen simultaneously. You will always want to perform the requirements analysis step but depending on the size and complexity of your project you will want to adjust the requirements document to best fit your needs or the methodology you choose.

    NOTE: It is a serious mistake to assume the once the requirements analysis and documentation has been completed that the requirements can be frozen. The requirements cannot be frozen in time. Your user's needs will change, the problem will change, the technology will change, and it is impossible to capture all the requirements the first time. You should continue to modify your requirements as the project progresses. See the section on "How do the different methodologies handle requirements" below for more about this.

    Requirements analysis is the process used to identify what your customers or stakeholders (users or scientists that will use the code or it's results) want the software to do. This should include interviews and ongoing discussions with the customer. 

Usually the customer has only a high level or incomplete idea of what they want. Requirements analysis allows you to engage the customer in discussions that not only bring to light features and behavior that the customer may not have thought of, but it also promotes an atmosphere where the software engineers discover functional problems and possibly new solutions that would otherwise only be discovered at a much later and costly date. 

    Requirements analysis should include a discussion with your customer about what is feasible or affordable to do. Some features may be too complicated or time consuming to complete within the expected time constraints. The analysis phase allows you to discuss this early on in the project instead of being forced to realize the problems later.

    Requirements analysis is complete when you have understood in detail what the software will be required to do. The results of this analysis is captured in the requirements documentation. In some sense the requirements analysis is never completed because you are trying to hit a moving target. The customers and stakeholders change their mind as to what they want or perhaps external factors force changes upon the project. You should continually revisit the requirements document and analysis to determine if it reflects what you need to build.

Requirements Documentation.

    For any significant project, as the requirements analysis discovers new requirements, these requirements should be written down and recorded in a requirements document. The purpose of this document is three fold.

• First, the requirements document is a contract between the software developers and the customers or stakeholders. Both parties have agreed that this is how the software will behave. Changes can and should be made to the requirements document on an ongoing basis to reflect the customers needs, but any and all changes must be discussed and agreed to by both parties. If there is a disagreement in the future over what is being built or what was built, this document should resolve the issue. The requirements documentation provides protection for both the customer and the software programmers.
• Second, the very act of writing down what the software should do, forces the software programmer to think throughly about the behavior. This usually results in more questions and a deeper understanding of the problem which in turn results in a higher quality requirements analysis.
• Third, the requirements document provides the very basis for what should be tested during the test phase. If the software can perform everything that you said it would do in the requirements document, it has passed the test phase and is ready to deliver.

Use Cases.

The following document is a good example of how to write a Software Requirements Specification including use cases.
DirServicesRequirements.doc

How do the different methodologies handle requirements?

Rational Unified Process (RUP)

Agile