Well, a few days ago a developer colleague asked on Twitter: “how to reduce costs in software development process?”, this question made me think about all the steps in producing a software and making him available to the customer. After thinking about it a while I came to the following response: “the best way should be doing a great requirement engineering process” and now I will show to all you readers what made me answer that.

On first, what is Requirement Engineering?

Nowadays the Agile Movement take a great space into software development culture, with its many advances in delivering high quality software with time-to-market asked in the customer segment. But, as Fred Brook precisely said in The Mythical Man-Month: “There is no silver-bullet in software engineering”. Exactly as he said, Agile culture is a great advance in this engineering but with its gain comes the price, many software engineers visioning the agility and time-to-market pressure takes the requirement engineering process to a second order. What a big mistake!

According to Ian Sommervile, in his Software Engineering book, this process is defined as : “the first stage to be done in the software engineering process”. In fact, this step is done mostly in Scrum or Kaban with the term “technical refinement”, but many just skip the step “functional refinement” because thinks it a step only to satisfy stakeholders thoughts, and here lives one of the big mistakes in software development. Well, we can refine technically the most as we can, but if it doesn’t satisfy stakeholders it won’t serve. So as the opposite works, if stakeholders think a big project, in many cases it will just be unfit for just one project and should be break into two or more. In any cases, the fault of a well-done functional refinement will lead into a more expensive process, the technical refinement will take more time than expected and result in more doubtful requirements that obligates the team to stop and revisit it in the future.

By its time, a confusing and bad-done technical refinement will take to a bad software modeling and a not efficient architecture, summing it together we have the recipe to more costs into developing process and as consequence the software will probably have a larger memory consuming than it should, what in a Cloud Computing perspective means more money wasted.

In my words I usually say: “Requirement engineering process is the fundamental to spend less money in software engineering”.

So, what would I do to do better in it?

To be honest, there is no cake recipe, every company, every department, every squad has its own differences and dynamic. But you should take the following advice with you: Do not fear in taking a considerable time in this process. See, many projects that I participated focused it’s time in codding. I should suggest you the following as an experiment: invert it. Focus many part of it in refining and mapping requirements, negotiates it with the stakeholder and in the end you will write less code and the stakeholders will spent less money too. Happy ending !

Jokes apart, we know that stakeholder’s pressure are a real pain in many cases, so if you need to do daily reports, I should suggest you spent about 30% of the project time in this step. Define with clarity and objectively the non-functional and functional requirements, the business rules too, and attaches them to its following history, you should spend like one week to one refine one-two history and discover all its requirements and demands.

As you do the refinement, produces in parallel artifacts and documents about it, UML diagrams, requirement documents ( do not bind yourself in the waterfall model, create a template that should take only the essential about the requirements), record meetings and then in the final produce a final report that should map the UI with the followings requirements, talk to the other necessary areas and then do a final meeting, after that you are clear to code.

Taking those steps in mind, developers will not only have less stress than more money will be saved and the success project chances will increase considerably.

Thank you!

Thinking about software engineering, have you already asked yourself: “Why should I still care about doing a colleague”? Check this article !