Question- We already understand what the customer needs, why do we need to take up time with Requirements gathering?
Answer- You'll thank me later
Throughout my 20+ years working in all things functional in software development, I have painfully observed that when teams cut requirements gathering out as an official part of the development process, eventually someone pays the price. Even when software requirements seem glaringly obvious, there are often nuances that must be understood in order for software to effectively meet business needs. Ultimately, conducting a requirements analysis and review cycle will save time, money and frustration.
Connecting the Dots Between Software and Process
For one part of a multi-year effort on an enterprise system, we were tasked with taking over a relatively small legacy system that seemed very straightforward. Indeed, the software was- essentially, it was tracking all of a company's physical assets and where they were in the product lifecycle. There were less than 100 users of the system. Our development team was granted access to a test version of the legacy system containing sample data. They determined they didn't need the functional team to gather formal requirements- they 'got it'. This was a quick turnaround development effort, so management agreed with this approach. Our requirements team wrote high-level use cases, with very little involvement by stakeholders, or a formal requirements control gate. In addition, the company's Product Owner retired mid-way through development and was not replaced.
It was a perfect storm.
The weekend of the legacy data migration into the newly built system, I was called in to help validate the success of the conversion. I had spent the prior week at the company's facility, training users on the new system. Many of the system users had been in their positions for 10+ years and were less than enthused about the new system. I spent hours with two of their supervisors, who did the most data entry. During these shadow sessions, I realized there was a part of their jobs that was undiscovered by us, and it heavily affected the way certain data was entered. Procedurally, it was handled outside of the legacy system. But it greatly impacted how the data for a certain type of record was recorded.
On that Sunday after data migration, when I analyzed how the data had been converted into our new application, I realized the algorithm would not accommodate that specific data. The data did not convert properly. I will never forget the horrible feeling in the pit of my stomach upon realizing this. I picked up the phone and called our PM.
Ultimately, we had to roll back the deployment, redefine the data migration rules and delay the full replacement of the legacy system for 6 weeks. We had neglected to connect the dots between their processes and the new system.
Stakeholder Acceptance
In the scenario I've described, the stakeholder management team had approved the aggressive schedule, since the support for the legacy system has expired. The demo we provided the company, and the training I had done, used simple data examples. The specific use case for this more complex data was never known or recorded.
Spending time on requirements upfront may sometimes seem unnecessary, especially when an effort has been determined high priority. There are always legitimate circumstances that warrant an abridged requirements phase, especially in a mission-critical environment. However, even for simple software needs, development team management should advocate for a formal requirements phase where analysts have easy access to end users, ideally on their home turf. This will save time, money, frustration and potentially the reputation of the software team.