Identifying what the people involved want the piece of software to do. They can be described as what problem you want the program to solve. Wikipedia lists 4 key steps:
- Elicitation: Finding out what your software should and shouldn’t do. Interviews, workshops, brainstorming, and role playing are used in this step. You should get input from users and customers.
- Analysis: More precise interpretation of the requirements from the first step.
- Specification: Organizing requirements in a way that facilitates communication. This step includes defining functional and non-functional requirements. Once listed, requirements need to be validated.
- Management: Final agreement on the requirements and tracking progress on getting it done.
TutorialsPoint also lists what characteristics should be met when done with the process:
- Clear
- Correct
- Consistent
- Coherent
- Comprehensible
- Modifiable
- Verifiable
- Prioritized
- Unambiguous
- Traceable
- Credible source
These give you an idea of what one may do with requirements.
Modifiable is, to me, the most interesting one. Changing requirements later on agrees with the idea that software can’t always be made following a simple list of steps. As the project develops, old requirements can be changed and new ones added.
