Software requirements elicitation and specification

A software that no one is going to use is useless. You might have an awesome piece of code. Very well written, well developed, efficient, and practical, but people might not use it because it doesn’t serve any purpose to them. When developing software is important to keep in mind what is your software going to a port. Basically, defining the main requirements of the software. What it’ll do, and how it will be done. The IEEE Computer society defines requirements as following:

  1. A condition or capability needed by a user to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
  3. A documented representation of a condition or capability as in 1 or 2.


To gather the requirements, and other resources from stakeholders interested or related to your project. This is the first step for developing requirements from a project.


During the analysis of the information gathered during the previous step, developers try to get a clearer richer idea of each requirements.


Representing the gathered information in a well-organized matter. This makes communication easier, and ambiguity less common.


Confirm the correct set of requirements.


It’s normal for requirements to change during the project. It’s important to manage this changes.