Have you ever worked on something for a long time, only to realize in the end that you’ve completely missed the point?
I did. I once worked on the new feature of an insurance application that included multiple steps of calculations. We were already pretty close to the code freeze of current release and customer acceptance tests phase (yep, that was your typical waterfall). When I was finishing the implementation of some really tedious calculations I’ve started to notice that something just really doesn’t add up. It was the calculation described in the requirements document so I was happily implementing it. But the farther I went with the implementation the more incoherent it was with the whole system data. I went back to the customer to ask for the requirements. It turned out that the system didn’t have the flow they were looking for. We’d eventually agreed on something that worked, and then I made it work.
As you can see the communication of requirements can often result in an error. A requirement describes a need or want. Sets of requirements are used to capture the information required to design, build and test new software/software module. Unfortunately, those requirements are quite often vague, not cohesive, incomplete, inconsistent, incorrect, out-of-date, impossible to verify, fill-in-the-blank…
As a software engineer or developer, you ought to keep an eye of what the business wants. It is your responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built and to make sure that all ambiguity is removed from the requirements.
How to ensure you know what’s about to be built?
There are few questions, you can ask yourself when you see the requirement for the first time:
- Is it vague or is it specific?
- Does the requirement describe one and only one thing/functionality?
- Was it validated by the client/business matter expert?
- Does it correctly meet business goals?
- Is it consistent with the rest of the system or other requirements?
- Is it possible to implement given system/project constraints?
- Can it be verified?
Requirements are one of the most common communication issues between programmers and the business. So whenever you are just about to review or develop it remember to flesh out a requirement and remove all ambiguity from it.