After reading several of my past entries, one can conclude that some of the most important things in software engineering is the requirements analysis and the requirements themselves. In fact, this is the one post in which I talk even more about them. Why? Because requirements are a part of the software purpose. And developing software without a purpose is not only useless and illogical, but also stupid.
If you haven’t read any other of my articles, you might want to start here. Software requirements are requirements made by the customer and the public for a particular software to develop. They are not static: they can change, evolve in time. One day, the customer wants a rubber duck. Another, he wants a stone duck. Maybe one day he wants a laser gun.
The process to requirements is divided into 4 steps:
- Feasability analysis: Is it possible to be developed? Is the customer not asking for Godzilla?
- Requierement gathering: The team listens to the customer’s requirements.
- Requirement specification: This is the same that in past step, but more specific. Example: the user asked for a tool to make sales report. In this step, he says that the tool must have the funcionality to make reports by different dates.
- Requirement validation: After listening to the client, the team talks by itself and goes back to the client to check if the requirements are feasible, to check there are no misunderstandings, etc.
