The story of a simulation, with tight deadlines, and with a valuable lesson
A long time ago, when I was still in college, there was this course called “software engineering lab.” The idea was to create a working solution together with your fellow classmates, going through a full software development process, as realistic as possible. But what made this lab quite real, rather infamous, and absolutely memorable, was receiving the following notification so close to the final deadline:
“The requirements of the application have changed. Now it needs to work in a different way.”
Which can also be read as: “I don’t want what you’ve coded. Please, re-do it from scratch.“
The objective of this wasn’t to get people cursing in a creative way – which it also achieved. It was meant to prepare people to real software development. And with more than a decade of professional experience after these events, I can guarantee you that it was an on-target valuable lesson that I still remember.
Requirements change, because users’ needs evolve. But also a flawed perception of your users’ real needs will result in eventual changes in the requirements specifications. The takeaway lesson is that only by understanding your users’ requirements you can deliver solutions that would please them.
After all, you can only see the solution if you can see the problem.
This is precisely what requirements engineering is about, and what makes it so important.
How requirements engineering applies to your projects, in plain English
So delivering a successful solution requires understanding what your users need. Even more than a decade ago, I also found this part of the software engineering process fascinating, and that’s why one of my first projects would revolve around Quality Assurance and Requirements Engineering.
It might sound complicated, but it was really insightful for me, as it gave me an effective structure to enhance how I understood my clients. It improved all my software development workflow. Since those days, I keep this structure – and my final users’ needs – in mind during the whole development process.
And it pays off.
For many companies, all this requirements engineering process starts by identifying their own high-level business goals. The functions that my software application will perform will have to be aligned with these business goals.
Then, it is essential to find out what is the target market of that application, or basically, who will be the main users of such software. By defining their key use cases and interactions, and by following with drafts and wireframes, I will also have a roadmap of what the system should do for them.
All this information is worth keeping in mind throughout all the process, because this will guarantee successful validations in all our agile development iterations. My code will do what my final users expect it to do.
The better I can understand the end users of an application, the closer we will be to a final, successful software deployment. And that’s essential, because it means time, money, and client satisfaction.
I’m ready for this. Now, tell me about your project.