Software requirements was always an important part of planning and building a software. Build a good application starts with knowing the problem we want to solve and if it's really worth to build a fix for it.
Anyone with experience building software knows that the slowness problem on the building phase isn't caused by the engineers. The main responsible for it usually are bad specifications, focus on fake problems or on fixing/automating flows that no one cares. The software requirements engineering as a disciple focus on these questions and try to discuss these problems before anyone touches any code. It can help us answer why creating something, what needs to be done and for who. The phases of software requirements engineering are:
1. Viability Study
During the viability study pahse we want to know if the software or feature we are building is worth the work, time and money or not. This means understand if what we are proposing really helps our users and our company to achieve their goals.
For this we need to know what is the real problem we are targeting. Go deap in conversations and research to discover if the problem the user declares is really the problem he wants to see solved or automated. We also calculate the estimate time, effort and cost. To finish, we also calculate if it wouldn't give more return to the company to simply invest that money on another thing.
A software, to be worth to be built, needs to perform better than a low/medium risk investment and fix a real problem.
2. Requirements elicitation
After defining that it's worth to build a software/feature, the next step is to go deeper and uncover what are the necessary requirements that we need to work on to make that application exist. To do that, we need to know who are the users, what are their expected flows, ans what are the levels of quality they expect from the product.
For someone that knows a little more about software requirements engineering, this is where we should start discussing functional and non-functional requirements.
Functional: the requirements that implements functionalities expected from the user. Like adding a new user to the system; buy something; see the status of an item;
Non-functional: the requirements that don't implement functionalities expected by the user, but are responsible to define quality standards, security, performance, or to make sure the application follows any required laws.
With these definitions, we can start to question/answer better about the context the software will be inserted, who are the users, and what the app needs to do to to solve both the functional and non-function requirements.
To help answering those, we have tools like: creation of personas; interviews; questionnaires; user journey; prototypes; brainstorm. The tool that you should use depends on your team and the product you are trying to build.
3. Requirements specification
With the requirements uncovered, the next step is to specify them in a way to describe behaviors and restrictions expected to the software itself.
On this step, we are talking about the creation of Use Cases, User Stories, Business Rules, Acceptance Criterias, and Non-functional requirements.
Each of these documents helps us to understand how we should implement the software. On a world where we use LLMs and there are more LLM-assisted coding tools, these documents helps the tool to calculate better the paths and code it should follow. Each document answer different questions that we and a LLM-assisted coding tool can have.
Use Case: how a user interacts with the system step-by-step;
User story: who want a functionality, why and what are the details;
Business rules: which business guideline should be followed;
Acceptance criteria: defines if a functionality was correct implemented or not;
Non-functional requirements: what are the legal restrictions, quality, security, and performance standards the app needs to follow.
Other stages and conclusion
The next steps of the software requirements flow would be validation and prioritization, and requirements management. I won’t go into those today.
From the steps above, all were already important on the pre-LLM world. The steps helped us to mitigate errors and build a software that doesn't solve a real problem our users have. However, with tools like Claude Code and Codex, they are now even more important. Writting code has become an automated process and having good definitions is what separates success from failure.